For these shops, you don't need the paid enterprise offering across the board (dev, testing, etc) so that is where an EL rebuild is handy. In those cases you don't want too much different between prod and test/dev, but you don't need the paid support or priority patches on internal test hosts.
RH would not be of much value if the support staff were not any more effective than the average end user.
Is this an ego thing?
It's only the boss that wants to pay for a safety net, forcing the issue of raising a ticket is their validation of money well spent I highly suspect. We're all human beings who are quite technical on this forum, you work for RH, the other guy works for someone else.
I have a suspicion that RH support is what the boss pays for as a backup should their employees be unable to solve a problem or decide to go to pastures new, as people do from time to time.
they're not, because they have no idea what they're looking for, they lack the subject knowledge and expertise, and they werent involved with directly producing a lot of the open source components they are having problems with.
By "engineer" I mean, "we are the people that wrote the actual open source components they are having a problem with". It would not be in their interests to hire us directly because 95% of the time the regular support people can do everything they need without things escalated to engineering.
My gripe about the original thread was bosses interrupting that investigation and telling the onsite staff to open a case elsewhere, IMO, that's disruptive behaviour.
I dont think this really happens, when we get these customer issues and the people who have tried to fix the problem are on the phone, they are lost / panicked / at a dead end. They are not like, "yeah we think it's ABC but our boss told us to call you". that's not really a thing. if customers can fix the problem, they do. they are not in a hurry to call redhat for things they can do themselves and they're not really supposed to since their support minutes are a finite resource.
What typically happens in this situation is the chap logging the ticket gets pissed off and says to the boss, "ticket logged it's with $vendor, I guess it doesn't need babysitting so I'm working on other tickets now".
The boss in this case is happy as it shows their earlier investment was a fine idea. The employee though is disgruntled as their toys were taken away and things it's not such a fine place to work.
For just ease of management and customization can't beat vanilla Debian
If you run the standard installer from a vanilla USB image, you will be asked questions about the config, most of which produce reasonable results if you just hit <enter>. Some of them will fail in certain environments. (No DHCP server? You will need to enter IP networking details.)
If you want to install a fleet of Debian machines (or VM images), you set up a PXE server and a set of answers to the installation questions, or you build an image for direct deployment, or you use the Debian VM image, or... whatever: there are a lot of possibilities that will work.
Most of this has been true for at least 3 Stables.
For home server use: Tumbleweed, Leap or MicroOS depending on your personality. :)
RHEL and its clones are supported with updates for 10 years, often ship with "more modern" server software than Debian does (e.g. firewalld, podman, systemd etc) and DNF, whilst slower, still blows apt in terms of feature set (e.g. transcriptional, roll-backs, history, offline upgrades)
There's also SUSE.
My understanding is that the problem with RHEL clones is just that, that they are clones.
From what I've read, the problem is that RHEL will often make changes to suit their various enterprise customers, for example I seem to recall reading somewhere that OpenSSL was one of many things "touched" in that way.
I hear many good things about DNF vs apt, but I'm too worried by the skeletons in the clone cupboard.
> There's also SUSE.
So, why doesn't SUSE get close?
It's terrifying actually.
That's not really true. They often ship with Red Hat specific software (like Podman is) replacing widely used software (e.g. Docker, to which Podman still isn't feature complete even though it has been shoved in everyone's throats for a couple of years now), but "more modern" will vary wildly based on the release date.
Sooo much less fuckery, packages are just there and don't require installing/buying some random addon just to have DRBD+pacemaker cluster (that RHEL for some reason put into separate repo and subscription).
Ubuntu LTS is long enough for me, and seems to work without complaints.
At home I run Gentoo because I like to fomit and funroll.
For personal machines, I don't mind Fedora Server (or CentOS Stream) because I can handle the more frequent upgrade cycle.
Major version upgrades have less risk of breaking, while rollbacks become an option. And the attack surface is lower.
If I was choosing a server OS today, I personally would probably pick Debian.