The Significance of Red Hat Linux 9

[This article was contributed by Ladislav Bodnar]

At first glance these changes might seem insignificant. But a closer look reveals that there are reasons why they come into effect at this point in time and some of these changes will have substantial impact on enterprises.

Firstly, let's look at the significance of that "9". Of all Linux distributions out there, Red Hat is the only one that maintains a technically and logically justified versioning scheme, as opposed to a scheme driven by marketing. Historically, Red Hat only increased the major version number if the new release broke binary compatibility with the previous one. The binary compatibility was, to a large extent, defined by the the glibc library and if we look at the last few years' worth of releases, we will see that Red Hat 6 series shipped with glibc 2.1.x, Red Hat 7 series with glibc 2.2.x and Red Hat 8.0 with a pre-release version of glibc 2.3.

Red Hat 9 will ship with glibc 2.3.2. However, there is something else that breaks the binary compatibility in this case and that something is called NPTL (Native POSIX Thread Library). What is NPTL? A comprehensive white paper (in PDF format) explains all the technical details, but in layman's terms, NPTL is a much improved new library for threading of processes which takes into account capabilities of modern processors. This library, developed by Red Hat, is designed to replace the existing library written back in 1996. (See also LWN's coverage of NTPL from last September).

As a result of introducing NPTL, many applications compatible with previous Red Hat releases will no longer work on Red Hat Linux 9. Some of the implications are explained in this mailing list post. The poster (Red Hat's Matt Wilson) also points out another interesting fact: the Enterprise Linux series of products has freed the company to put newer technology into the base "Red Hat Linux" distribution. Red Hat Linux is starting to look like the final proving ground before software moves into the (more stable) Enterprise distributions.

Also note the missing ".0" from the version number. This has possibly something to do with market perception (whether it is correct or not is a different matter) that x.0 releases are generally buggy and unsuitable for deployment on servers. Whatever the meaning, this is not a new tactic for Red Hat; Red Hat Linux 7 also lacked a ".0".

The quick succession of major number releases was noted by many Red Hat Certified Engineers (RHCE). Up until now the validity of the rather pricey, but highly valued RHCE certificates was limited to two major releases. Red Hat was quick to react with a policy change: "The validity period for all RHCEs and RHCTs is now officially pegged to the release of the Enterprise product commercially available at the time certification was earned, and certification shall be current until after one (1) major release of the Enterprise product." More details are available here.

All these changes, together with the recently announced restrictions on free access to Red Hat Networks and reduction of support periods are designed with one goal in mind: to increase Red Hat's revenue. Despite some voices of criticism, one cannot blame the company. Red Hat Linux has become the dominant Linux OS on servers and there are possibly thousands of enterprises around the world that use Red Hat's products without ever paying a single cent to Red Hat. The time has come to collect the toll.

As Red Hat tightens the screws, the small and medium enterprises with limited IT budgets -- especially in the current economic climate -- are the ones that are being affected and might even re-evaluate their needs. But do they have alternatives? After all, there are so many Linux distributions, so why use Red Hat? The awful truth is that, for many customers, the alternatives are not particularly appealing. Mandrake and SuSE, despite their ranges of enterprise products, are still perceived as distributions for desktops. Slackware's total lack of interest and ability to market and provide commercial support for their otherwise excellent server product leaves it as a viable choice only for experienced Linux enthusiasts, rather than medium-skilled system administrators. The only other alternative is Debian. But for Debian to make inroads into server rooms, corporations would have to learn to live with a product made by volunteers in their spare time, without any commercial interests. And that's something that is unlikely to happen on a large scale.