What the big players and an outlier are doing, and why
Part 2 This is the second half of a feature about work undertaken to harden and improve Linux, beginning with part 1 here.
Commercial Unix was expensive so it was carefully tended – and indeed tendered. Linux is free so it has to fend for itself.
Linux itself was inspired by the tried and tested designs of the proprietary Unixes that preceded it – or predeceased it – which it drove into extinction. Some of their tech continues to make its way into Linux, and some is being reinvented, usually to get round IP issues. The goals are to make Linux more resilient: fault-tolerant, self-healing, and in general to lower the cost of its maintenance.
Just as desktop distros get their core tech from the lucrative server ones, some of the methods being used started out in old enterprise Unixes, or are reimplementations of tools and methods from them, but that’s only the beginning of the influence.
A starting point is one of the longest-standing bits of enterprise IT: databases. They’ve been around for longer than minicomputers and their contents are usually very valuable so lots of time, effort, and money has gone into research into how to make them more resilient. A core property has been to make them transactional – once an important buzzword for big commercial databases, and something that later filtered down to the smaller ones. The idea is to make every alteration of your precious business data into a transaction. Ideally, it completes fully, but if it doesn’t, you have a record of what was going to happen, so you can fully undo it, thus putting things back exactly as they were before.
The rules for how to make this reliable were defined by the great Tedd Codd to operating systems. Notably, this means the ACID properties: Atomicity, Consistency, Isolation, and Durability.
In the Linux world, this first appeared with journaling file systems. First, some proprietary ones were hacked out of commercial Unixes: we reported on SGI’s XFS in 1999, and IBM’s JFS in 2000. The new journaled ext3 file system was merged into kernel 2.4.15 in November 2001, although an intrepid Reg correspondent was already trying it out shortly before. Apple added journaling to HFS+ the following year.
Now efforts are afoot to bring some degree of transactionality to software installation too, and that leads us to executive summaries of the approaches of some of the more significant players.
The SUSE family of distros has long been given to using less-than-mainstream disk file systems. Way back in the 1990s, it defaulted to using ReiserFS while most others used ext2 or ext3 – The Reg mentioned this relatively exotic file system 21 years ago. ReiserFS became a less desirable choice because its eponymous lead developer was convicted of murdering his wife in 2008. SUSE was already offering Btrfs instead a decade ago, and it became the default file system by 2014, and the company remains committed to it.
Although other snapshot-capable file systems are out there, this remains a key strength of Btrfs: while OpenZFS on Linux is a thing, and is under active development, it’s not part of the Linux kernel. Red Hat has yet to commit to its own Stratis, and despite years of development the new bcachefs remains unfinished. For now, only Btrfs offers copy-on-write (COW) snapshots and is part of the Linux kernel.
The great advantage of COW snapshots is that they are very quick. Essentially, it enables the OS to make a near-instant backup of the state of a set of files: from the moment a snapshot is created, any writes to those files will be redirected to a new copy of the relevant files, held elsewhere. It’s fast and basically invisible to other programs on the system.
SUSE’s Snapper integrates Btrfs snapshots into package management. Whenever the OS’s package manager is told to install some new software, it first makes a Btrfs snapshot. If anything doesn’t work afterwards, the user can revert to the snapshot before the most recent update, and get a working system back again. Snapshot handling is integrated into the boot manager too so this also applies to kernel updates. It’s a key selling point of openSUSE’s rolling-release distro, Tumbleweed. Some other distros have added Snapper too, including the Debian-based SpiralLinux, the rolling-release Debian sid-based Siduction and the Arch Linux derivative Garuda.
But SUSE itself is pushing ahead with more sophisticated plans. Once independent from UK COBOL-shifter Micro Focus, SUSE chose to grow by acquisition, and soon snapped up Kubernetes merchants Rancher. With a newfound appreciation for containers, SUSE’s next-generation OS, codenamed Advanced Linux Platform or ALP, aims to increase reliability by moving beyond simple snapshots by making the root file system read-only. The only way to install software, including updates, is during a reboot, using a new command, transactional-update. The OS can check that all its services come back up without errors, and if some fail, it can revert to an older snapshot and reboot itself.
If you have a cluster of hosts running lots of containers, this should not be too intrusive: an orchestration tool, such as the ubiquitous Kubernetes, can migrate “pods” of containers off that machine, apply updates, and then bring containers back when the machine comes back up and rejoins the cluster. It’s less convenient for a non-clustered machine, but it may prove possible to work around this using tools akin to the existing Distrobox, which builds a conventional, read-write OS instance in a container on a machine running an immutable OS.
Other companies, with less stake in sophisticated file systems, are taking different approaches, but with similar ultimate goals. Another way to make software installation transactional is to move the functionality into the package manager, rather than the file system.
We have explored this in some depth, but we hope you’ll forgive a potted recap. The main contenders are Snap and Flatpak. Snap is the more controversial because of the perception that it’s proprietary, and the way that recent Ubuntu releases force it on Ubuntu users. The now official Ubuntu Unity remix adds in Flatpak support as standard. Linux Mint goes further: it completely removes Snap support and only offers Flatpak.
So what are the differences, and why?
A few years ago, and despite some controversy, Canonical was actively working on integrating OpenZFS into Ubuntu. However, more recently, it looks like Ubuntu’s ZSys tool is being deprecated.
However, Canonical remains firmly committed to its Snap packaging system, and offers its own immutable distribution, Ubuntu Core; we recently looked at Ubuntu Core 22. Like SUSE MicroOS, the root file system is read-only, and the conventional package manager is gone. Ubuntu Core only supports Snap, and even the kernel is packaged as one.
