I was thinking about going immutable for a long time and now I’m choosing a distro to hop to.
My question is: what are good immutable distros other than Fedora Silverblue spins, UBlue family and NixOS?
Maybe someone uses/used any? What is/was your experience with it?
Please don’t hurt me but what’s an “immutable” distro?
It’s a distro that makes all but a few system directories immutable. This means you can’t just install whatever you want in the same way you would install in a traditional Linux system.
This comes with some benefits:
- Malicious and buggy software can’t permanently fuck up your installation. Even root can’t edit those directories.
- Each system update replaces only the system layer, but you can rollback to the previous one if something breaks.
- You can rebase to other images (like going from Fedora Kinoite to UBlue Aurora) with a simple command, and you don’t need to reinstall anything or worry about backing up your /home directory.
- Most software is installed via flatpaks or appimages, keeping a layer of separation between your system and your applications.
- Distroboxes/Podman containers can handle a lot of additional software while keeping it safely containerized.
- The system is generally reproducible, so the core of what you have is the core of what everybody else has.
Some drawbacks:
- You can’t install whatever you want however you want. There are some hard limitations on where files are allowed to go, and installing certain software that interacts with the kernel can be tricky (I’m currently trying to figure out the best way to install my VPN provider’s client).
- There’s a definite learning curve to working with containers. It’s not always as simple as “create container, install thing.”
- There’s a definite learning curve to retraining yourself to think in layers/containers.
Some examples of modern immutable distros are:
- Fedora Silverblue
- Fedora Kinoite
- Universal Blue Aurora
- Universal Blue Bluefin
- Universal Blue Bazzite
- NixOS
- BlendOS
As I understand it, it’s read-only, so the updates you get are basically replacing your current ones but keeping your apps (like flatpaks) installed.
I think about it like this:
Layer 2b: ->> User applications (flatpak, nixpkgs, etc.)
Layer 2a: ->> User data (mutable, persistent no matter what your system layer is)
Layer 1: -> System (immutable/read-only/updated "atomically" meaning all at once)
Layer 0: Hardware
Or, alternately, it’s what macos has been doing with absolutely no fanfare for several versions now. That’s not a knock, btw. It’s an illustration that it can be completely transparent in use, though it may require some habit changes on linux.
Here’s a resource I’ve been keeping in my back pocket for when I dive in:
I’m surprised to hear you don’t like Fedora. I recently tried Kinoite and I wish I’d discovered it sooner. I’ve never had a Linux distro that felt so detail-oriented and complete. I’d be curious to hear your reasoning!
It’s complicated and I have a few reasons.
- Last time I used it, Fedora’s updates were too unstable. I twice got updates breaking my system setup. For example, with openSUSE it happened only once (recent broken Mesa update). Also openSUSE updates surprisingly feel more stable than Fedora ones.
- I don’t like Red Hat. Even though I understand that open-source projects are complex and I should separate developers from their software, that doesn’t change my opinion on Red Hat.
- This problem stems from the previous ones. Using Fedora I feel like a beta-tester for future Red Hat projects and especially RHEL.
Keep in mind, that I last used Fedora on versions 37–38 and things might have changed since.
OP, I don’t intend to convince you otherwise. I merely intend to share my own takes on this. So, without further a due.
- Last time I used it, Fedora’s updates were too unstable. I twice got updates breaking my system setup.
So, first of all, you seem to think that Fedora’s updates are equally “unstable” compared to those found on Fedora Atomic. But this is simply categorically wrong due to Fedora Atomic being (as it’s name applies) an atomic distro. And hence has far superior updates (in terms of ‘stability’).
Secondly, I recall this period quite vividly, and I actually agree with you that Fedora’s handling was a mess. And, unfortunately, this mess also affected Fedora Atomic. Thankfully, uBlue’s team ensured that the issues were not felt on any of its images. So, even if, at times, issues spill over to Fedora Atomic, users of uBlue images will not have to face those. Heck, history has recorded that the uBlue images have consistently prevented those issues to spill over to its images. Thus, while this may (perhaps rightfully so) make one question if they should use Fedora Atomic or not; this, however, does not represent the situation over at uBlue images. Hence, one could rely on those without fearing issues related to ‘stability’.
- I don’t like Red Hat. Even though I understand that open-source projects are complex and I should separate decelopers from their software, that doesn’t change my opinion on Red Hat.
Fair. What makes you hate Red Hat? I know often cited reasons for why people hate Red Hat. But what are your reasons*?
- This problem stems from the previous ones. Using Fedora I feel like a beta-tester for future Red Hat projects and especially RHEL.
Is this specifically a problem because you hate Red Hat? Because, quite frankly, the same somewhat applies to openSUSE and SLE. But this doesn’t seem to bother you.
Keep in mind, that I last used Fedora on versions 37–38 and things might have changed since.
Excellent point. Since that ‘double trouble’, it has been relatively stable. However, I wouldn’t be surprised if Fedora would act similarly if a new issue arises.
Highly recommend Guix, been using it as my daily driver for years now.
System Crafters has a really nice series on getting it setup the way you want it. I think it’s fixed a lot of stuff that is a little wonky with Nix – proper separation of config-time things and build-time things with g-exps, no putzing with bash scripts, grafting so you can reuse builds even when dependencies get updated, and just general good documentation and hackable culture with a pretty active IRC. They’ve recently added support for also managing your dotfiles the same way you do packages and system config (Guix Home). They’ve also pushed the boundaries of bootstrappability/reproducible builds so far that bitcoin-core is now building on Guix for security.
The system is pretty well thought through, and has saved me a few times where I would’ve bricked my machine on a mutable distro – now, I can just boot to a previous version of the system from the bootloader whenever my lastest changes are messed up.
I’ve been using Opensuse Aeon just over a year and it’s done great.
Tumbleweed user for the last 5 years, and dealt with a few issues over that time. The usually infrequent update break that comes with rolling release. And the Opensuse ‘Patterns’ started, which I loathe and it’s a disaster to try to disable them every install.
Aeon hasn’t had any of those issues. It’s been very much a “turn it on and get to work”.
I’ve generally had less issues with Aeon than Tumbleweed - like certain flatpaks not crashing.
But downsides as I see them:
I’m not a gnome guy. It’s fine though, I don’t hate it. But some people can’t stand it.
I had a bit of trouble running wine. Something about the default security policy. There’s a known workaround.
Kalpa needs to attract more developers to keep up with Aeon’s pace. I understand it is usable as a daily driver, but it’s not just a one to one mirror of Aeon with Plasma on top.
https://sfalken.tech/posts/2024-06-08-how-do-aeon-and-kalpa-relate/
Richard Brown is all in on Aeon along with whatever contributors are helping him. Stephen Falken appears to have no one helping him work on Kalpa unfortunately. I disagree with Richard’s stance that Kalpa shouldn’t exist, but I do wish there were some capable people able to help that project.
I don’t mind using Gnome anyway, it actually does solve some networking issues that I’ve always had with Plasma. (Dolphin not handling it well whilst Gnome Files has no issues)