This post is part of my “Immutable Linux” post series I have planned.

This one here is the first of (probably) three posts in total. It should provide you an introduction into this topic, debunk some myths, give you an overview into different concepts, and maybe a slight hint into Linux’ future.

If you’re after a super complicated expert-level post, you’re wrong here, sorry. I want to keep it simple and, because of that, I’m gonna “lie” a few times in this writeup to keep everything understandable for everyone, including Linux newcomers. The post will be a bit longer to read.
I know, that not everyone has the time for that, so here’s a

TL;DR:

  • Immutable distros are the future and totally underrated!
  • Don’t call them immutable - you can still change and customize them to your liking.
  • They have A LOT of pros compared to traditional systems - less bugs, better security, indestructible, and more!
  • Maybe check out Fedora uBlue. It’s the most sophisticated image distro out there right now. But its’ contenders aren’t sleeping too and will be interesting too in the future.
  • They are still pretty new, which might be a problem right now regarding compatibility and spread of use.

1. Introduction

I. What is an immutable distro?

The term “immutable” is very unfitting in my opinion. Why? Because those kind of distros are, in fact, changeable. They just require a different approach than traditional ones (e.g. Arch, Linux Mint, etc.). But more onto that later. I prefer the term “image based” or “atomic”, not only because that’s more fitting, but also because it doesn’t imply inherent restrictions.

II. How do they differ from traditional distros?

Image-based distros (IBD from now on) are a pretty new concept, that heavily relies on many new technologies from the recent past, especially containerization and new partition systems.

Their main differences, compared to traditional mutable distros (TMD from now on), are:

  • Restricted file system: most parts of the OS are locked down and not changeable as easily, at least from a side level. Of course, you still have sudo rights and “own” your device.
  • For the end user, there’s now an easy distinction between “your” stuff (photos, configs, some applications, etc.) and “the rest of the system”, which, in short, only exists to make your computer running. Use your Android phone as example. You don’t notice many restrictions there too and it hides the complex stuff successfully for normal users. Rooting has become a thing of the past for most users and everything works as it should.
  • Atomic changes: your system gets either changed completely, or not at all when upgrading. If the power gets lost while updating, you won’t end up with a half-upgraded OS in the end. It will just boot into the same state as before. With every transaction, it basically “copies” the source image and applies it to yours, so it will be the same.
  • They are based on a clearly defined, centralized setup.
    Imagine it like how McDonald’s works. There are thousands of restaurants in one country, but they all have the same recipes in common. This results in every burger tasting the same around the country, no matter where you are. Every process is heavily regulated, documented and supervised. It’s a very rigid system. In contrast, TMDs are very wobbly. They change all the time. Many programs write somewhere, whereever they want, into the root file system, updates add and remove stuff, and so on, and so on. Imagine every cook at McDonalds now decides to freestyle his burgers. In the beginning, they may taste the same as before. But then, he adds more and more mustard, forgets the salad, and after some time, the burger isn’t recognisable anymore, and no one knows why. This is called package drift, and I’ll tell you why that’s bad in the next paragraph.

III. Advantages

Package drift

Package drift is a developers’ nightmare.

Did you ever notice, how, after some time, may it be weeks, months, or years, your Linux install or programs become ever so slightly less reliable? Freezes here, memory leaks there, crashed programs, and so on. It’s because of the point explained above.

Even, if you use a TMD just like you would an IBD (everything via Flatpak, no root usage, etc.), you still change the underlying system all the time due to updates and executed apps. You have one starting point, and after some time, it won’t be the identical to the install from someone else, even if you used the PC exactly the same.

Realistically, this usually isn’t a huge problem to be fair. Package managers are great and you will barely notice it, at least in the beginning. But after some time, the state diverges too much and you’ll run into problems. The most notable one:

“It works on my PC. Issue closed.”.

I’ve used KDE again and again from time to time for example. Usually, on the normal Fedora KDE variant, installed via a clean reinstall. The first weeks were fine - and then came the Krashes. Every time. I used it now for quite some time on Fedora Atomic, and I encounter almost no bugs at all! Same with other software. Barely any bugs or crashes.

Security

The first reason why IBDs are more secure is the point from above. If there are the same loop holes on every install, the devs can reproduce it and fix it immediatelly.

Software not being able to modify the whole file system is also a huge plus.

Because you usually work with restricted containers, you can define permissions for each program, at least with Flatpaks.

Ease of use

They often feel like a great hotel room. You know, it is being cleaned by the staff and you don’t have to make the beds or care for other stuff. Updates are usually (if you want) being taken care of automatically without the user having to press a button or restart. If you shut down your PC anyway, like you always should after a few days at least, you boot into the updated image.

