Red Hat Enterprise 3 bit rot: spamassassin [LWN.net]

Red Hat Enterprise 3 bit rot: spamassassin

Posted Jun 13, 2005 7:04 UTC (Mon) by djao (subscriber, #4263)
In reply to: Fedora is free by ronaldcole
Parent article: Red Hat Summit Day 3: Fedora is free (NewsForge)

I have to disagree with your assessment of spamassassin in Red Hat Enterprise 3 as "bit rot". Please note that I am not suggesting that you are expected to agree with me. One of the great strengths of Linux is the diversity of offerings available. If you prefer SuSE's maintainence policies, by all means become a SuSE customer and let the free market decide.

Red Hat Enterprise is not designed to have the latest and greatest software. In fact, as far as I'm concerned, its purpose is almost the opposite. Most RHEL users want as nearly as possible to keep the same version numbers on all system software for as long as possible. Red Hat is the only linux vendor who is willing to commit to maintaining the same software versions for seven years. Not even the venerable Debian distribution, long the butt of antiquated software jokes, provides seven years of security support for their stable releases.

Now, I do admit that the spamassassin 2.55 used in RHEL 3 is useless. If you want to upgrade to a more recent version, you have at least three options. You can go to the spamassassin download page where they provide a very clear single command for building newer RPMs (and these RPMs work in RHEL3). Or you can install an updated pre-built RHEL3-specific spamassassin package from the well known DAG repository (and this can be automated with apt-get). Or you can of course upgrade to RHEL4 which has lots of extra goodies. But the point is, it's your choice and you have lots of choices. Forced upgrades should never be a part of the game. Red Hat Enterprise 3 at least gives you the option of continuing to use the exact same version that came with the system. No other linux vendor gives you that option and backs it up with security updates for seven years.

There are extremely rare occasions where Red Hat Enterprise is forced to upgrade a component to a newer version for security reasons, because the security fixes were too intrusive to backport into an older version. These events always cause a lot of pain to those who have third party software that depends on the specific older versions. One recent example that comes to mind is the mozilla-1.7.8 upgrade, which made it impossible to compile galeon on RHEL3. Although this example may seem to reflect negatively on Red Hat, the point is that every other distribution suffers from version treadmill even more. RHEL limits such incidents to the absolute minimum. (Compare this with debian woody, which never upgraded from the security-hole-ridden mozilla 1.2.1 -- not a good choice, IMO. In such a difficult scenario the vendor should at least provide the security updates and let the user decide.)

"If it ain't broke, don't fix it" is the general rule regarding RHEL software maintainence. Time will tell whether that approach is valued by the marketplace.

(Log in to post comments)