To some degree, all distribution developers want to have systems that can deliver updates safely to the users. At the same time, that process should be reliable: After an update, the system should still be functional.
Many solutions have been created to mitigate the issues that could impede the update to be both secure and reliable. The first paradigm was the package manager: a tool to automate some everyday software management tasks (installation, updating, removal, etc.). Some of them evolved to complex, non-trivial sets of tools. However, this approach has proven to be sometimes untrustworthy. Unbootable post-update systems, broken installations, missing dependencies after an update, among others, are common issues in systems on which software is served via a package manager.
Today we will explore a more reliable approach in some distributions: immutability. This is how some of them achieve it.
Atomic upgrade: is an update that is atomic (it is either fully applied or not, but never partially) and can be rolled back.
Fedora Silverblue.
Silverblue is a variant of Fedora Workstation. It looks, feels, and behaves like a conventional desktop operating system, and the experience is similar to what you find with a standard Fedora Workstation.
All good until here. Silverblue will feel just like a regular Fedora installation, except for one thing: the system is immutable. This means that every installation is the same as any other installation of the same version. Under the hood, ostree is responsible for managing the deployment and updating of the system, as well as managing the bootloader (GRUB2) configuration. Applications can be installed via rpm-ostree or flatpak. Every time you install a package, a new image of the system will be created. When you reboot it, you’ll be able to see the changes applied.
openSUSE MicroOS.
openSUSE MicroOS is a modern Linux Operating System, designed for container hosts and optimized for large deployments.
Although MicroOS differs from both Silverblue and Nitrux on the target public, it’s still worth mentioning how does it achieve its goal.
MicroOS is only focused on containers (thus, its target public is more on the developers/sysadmins side): It’s the foundation for openSUSE Kubic. It features a read-only root filesystem and atomic upgrades thanks to BTRFS snapshots. The system is managed with the transactional-update command. It is not a replacement for the package manager (zypper): it wraps it, and it also handles the bootloader. As in Silverblue, you need to reboot to see the changes applied.
Nitrux.
Nitrux is an operating system based on Linux. Nitrux works without any need for a traditional installation.
Nitrux is focused on the desktop and the end-user. Back in time, Nitrux was a “standard” Ubuntu derivative. But, since the introduction of znx, it is a read-only base system that supports atomic upgrades. Nitrux encourages the use of AppImages as the standard for application delivery, which also supports atomic updates just like the operating system; in fact, Nitrux does not use the Debian package manager (dpkg) or APT (Advanced Packaging Tools) at all to manage either. It emphasizes a strong separation between the operating system contents and user data. Like the previous ones, a reboot must be performed before the update takes effect.
Now what?
Is immutability useful at all? Yes! This may sound weird at first glance, but now I’ll explain how is that is, actually, a significant improvement in how the updates work.
As I mentioned before, updating a system can be risky. And this is why immutable systems that perform atomic upgrades are a smart solution. I mean, you’ll never have to worry about broken dependencies when an update is available; nor you’ll have to worry about if your system will be able to boot after you shut it down. Also, the workflow is pretty simple, as the system acts as an integral unit, instead of a big group assembled with smaller pieces. Atomic upgrades give us rock-solid systems, systems that are predictable, reproducible, and considerably easier to manage.
Let’s see an example with Nitrux. The process starts when the user downloads our ISO image. Once the live session is started, the user can deploy the system to the computer’s main storage. After, say, three weeks, we release an update. The user proceeds to update the system (this can even be an automatic task). When he reboots, it turns out that his hardware isn’t compatible with the kernel shipped with the update. Well, it’s as easy as reboot and select the previous, functional, version of the system. Does he want to have Ubuntu alongside Nitrux? Well, he just needs to deploy another system. He didn’t like Ubuntu and wants to throw it away? Just znx remove ubuntu/18_04. Yes, managing the operating system(s) is as simple as adding or removing files (it’s actually just that in znx’s code).
So, should we care about immutable systems? We should. Are they worth it? They are.