Immutable OSs

Matthew Waanders recently brought to my attention a new desktop OS by Fedora: Kinoite. It is based on Fedora Silverblue, but with a KDE desktop environment. What is really fascinating about it is the idea behind both OSs. They’re both immutable desktop operating systems built around rpm-ostree and that is exactly what I’d like to focus on in this post.

Usually operating systems use package installers like apt, dnf, yum on Linux and even homebrew on macOS. These focus essentially on downloading packages and installing them in a local directory where they can be accessed by the user or other apps. This approach, although fast and quite flexible does have a drawback: its live updating of packages without easy stateful rollback. Sometimes packages can use different libraries across OSs and maybe for your specific one that you are installing them on, they’re quite simply not tested enough. So what can be done to improve this?

Enter images

We know images from the container world. We package an application and all of its dependencies in an image which can then be replicated exactly on other machines. What if we take this concept and apply it to OSs? What if we make a repo for images of apps ready to use with the correct state and have users pull them to their local OSs from there?

This is exactly what rpm-ostree is doing. The packages to be installed are all on a remote server that OSs can synchronise from. If a package exists on the remote server, then it should be synced to the OSs as well. As the rpm-ostree project self describes it is almost like git where people push to and pull from remote.

The main benefits of this are consistency and scalability. If you have a big fleet of EC2 instances to manage for example, you want to make sure that your package management system can handle that scale and do it consistently. We want the guarantee that once deployed a package will run the exact same way on one instance and every other around it. Of course, I’m an advocate for fully immutable infrastructures where instead of updating running EC2 instances you should just replace them with a newer AMI with all required updates, but that is a topic for a different post.

Let’s go a bit further in the architecture of such an OS. Let’s take the following filesystem for example. These are the default mount points as show in the Fedora CoreOS docs:

TARGET        SOURCE                                                   FSTYPE  OPTIONS
/             /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash]     xfs     rw
|-/sysroot    /dev/vda4                                                xfs     ro
|-/etc        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/etc] xfs     rw
|-/usr        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/usr] xfs     ro
|-/var        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/var]       xfs     rw
`-/boot       /dev/vda3                                                ext4    ro  

Every other mount point here, with the exception of /etc and /var, are immutable. Only rpm-ostree, and in the case of Fedora CoreOS bootupd, can make changes to the rest of the filesystem.

This way of managing filesystems is secure and efficient for servers, but now projects like Kinoite and Silverblue have brought it to the desktop as well. I am definitely excited to see those in action and play around with them and I encourage you to do the same.