4 ms·

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

by fps 13y ago

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.

mpdehaan2 13y ago
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.

by fps 13y ago

mpdehaan2 13y ago

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.