I see all the drama around Red-hat and I still don’t get why companies would use RHEL (or centos when it existed). I was in many companies and CentOS being years behind was awful for any recent application (GPU acceleration, even new CPU had problems with old Linux kernels shipped in CentOS).
Long story short the only time one of the company I worked in considered CentOS it was ditched out due to many problems and not even being devs/researchers friendly.
I hear a lot of Youtube influencers “talking” (or reading the Red-Hat statements) about all the work Red-Hat is doing but I don’t see any. I know I dislike gnome so I don’t care they contribute to that.
What I see though is a philosophy against FOSS. They even did a Microsoft move with CentOS (Embrace, extend, and extinguish). I see corporate not liking sharing and collaborating together but aiming at feeding of technology built as a collective. I am convinced they would love to patent science discovery too. I am pretty sure there is a deep gap in philosophy between people wanting “business-grade” Linux and FOSS community.
If you have concrete examples of Red-Hat added value that cannot be fulfilled by independent experts or FOSS community, I’d really like to hear that.
Apart from RHEL, RedHat contributes to hundreds of FOSS projects and hires a lot of FOSS devs. So their contribution in progressing the desktop linux is huge. You can see the contributions to the various project here: https://www.redhat.com/en/about/open-source-program-office/contributions
Believe it or not corporates play a big role in making Linux what it is and their enshittification is bad for Linux ecosystem.
Sad that RedHat went this way.
RedHat contributes to hundreds of FOSS projects and hires a lot of FOSS devs.
They don’t do this because they like the idea of free software (as recently proven - again) but because of thy need the software and doing it like this is the easiest way.
corporates play a big role in making Linux what it is
Same with Microsoft, for example. I’m still not going to use any of their software just because they support FOSS they need because it’s easier this way.
Of course they need the software and that’s why they contribute to make it better. That’s how most of the FOSS development works anyway. People have an ‘itch’ to fix the issues or add a feature and they do it and the license makes sure that others benefit from that itch.
CentOS being years behind was awful
You’re not doing it right. There’s absolutely a reason why enterprise linux works with a version that’s more-or-less locked in place (but for security updates, like a maintenance fork). You need to understand the value you’ve been overlooking.
- ten years of a stable platform. Because, yeah, it’s not this week’s release with the glitter, but it’s also not a moving target of broken suck you have to constantly chase, and you can actually do dev.
- dependencies are figured out
- updates are trivial when security stuff comes out. Honestly – yum+cron is so stable and reliable, and the compatibility is part of the guarantee; so you - and your customers - don’t have to worry or - please god no - delay updates to gauge risk. Since updates are 99% of the work to avoid exploits, this goes from ‘huge risk’ to ‘no-brainer’. And you don’t have to worry that your dev environment is non-trivial to replicate on the daily.
- your requirements for your software becomes ‘EL7’; maybe ‘EL7+EPEL7’ or so. Your installation process becomes ‘add repo RPM which pulls in other repo RPMs. yum install’ , and you’re already onto mere config work.
- validating the install isn’t ‘did you install this ream of apps from this particular week in time, then run some
wget|sh
bullshit? Now run this other set of commands to confirm your installation’ – but in our case is just ‘rpm -qa|egrep’ or even an snmpwalk. - not working? Give me your one config file and your rpm-qa and we’ll replicate here trivially and find out why. (I didn’t work in support, but I liaised with them a bunch in the security work, and that was common practice) Tossing 4 lines and a
<<EOF
construct into a vagrant config is just so easy, now, and gives the entire machine to play with.
As someone who used to dev a notable app in the past, cross-distro problems alone made so many of the fringe OSes impossible to support, and so we didn’t. EL was the backbone because we respected what we had.
I just can’t figure out why this-week’s-glitter is more important than losing the install/support/update/validate burden by choosing a stable platform to work within. Life’s too short to support dependency hell or struggle just to replicate a failing setup in your lab for testing. Do you just not support customers?
One example would be HDR, here and here are two articles I found after a quick search. I’m no dev, but I know HDR is a complicated beast and more importantly not critical infrastructure so community developments are slow or non-existant. If you check who has been contributing to HDR it’s always big corps like Red Hat, AMD and Valve.
They’re a pretty big contributor to Linux, so even if you don’t see their work you’re probably using it anyway. https://lwn.net/Articles/915435/
added value that cannot be fulfilled by independent experts or FOSS community
Wrong question IMO. It’s more relevant to ask “without Red Hat, would independent experts or the FOSS community have added the same value?”. Sure, it’s possible that Red Hat has some highly skilled developers that possess unique skills required for their contributions, but in general contributing to FOSS projects is more about willingness to spend large amounts of time and resources on something that doesn’t give you money in return.
Lots of large companies “could” have spent thousands of hours contributing to Linux, but unless they actually do it then it is irrelevant.
The two major benefits of RedHat seem to be:
- Dedicated support
- Long term stable
Now LTS is provided by others but the support isn’t always there. A lot of enterprises like the support as sort of an insurance if they lose their experts.
Personally I don’t agree with enterprises that think that way, but it is the reason it has stuck around so long.
You can add support contract requirements for some pieces of software coming from vendors with so little confidence in their product that they’re rather have it run on an outdated dependencies environnement. A side effect of the logic you talked about, applied to software vendors.
I worked for a bank. When they decided to deploy Linux on their infrastructure, they chose RHEL and they have signed a big contract with RedHat for tech support.
Overall, they chose RedHat for the same reason they chose Microsoft before: tech support. They have >10000 engineers, and yet somehow they think they absolutely need tech support… They pay a lot for it. In my building, they even got a Microsoft engineer once a week on-site until Covid. I don’t know for the other people working for this bank, but I asked for Microsoft support only once in 2 years. In the end, their guy sent me back an email telling me “I’ve transmitted your question to the corresponding engineering team” and … diddlysquat.
Now to be fair, for paying customers, RHEL and Microsoft both ensure security updates for a really a long time. Red Hat pays a lot of people to backport security patches from upstream to previous versions. It allows companies like the bank I worked for to keep running completely crappy and obsolete software for an insane amount of time without having to worry too much about security vulnerabilities.
Anyway regarding RedHat contributions, a lot of them are subtle.
- A friend of mine works for RedHat. He is a core Python developer and is paid full-time by RedHat to work on Python.
- Through this friend, I applied for a position in their company at some point (unfortunately, it didn’t happen ; don’t remember why exactly). The position was in a team dedicated to improve hardware support. They have built an infrastructure to let computer manufacturers (Dell, Lenovo, etc) test the compatibility of their new hardware with Linux/RHEL quickly and automatically.
- Part of the technical support they provide to some clients is “making things work”. It may imply fixing bugs or improving drivers and then sending patches upstream.
- If I’m not mistaken, they paid Lennart Poettering to work on Systemd and Pulseaudio.
- They pay for the development of some infrastructure software like Corosync for instance.
This list is far from exhaustive. I’m sure they have paid for a lot of other things you’re using daily without knowing it.
VFX studios have been using CentOS and Red Hat for decades. I don’t know why exactly but my understanding is that it’s more reliable, stable, and with better support than other distributions. I don’t speak from personal experience, so these reasons might be wrong, but I’m certain there is a strong preference for RHEL in the industry.
I don’t know anything about the drama but back in the day I was in DevOps and pretty much every engineering tool we had strongly urged us to run it on the RHEL family. Also it was kinda nice that there was a phone number to call when things were going to heck. Plus for some reason I could always get drivers to work faster on fedora, which might have been my knowledge base. Not sure
Also for a corporation a red hat license is pennies so for them just having official support is worth it.
For individuals I don’t think it really serves any use.