Continued from Part 3:
So far this series has been about desktop containerization. What about the title? IMMUTABILITY! Many people run containerized desktops without even thinking about it. Perhaps 99% of their computing time is with Firefox from Flatpak (for its no-fuss codec support) and Steam packaged by their distro (where Steam then manages the containers for Linux and Windows games transparently). Or, perhaps a developer spends 99% of their time inside a Docker container or nix-shell. Their desktop is running something like Mint or Void or Manjaro, but almost everything they use is containerized. If this works so well, why then create immutable distros for the desktop?
There are several reasons:
1. In an immutable distro every file in the system is accounted for, either by the system image pushed from the distro maintainers (as in SteamOS), or by the package management system (as in Silverblue). There are no rogue files anywhere in the base system.
2. Since there is essentially no deviation from the system image (or the deviation is managed by a package system with absolute control) each install of the distro is identical to every other install of the distro. Thus, the “it works on my computer” support problem is greatly minimized.
3. An update takes a system from a known-good configuration to a new known-good configuration. There is no “hope it works” with updates to an immutable distro.
4. System updates can be fully atomic. Since the base system is so tiny (including virtually no applications at all), multiple copies can be kept. Updating the system creates a new copy with those updates. Because it is updating so little this process can be fast, and can take place without user intervention. When the system is rebooted the bootloader boots into the new copy, but with the old one still intact. If the update fails for any reason (including power failures) the previous version of the system is untouched. The system update either succeeds completely, or no change is made. While the update is in progress the system is not a mix of old a new libraries and files. It's either all the previous version, or upon reboot all the updated version.
5. If there is any problem with the updated software (bugs, regressions), the user can do an instant roll-back to a previous version of the OS.
6. Distros can (if they wish) use image-based system updates rather than slower package-based updates.
7. Security – it is much harder to attack a system that has a read-only filesystem.
For some uses, an immutable distro is the only realistic choice (the Steam Deck comes to mind here). For a regular desktop user, the ability to have atomic updates and instant rollbacks may very well be worth the restrictions. If everything on the desktop is run through container management software anyway, why not take the added reliability of an immutable distro?
So – why have there been so many forum posts about trying an immutable distro and being frustrated with it? I suspect the answer is a combination of two issues. First, there are still parts of a typical Linux desktop experience that requires the ability to modify a file somewhere in the base system. For example (one of many), CUPS has some elements of its printer drivers in /usr/lib/cups/filter. If someone wants to add a filter to support their printer they have to be able to write to that directory. Likewise, SDDM has its themes stored in a system directory, and a user needs write access to that folder to do things like change the login background image. Some kernel module systems are friendly to immutable distros (AKMOD) while others are not (DKMS). If a user needed to be able to write to the system image and used a distro that took on a more restrictive model for immutability (like Silverblue), they would be understandably annoyed. “All I need to do is drop this file into that directory! It would be so easy with a normal distro! Why am I bothering with this thing???” They could use a distro with a less-restrictive model for immutability (like Aeon, for example) and perhaps get around the issue. Or, there are likely users for whom any immutable distro would be the wrong choice because they have software that needs to be able to write to system directories in order to function properly. I think that set of software is shrinking, but if you are that user that needs it, just stick with a traditional distro and don’t worry about the immutability thing for now. You still get the benefits of containerization to the degree you use that technology.
The second issue that causes frustration is a fundamental misunderstanding of how the distro is designed to function. When the Steam Deck was released and users started playing around with its Desktop mode, they quickly discovered that since it supported Flatpaks they could install nearly all the software they needed for a functioning desktop computer. There are people out there that plug in the Deck to a USB hub and use it as their primary desktop computer. This is a system with a fully immutable OS. The only way to make changes to the system image is when Valve pushes a new update. But with Flatpak and the Plasma desktop, they were installing Firefox, OBS, GIMP, Blender, Chrome, Spotify, Discord, Dolphin, DOSBox, etc… Since the hardware was fully supported by the OS there was no need to install any drivers – just the desktop applications. Essentially, these users embraced the containerized desktop because that was the only way to install software on SteamOS.
Unlike SteamOS, nearly all of the immutable distros allow the user to make changes to the system. Silverblue can layer packages (even ones from RPM-Fusion or random .rpm files the user wants to install) into the system image. It makes major-version updates more difficult, but Silverblue will allow you to install whatever RPM you want (as long as it conforms to their requirements, such as no DKMS). Likewise, VanillaOS will let you add in whatever .deb you want into the base system. Aeon will happily allow you to run arbitrary commands to influence the next system snapshot. Each one of these distros’ maintainers strongly suggest that you not do this (and the Aeon website says not to bother with a support request if you do and the system breaks). But they will let you, and there are good reasons to allow it (hardware drivers being a prime example). But it should be done sparingly.
Proper usage has some gray area here. I use Microsoft OneDrive for cloud storage, and the Linux client I was using could be installed as an RPM or run in Docker. I’m lazy, so when I was using Silverblue at work I just layered in the RPM. It probably would have been worth the time to learn how to do it through Podman, but I didn’t want to be bothered with it at the time. I encountered no issues with this setup other than needing to un-layer it when upgrading to Silverblue 37 and then re-layering it. I didn’t do it the wrong way, just not the most optimal way given the immutable distro’s design. However, I hear people saying that they want to layer in some long list of packages into Silverblue and are annoyed that the updates take a long time, and that they have to reboot every time they want to update Firefox, and it’s just a hassle compared to regular Fedora. And – if that’s the way someone is using it, they’d be right! But that’s not how it’s meant to be used.
Naturally, there may be some reason you want a particular application layered into the immutable base image. If that’s the case, Silverblue (and nearly all the others) will allow you to do that. It’s not going to second-guess your reasons for having that particular code editor (or whatever) as part of the immutable base. But – and here's the big question - wouldn’t you rather have it running inside a container instead? Isn’t that nearly always (apart from hardware drivers) the better way?
And this brings me to the primary reason to go down the containerization route – most of us are using Linux desktops because we are what used to be called “power users” – we want the maximum degree of flexibility and customization when we use our computers. This is a community that has passionate debate about the superiority of tiling window managers vs desktop environments, and spirited discussion about different init systems. Just the other day I was using some new software on github that required very specific versions of python and node.js. It was experimental software and had quite a few esoteric dependencies. The developer had helpfully provided instructions for getting it running on the last Ubuntu LTS. Now, since I wasn’t planning to switch to the Ubuntu LTS I had a choice – I could run the application in a VM with that version of Ubuntu, or I could try to get all those dependencies sorted out on my computer, or… I could do what a normal (the new normal) person would do and spin up a Ubuntu LTS container through Distrobox, follow the instructions, and let that be it. If it didn’t work correctly, or caused that container to have issues, I could simply delete the container without any changes to my system. Why worry about whether that version of the dependencies would cause trouble for my system? In other words… after getting used to running everything in containers, I wonder why I would do it any other way.
I completely understand those who have desktop machines that are tightly RAM or storage-constrained. The extra disk space for the Flatpak runtimes might actually be a dealbreaker. My example of Freyr above weighs in at 56mb for the docker container image. For some uses, that may, without irony or sarcasm, be too large and unacceptably bloated. And if that is the case, the good news is that the market for lightweight, highly efficient distros is still healthy and shows no signs of dying out. For those with “modern desktop” machines, the benefits of containerization are too great to ignore. And if the distro is already highly containerized, why not see how far that can be taken with an immutable distro and have a reproducible, atomically updated OS on your computer?
For those who want to give this new style of distro a try, I recommend beginning with openSUSE Aeon. It includes Flatpak and Distrobox, its update system (transactional-update) is well suited to a rolling distro, and it gives the user the greatest possible flexibility in adding things into the immutable base (any RPM that will work with Tumbleweed, and even arbitrary commands/changes if necessary). Updates take as little disk space as possible since it uses BTRFS snapshots to do the hard work of keeping previous versions of the OS safe and ready for rollbacks. Due to that flexibility, it is also, unfortunately, the least reproducible of the immutable distros in common use now. But it's a great way to get your feet wet in this world, and is one of the most stable rolling release distros you can find.
For the users who can work within its limitations, Fedora Silverblue is probably the most release-ready of any of the immutable distros. It uses rpm-ostree to create system images so it offers a good mix of reproducibility (each install of Silverblue is identical to every other install of Silverblue that has the same RPM overlays) and flexibility (you can overlay nearly any package you want). The normal graphical tools act as they should (gnome-software, for example, will let you know when a new system image is staged and ready to be activated with a reboot), and the experience is fairly polished. It uses Toolbox rather than Distrobox to handle running other distros in Docker/Podman containers. Distrobox has more features, but Toolbox works quite well and they can use each other’s OCI images.
On the horizon: VanillaOS is readying their 2.0 release. It, like BlendOS, is positioned as a kind of meta-distro, with graphical tools allowing the user to install packages from several different distros into their own Distrobox containers. It handles keeping them updated, and creates desktop shortcuts for applications installed within those containers as well. VanillaOS is based on Debian, but uses OCI images for core components. BlendOS just released v3 of their Arch-based distro, and it has some ambitious features (like Waydroid built in), but still needs some polish for regular use.
And of course, the big news that started this series: Canonical announced that the next major version of Ubuntu would include an official immutable version in addition to a traditional one. This one will use Snap instead of Flatpak, and I do not know if they will be planning to include Docker in the base image. I think that this may not go over that well, since Snap has some features that make it less well-suited for managing all the software on a desktop. Each Snap has to be mounted as a filesystem on startup. Having a handful of them might make checking filesystem free space a little strange, but having 20-30 would make the filesystem mounts look a bit of a mess. And since they have to be mounted at boot, the more Snaps installed on a computer, the longer the boot time. Again, a handful might not make much of a difference. “Snap Everything!” may not be that workable in practice the way it does for Flatpak (heck, on Aeon even most of the GNOME accessories like the calculator and text editor are Flatpaks). But Canonical wants their tech to succeed, and I look forward to giving it a try and seeing how well they are able to have 40-50 Snaps installed on a modern desktop system.
There are others, like Nitrux, Neptune, EndlessOS, and more. Though I’ve been told not to include it on the list, I believe NixOS counts as an immutable distro, though it goes about this in a unique way.
At least one of these will "stick" and become a standard. It will have solid mindshare and come installed by default by OEMs the way Ubuntu or PopOS is today. Every desktop distro will benefit when that happens.
Comments