The “your stuff” and “the rest” explaination from above also applies here. Especially newcomers don’t need to learn what every part of the Linux OS does, because they won’t even touch it anyway.

Many images also come pre-made with baked in drivers, e.g. for Nvidia GPUs, Asus hardware or Microsoft Surface devices. No fiddling required! Because the drivers are already part of the image, they are usually more reliable than if you would install them on another distro. If there’s something broken, it will be broken for everyone, and the devs can fix it instantly. In the meantime, you can just roll back and have an always working system.

Reliability

You’ll always have a working OS. They are known to be almost indestructible, both from user errors, and bad updates.

If you still manage to fuck it up, you can just boot into the image from yesterday, and it will be exactly in the same state as back then.

This doesn’t work like Snapper (from OpenSuse Tumbleweed) for example, where you have to restore a certain config, and even then, it might still not work. It’s more like a second/ third parallel installed OS next to your current one, which only share the user data between them, and in which you can just boot into in seconds, just like when dual booting. I had to make use of that a few times, and it always worked reliably. Restoring backups, e.g. on Tumbleweed, on the other hand, often didn’t work for me and I had to reinstall my system.

The Atomic-Update point from above also applies here, if you have an unsteady power supply, pets, or whatever.

They feel cleaner

All your data are in one place, and not scattered around the system.

You will work in containers a lot, which will also make organisation easier. Look at my Distrobox-post for more information.
It’s basically like using drawers instead of cluttering your whole apartment with stuff.

Distrohopping made easy

Due to how the file system is build, you can easily swap out “the OS”-part with something else, while keeping your user data.

If I’m on Fedora Silverblue (Gnome) for example, I can just rebase to Kinoite (KDE) in less than 10 minutes. It is like a clean reinstall without any weird dependencies or leftovers. I just did that today again because I just can’t decide…

You can also choose between many other DEs and TWMs too if you want.

IV. Limitations and cons

Container workflow

While you usually can install packages the traditional way (e.g. via rpm-ostree layering on Fedora Atomic) on most distros, it is usually not recommended and should only be reserved for TLP or your printer driver for example. If you decided to do that, you have to reboot each time you install something, which obviously sucks!

Because of that, you work with containers. The most common one is Flatpak. They cover 99,9% of your needs for every graphical app and are easily installable via software center.

Other common ones are Distrobox/ Toolbx and Nix, especially for CLI tools.

They all sometimes don’t work everytime as intended. For example, I still have to fix a Flatpak permission from time to time, and other commenters said they still have some problems getting specific programs working in Distrobox. But, to be honest, I never encountered software that didn’t work on my OS yet, with the exception of a VPN client, which should be fixed by now.

Too new

The concept and spread of IBDs is not yet fully matured. They work wonderfully, don’t get me wrong. But, there are still some minor rough edges and potential to uncover. That’s not being me just a fanboy and saying it’s “just some minor problem here and there”, while it is infuriating in reality, no. It’s literally only super minor stuff that is fixed easily. For example, I encounter some programs that could work absolutely fine, but just spit out errors because of a missing link, e.g. it wants to access /bin/, but the OS only has /var/bin as example.
It’s great to see devs now knowing about this issue and trying to fix them. The biggest problem is the lack of documentation and spread. There are just sometimes minor issues you have to fix yourself, because it doesn’t apply to other distros and you can’t find a solution online.

And this is the main reason I don’t recommend every super new user to check out IBDs yet, because of the lack of support. Not, because they don’t work fine. They do. Better than normal ones imo. It’s just because if they google something, they want to apply the guide for Ubuntu to their own system, and that won’t work. They can’t think of a workaround due to the lack of experience. This is why. Wait 1-2 years, and it should work completely fine.

For people I can help physically, I would do it without any doubt.


2. Misconceptions debunked

You can’t change anything and they aren’t customizable

They are just as customizable as traditional distros. You just have to do that differently. Instead of trying to change them from a bottom-up-approach, you have to change the image itself and then apply the changes. This sounds more complicated than it is. On Nix, you just change a few lines in your config and then reload, and on uBlue it’s even easier!

They aren’t user friendly

In my opinion, they are even more user friendly than classic ones. They only appear so, because they are different from what we learned over the last years.

I would even go as far as saying that VanillaOS or Silverblue have the potential to “replace” Mint, especially if all they wanna do is consume media and play some games. See a few lines above why I think it isn’t the time for that yet.

They’re a dumbed-down OS

They’re as complicated and capable as you wish. It’s still Linux, don’t forget that.

