Could immutability be a Leap too far for openSUSE users?

Update on Linux distro's next major version heralds big changes ahead

Updated The future of openSUSE is firming up, but possibly not in the direction that existing users of the distro will enjoy.

The latest update on the future of openSUSE Leap confirms that there will be a release called Leap 16 at some point, alongside a version 6 of the existing Leap Micro … but version 16 will be based on SUSE's containerized ALP distribution. This means that Leap 16 is destined to be an immutable distro with transactional updates, and thus significantly unlike the current openSUSE distribution. Although the project is promising a migration path, it seems very unlikely to be a simple in-place upgrade.

As we described in detail in last year's pair of features on making Linux safer, immutable distros are the hot new thing in the Linux world. A read-only root file system makes the OS much more resilient against disk corruption, and it is closely coupled with transactional updates, where snapshots mean that if an update causes problems, it can be rolled back, cleanly undone, as if it never happened.

SUSE and its affiliated openSUSE project have a large and growing family of distributions, but until the company's 2020 acquisition of Rancher, the distros' relationship with the SUSE Linux of old remained clear. openSUSE Leap is the free stable distro, with a relatively slow release cycle that is close enough to the commercial SLE that it's possible to migrate from Leap to SLE in-place for a few years. openSUSE Tumbleweed is a rolling-release distro, whose components constantly trickle down from the project's Factory development model. The main thing is that both are conventional distros, with a read-write root file system and management of RPM packages using SUSE's Zypper tool.

Where they depart from other mainstream distros is that SUSE distros not only default to using Btrfs, they also lean heavily on its advanced features in a way few others do. Specifically, this means Btrfs' COW snapshot support. Btrfs enabled SUSE to integrate its Snapper tool directly into its package manager, relatively easily. As a result, SUSE distros automatically create pre-installation snapshots before software installation or updates. If anything goes wrong, there's an "undo" feature. You can roll back to how things were before the change.

This is excellent technology … but as ever, there is a cost for every benefit. Btrfs is not the stablest file system. The Reg FOSS desk is confident that the strapline of the radical new bcachefs – "the COW file system for Linux that won't eat your data" – is a jab at Btrfs' reputation. (Incidentally, we think the "for Linux" part is a jab at OpenZFS, famously not part of the kernel.)

Using Btrfs to deliver transactional package management means that SUSE's implementation is technologically far less complex than Red Hat's OSTree, as used in Endless OS, the immutable variant of Fedora Silverblue, and also in Flatpak, which is in many distros including Linux Mint.

Flatpak itself is simple and open, but its complexity lies in its implementation using OSTree. OSTree's own project description compares it to Git. Git is famously hard to use, but how it is implemented is so complex and obscure that there are cartoons about it. (If you don't use Git, be happy … but if you want some amusement, look for a Git enthusiast, ask them how it tracks and manages changes, then watch them flail.)

OSTree is complex. Worse still, because Flatpak is optimized for GUI apps and doesn't work well for command-line ones, you can't build a distro out of Flatpaks. You need OSTree as well, and that means fundamentally restructuring and rebuilding the whole OS.

Canonical faces similar issues. Canonical's Snap format is much simpler: Each app is just one file, a SquashFS, and it handles command-line apps fine. This means Snap doesn't need any Git-like shenanigans, nor does it need a fancy file system with COW snapshots, and Canonical can use a single tool for the whole OS. However, it's a completely different tool from conventional Ubuntu, which is built from Debian – and Debian is built from deb packages. Building a distro from Snaps instead means reconstructing the whole thing from the foundations up. We looked at Ubuntu Core, Canonical's IoT distro, in 2022, and later this year Canonical plans to release Ubuntu Core Desktop, when Ubuntu Core turns ten.

Canonical stated that Core Desktop won't replace conventional Ubuntu yet. Similarly, the immutable forms of Fedora are not yet ready to replace the mainstream versions. RHEL will surely follow in time, but not until years later.

In stark contrast, SUSE is planning to make the transition as soon as next year. Already, the newer distros in the SUSE family, openSUSE MicroOS and SLE Micro, are both minimalistic, immutable operating systems. Although they are built using the same tooling (RPMs, managed using Zypper), and their packages originate from Tumbleweed, both ship with read-only root file systems, and their conventional package-management tools are inaccessible. Even the root user cannot interactively add, remove, or update software; they must use the new transactional-update command. This has helpful man pages and a good manual – a SUSE hallmark for decades – but means a new way of managing a Linux machine.

The software tooling is far from new and untested. The commands were available in SUSE's Kubic Project back in 2017, although that was retired in 2022, replaced by the now-mainstream MicroOS.

SUSE has a more direct path to an immutable OS than any other Linux vendor. It need not even be a big-bang transition. Spokesperson Douglas DeMaio told The Register a non-immutable variant of Leap 16 may be offered in some way:

There is an option in building an OS to install transactional and non-transactional (the Tumbleweed installer supports both, for example) … Technically, there is not really a lot of difference; the read-only rootfs is mostly a "guarantee on top" for the system not to be changed on the fly.

Quite how that – an ALP-based distribution that's both transactional and non-transactional, or immutable and non-immutable – will work isn't clear at this stage. It sounds as though the distro maker isn't planning to force container-based workloads on its users, at least. SUSE CTO and openSUSE chair Gerald Pfeiffer had these reassuring words for us:

Yes, there are still flavors of openSUSE in our future that are not MicroOS-based, and won't require user workloads to leverage containers. We are looking at other modalities, possibly MicroOS-like, to include. Ultimately, it's all about choice for the user!

As to when will this next generation of Leap may arrive, DeMaio said:

We are thinking of the end of 2025, but there is a chance for a slip, which is why we put Leap 15.7 as a last resort.

SUSE has a simpler route to delivering immutable Linux than any other vendor, and it is aggressively pursuing it. Even the end of 2025 is sooner than anyone else in the enterprise space. The risk is that it may alienate existing users in getting there. ®

Update on Friday, January 19

Our FOSS vulture Liam spent a decent amount of time this week trying to nail down with the openSUSE team whether or not Leap 16, being based on ALP, will be immutable-only – only to be told after he finished this article that the org hopes to offer an installable distribution that's both immutable and mutable. After asking how that would work, he received no explanation, leading him to the conclusions you see above.

Some time on Friday, days after the article went live, openSUSE updated its announcement of Leap 16 to include the following passage:

There are no plans to drop the classical (non-immutable) option for Leap; both non-immutable or immutable installation variants are available for Leap 15 and are planned for Leap 16. This is set to remain the preferred way for people to deploy Leap.

The original announcement is here. The project's DeMaio also dropped The Register an email asking us to correct our article to reflect that "openSUSE Leap 16 is planned to have both immutable and non-immutable installation variants." We've still not had an explanation of how it plans to do that.

To us, it appeared openSUSE was still figuring all of this out. No doubt spurred by this article, it has now sought to clarify the situation more robustly, which is welcome but would have been more greatly appreciated some days earlier.

So, anyway, if the mutability of Leap 16 is a concern for you, bear in mind the project intends to offer a traditional non-immutable variant as well as an immutable one at some point, the details of which are still unknown.