Could immutability be a Leap too far for openSUSE users?
(2024/01/17)
- Reference: 1705505475
- News link: https://www.theregister.co.uk/2024/01/17/opensuse_confirms_leap_16/
- Source link:
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 [1]future of openSUSE Leap confirms that there will be a release called Leap 16 at some point, alongside a version 6 of the existing [2]Leap Micro … but version 16 will be based on the company's [3]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 [4]pair of [5]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.
[6]
SUSE and its affiliated openSUSE project have a large and growing family of distributions, but until the company's [7]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 [8]for a few years . openSUSE Tumbleweed is a rolling-release distro, whose components constantly trickle down from the project's [9]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 [10]Zypper tool.
[11]
[12]
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 [13]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 [14]strapline of [15]the radical new bcachefs – "the COW file system for Linux that won't eat your data" – is a [16]jab at Btrfs' reputation . (Incidentally, we think the "for Linux" part is a jab at OpenZFS, [17]famously not part of the kernel .)
[18]
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 [19]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 [20]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.
[21]Debian preps ground to drop 32-bit x86 as separate edition
[22]Time for a Geeko remix: openSUSE is looking for a new logo
[23]Systemd 255 is here with improved UKI support
[24]Cinnamon and KDE sync version numbers in desktop sibling rivalry
Canonical faces similar issues. Canonical's Snap format is much simpler: Each app is just one file, a [25]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 [26]looked at Ubuntu Core , Canonical's IoT distro, in 2022, and later this year Canonical [27]plans to release Ubuntu Core Desktop , when Ubuntu Core turns ten.
Canonical stated that Core Desktop [28]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.
[29]
In stark contrast, SUSE is planning to make the transition as soon as next year. Already, the newer distros in the SUSE family, [30]openSUSE MicroOS and [31]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 [32]transactional-update command . This has [33]helpful man pages and a [34]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 [35]SUSE's Kubic Project back in 2017, although that was [36]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 :
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.
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:
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. ®
Get our [37]Tech Resources
[1] https://news.opensuse.org/2024/01/15/clear-course-is-set-for-os-leap/
[2] https://get.opensuse.org/leapmicro/5.5/
[3] https://www.theregister.com/2022/10/05/suse_alp_v001/
[4] https://www.theregister.com/2023/02/14/make_linux_safer_p1/
[5] https://www.theregister.com/2023/02/16/bulletproof_linux/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://www.theregister.com/2020/07/09/suse_acquires_rancher/
[8] https://www.theregister.com/2021/06/04/opensuse_leaps_to_153_now/
[9] https://en.opensuse.org/openSUSE:Factory_development_model
[10] https://github.com/openSUSE/zypper
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] http://snapper.io/
[14] https://bcachefs.org/
[15] https://www.theregister.com/2022/03/18/bcachefs/
[16] https://www.theregister.com/2022/05/12/fedora_36_released/
[17] https://www.theregister.com/2020/01/13/zfs_linux/
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[19] https://github.com/ostreedev/ostree
[20] https://xkcd.com/1597/
[21] https://www.theregister.com/2023/12/19/debian_to_drop_x86_32/
[22] https://www.theregister.com/2023/12/08/opensuse_vote_on_logo/
[23] https://www.theregister.com/2023/12/08/systemd_255_is_here/
[24] https://www.theregister.com/2023/12/01/cinnamon_6_kde_6b/
[25] https://tldp.org/HOWTO/SquashFS-HOWTO/whatis.html
[26] https://www.theregister.com/2022/06/17/ubuntu_core_22/
[27] https://www.theregister.com/2023/06/06/desktop_ubuntu_core_in_2024/
[28] https://www.theregister.com/2023/11/08/ubuntu_core_desktop_details/
[29] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[30] https://microos.opensuse.org/
[31] https://www.suse.com/products/micro/
[32] https://github.com/openSUSE/transactional-update
[33] https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html
[34] https://kubic.opensuse.org/documentation/transactional-update-guide/transactional-update.html
[35] https://www.suse.com/c/introducing-kubic-project-new-open-source-project/
[36] https://kubic.opensuse.org/blog/2022-06-10-kubic-retired/
[37] https://whitepapers.theregister.com/
The latest update on the [1]future of openSUSE Leap confirms that there will be a release called Leap 16 at some point, alongside a version 6 of the existing [2]Leap Micro … but version 16 will be based on the company's [3]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 [4]pair of [5]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.
[6]
SUSE and its affiliated openSUSE project have a large and growing family of distributions, but until the company's [7]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 [8]for a few years . openSUSE Tumbleweed is a rolling-release distro, whose components constantly trickle down from the project's [9]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 [10]Zypper tool.
[11]
[12]
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 [13]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 [14]strapline of [15]the radical new bcachefs – "the COW file system for Linux that won't eat your data" – is a [16]jab at Btrfs' reputation . (Incidentally, we think the "for Linux" part is a jab at OpenZFS, [17]famously not part of the kernel .)
[18]
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 [19]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 [20]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.
[21]Debian preps ground to drop 32-bit x86 as separate edition
[22]Time for a Geeko remix: openSUSE is looking for a new logo
[23]Systemd 255 is here with improved UKI support
[24]Cinnamon and KDE sync version numbers in desktop sibling rivalry
Canonical faces similar issues. Canonical's Snap format is much simpler: Each app is just one file, a [25]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 [26]looked at Ubuntu Core , Canonical's IoT distro, in 2022, and later this year Canonical [27]plans to release Ubuntu Core Desktop , when Ubuntu Core turns ten.
Canonical stated that Core Desktop [28]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.
[29]
In stark contrast, SUSE is planning to make the transition as soon as next year. Already, the newer distros in the SUSE family, [30]openSUSE MicroOS and [31]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 [32]transactional-update command . This has [33]helpful man pages and a [34]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 [35]SUSE's Kubic Project back in 2017, although that was [36]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 :
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.
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:
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. ®
Get our [37]Tech Resources
[1] https://news.opensuse.org/2024/01/15/clear-course-is-set-for-os-leap/
[2] https://get.opensuse.org/leapmicro/5.5/
[3] https://www.theregister.com/2022/10/05/suse_alp_v001/
[4] https://www.theregister.com/2023/02/14/make_linux_safer_p1/
[5] https://www.theregister.com/2023/02/16/bulletproof_linux/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://www.theregister.com/2020/07/09/suse_acquires_rancher/
[8] https://www.theregister.com/2021/06/04/opensuse_leaps_to_153_now/
[9] https://en.opensuse.org/openSUSE:Factory_development_model
[10] https://github.com/openSUSE/zypper
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] http://snapper.io/
[14] https://bcachefs.org/
[15] https://www.theregister.com/2022/03/18/bcachefs/
[16] https://www.theregister.com/2022/05/12/fedora_36_released/
[17] https://www.theregister.com/2020/01/13/zfs_linux/
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[19] https://github.com/ostreedev/ostree
[20] https://xkcd.com/1597/
[21] https://www.theregister.com/2023/12/19/debian_to_drop_x86_32/
[22] https://www.theregister.com/2023/12/08/opensuse_vote_on_logo/
[23] https://www.theregister.com/2023/12/08/systemd_255_is_here/
[24] https://www.theregister.com/2023/12/01/cinnamon_6_kde_6b/
[25] https://tldp.org/HOWTO/SquashFS-HOWTO/whatis.html
[26] https://www.theregister.com/2022/06/17/ubuntu_core_22/
[27] https://www.theregister.com/2023/06/06/desktop_ubuntu_core_in_2024/
[28] https://www.theregister.com/2023/11/08/ubuntu_core_desktop_details/
[29] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZagHt4wHBaL4a122C7MPFQAAAM8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[30] https://microos.opensuse.org/
[31] https://www.suse.com/products/micro/
[32] https://github.com/openSUSE/transactional-update
[33] https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html
[34] https://kubic.opensuse.org/documentation/transactional-update-guide/transactional-update.html
[35] https://www.suse.com/c/introducing-kubic-project-new-open-source-project/
[36] https://kubic.opensuse.org/blog/2022-06-10-kubic-retired/
[37] https://whitepapers.theregister.com/
re: A read-only root file system makes the OS much more resilient against disk corruption,
Steve Davies 3
That is only half true
If a disk/ssd/nvme is going bad with a hardware fault, a read only FS will not protect you.
The R/O filesystem will only protect you from some threats. If the bad guys find the password or can crack it then read only won't stop the bad guys.
Many of us long time Linux users follow the KISS principle. All this containerization malarkey is a monster step too far. Sorry. The SUSE users I know love the old KISS approach. They will not like this move.
Why do Linux Distro management keep shooting themselves in the foot like this? We are just getting over the IBM/RedHat madness with CentOS and hiding sources then we have this...
I would like them to [see icon]
Re: re: A read-only root file system makes the OS much more resilient against disk corruption,
Liam Proven
[Author here]
> If a disk/ssd/nvme is going bad with a hardware fault, a read only FS will not protect you.
Absolutely true, but I think the key thing is that there are _already_ tools & tech to help with that kind of threat, such as RAID, drive mirroring and so on, and they are to some degree hardware- or kernel-level stuff. That means they are in a different realm from distribution design. Distro designers are trying to find new ways to protect distros _as well as_ existing measures such as this.
The bigger picture view: iOS, iPadOS and Android have shown that immutable OS deployment and image-based update distribution works, well, in the field, at vast scale, on devices with no local tech support. This stuff is out there today and used by literally billions of people. It works.
Distro vendors are now scrambling to bring this _kind_ of tech to end user OSes, to server OSes, and possibly most lucrative of all, to IoT and edge devices (because there are lots of them and they stick around for years, unlike datacentre VMs which tend to be evanescent).
> If the bad guys find the password or can crack it then read only won't stop the bad guys.
Well, it might. This is future tech, not out yet, but Endless OS is a good example, which I wrote about here:
https://www.theregister.com/2023/01/12/endless_os_5/
I've been experimenting with Endless for years. It doesn't matter if you make yourself the root user: the root FS is still read-only. *Even root can't change it.* There *is* no normal package manager and even if you get root you can't install one.
> Why do Linux Distro management keep shooting themselves in the foot like this?
Well, because they want to sell millions of licences to automobile makers, for instance.
If you alienate existing users to achieve something you think is important then either it really isn't important to them or you've done an inadequate job of explaining why it really is important to them.