ChromeOS or Android can be considered dumbed down, yes. Fedora Silverblue is the same OS as Workstation on the surface, you wouldn’t notice a difference first at all. And NixOS is one of the most capable and complicated distros out there. They’re very diverse and have different philosophies and tech under the hood!

They will take away my distro of choice!

No one will. There will always be at least one other person who likes Arch just as much as you do. It’s still Linux and FOSS. It will replace some use cases where it makes sense, and it will go under in others where it doesn’t. Only time will tell.

And even if they replace your distro of choice, it would be a slow and welcome transition, similar to Wayland over the last years.


3. Small overview over different distros and concepts

Fedora Atomic

With that I mean the “immutable” Fedora variants, like Silverblue, Kinoite, and so on. They only differ by their DE.

In my opinion, Fedora Atomic is the most refined one currently. It uses a version-archiving package manager (often gets called “git-like”), that documents and stores changes like the branches of a tree. Hence its’ name OSTree.

You can “layer” packages with rpm-ostree, which allows you to use software from the normal Fedora repository, while keeping the base system unchanged.

The coolest thing about it is a project called universal-blue.org. With uBlue, you can create images yourself and basically create your own distro, with the main plus that you don’t have to maintain it for security or other updates, because it does that itself.
If you’re missing Hyprland for example in the list of available images, you can just create your own setup with it and publish it there for others to use. uBlue provides OOTB-usable vanilla images with drivers, codecs and some QOL-changes baked in, because the official Fedora image isn’t allowed to ship them by default.
The main pro-point is that, as example, the Nvidia-driver is already baked in and won’t break. And if it does, it will on thousands of other installs, and the devs can fix it extremely quickly. There are many community spins and variants, for example one with the Deepin DE, a hardened variant for better security, and much more!

Bazzite, also a community image, is the best alternative to SteamOS and Nobara. It has the same pros as Nobara, without the problems of security or instability due to only one developer. Best gaming distro out there!

NixOS

“The new Arch”. It’s considered to be one of the most complicated, but also extremely powerful distro and should only be used by experts according to some, or it will lead to frustration.

It also has a great packaging system called “Nix”, which can be used on any other distro, and even MacOS!

It’s known to be the king of reproducability, since the whole config is written in just one single text file.

OpenSuse Atomic

Once called MicroOS Desktop in general, it’s now split between Aeon (Gnome), MicroOS (headless base) and Kalpa (KDE). It works a bit differently than Fedora Atomic, but currently, it’s in its’ infant shoes and isn’t as commonly used yet.

VanillaOS

It’s supposed to be a next-gen Linux Mint. Same principle of stability, reliability, user friendliness and simplicity, but with a different way of achieving that.

It’s made by the same team that also develops Bottles (for WINE) and currently undergoes heavy development. It will be based on Debian instead of Ubuntu soon and only offers the Gnome desktop right now. It, and OpenSuse Atomic, use the concept of A/B-Root, which is also used by Android.

I will keep an eye on it and maybe, in some time, recommend it to noobs instead of Mint. We’ll see!

Others

There are a lot of other ones out there too, like EndlessOS, BlendOS, SteamOS, and more. If you missed them, tell me in the comments!

I just wanted to name the most popular or promising ones.

Future

There’s the saying of “The future of Linux is immutable”. I think that’s right.

There are so many great things image based systems do better than our current traditional ones. It’s fascinating what new possibilities will arise soon. The clean rebasing to custom images for example is only the start!

I think they are great for both newcomers, due to simplicity and reliabiltiy, aswell as experts.

I can only see those minor rough edges being polished in the next 1-2 years. Flatpak and Wayland for example used to be in the same spot just 2 years ago, and now, they’re a staple of the Linux desktop.

Everyone should at least take a look into them in my opinion!

  • d3Xt3r@lemmy.nzM
    link
    fedilink
    arrow-up
    14
    ·
    10 months ago

    Nice writeup!

    Only thing is:

    If you decided to do that, you have to reboot each time you install something, which obviously sucks!

    You don’t have to reboot if you use the --apply-live switch, but of course, you’d still need to reboot for something like a kernel update. And of course, I wouldn’t recommend layering packages either, unless there’s no other alternative.

    • Guenther_Amanita@feddit.deOP
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      10 months ago

      Thanks!

      Yeah, of course you’re right. As I said in the beginning, I had to lie a bit for simplification.

      But, rebooting is the recommended way to keep everything running buttery smooth. I personally also recommend just sticking to the usage guidelines, since you don’t have to layer any stuff on regular basis. Just rebooting and losing one minute once a while is worth it for me. I work in containers anyway, see my Distrobox-post.

      The --apply-live-tag also only applies to rpm-ostree, not to A/B-root afaik, and I wanted to keep it a bit more general.