TL&DR

The Linux landscape is looking lit

Why

Tooling around creating/customizing Linux distributions is reaching broad production quality. systemd, mkosi, virtme-ng, virt-manager are all changing the face of distribution creation and the distribution landscape is going to radically change as a result of this. Further tooling like distrobox/toybox makes living with an immutable Linux base very plausible.

I spend a fair amount of time in yocto land; much like gentoo, you are starting from a rather low level, so arriving at a modern distribution requires a fair amount of time/effort/coordination and you need to solve incredibly high level issues at the same time as low level issues are eating your face. When I was consulting, I delivered 2 discrete a/b partitioned OSes to different customers; both were provisioned using docker with partition selection being handled of a modified version of systemd-bootd (formerly known as gummiboot).

a/b partitioning is kinda trivial to implement when shipping appliances, and I remain convinced that the modern distribution that gets this right is going to sweep the board. Why should an OS update require any protracted work on the part of the receiving machine. The only valid case I can see is where the structure of the OS fundamentally changes, which is reasonable when the OS is in flux and only when the OS is in major flux. The common path should take the length of a standard reboot. Somehow Windows makes every update I ever installed some Sisyphean task. Traditional distributions like Fedora and Ubuntu have these discrete (non rolling) junctions where their dependency graph needs to be broadly revisited, and with Ubuntu at least I have felt this sting on more updates than not. Managing a fleet of appliances running Ubuntu as the underlying OS is something you only think is a good idea once. The more power user you try to be, the larger the dildo of consequences lurking in yonder shadows. Hell, even Mac OS, the technical gold standard manages to burn something like 10-20 min updating itself. Chrome OS might get this right, but a glorified browser appliance is not a really fit for an apples to apples comparison with real OSes.

Sorry, to clarify, this is trivial if you remove corner cases. The corner cases I removed in the past were non-EFI and grub. Grub might be a perfectly nice piece of software, but I hate it with a passion and Fedora’s continued use of it makes me want to bite them. Over in Arch land, any sane person has been living with systemd-bootd and bootctl. EFI puts amd64 devices on the same footing as uboot devices, and in these contexts you are not going to get a Nobel Prize for implementing a/b partitioning in this context.

systemd-bootd is highly readable by the by; that is an easy project to recommend the curious to consume.

To be clear, there is no argument being made against traditional distributions/package management. The argument being made is that these should be discrete from the core system you boot into, which basically can and should be decoupled from your litter/sandbox. Similarly, why the hell is my desktop machine going to fail to root, because some async service happened to fail. This makes no sense, yes this falls out of most modern distributions.

When my machine boots, I want to decrypted my data, then I want to be able to execute on intent. I need a graphical environment to be effective on that front. Then once I am operational and executing, I am happy if my machine continues to spin up any infrastructure I maintain, and reports issues with said infrastructure to me. To prevent me reaching my window manager is very clearly putting the cart before the horse. Even better again, leaving you to debug your inferno with 80 columns of character, or inside a hobby horse initramfs env.

In this booted env, I will happily start different terminals which spawn in different distrobox environments, where I can relish the traditional clusterfuck model every Linux user knows and loves. Distrobox allows applications to be exported, provisioning desktop files, giving KDE visibility of your plethora of pet apps beyond those provisioned in the immutable base image.

On this front, it is kind interesting to see initramfs’ still exist as discrete entities. I dont want a duplicated subset of functionality between my rootfs and my initramfs, especially not some provisioned subset of modules which might leave me in the lurch. The kernel should start a minimal env which contains the entirety of /lib/modules, and this should find its way into my final booted system. There is still complexity here which stands to be addressed, and kde-linux decouples from mkosi at this point doing manual provisioning of the efi initramfses.

What are the upsides?

  • No more opaque automatic launching of background bullshit for every installed desktop env. I tend to have Gnome installed, but I am non-chuffed and surprised to see the plethora of crud that is launched implicitly by the existence of desktop files. In modernity, it is too easy to have background services roped for the ride, requiring you to debug and investigate to identify and neutralize, where neutralizing often requires uninstalling crud and fighting a dependency graph
  • No need to bask in the glory of a wiki; most configuration goes into tampering with the base system/configuration and a lot of things can be addressed once for a fixed audience with shared interests
  • Reproducibility: Sure, configuration lives in home and is allowed to roam, but by locking down your base image whole swathes of problems become a shared problem.
  • A factory reset should drop you back to a fresh install; your system is automatically running the image and base configuration you want. You lose your data, home, you booting to the onboarding configuration of the distro of your choice
  • Or booting into a full fledged OS to debug the absence of your home partition. I know being crapped out into initramfs with 80 col chars, 10 min before a customer meeting is exhilarating, but this kinda BDSM is counter productive.

Immutable Linux Contenders

  • particleos - the reference OS made by the authors of mkosi. I got the installer booted and the OS installed once in virt-manager and only once. Having completed the install, it failed to find /usr. (or was it root). I am clearly too stupid to be its audience.
  • openSUSE Aeon - shipping! Functional distrobox and other tooling, which makes the idea of replacing your existing distro with something with an immutable rootfs feasible. Gnome centric.
  • kde-linux - Also shipping! I have now installed this in virt-manager and on baremetal hardware. Uses mkosi to a limited extent, and a limited extent which continues to function when the rest of mkosi blows up. Good show. Gets OTA updates! I love KDE (at this point) and this looks really well positioned to get a lot of stuff normally half arsed implemented out of a wiki (if you have infinite time) baked into the base system. Not only
  • bazitte - highly praised immutable steam OS alternative. Bootc based. Looks powerful, and hence a little complicated. rollback info

Opinionated Distros

  • Omarchy - Arch, with Hyprland dialed in and web pages as first class citizens. Addresses the last mile problem regarding usability. The bit distributions have kinda consistently failed at, probably under the assumption you are a sim player and want to spend your life attaining some semblance of usability.