Angst over RHEL’s Slowing Pace

Red Hat Enterprise Linux 5 is getting very old. As an example let’s look at RHEL 5’s kernel. RHEL 5’s kernel is based on upsteam vanilla 2.6.18.4. The original 2.6.18 release happened in September of 2006. Every RHEL 5 kernel is a modified version of this upstream release.

The source RPM file for building RHEL 5’s 2.6.18-128.1.14.el5 kernel contains 2680 patch files to be applied against vanilla 2.6.18.4 source. The diffstat from a full patched tree vs 2.6.18 vanilla:

 3780 files changed, 235061 insertions(+), 170479 deletions(-)

Since RHEL 5’s release they have backported large chunks of drivers, bugfixes, and new functionality from mainline to their custom 2.6.18 kernel. As a RHEL and CentOS user these efforts are appreciated. I religiously read the release notes from major updates hoping that Red Hat has blessed us with gifts backported from the mainline tree. But more often then not one ends up disappointed that some key functionality available from the mainline Linux kernel is nowhere to be found.

The userspace receives a bit less attention. Bugfixes and security issues that bite Red Hat’s biggest customers get backported and there is an occasional version bump but for the most part the userspace doesn’t get much churn. As time rolls on my coworkers and I find ourselves reaching for compilers more and more often as the included open-source tools become so outdated as to become obsolete.

In the RHEL 3 and 4 days these backports served the purpose of introducing some needed new functionality and bugfixes while providing a long supported stable environment. It was just enough so that one could get along until the next major RHEL release. The time between new major releases was about two years give or take a couple months.

Unfortunately we’re about three months beyond the two year mark since the release of RHEL 5 and the next version (RHEL 6) is nowhere to be seen. Even more concerning is that Red Hat has announced that in the next major update (RHEL 5.4) they will be introducing a new virtualization platform and spinning off new products based on it. There is no concrete information on RHEL 6 anywhere that I can find.

What do I take away from this? RHEL 6 is at least six months off if not over a year off. The userspace of RHEL 5 is getting to be so old it’s starting to stink and frankly I’m getting tired of not having access to newer userspace and kernel features. I like Red Hat as a company but I’m getting annoyed at their flagship product.

I work in a .EDU and we use Red Hat’s very generous discounts so we are definitely not one of their high margin customers. I personally maintain a mix of commercial and open source software installs and in the past I’ve chosen to standardize on RHEL and it’s clone CentOS.

Unfortunately with the RHEL release schedules becoming so long between releases it looks like it would save me time and effort to start dumping RHEL for anything except Oracle and proprietary application servers. It certainly would reduce the amount of SRPM fiddling I end up doing and give me many more options as to update frequency.

Switching between Ubuntu LTS and the most recent non-LTS is trivial compared to switching between Fedora and Red Hat. And as much as people in the Fedora camp protest this view to the outside world Fedora’s lack of polish and 13 month support cycle means it is little more than an installable checkpoint on the Rawhide road. There is no granularity between them whereas in the Ubuntu world there is.

Is this really the trend that Red Hat wants to continue? Is there nothing in between excruciatingly slow updates with long support and Rawhide? Can there be a RHEL release lifecycle that doesn’t involve end customers eventually having to drag out the compiler and replace a part of the product?