The concept of immutable objects – objects that can be replaced but not edited – is not new to Linux. Object-oriented program languages such as Rust, Erlang, Scala, Haskell, and Clojure have immutable objects, and many programming languages allow immutable variables. Similarly, the chattr command has an immutable attribute for directories and files.

In recent years, immutable systems have emerged, originally for the cloud or embedded devices, but now for servers and desktop environments as well. Some of these distros are new, and many are based on major distributions such as Debian, openSUSE, and Ubuntu. All are seen as adding another layer of security and most use containers and universal packages, bringing these technologies to the average user for everyday use (see Table 1).

The Immutable Architecture

The structure of immutable systems is complicated and varies with the distribution. While only an overview can be given here, the general definition of an immutable distro is a core operating system, usually placed in a separate container, that is read-only. Once installed, this core system cannot be permanently edited. Any editing attempt will be lost once the system is rebooted. Unlike in traditional systems, not even a root user can alter this core. Instead, the core can only be completely replaced by what is described as an atomic update during a system reboot (i.e., the update must be applied all at once or not at all). Often, each update can be stored like a snapshot for backup and may be chosen at bootup. These images may be handled by an application like Fedora Silverblue's ostree or through snapshots in a Btrfs filesystem, as with openSUSE's MicroOS.

But what about non-core components? As you probably know, traditional package managers deal with one package at a time, adding dependencies as needed. Because a dependency might be an application or library that is part of the core system, in an immutable system, this approach would only alter the system until the next boot, when the change would be lost and the non-core package might cease to work. Instead, immutable distros often use a universal package system such as AppImage, Flatpak, or Snap. Because dependencies in a universal package contain their own dependencies, they can be run without interfering with the immutable core. Should a problem somehow emerge regardless, the system can be rolled back at boot. Alternatively, blendOS places traditional packages from each traditional distribution in a separate container, so that its immutable desktop can run multiple versions of the same package.

How much of this structure is visible from the desktop varies considerably. Some immutable distributions like Vanilla OS and blendOS include graphical tools for such tasks as creating containers (Figure 1) and controlling updates (Figure 2) and universal packages (Figures 3). In others like Fedora Silverblue, the immutable aspects are hidden on the desktop. For example, in Silverblue, /home is a symbolic link to /var/home, and the immutable structure is placed in /sysroot (Figure 4). The most obvious structure in any immutable distro is usually the tool for updating, like Silverblue's ostree and utilities for managing containers.

Figure 1: The blendOS desktop tool for creating containers.

Figure 2: The Vanilla OS desktop tool for updates.

Figure 4: Fedora Silverblue stores system images and other files for its ostree tool in /sysroot.

Figure 3: The Vanilla OS desktop tool for managing AppImage packages.

The Immutable Advantage

Details can differ from the general description given here. However, all immutable distros share the same advantages:

• Added security: Even if the core system is somehow cracked, any changes will disappear upon reboot. Moreover, with universal or containerized packages, changes are harder to spread from one application to another.
• Accident proof: System files cannot be altered by mistake. Atomic updates eliminate partial updates, and snapshots allow rollbacks.
• Easier administration: Testing, troubleshooting, and cloning are easier because of the more rigid structure.

Perhaps the greatest advantage, though, is that embedded and desktop development are no longer as separated as they have been in the past. In immutable systems, tools that once seemed relevant mainly to embedded systems such as containers and universal packages are given practical purposes in desktop environments.

Possible Limitations

Like most new technologies, immutable desktops are often overhyped. For this reason, I should stress that immutable desktops have their limits. For one thing, any container is only as secure as its contents, so immutable distros can never be totally secure. There is always the chance that bugs or security attacks can be introduced accidentally or deliberately when a container is created. If that happens, it could easily be missed out of a false sense of security. For another, unlike traditional packages, universal packages each contain their own libraries, which may not be be practical on systems with low memory. Vanilla OS, for example, requires 50GB for storage.

Perhaps more importantly, immutable desktops require more maintenance than traditional package systems like .deb or .rpm. Instead of a single package and its dependencies, in at least some cases, an entirely new system image must be created to avoid the unintended introduction of new problems. Either more hands or more hours are probably needed to assure quality. For rolling distributions like Arch Linux, whose emphasis is on the newest software, immutable releases seem especially impractical, although some sort of compromise with occasional immutable releases might be possible.

Such concerns suggest that immutable systems may not be suitable for every situation. But if general and rolling releases can coexist, there seems no reason why immutable distros cannot find a niche as well.