AlmaLinux 10 is joining RHEL 10 in public beta testing, and the developers of CentOS Stream 10 have just hit the release button ahead of the festive break.
As the holidays approach, so does a new version of Red Hat Enterprise Linux. AlmaLinux 10 is now going into beta test. This version is codenamed Purple Lion. If you want a quick overview of what's new, AlmaLinux's release notes are only about ten pages long. (This compares to a whopping 142 pages for the RHEL 10 beta release notes.) Nearly half of Purple Lion's release notes are the list of devices in "Extended hardware support" - in other words, the kit that AlmaLinux still supports that has been dropped from RHEL.
The AlmaLinux beta has arrived about a month after Red Hat released the beta version of RHEL 10 for public testing. It's based on Fedora Linux 40, which appeared back in April.
As usual, the AlmaLinux release notes provide a much more digestible summary of what's new in this version than the IBM subsidiary's epic. RHEL 10 will require version 3 of the x86-64 instruction set - we described the different versions a couple of years ago.
Back then, we used the same terminology as SUSE did: x86-64-v1, x86-64-v2, and x86-64-v3. We are avoiding that now. Early this month, paramount penguin Linus Torvalds expressed his considerable unhappiness with these version levels:
Even though this geriatric vulture will never be a kernel contributor, we wouldn't want to upset Mr Torvalds. The AlmaLinux folks are less worried, and they still use the shorthands. The release notes spell out that they have slightly more relaxed system requirements than RHEL 10 itself. There's a separate x86-64-v2 edition of the AlmaLinux 10 beta, but it's only intended for older hardware:
Other components have been dropped in this release. This was expected for X.org as well as for LibreOffice. It also includes Firefox and the Thunderbird email client. This removal also includes 32-bit support, even the supporting libraries. Red Hat's release notes recommend installing the Flatpak versions of the apps, while AlmaLinux continues to supply the Mozilla apps as packages.
RHEL 10 and all its downstreams use kernel 6.11, which was released back in September. This is despite the fact that kernel 6.11 was a short-term release, and it's already been superseded now. The final version, 6.11.11, came out on December 5 and the announcement said:
In other words, the future RHEL 10's kernel is already end of life today, while the final release is expected around May next year. This demonstrates the complexity of timing release schedules. When Fedora 40 came out in April, it used kernel 6.8. At the point when the Big Purple Hat's beta initially came out, kernel 6.11 was current; kernel 6.12 was released on November 17, four days after the RHEL 10 beta.
All the big enterprise-focused Linux distros maintain their own independent kernel versions and pay no heed to the kernel team's LTS versions. We've written about what it takes to keep an enterprise 'Frankenkernel' alive before. However, just because something is normal and common doesn't mean that it's the right thing to do.
This is the first major release of RHEL since LWN editor and kernel maintainer Jonathan Corbet spoke at the Open Source Summit 2023 about overwork and burnout in the kernel team. It also follows SAMBA developer Jeremy Allison's provocative blog post, "Cracks in the Ice," which we summarized as "long-term supported distros' kernel policies are all wrong."
This problem is being aired in public now. Canonical has changed its kernel version policy to prevent Ubuntu from shipping with kernels that are very close to their end of life date. Red Hat had a chance to step up, adjust its release cycle just slightly, and update RHEL 10 while it was still in beta to use the now-LTS kernel 6.12, but it hasn't. That means, as it's done many times before, Red Hat will be fixing and maintaining an end-of-life kernel for the next decade. It can do that. It has total freedom to choose whatever versions it wants, and there is no question that it is perfectly able to do it. The company has the manpower, the expertise, and the money to pay for this maintenance effort. Whether this is any kind of problem for Red Hat customers is at worst debatable, but almost certainly not. Red Hat is a huge force in the Linux industry, and everyone else works around it.
The real point is that Red Hat is not playing as nicely as it could with the wider Linux world. Red Hat could have chosen to help in the burden of maintaining kernel 6.12, at least for the first two years of RHEL 10's life. It is not under any obligation to pass any of its backported fixes and functionality upstream. Why should it? That's what its customers pay for. However, the company could have picked the kernel that came out just four days later. This was almost certain to be the next LTS kernel. Doing so would have enabled it to upstream the fixes it developed in-house. It would have been a modest temporary inconvenience for one release, but it would have helped the Linux kernel team, whose work every distro depends upon.
And there is evidence that this was a possibility.
The AlmaLinux 10 beta announcement calls out the fact that AlmaLinux 10 and the project's internal upstream version, which is called AlmaLinux OS Kitten and which we described back in October, are already out of sync:
In other words, CentOS Stream 10 is already ahead of RHEL. This is very visible: CentOS Stream 10 was released just one day after AlmaLinux 10 beta. Look what it says in the Centos Stream 10 release notes:
If nothing else, this does serve as an effective demonstration that CentOS Stream is not some kind of disguised rolling beta for what will go into RHEL. Stream continues to develop its own, separate identity. Like Fedora, it has value for Red Hat as a testbed. It just has less value for the wider world than its predecessor, CentOS Linux. Much as vendors maintaining their own in-house kernel versions has important value for their customers, but is less useful to the wider world.
Rightly or wrongly, Red Hat lost a lot of good will among the wider Linux community over killing CentOS Linux and replacing it with something that, as the release of CentOS Stream 10 demonstrates, is significantly different. Linux, as we have said recently, is a mature stack of software now, which means it's not changing all that radically or rapidly. You can switch a distro's kernel versions quite easily without breaking anything. Fedora routinely upgrades the kernel version after release, Canonical puts out HWE updates to its LTS releases, and there are even third-party kernels such as Liquorix.
Red Hat doesn't need to even think about upstream LTS kernels. The company may not even have considered it, but there was an opportunity here. By changing its practices slightly, the company had a chance to reclaim some positive feelings, just by selecting a kernel version that was one minor release later. Stream 10 demonstrates that it wouldn't have been hard to do. Had it wanted, the Hat could have chosen the current LTS kernel, and then starting, next year some time, to upstream some bugfixes, and keep doing so for a couple of years. If it keeps to RHEL's three-year release cadence, version 11 should ship in 2028. The next time it has to make this difficult choices isn't for a whole four years. A lot can happen in that time. For example, it's plenty of time for lots of people's careers to be destroyed by burnout. ®