Hacker News new | past | comments | ask | show | jobs | submit login

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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: