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 the company’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 company 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. The company’s Doug deMaio told The Register:
The company isn’t planning to force container-based workloads on its users. SUSE CTO and openSUSE chair Gerald Pfeiffer also had reassuring words for us:
As to when will this next generation of Leap may arrive, deMaio said:
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. ®
