RHEL documentation is second-to-none. It's akin to old UNIX documentation, or the pre-10 offerings from Microsoft.
As an example, I wanted to set up kerberos. Red Hat had a guide on setting up IdM, covering every step in the process, often with two alternates depending on desired final state and having an intro paragraph to choose between them, full command line docs for every command ran, steps to test this was ran correctly, and troubleshooting steps for commonly-encountered errors. In contrast, the Ubuntu docs for setting up a IdM client were a wiki, half of which was for the old version, and a detailed stackoverflow response. Server and client setups took the same amount of time; the client should have been much faster.
1. SELinux. It's configured for all packages in RHEL distribution and it works. It's an additional layer of defense and think that's the most important denominator from other Linux distributions. I saw recent Ubuntu distributions shipped with AppArmor, but I'm not sure that it's as good.
2. First-class support for systemd. Well, I'm not sure that's a fair point.. But with Debian I'm always seeing some messages about sysv scripts, even when I'm using systemctl. It feels like some scripts were not fully ported to systemd or something like that. Some people don't like systemd, but I, personally, think that it's a good solution. AFAIK systemd development is sponsored by Redhat and its support is very good, all services are shipped with proper systemd units.
3. First-class support for NetworkManager, Firewalld. I think that those packages are available for Debian, but it's nice to have them installed and configured from the start, they're very convenient to use.
4. Documentation. Most of that documentation is hidden behind loginwall, but http://access.redhat.com/ contains plenty of information.
There are some drawbacks of RHEL. The major one for me is limited software selection. You need to enable EPEL even for some basic software like Strongswan, Certbot or OpenDKIM. And EPEL is not RHEL (although it's quite good).
For anyone who might be interested in Fedora-family, namely systemd, SELinux, and firewalld bits I am writing a book now about deploying with Fedora and CentOS Stream[0] and I am almost finished. With this announcement I might add RHEL support directly - the difference is just in running a subscription manager.
Also, if you are using Vagrant, you can use RHEL with a vagrant-registration plugin that automatically subscribe you (disclaimer: I made the plugin when working for Red Hat and packaging Vagrant for Fedora).
I've gone back and forth on selinux (and a bunch of other in-house stuff that RHEL makes). Yes, it has improved over the years, but it still breaks a lot. The thing with RHEL is that you really need to be paying for the support to get any value out of it. With CentOS or this beggar subscription level, you are better off using Debian or Ubuntu, because when shit breaks, all you'll do is create a bug report in any OS. With Debian or Ubuntu, you have a slightly better chance at recovery. RHEL has a strict demarcation between support levels, features, release timelines, etc. So if you report a bug to RHEL, they may not backport the fix even if it fixed upstream. And then you are just stuck.
> RHEL has a strict demarcation between support levels, features, release timelines, etc. So if you report a bug to RHEL, they may not backport the fix even if it fixed upstream. And then you are just stuck.
This is changing with CentOS Stream. Bugs can be filed against CentOS Stream in the Red Hat Bugzilla and they will do something with that bug report. Additionally, if you know what to backport to fix it, you can submit pull requests on any package in CentOS Stream to have it reviewed and merged to fix your issue. The fix would then be built and released within days of merging your fix.
From my perspective, that's pretty golden for an Enterprise Linux platform. The only other that's like that is openSUSE Leap/SUSE Linux Enterprise.
Stream is a bit closer than Fedora, but the larger point of needing paid support remains. The slow cadence of RHEL means that unless you are paying for support, things get kind of frozen around the .5 release. After that, they just won't backport fixes, not even regressions, unless a) You are paying, b) It's really a critical security bug. I don't think that will change with Stream.
To summarize, the RHEL model of releasing an OS every 5 years with these staggered upstreams is really not that great. It creates immense inertia and pain down the road. RedHat itself hasn't been able to port its own offerings like Satellite to RHEL 8. I would rather have the Ubuntu cadence of LTS releases every 2 years so that you are at most 2 years away from any fixes you need.
Last workplace had a storage array. Tested on Red Hat, supported on Red Hat. The same is true for lots of other things. Enterprise databases, drivers for hardware, CAD software, that sort of stuff.
Once you have it in place, you are guaranteed not to have to change it a decade. All security fixes is backported. They also vet upstream changes to minimize nasty surprises. You do pay handsomely for the privilege.
> Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
A question is whether that is truly positive. A long cycle means that each update becomes a project in itself disrupting whatever else you are doing. (After 10 years so many things changed everywhere, that you need to bring so many things together ...) With frequent updates it is part of the ongoing process.
(And yes, there are cases for which one can make an argument)
There's absolutely an argument that, for many companies, if you're dependent on a long-term stable release for everything (especially in the absence of actual paid support) you're probably doing it wrong.
in my experience, systems such as Debian and Gentoo for servers have an entirely different market than RHEL, z/OS or SUSE: the former seems to be more so used by i.t. companies themselves that of course also need to run an i.t. infrastructure, and the latter more so by companies whose primary services are not i.t., but that need such infrastructure nonetheless.
Looking at Red Hat's customer list, most of them are based in finance, transportation, retail, hotel, and other such sectors.
Looking at Debian's statistics of use per sector, the plurality is companies that develop computer software, though retail comes second, but after that it's i.t. again.
This is primarily the difference and the gap that RHEL attempts to bridge through it's extensive inclusive support, which is what one is really paying for. The target of RHEL has never been i.t. companies.
The big difference to me is that Red Hat family distros have been a lot better suited to managing a large fleet of servers that I want to treat as cattle, not pets. I've finally managed to get away from Debian derivatives a few years back, but here are some specific complaints I can remember from my last job, managing about 1k Ubuntu servers.
- Installing a package on RH is always non-interactive. To install packages reliably on Ubuntu, we had to set three separate "Please just install the package, don't try to ask questions" options for different layers of the stack, and still occasionally ran into buggy packages that would hang the installation waiting for a nonexistent user to type something.
- On RH, when I try to install or upgrade an RPM that's missing dependencies, it gives me an error and refuses to break my system unless I specify --force. With debian, there's no way to query "Are the dependencies for this .deb satisfied" that I could ever find, and "dpkg -i foo.deb" will instead leave it "half-installed", and your package database is broken until you manually fix it.
- I really missed an equivalent of `rpm -V` (list files in an installed RPM that have been modified since installation). Asking Google now, I see that there's `debsums` which can handle some of this; I don't recall whether I failed to find that before, or if there was some other reason I didn't use it at the time.
- On RH, automated installation with kickstart is fantastic and comprehensive. It's well-documented, and has just worked for every configuration I've thrown at it. Debian's preseed is severely under-documented, and many combinations of features are just unimplemented and silently didn't work. For example, you can reserve unallocated disk space from a raw partition, but that's ignored for LVM, so to keep space free for snapshots in my volume group, I had to configure a "delete_me" volume, and then later delete it.
- Red Hat's SELinux support is fantastic. Ubuntu's choice of apparmor and deficient SELinux support has been annoying.
- I've personally found Red Hat's packages to be higher-quality. The biggest defect I remember finding in Ubuntu's repos was a service whose init script was literally copied from Red Hat, which didn't work, as it tried to source a file of init script utility functions which doesn't exist on Ubuntu, among other issues.
- Red Hat's documentation is fantastic. Ubuntu's documentation is, uh... sometimes present.
- I've found building RPMs to be much simpler and much-better-documented than the process of building debian packages. I vaguely remember being repeatedly frustrated at debian packaging that felt like "this magic thing just interferes and does special stuff when this case is detected", vs RPM's "it just does what the spec file says to do", but I can't remember any details or examples.
- I've had a much easier time building yum repositories than building debian repositories. Just dump a bunch of RPMs in a directory, run createrepo, serve over HTTP. I failed to find something similarly-simple for apt repos.
- Red Hat family had systemd way earlier, and with way better support and integration, than Debian family. While I do agree that there are some implementation issues with systemd, it's been a huge usability and quality-of-life improvement for me professionally.
To me, Debian has always felt like it's designed for someone administering a small number of long-lived pets with a variety of special circumstances, which really isn't what I want professionally. Red Hat has felt like it's engineered for use-cases I care about.
Other then what has been already mentioned (chiefly commercial 3rd party software support), I enjoyed the set-up time. Now there are better provisioning methods, particularly when setting up hundreds of hosts, but when doing it naïvely for a single or few hosts using the interactive installation software, I preferred RedHat/CentOS. That got me to a booting system in some ten, fifteen minutes, while the dreaded installation in Debian used to take easily 1.5h. Once installed, I found Debian easier to maintain and upgrade in place, but initial installation was a time-sink for many years.
To also comment here: every red hat system boots from dracut. There's no separate PXE for netboot: provisioning is consistent whether your boot medium is local, LAN, or ephemeral. It ships netboot-capable out of the box, and this is huge.
I am not a linux guy but had the same question and found out by googling a bit that it was because of software support. Major Linux vendors support only enterprise distros (like Redhat, CentOS and Suse)
Last i checked (2 years ago), when it comes to linux, Oracle Database officially supported only RHEL and OEL. I don’t think CentOS ever made it to the various support matrices, although of course its close compatibility with RHEL meant it likely worked just fine.
As an example, I wanted to set up kerberos. Red Hat had a guide on setting up IdM, covering every step in the process, often with two alternates depending on desired final state and having an intro paragraph to choose between them, full command line docs for every command ran, steps to test this was ran correctly, and troubleshooting steps for commonly-encountered errors. In contrast, the Ubuntu docs for setting up a IdM client were a wiki, half of which was for the old version, and a detailed stackoverflow response. Server and client setups took the same amount of time; the client should have been much faster.