Home

Search Posts:

Archives

Login

January 2014

S M T W H F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

In the past, I've always run Red Hat Linux on my boxes at home. Sure, it had its quirks (RPM dependency nightmares, RH-specific config files, etc), but RHL was always rock solid, reasonably current, and cheap. Although I made a point to at least try other distributions, RHL was the measuring stick - and everything else just came up short.

Then came last year's bombshell - RHL was no more, and even RHL 9 was to be EOL'd in early '04. What's a guy with RHL on everything to do?

Out of desperation, I upgraded my EOL'd RHL boxes to Fedora Core, Red Hat's new "community driven" Linux distribution, hoping it would be a good interim solution that wouldn't involve a complete rebuild. I was reasonably satisfied with Fedora Core 1 at home, so when I took my current job last November I upgraded the EOL'd RHL systems at work as well. Unfortunately, given some reported problems with Core 2, combined with the rapid pace of changes and the semianual forced upgrades, I knew I'd need a better solution for the long haul.

I initially assumed I would end up with the same distribution for all of these former RHL machines. I hashed out the following lists of requirements:

Work:
1) Proven stability
2) Software availability
3) Ease of administration
4) Feature freeze - not a moving target
5) Longevity (long-term patch availability without forced major version upgrades)
6) Inexpensive

Home:
1) Stability
2) Software availability
3) Ease of administration
4) Longevity
5) Inexpensive
6) Flexibility

So the search began.

I'll start off by saying that every Linux distribution I've tried has at least one incredibly annoying aspect that keeps it from being perfect for me. RHEL updates cost far too much, Fedora Core is bleeding edge and has major version upgrades far too often, SuSE also suffers from frequent version upgrades and is a configuration nightmare due to the monolithic YaST, gentoo is too bleeding-edge and compiling patches is annoying on slower systems, etc.

