The Reg has collated information that points at the direction of the Adaptable Linux Platform – SUSE’s future replacement for its conventional distros.
One element is relatively straightforward, but may be unexpected – possibly requiring version 3 of the x86-64 spec. Since a discussion in 2020, there are now four defined levels of x86-64 architecture:
x86-64-v1equates to the original AMD K8 architecture, as in the original Opteron in 2003.
x86-64-v2means Intel “Nehalem” and later: AVX2, plus SSE4.2 and SSSE3 (most processors after approximately 2008-2011).
x86-64-v3means Intel “Haswell” and later: AVX2 with vector extensions, and a big-endian
MOVBEinstruction (most processors from 2013-2017).
x86-64-v4means several flavors of AVX512
Compilers have supported these levels since GCC11 and LLVM Clang 12. Over in Red Hat territory, distros since Fedora 32 in 2020 and RHEL 9 this year have targeted and required
x86-64-v2. So far, we haven’t heard anyone complaining too much about it – but requiring
x86-64-v3 is another matter.
Although SUSE is not yet confirming anything, recent announcements from the openSUSE project are giving some ideas of how this future family of distributions might look. The openSUSE project is asking users to try out the MicroOS Desktop distro “to gain user perspectives on its applicability.” The distro offers both GNOME and KDE flavors, and is still somewhere between alpha and beta testing stage depending on which desktop you choose.
The openSUSE community also has a working group discussing the impact of these technologies. Interestingly, one of the early reactions we’ve read is strongly positive.
OpenSUSE MicroOS, along with its commercial sibling SLE Micro, are immutable-root distributions. As we discussed last year, Linux distro design is changing under the influence of containers, Kubernetes, and containerized cross-distro packaging formats. This tends to be unpopular with many Linux techies, but non-techie users neither know nor care… as is suggested by the strong sales of Chromebooks in recent years.
When The Reg FOSS desk looked at Fedora 36, we talked about its Silverblue and Kinoite editions in some depth. Both use the OStree tool Red Hat built for snapshot-based deployments on file systems without snapshot support.
Providing transactional installation and rollback is considerably simpler in SUSE and openSUSE because they default to using the Btrfs file system, which directly supports file system snapshots. Oddly, although the recently updated Ubuntu Core IoT distro also uses transactional updates, it doesn’t use ZFS to provide snapshots. Google’s ChromeOS achieves comparable results using a complex partitioning system.
The move towards immutable distros, where the root file system is write-protected and OS updates are provided in large, heavily integration-tested transactions, looks increasingly inevitable. As this reduces the importance of package-management tools, it fits well with containerized app deployment.
For SUSE, this direction was set when it acquired Rancher, a container-centric company. Red Hat’s 2018 purchase of CoreOS in 2018 seems to have had less impact, with the distro summarily terminated just two years later, but its Project Atomic was already heading in that direction years earlier.
It is early days yet, but ALP may spell the end of the traditional versioned Leap and SLE distros, managed with Zypper and YaST. There may not even be a direct in-place upgrade path. However, boldly seizing the technological initiative like this could give SUSE an edge on its rivals and their more cautious approaches. ®