news
An alternate path for immutable distributions
LWN has had a number of articles on immutable distributions, such as Bluefin and Bazzite, in recent years. These distributions have taken a variety of approaches, including using rpm-ostree, filesystem snapshots, and bootable container (bootc) images. But those approaches, especially the latter, lead to extra complexity for a user attempting to install new software, instead of just using the existing package manager. AshOS (Any Snapshot Hierarchical OS) is an experimental AGPL-3-licensed "meta-distribution
" that tried a different approach more in line with traditional package management. Although the project is no longer updated, it remains usable, and can still shed some light on a potential alternate path for users worried about adopting bootc-based approaches.
There are a few reasons to find immutable distributions appealing. The fact that updates can be applied and rolled back atomically is probably chief among them, but they also make it easier to reproduce a corresponding installation from a small set of configuration files. Immutability means that changes to the configuration are cleanly separated out, so it's easy to see how a long-lived immutable system has been changed, and to reproduce a new system from those changes. The question, as always, is whether these benefits are worth the disk usage of A/B updates, build times of any custom images, complexity, and inconvenience. AshOS was an attempt to change the balance of that tradeoff by making it possible to add immutability onto an existing distribution, while keeping the existing distribution's package manager in control.
To do this, AshOS makes and manages snapshots of the root filesystem (including installed software and configuration files, but excluding users' home directories). These snapshots can be overlaid on top of one another, so that package-management operations can be separated out and named (similar to sysext images). For example, a user might have one snapshot for the base OS installation, another for their graphical user environment, and a third for their mail server. To try out a new piece of software or configuration change, they would create a new snapshot to work in on top of the existing ones. Within that snapshot, they could use the distribution's normal package manager to install the software. If that turned out to have horrible consequences, they could remove the most recent snapshot and return to the previous (working) configuration.
Other immutable distributions do offer similar capabilities. Fedora Silverblue-based distributions can use rpm-ostree to layer packages on top of a base image, for example. But doing so is rife with sharp edges compared to just using dnf — for example, if a base image is updated to include a package that was previously layered in, removing the exising layer is difficult to do with rpm-ostree.