AlmaLinux 9.4 beta prepares to tread where RHEL dares not

CIQ also has an alternative approach to compatible kernels with RockyLinux

The bigger RHELatives continue to diverge slightly from Red Hat, with additional drivers and newer kernel versions.

The AlmaLinux project has announced the beta of version 9.4, with some small but intriguing differences from Red Hat's plans for RHEL 9.4. The Alma 9.4 beta follows 20 days after Red Hat announced the beta test of RHEL 9.4 and RHEL 8.10.

As usual, the IBM subsidiary has a humongous set of release notes for the 9.4 beta, which in PDF form totals 167 pages. Highlights include new driver support for kit including Intel's Data Streaming Accelerator, NVMe-over-TCP, and support for DEP and the NX bit as early as the GRUB bootloader. Plus, at long last, support for Intel's Software Guard Extensions. It took Intel a few years to offer Linux drivers after SGX first appeared in 2013, and The Reg has been reporting on issues with the tech every year or two ever since.

The AlmaLinux team's beta release notes are much shorter and more to the point, especially the changelog section. This summarizes the highlights: Git 2.43, Git LFS 3.4.1, plus some optional new versions, Python 3.12, Ruby 3.3, PHP 8.2, nginx 1.24, MariaDB 10.11, and PostgreSQL 16.

What's interesting is that Alma Linux 9.4 is set to support kit that RHEL $NEXT will drop. The beta modifies a small list of device drivers (aacraid, be2iscsi, hpsa, lpfc, megaraid_sas, mpt3sas, mptsas, qla2xxx, and qla4xxx) to include PCI device IDs that Red Hat has removed. This will enable the drivers to work with a list of hardware that RHEL will soon no longer support.

Meanwhile, in Rocky-ville…

Although there's no news yet of the corresponding beta of Rocky Linux, its primary backer, CIQ, has announced an interesting new move. It is offering Rocky Linux users the choice of using upstream LTS kernels.

Jeremy Allison, Distinguished Engineer at CIQ, told The Reg:

Generally speaking, upstream stable kernels provide greater security than vendor kernels. The Linux kernel interface to user space is what provides the stability that application vendors and customers rely on to support their most critical workloads. Also, although some customers rely on absolute RHEL kernel compatibility in order to support device drivers not yet merged into the upstream kernels, we believe the majority of customers would get greater security and performance by using upstream stable kernels.

CIQ's interest in long-term support kernels is documented. It is a primary backer of the Open Enterprise Linux Alliance, and, as we reported last month, the OpenELA recently brought kernel 4.14 back into maintenance. On US Independence Day last year, we reported on how the Rocky Linux development team is obtaining RHEL kernel sources, and soon afterwards, on Oracle and SUSE getting involved too.

Perhaps we are being overly suspicious, but we wonder if the alliance is encountering some blockages or hiccups in this code pipeline, which could be why it's looking into alternative paths.

Extra work to bring kernel 4.14 back into maintenance again was needed because the kernel team has cut the number and lifetime of long-term kernels.

For as long as there have been long-support-lifetime enterprise distros, each vendor chooses its own kernel version for its long-lived products and then maintains it for years. As we said when reporting on Canonical's support lifecycle for Ubuntu kernels, we feel that this is not ideal.

For us, the best outcome would be that the enterprise vendors coordinated with the upstream kernel team, and they all worked together on shared, common LTS kernel versions. There would still be plenty of room for differentiation – they could continue to offer their own enhancements and backported functionality. ®

More about


Send us news

Other stories you might like