Language Selection

English French German Italian Portuguese Spanish

Site Map

Blogs

Community blog and recent blog authors at Tux Machines.

Forum

forums

content

blog

More in Tux Machines

Compiling Krita for ARM: an AppImage tale

Someone on #krita, can’t remember their exact nick, asked if it was possible to run Krita on ARM-based computers, specifically the Raspberry Pi 3B+. AFAIK, no one has tried to do so, so I will tell you: yes, it is possible! (Although it will run as slow as a turtle!) This work took me the whole weekend, but it was an excellent experience as well as a wonderful way to test our infrastructure. A key warning before moving on: DO NOT TRY THIS ON YOUR PI. It will be unbearably slow I built mine with a Ryzen 7 with 12 threads and it still took me two 12-hour shifts! This post covers three steps: setting up the build environment, compiling the dependencies and Krita itself, and finally packaging the AppImages themselves. As per the official instructions, we’ll target Ubuntu 16.04 ARM. I chose the armhf port to match the Raspberry Pi’s default distro, Raspbian. I also tested aarch64 – see the last section for the necessary changes. Read more Also: Wasabi character design

The Supercomputing Monoculture

But that very competition led to fragmentation. Alpha, MIPS, SPARC, and all the others each sold to a small niche of users. Meanwhile, Intel was selling x86 processors by the truckload to every PC maker on the planet while backing up forklifts full of cash into its bank vaults. The x86 franchise was an obscenely lucrative cash cow, even if some engineers ridiculed it as outmoded technology. Intel sold more processors than all the other vendors put together. And CPU development is expensive. Very expensive. One by one, the boutique CPU makers (Sun, Digital, Silicon Graphics, Intergraph, et al.) gave up on their in-house designs and started buying commercial processors, often from Intel. And, one by one, those companies failed anyway. PCs running Windows on x86 were ubiquitous and cheap. Artisanal Unix workstations running proprietary RISC processors were expensive – and not much faster than a PC anyway. The full-custom route just didn’t add up. The huge uptake in x86-based supercomputers starting around 2005 wasn’t because Intel chips got a lot faster (although they did). It’s because most of the other competitors defaulted. They left an empty field for Intel to dominate. If the brains behind Alpha (to pick just one example) had had Intel levels of R&D money to work with, they probably would have stayed near the top of the performance heap for as long as they cared to. But that’s not reality or how the game is played. If my grandmother had wheels she’d be a wagon. Now the same story is playing out again, but in ARM’s favor. ARM has the volume lead, beating even Intel by orders of magnitude in terms of unit volume. And, although ARM collects only a small royalty on each processor, not the entire purchase price, it also doesn’t have the crushing overhead costs that a manufacturer like Intel carries. ARM’s volume encourages a third-party software market to flourish, and that fuels a virtuous feedback loop that makes ARM’s architecture even more popular. There’s nothing inherently fast about ARM’s architecture – it definitely wasn’t designed for supercomputers – but there’s nothing wrong with it, either. If the x86 can hold the world’s performance lead, any CPU can. All it takes is time and volume. Read more

Security: Remote (Home) Work, Patching OpenSSL and GNU C, IPFire on AWS

  • Security when you're suddenly remote

    Imagine a scenario where forces outside of your control have suddenly made it impossible for people to be in close proximity to each other, forcing them to vacate their offices but somehow continue "business as usual." This upheaval of daily life is all to help limit the spread of a virus that is spreading across the globe. It sounds like the opening scenes to a sci-fi movie, but it's our reality. In late January here in the US, and earlier in many other parts of the world, the global pandemic known as COVID-19 forced authorities to respond by recommending and/or requiring that we all stay at home and avoid non-essential contact with people outside of our households. This, of course, makes it very difficult to maintain a business. If you're reading this blog, you're probably either already working in IT or adjacent industry, or you're considering it. Most IT workers have the ability to think and work at a keyboard all day, no matter where they're geographically located. Other than a few datacenter roles that require you to be physically onsite, most IT jobs can be done from anywhere in the world. That also goes for most of the support, customer service, billing, and even human resources roles at an organization.

  • Patching OpenSSL and GNU C Libraries Without Service Restarts

    According to the 2020 Global Threat Intelligence Report, “cyber-attack volumes increased across all industries between 2018 and 2019.” Web shells, exploit kits and targeted ransomware are just a few tools that bad actors use for attacks. Mostly, such attacks are still successful due to organizational practices related to networks, operating systems and application configurations, testing, security controls and overall security posture. Attackers are still trying to exploit vulnerabilities which are several years old and have patches available, but nevertheless are not being addressed by many organizations’ patch and configuration management programs. Persistent exploitation of old and famous vulnerabilities such as HeartBleed (CVE-2014-0160) make OpenSSL the second most targeted software technology involved in 19% of hostile activity globally. According to researchers, OpenSSL was the most targeted technology in both the manufacturing and technology industries.

  • IPFire on AWS: Update to IPFire 2.25 - Core Update 146

    Today, we have updated IPFire on AWS to IPFire 2.25 - Core Update 146 - the latest official release of IPFire. Since IPFire is available on AWS, we are gaining more and more users who are securing their cloud infrastructure behind an easy to configure, yet fast and secure firewall. This update brings a new kernel as well as many other exciting changes.

Graphics: AMD GPU, Libinput, Intel's Elkhart Lake

  • AMD's Next-Gen Navi 22 'Navy Flounder' GPU Spied In Latest Linux Driver Release

    There's a new Linux driver release that contains a reference to an upcoming AMD graphics processing unit (GPU) codenamed "Navy Flounder," and now I can't get that Pinkard & Bowden song out of my head. You know, the fishy one titled, "I Lobster But Never Flounder." Yeah, don't judge, click that link and it will be stuck in YOUR head as well. You're welcome. But I digress—I'm not here to discuss goofy country songs. This is all about AMD's upcoming Navi launch, which is underpinned by the same second-generation Radeon DNA (RDNA 2) architecture that will power both Sony's PlayStation 5 and Microsoft's Xbox Series X consoles, as well as a new round of Radeon graphics cards.

  • Libinput 1.16 Will Warn You If Your System Is Too Slow

    It's been over a half-year already for the current libinput 1.15 series for this input handling library used on both X.Org and Wayland environments. But libinput 1.16 is finally en route with the first release candidate out today. Libinput 1.16 has been baking a while due to no pressing features that needed to be shipped right away and seeing a number of 1.15.x point releases. Coming with this new series for libinput are: - Monitoring of timestamps compared to when the libinput dispatch function is called by the compositor. If the difference is too large that it could result in issues for input processing, a new warning is displayed in the log that the event processing is lagging behind and the system is "too slow."

  • Intel Adds More "Elkhart Lake" IDs To Their Linux Graphics Driver Code

    Two new PCI IDs were added for Elkhart Lake and two for Jasper Lake graphics that are in new hardware configurations as well. The new 0x4555 is Elkhart Lake graphics in a two subslice configuration with eight EUs per subslice along with a similar 0x4E55 addition for Jasper Lake with the 2x8 configuration.. The two other new IDs are 0x4557 and 0x4E57 for Elkhart and Jasper, respectively, that are for a four subslice configuration with five EUs per subslice.