The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system’s runtime libraries, and they now all use containerization to accomplish this. Flatpak calls itself “the future of application distribution”. I am not a fan. I’m going to outline here some of the technical, security and usability problems with Flatpak and others. I’ll try to avoid addressing “fixable” problems (like theming) and instead focus on fundamental problems inherent in their design. I aim to convince you that these are not the future of desktop Linux apps. I fully agree. If you’re a Linux application developer, packaging your application up as an RPM and DEB is really all you need to do; you’ll cover by far the most desktop Linux users, and your code will most likely be packaged up by package maintainers of smaller package management systems as well. All these “solutions” just add additional layers of confusion, bloat, issues, and bugs that can be easily avoided by sticking to your distribution’s own package manager. I simply avoid any application packaged up in any of these formats – with the exception of Steam – and move on to something from a developer who does understand and care about desktop Linux.
Let’s say you got your filthy hands on an ISO of Red Star OS Desktop 3.0 (like, 5 years ago but you forgot about it). The obvious next step is to install it on your main computer and give it access to the outside so it can spread love and goodness. Just kidding, install that motherfucker in a virtual machine (VirtualBox, VMware, etc), just because. These articles looking at North Korea’s Red Star OS pop up every few years, and they’re always a fun read.
As you’d expect, Linux 5.15 includes an impressive itinerary of improvements. These range from small fixes at lower levers through to major restructuring of core functionality. The following roundup highlights the additions that caught my interest/eye but is by no means an exhaustive run-through. The biggest new feature is the new NTFS driver, but there’s a lot more in this release, such as an in-kernel driver for SMB, and more Apple M1 support, to name a few.
Chimera is a Linux distribution with the following goals: – Built entirely with LLVM– FreeBSD-based userland– Binary packaging and a well designed source build system– Bootstrappable– Portable This project is still very early in its development, but it’s an interesting premise. It’s developed by Daniel Kolesa, who also contributes a lot to Void Linux, most notably the excellent POWER/PowerPC port of that excellent distribution. Over on Twitter, Kolesa regularly posts updates on the status of Chimera, and even though some of the stuff definitely is above my pay grade, it’s quite interesting to follow along.
It’s been a busy month! We’ve had a lot of movement in kernel land, as well as some tooling improvements and reverse engineering sessions. At this point, Asahi Linux is usable as a basic Linux desktop (without GPU acceleration)! The ground had been shifting until now, but we’re seeing drivers settle down. Let’s take a look at what’s been going on. Linux on Apple’s M1 Macs is making progress, but I would never buy an Apple computer to run Linux on it. It’s always going to be a moving target without any documentation or support – official or tacit – meaning you’re basically running a perpetual reverse-engineering effort. To make matters worse, Apple can flip the switch and block any non-macOS operating system at any time. The M1 is impressive, but only if you’re into macOS.
Btrfs—short for “B-Tree File System” and frequently pronounced “butter” or “butter eff ess”—is the most advanced filesystem present in the mainline Linux kernel. In some ways, btrfs simply seeks to supplant ext4, the default filesystem for most Linux distributions. But btrfs also aims to provide next-gen features that break the simple “filesystem” mold, combining the functionality of a RAID array manager, a volume manager, and more. We have good news and bad news about this. First, btrfs is a perfectly cromulent single-disk ext4 replacement. But if you’re hoping to replace ZFS—or a more complex stack built on discrete RAID management, volume management, and simple filesystem—the picture isn’t quite so rosy. Although the btrfs project has fixed many of the glaring problems it launched with in 2009, other problems remain essentially unchanged 12 years later. One of those projects we’ve been hearing about for years. I think most distributions still default to ext4 – except for Fedora.
A WSL alternative for users who prefer an MS-DOS environment. DOS Subsystem for Linux integrates a real Linux environment into MS-DOS systems, allowing users to make use of both DOS and Linux applications from the DOS command prompt. What is this unholy union.
Version 5.14 of the most popular operating system kernel in the world has been released. See the Linux 5.14 feature list for a comprehensive list of the changes in this new kernel version. Some of the Linux 5.14 highlights include core scheduling support, secret memory areas support with MEMFD_SECRET, continued enablement around Intel Alder Lake, Yellow Carp and Beige Goby AMD graphics support, AMD SmartShift laptop support, Raspberry Pi 400 support, and more. Linux 5.14 has the usual mix of new hardware support, improving existing features, and adding in other new kernel innovations. Coming to a distribution near you.
Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection. Void Linux is one of my favourite distributions, but since it employs a rolling release model, I never really get the opportunity to highlight it. So, I’m picking this random day to talk about it. If you’re fairly proficient in “install and go” Linux distributions like Ubuntu, Fedora, Manjaro, etc., and want to get a better insight into a Linux system without going overboard, Void is a great choice. It’s easy to install, easy to grasp and manage manually because it eschews systemd in favour of runit, it has an excellent community, and the package repository is far, far larger than you’d expect. Void also offers both GNU libc and musl versions. Void is a bit more hands-on than e.g. Ubuntu, but not over the top like some other distributions. Setting up a Void Linux system will teach you quite a bit about how a Linux system works, but the no-nonsense, logical layout of it all means you’re not going to be overwhelmed. It also happens to be one of the few distributions that take ppc64le seriously thanks to a dedicated community, so it’s my system of choice there. It’s not for everyone, and if you just want a no-nonsense desktop experience with minimal fuss, you’re better off with Linux Mint or Manjaro or similar systems, but if you want to get your hands a little bit dirty, you can do a lot worse than Void.
Asahi Linux, the effort to port Linux to Apple’s new M1 SoC, has posted its second progress report. It’s been a long time since the last update! In all honesty, the first Progress Report set the bar a little bit too high, and I found it difficult to sit down and put together monthly reports that would do it justice. So, going forward, we’re going to be providing shorter-form updates while striving to keep a monthly schedule. That said, a lot has happened in the past few months, so strap in for a bigger update this time! Quite a lot of detail in here, and lots of insights into the reverse engineering processes the developers are implementing.
It’s no secret that the ACPI CPUFreq driver code has at times been less than ideal on recent AMD processors with delivering less than expected performance/behavior with being slow to ramp up to a higher performance state or otherwise coming up short of disabling the power management functionality outright. AMD hasn’t traditionally worked on the Linux CPU frequency scaling code as much as Intel does to their P-State scaling driver and other areas of power management at large. AMD and Valve have been working to improve the performance/power efficiency for modern AMD platforms running on Steam Play (Proton / Wine) and have spearheaded “ was not very performance/power efficiency for modern AMD platforms…a new CPU performance scaling design for AMD platform which has better performance per watt scaling on such as 3D game like Horizon Zero Dawn with VKD3D-Proton on Steam.” Valve has single-handedly made Linux a viable choice for people who play games, and with the Steam Deck on its way, their efforts are only going to ramp up. They’re doing this for their own bottom line, of course, but this is one of those cases where a corporate interest lines up perfectly with a consumer interest.
As a weekend blast from the past, the Linux 5.14 kernel saw some Alpha CPU architecture updates — including various fixes and the removal of an Alpha-specific binary loader for running a decades dated x86 software emulator. While past the merge window, the Linux 5.14 code this week has dropped “binfmt_em86” from the kernel. This is an Alpha binary loader for Linux focused on running i386/i486 binaries via the EM86 emulator in user-space. This was part of the effort for allowing Intel Linux x86 binaries back in the day to run on DEC Alpha hardware. How will I run x86 Linux binaries on my AlphaServer ES47 now? What a preposterous commit. Linux is definitely going down the drain.
First thing to understand about Mariner is that is not a general purpose Linux distribution like Ubuntu or Fedora, it was created by Microsoft’s Linux System Group which is the same team at Microsoft which created the Linux kernel used for Windows Subsystem for Linux version 2, or WSL2. The goal of Mariner is to be used as an internal Linux distribution for Microsoft’s engineering teams to build our cloud infrastructure and edge products and services. Of course Mariner is open source and it has its own repo under Microsoft’s GirHub organization. No ISOs or images of Mariner are provided, however the repo has instructions to build them on Ubuntu 18.04. There are a series of prerrequistes listed in this GitHub page that roughly include Docker, RPM tools, ISO build tools and Golang, amongst others. Not surprising, of course, but still quite interesting to poke around in.
In this post I’ll try to explain PipeWire in the most simple way possible, to make it accessible to others that want to start following this cool new project but that don’t know where to start. It’s especially important to do this to open the door for more people to join in and follow the current development, which is happening at a fast pace. PipeWire is making its way into the generic Linux desktop market, so now is as good a time as ever to gain a better understanding of what it is and how it works.
Google wants to see Rust programming language support within the Linux kernel so much so that they have contracted the lead developer working on “Rust for Linux” as the work aims to get mainlined. Google is going public today with their formal support for Rust in the Linux kernel to enhance memory safety and that they have contracted developer Miguel Ojeda to further his work on Rust for the Linux kernel and related security efforts. This contract is going through at least the next year. Making any meaningful statements about programming languages is far above my pay grade, so I’ll leave this one to you people to discuss.
Linux 5.12 brings Intel Variable Rate Refresh (VRR/Adaptive-Sync), Radeon RX 6000 series overclocking support, mainline support for the Nintendo 64, the Sony PlayStation 5 DualSense controller driver, CXL 2.0 Type-3 memory device support, KFENCE, dynamic preemption capabilities, Clang link-time optimizations, laptop support improvements, and much more. A decently sized release. My favourite is definitely adding N64 support to the kernel.
A statement from the University of Minnesota Department of Computer Science & Engineering: Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical. This story is crazy. It turns out researchers from the University of Minnesota were intentionally trying to introduce vulnerabilities into the Linux kernel as part of some research study. This was, of course, discovered, and kernel maintainer Greg Kroah-Hartman immediately banned the entire university from submitting any code to the Linux kernel. Replying to the researcher in question, Kroah-Hartman wrote: You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems. This is obviously the only correct course of action, and the swift response by the university is the right one.
Although we don’t expect to see a full implementation of the Linux kernel in Rust anytime soon, this early work on integrating Rust code into the kernel’s C infrastructure is likely to be very important. Both Microsoft and the Linux community agree that two-thirds or more of security vulnerabilities stem from memory-safety issues. As software complexity continues to increase, making it safer to write in the first place will become more and more important. Torvalds’ pragmatism is one of the key reasons for Linux’ success, and I have no doubt his position and opinions on Rust in the Linux kernel will turn out to be the right ones.
The community around Linux phones is interesting. The phones do sell to a lot of people, but it seems a lot of those people come back to complain that Linux phones isn’t what they expected it is. For some reason all the distributions for the PinePhone are bending over backwards to provide an Android or iOS experience on the phone. The operating systems are judged on the amount of apps preinstalled and every tiny issue labels the distribution as completely unusable. Stability doesn’t matter at all, as long as there are features! more features! Doesn’t matter there are 20 patches on top of every package and things aren’t upstreamed. Doesn’t matter if the kernel is full of hacks with no upstream in sight for most things. The currently available ‘true’ Linux phones do not seem to be, well, any good. They’ve got a lot of work ahead of them, and anybody expecting a fully functioning smartphone experience from the PinePhone or Librem 5 will be disappointed. I have no clue about possible solutions to this problem.
One of the most important tasks of the distribution packager is to ensure that the software shipped to our users is free of security vulnerabilities. While finding and fixing the vulnerable code is usually considered upstream’s responsibility, the packager needs to ensure that all these fixes reach the end users ASAP. With the aid of central package management and dynamic linking, the Linux distributions have pretty much perfected the deployment of security fixes. Ideally, fixing a vulnerable dependency is as simple as patching a single shared library via the distribution’s automated update system. Of course, this works only if the package in question is actually following good security practices. Over the years, many Linux distributions (at the very least, Debian, Fedora and Gentoo) have been fighting these bad practices with some success. However, today the times have changed. Today, for every 10 packages fixed, a completely new ecosystem emerges with the bad security practices at its central point. Go, Rust and to some extent Python are just a few examples of programming languages that have integrated the bad security practices into the very fabric of their existence, and recreated the same old problems in entirely new ways. This post explains the issue packagers run into very well – and it sure does look like these newer platforms are not very good citizens. I know this isn’t related, but this gives me the same feelings and reservations as Flatpak, Snap, and similar tools.