The particularly unfortunate part is, as much of the world's commercial hosting runs on RHEL, it's the world that doesn't get this until 2020. Well, except for services that roll custom kernels.
I highly recommend making the switch. They've been doing the package management thing the longest, and it shows, both in package selection and how smoothly it all generally runs. And I've never had less trouble upgrading from one version to the next than on Debian.
I would counsel against using anything but RHEL or one of its clones in production, especially if you're running on bare metal. None of the Tier-1 server vendors support anything but RHEL. This is incredibly important if you care about ever upgrading your firmware, or debugging hardware/software integration issues. Otherwise you get trapped in vendor-fingerpointy hell.
Another good reason to stick with RHEL is that they do a very good job of maintaining compatibility between minor releases. You're pretty much guaranteed to be able to install a third-party package across all minor releases. If it installed on 6.0, odds are it will install and work on 6.4 without issue. Others make no such guarantees.
RHEL has way, way better (and accurate) documentation than any other distro I've used, particularly when it comes to unattended installations and server configuration tuning. Other distributions tend to focus much more on desktop users than massive server installations and their particular needs.
It's a common complaint among people that RHEL is always too far behind the curve in terms of software packages. But really, your OS will be stale the day after you install it, much like a car loses so much of its value the day you drive off the lot. Freshness is a tempting siren, but can lead you onto the rocks.
If you're a sane implementor, you're going to stick with any distribution you choose over the course of several years. You will favor uniformity over freshness, and stability over constant (and arguably needless) work. And no matter what distribution you choose, you are very likely to roll your own packages of whatever software is critical to your business, as you'll need custom patches and so forth.
"You are very likely to roll your own packages of whatever software is critical to your business, as you'll need custom patches and so forth."
If you care about taking advantage of prompt security updates from your distro provider, you will do this as little as you possibly can. Otherwise you need to pick up that burden yourself, and since most of us aren't security pros, it is a weight that should be assumed with great reluctance. You're no doubt familiar with the dilemma: Are you going to attempt to maintain stability (which isn't at all guaranteed) by backporting patches, or annoying your ops people by forcing version upgrades?
To a certain extent, how bad this gets is a function of how out-of-date your distro is. This is where having packages that are 4 years old can bite you -- you end up rolling your own far more often than you really should. Overuse of tools like virtualenv leads to the same problem.
I wasn't necessarily referring to security updates. I was referring to core service subsystems, like webservers, caches, databases, Java VMs and the like. Most large, mature companies I've worked with (who were all core web properties) maintained their own versions because they had enterprise needs that required specific functionality beyond what the basic packages could provide. Sometimes they tune the code itself with custom patches to fix bugs or improve scalability.
If you're betting your business on this software and are operating at scale significantly larger than the typical Web service, odds are you're not going to live on the distro-provided packages for very long.
It can work out O.K. if you stick to patching srpms of the official releases. For example, in the past I've needed to patch performance fixes for RAID cards into the kernel. When set up carefully, this is easy, repeatable, and has minimal impact.
On the other hand, one of the nice things about RHEL is you hardly ever have to upgrade major version... RHEL4 has been around since 2005, and is only now finally being phased out.
In comparison, I think "sarge" was the stable Debian in 2005. "sarge" is no longer oldstable- nor is etch. oldstable is "lenny", released in 2009.
Don't get me wrong, I like Debian, but when you compare "ease of upgrading", don't forget to consider "need to upgrade"!
True, but don't forget that the longer you wait with upgrading, the more compatibility issues you may run into when you finally have to upgrade. Linux has changed a lot since 2005.
I'm more devops than sysadmin, so more expertise may have changed my experience, but when I did run a CentOS server, I thought, "yay, this is great"... until it came time to actually update.
Then, I realized that I had simply been accumulating up all of my upgrade pain as debt - with compound interest.
By comparison, upgrading Debian servers from version to version felt like hopping from bed to bed in a mattress store. Aside from a missed footing or two, it was usually a nice soft landing.
Yes! Plus I get an unreasonable amount of satisfaction out of that server I last imaged in 1998 running the latest version of Debian. So awesome -- it might outlive me, and if it does, it'll be up to date!
> one of the nice things about RHEL is you hardly ever have to upgrade major version
This is a huge downside for me. I worked for a remove server management company, and every time I had to work on a new (to us) RHEL4 or RHEL5 server (or CentOS equivalent), it was like pulling teeth. In order to run half the software our clients needed, I had to compile newer versions of daemons, create our own RPM packages, patch and recompile code. RHEL5 didn't even include memcached for crying out loud!
For 'enterprise deployments' I can understand wanting to go with RHEL if you don't know much about server administration and want to make it 'easier' on yourself, but even for basic web apps, most of the software you'll want to use is absent, out-of-date, or incompatible. I can't imagine anyone working for a startup wanting to use it.
That's true. I like the Debian ecosystem but I also like the idea of putting off an upgrade for 5 years, so I'll probably give an Ubuntu LTS edition a try at some point. Unfortunately my past experience in updating between Ubuntu versions has not been encouraging. Probably best to try it on a box that'll be reimaged or retired rather than updated.
Debian was my first linux distro and moving from stable to testing repos the first time was a real pain in the ass. After doing it once or twice, and reading a ton of stuff and learning what was actually going on when I was changing settings, I was much better off.
also, you can easily get the latest linux kernel to work with Debian; Im currently running the 3.2 kernel on squeeze, although it comes with 2.7 by default. And im no kernel hacker; they have an easy way to do just this:http://www.debian.org/releases/stable/i386/ch08s06.html.en
The particularly unfortunate part is, as much of the world's commercial hosting runs on RHEL, it's the world that doesn't get this until 2020. Well, except for services that roll custom kernels.