Tech Choices - Why we use Centos instead of Debian / Ubuntu

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.

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.

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.

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.

"Many people ask us why not use Debian-based systems such as Debian or Ubuntu server. We do support these if there is no other choice, but in our experience, they are not nearly as stable or trouble-free as RHEL/CentOS."

So while they do have "less experience" they do have ongoing experience with Debian or Ubuntu. They say. We don't know what that means it could mean 1 machine per year or it could mean 10 per month.

Now if they hadn't needed to support essentially any Debian/Ubuntu that might mean they are stale in that area. So without qualification of their exact experience "how often" it is really hard to tell the bias in that statement wouldn't you agree?

I take the contrasting view (vastly prefer Enterprise Linux) but write software that has to support many distributions.

Generally speaking, there are better package review standards applied to Fedora (Red Hat and CentOS upstream) and you don't have things like debconf that make figuring out how to do a non-interactive install a little confusing. This means that in general there is less "randomness" that will occur than in your typical apt package.

Kickstart is also easier for users to bootstrap installations than preseed files, which in many cases require scripts to all be written on a single line. Writing preseed files causes me immense pain.

.rpmnew is also a nice system for replacing configuration files. By contrast, I've had apt purge fail when files were deleted prior to running the purge.

Ultimately I'm not sure what kind of repositories you are working with, but that may be the problem.

I would choose CentOS or RHEL every time.

Many slowness issues can be solved by maintaining a local mirror and also by disabling the fastestmirror plugin -- while perhaps good for slow connections, the mirror speed checks cause added delays.

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.