After trying every flavor of Linux known to man, I finally narrowed down my options to a few finalists. FreeBSD (no, it's not Linux, but from a functionality standpoint it is similar), CentOS Linux, White Box Enterprise Linux, and Debian GNU/Linux.

FreeBSD 4 certainly met my requirements for stability, longevity, software availability (via ports), and price (free). But what about administering a FreeBSD system? I know vi like the back of my hand and I'm familiar with generic Unix concepts, but even though I've used other unices my primary system has always been Linux. From a Linux user's standpoint, the basics of FreeBSD look pretty darn similar, but as time goes on you notice that things aren't quite right. You start finding out that the --monkey option only works on the GNU version of foo, that the soandso.conf is in a different location and of a different format, and that you end up hitting man pages for commands you thought you knew by heart. I found myself wishing that the systems were either a little more similar or a little less, as I constantly ran into minor differences trying to do familiar tasks. The package management utilities for ports are spartan, and though I was able to accomplish what I needed to do, I found tasks taking twice as long as I expected them to.

For me, FreeBSD loses, but I can't help but thinking of the old breakup line: "it's not you, it's me." Package management could stand to be a bit more robust, but I imagine an experienced FreeBSD administrator could do fine with what's available. I may revisit FreeBSD when I have more time.

Now, on to the attack of the (RHEL 3) clones. White Box and CentOS are both functionally identical, repackaged-to-be-free versions of Red Hat's flagship offering, Red Hat Enterprise Linux 3. Running through my lists, RHEL 3 has everything except for price - there's a 5 year guaranteed lifespan, no constant upgrading, easy administration, and a thoroughly tested and promptly patched system with a stable set of core software. Lots of 3rd party binary packages are available in RPM format, and the chances are that you can find rpms for pretty much everything (RHEL 3 is similar to RHL 9, so most RHL 9 compatible packages should work just fine). The price meant that "real" RHEL was out of the question, so CentOS and White Box entered the picture. CentOS won over WBEL, as it's a project with multiple maintainers that seems to offer a higher probability of future support. Interestingly, it's trivial to switch a live system from either distribution to the other, as they both use yum/rpm for package management - so if the project you opt for dies and the other lives, you'll still be able to update your systems. The one achilles heal of both products - security patches come from recompiled RHEL3 srpms. Even though Red Hat is required by the GPL to provide the source code of these patches, there is nothing that says they have to make it easy for us to get that code quickly. Should Red Hat decide to pull the plug, the CentOS community will be left scrambling for a way to keep systems up to date. I imagine CentOS would become a proper "fork" at that point, with user-packaged rpms instead of recompiled RHEL srpms.

On to Debian. In a lot of ways, Debian is (to me) the Holy Grail of Linux, with a couple of glaring weaknesses that prevent me from using it on the systems at work. Debian is a joy to administer (thanks to dpkg, apt, and some other inventive solutions such as the alternates system), has virtually every useful software package available via apt, is completely free, is proven rock-solid stable with timely security fixes, includes great documentation, and has massive community-driven support.

The problem with Debian is that you can't have everything at once.

It's important to understand that Debian comes in several main flavors - Stable (Woody), Testing (Sarge), and Unstable (Sid).

Debian Stable (Woody) is the "official," frozen version of Debian, released "when it's done" and only patched to fix security issues and bugs. Woody provides one of the most rock-solid, guaranteed-to-work Linux environments out there. The problem, as you may know, is that Woody has virtually no new versions of software from the past 2 years - in fact, the default Woody kernel is still 2.2. Ouch!

There's a not-so-fine line between being "stable" and being "archaic," and unfortunately Woody crosses over to the wrong side of that line. Woody isn't exactly useless - if it has the software you need, you can set it up, automate updates, and be fairly sure you'll never have any problems with the box until the hardware fails. You can force Woody into the 21st century by pinning packages from testing/unstable or using unsupported backports - but if you install a bunch of unstable, unsupported software on Woody you have to ask yourself just how "stable" your Frankenstein system will really be.

Then there's Unstable/Testing. Sid and Sarge are closely related - newly modified packages show up in Unstable first, and only after they're proven to be fairly solid will they work into Testing. For this reason Testing often has missing/outdated packages, and is really only useful if you're willing to pull required packages from Unstable.

Debian Unstable/Testing can be bleeding edge, but it doesn't have to be. You can stick with Apache 1.3 and the 2.4 kernel, or you can easily throw on 2.0 and 2.6. Unstable/Testing includes virtually every free software package for Linux, easily installable via aptitude. I wouldn't be surprised if you could just "aptitude install the_kitchen_sink." It has an amazingly powerful package management frontend in aptitude, has a wonderful configuration utility in debconf, and has countless other little things that make it one of the cleanest, most enjoyable systems I've ever used.

The problem, of course, is that it's a moving target with questionable stability. You can mitigate some of the potential problems by selecting more stable versions of software, but in the end you can't escape the fact that Unstable/Testing is a work in progress and has absolutely no guarantees.

For work I decided on CentOS and didn't look back - its solidity and longevity made it the ideal choice for predictable systems designed to fill specific roles for years to come. Although I absolutely fell in love with Debian, Woody was useless to me without tons of backports and Sarge/Sid were just too unpredictable for production use. The only extra software I required for CentOS was ClamAV, which is available in handy RPM format and easily updatable via a 3rd-party yum repository. No fuss, no muss, statically configured systems designed to keep trucking without constant tinkering.

For home, I started to rethink my priorities. Just what was this box going to do, anyway? Flexibility seemed to really come into play, as the role for the system is very vaguely defined and subject to change frequently. Debian's massive vaults of packages started to look really attractive, and since (unlike work) users aren't depending on 100% reliability I can sacrifice some stability to gain versatility. I ultimately decided on Debian Unstable, which has continued to surprise me with its quality. I have yet to see any stability issues, and the system is a joy to work with.

Ultimately, I'm actually thankful to Red Hat for EOL'ing their venerable Red Hat Linux series of products. This has facilitated the need for the RHEL clone projects (CentOS/WBEL) which fill certain needs better than RHL, are 100% free, and never would have existed had RHL been continued. It also led me personally to re-examine Debian, which I've found to be a better solution for my personal system.

Something else of note - if you still have RHL 7/8 (maybe even 9?) machines and are trying to decide what to do with them, you can "yum up" a live system to CentOS/WBEL without having to rebuild.

New Comment

Author (required)

Email (required)

Url

Spam validation (required)
Enter the sum of 7 and 6:

Body (required)

Comments |Back