I've been supporting production RedHat and CentOS servers since RH 7 (15 years), and while RHEL 6 is a huge improvement over the bad old days of up2date and RPM dependency hell, RedHat still has a long way to go to catch up to where Debian was 10 years ago. The quality of packages on RH is still piss-poor compared to Debian (regularly missing man pages, broken default configurations, etc), and if it's not in RH core or EPEL, you're pretty much building it from source because finding up to date third party rpms that target the right version of RHEL is nearly impossible. yum is enormously slower than apt (I've clocked it at 10x slower on average on identical hardware), and rickety as crap. You get into dependency deadlocks regularly that require you to remove whole swaths of rpms just to clear out a conflicting dependency. Yum's use of an ancient version of Python mean that supporting modern python applications on RHEL means you're building all your own Python RPMs and installing in non-standard locations, or you end up breaking yum.<p>At my current job, we pxe install thousands of CentOS compute nodes and never touch yum again. When it's time to update, we build a new kickstart and re-install. That's the only reasonable way to run RHEL/CentOS and not lose your mind.<p>I have debian systems that are still running dist-upgraded versions of 10 year old installs, and the dpkg database is sane and clean. You can't do that with RHEL.<p>The unfortunate fact is that, in the enterprise world, people other than system admins make the decision to run RHEL at the expense of sysadmin time and sanity.
I see no discussion of package management in here, which is kind of a bummer. My experience with yum has been pretty crummy and I don't think it's improved over the last several years. That alone should drive someone developing software away from working on that platform.<p>Centos & Red Hat are great if you have a single package you need to deploy to a machine and all the dependencies are already there or easy to pull down from yum. You get the advantage of not having a capricious OOMKiller process that can randomly take down your system. But if you're actually in the process of building something, working on Centos is just a pain in the ass.
> <i>[W]e need reliability and predictability over a large variety of systems over many years. We need strong support by most of the world's software vendors and open source project. We need documentation, tools, and global resources for the most commonly used systems.</i><p>In which of these does Debain fall short?
FreeBSD has a very stable core distribution with an up-tp-date rolling release "ports" system for additional software. It's great for these purposes. It also has excellent documentation, stable native ZFS, and compatibility with Linux binaries.
This is a content-free article. It boils down to "we've committed to CentOS, so that's what we prefer to use."<p>The claim that "in our experience, [Debian/Ubuntu] are not nearly as stable or trouble-free as RHEL/CentOS" says more about their lesser experience with those systems than it does about Debian or Ubuntu.
Really the only major things that annoy me[1] about using ubuntu LTS as a server are:<p>- The fact that packages which install server software autostart the server on install, and the mechanism to disable this can vary package to package. I'd rather install-configure-then-start than install-disable-configure-then-start.<p>- The mechanisms for setting options for packages to be installed are geared towards interactive use. You have to disable it popping up a curses dialog, and I don't think there's an easy way to pre-configure them so you just wind up with defaults if you do.<p>- The version of upstart in 12.04 is really limited, and the mix of packages using old and new style init can be frustrating at times.<p>[1] Perspective check: I'm mostly a software developer, but I also admin my own servers for personal projects as well as having it as a peripheral aspect to my job at times.
Redhat puts a lot of effort into building its enterprise distro. Yeah, it's mostly out of FOSS parts, I get that, but distros are nontrivial and costly undertakings.<p>I've always had a bit of a problem with Centos, which as I understand takes Redhat's work, removes the proprietary parts, and redistributes for free-as-in-beer - perhaps depriving Redhat of a sale or two. It's not exactly theft, but not sporting either.<p>Would somebody straighten me out? Am I wrong to avoid Centos based on social principle? What does Redhat think of Centos?
At work I run close to 30 VM's on Ubuntu. I chose Ubuntu for two reasons. I've been running it on my desktop for years and thus know how it works. And CentOS did not have the newer versions of various packages I needed in its default repos.<p>For the couple years I've been doing this, I can't think of any downtime that wasn't caused by something other than the OS.<p>Heck, even my desktop hasn't had OS caused downtime.<p>I would bet my experience would be the same if I was using CentOS.<p>Also, there are so many different ways you can automate your server and app deployments, that your choice of OS should really depend on what app you are running. A cutting edge app might need the latest Ubuntu release to get the latest packages. Another app might need the stability of an LTS release. And another might only work with an RPM based OS and specific versions of dependencies that are only found on CentOS.<p>Anyway, that's my opinion and experience. I am curious if there's statistical/scientific evidence supporting the idea that CentOS/RHEL is more stable than Debian/Ubuntu.
Is it generally considered better to go with a better supported OS (eg CentOS or an Ubuntu LTS) and use extra package sources for non-OS programs or to use a more up to date OS that's already tested with the latest programs?<p>We made this choice recently, choosing Ubuntu 12.04 and a few (popular but unofficial) PPAs, rather than use Ubuntu 13.04.
I've usually hated using RPM/Red Hat based distros because they tend to create giant headaches whenever you need to use a relatively recent release of a library or application and because I just don't like their package manager.<p>I think most people's problems with Ubuntu having too short of a release cycle come from people installing the current version of Server instead of the LTS version. I've known shops that stupidly used non-LTS Ubuntu server releases, and then kept them running after their support cycle ended...<p>I think maybe that's what happens when people who don't really know how the Ubuntu ecosystem just start using stuff.
Why not have a tested Gentoo image and all servers with two root partitions to alternate between them on upgrades? The image can then be updated, tested and deployed (using pxe) when you feel the need.
Also, using puppet or chef or even emerge of binary packages (by an in-house built deployment solution), one can install supplemental packages on a running system if needed.
From my experience, having a fully source based Linux system is good for performance, security and - last but not least - stability.
I respect RHEL/CentOS but for ease of use (packaging system,vast amount of packages, easy upgrades) I prefer Ubuntu/Debian for my server and desktop.
"Stable" sometimes means people are more familiar with the bugs than bug-fixes...
Conservative tech choices: I'm only familiar with X so I don't choose Y like you guys who are familiar with both. -- This is OK because the benefit of better tech doesn't matter so much for their business.