Red Hat resets CentOS Linux and users are angry(zdnet.com)
zdnet.com
Red Hat resets CentOS Linux and users are angry
https://www.zdnet.com/article/red-hat-resets-centos-linux-and-users-are-angry/
19 comments
The BSDs are getting more and more appealing every quarter, personally. I've moved some personal/home services over to OpenBSD, the process was smooth and straightforward.
So what is the solution for production servers? The only free alternative to CentOS is now Oracle Linux?
You could stay on CentOS and have your own internal mirrors / snapshots, so that you could test a release in your dev/qa environment, then promote it to staging, then to production. That should really be done with any OS regardless.
You could pick another distribution, Ubuntu, Debian, etc... though you may have some up front time sink in getting everything re-tooled, depending on what you use the OS for. On large bare metal fleets, this should involve some critical thinking and planning. Some vendor tools may not be available.
You could go BSD. This is an even bigger change from a different distro, as 3rd party library and application support would need to be verified. Hardware support and monitoring would need to be tested. Proprietary (dell, hp) tools will need alternatives. OpenIPMI, static raid controller tools, etc... this is a massive topic on its own.
Other considerations are what reviews and approvals you need from your legal departments, compliance teams, security teams, datacenter build teams, etc...
You could pick another distribution, Ubuntu, Debian, etc... though you may have some up front time sink in getting everything re-tooled, depending on what you use the OS for. On large bare metal fleets, this should involve some critical thinking and planning. Some vendor tools may not be available.
You could go BSD. This is an even bigger change from a different distro, as 3rd party library and application support would need to be verified. Hardware support and monitoring would need to be tested. Proprietary (dell, hp) tools will need alternatives. OpenIPMI, static raid controller tools, etc... this is a massive topic on its own.
Other considerations are what reviews and approvals you need from your legal departments, compliance teams, security teams, datacenter build teams, etc...
I really don’t understand why, given contemporary patterns, we have Linux monoliths anymore.
Surely for servers and sysadmins, building out ones own OS artifact would be trivial in this cloud world.
Perhaps there’s some disruption to be had; Gentoo As A Service.
Surely for servers and sysadmins, building out ones own OS artifact would be trivial in this cloud world.
Perhaps there’s some disruption to be had; Gentoo As A Service.
Theres a huge benefit to having an entire company help you out with kernel fixes, and all sorts of problems.
This means you don't have manage this yourself.
This means you don't have manage this yourself.
Someone can just make their own community edition. This isn’t Microsoft here.
Wasn’t that basically what CentOS started out as - as a community edition of RHEL that you didn’t pay Redhat for? And then Redhat generously offered to sponsor the project? And then all the trademarks and other minutiae of running the project were transferred to Redhat? And now Redhat changes CentOS to make it less like RHEL?
IIRC, Redhat also made it more difficult to make a RHEL clone in order to neuter Oracle Linux and other possible RHEL clones and the sponsoring of CentOS was to have a cost-free RHEL clone in their direct sphere of influence.
I'm guessing you're talking about Red Hat stopping breaking out its kernel patches individually about 10 years ago?
That was to make it harder for Oracle to offer support for OEL, but made no difference to Centos & the non-commercial clones because they shipped the RH kernel unmodified and didn't need to worry about what any individual patch did.
I'm not sure its been a thing since RHEL6 either.
That was to make it harder for Oracle to offer support for OEL, but made no difference to Centos & the non-commercial clones because they shipped the RH kernel unmodified and didn't need to worry about what any individual patch did.
I'm not sure its been a thing since RHEL6 either.
Source RPMs are also not publicly published anymore. The source is available in the CentOS git repos, will be interesting to see what happens after CentOS 8 ends.
I think this should serve as an important lesson for open source projects. Hopefully it will be a case of once bitten, twice shy for the community
[deleted]
You missed a step: There were several "community editions of RHEL", including Scientific Linux, which merged into CentOS (because why duplicate effort). They're not terribly happy either.
> Wasn’t that basically what CentOS started out as - as a community edition of RHEL that you didn’t pay Redhat for?
Literally "Community ENTerprise OS", yes:)
> And then Redhat generously offered to sponsor the project? And then all the trademarks and other minutiae of running the project were transferred to Redhat? And now Redhat changes CentOS to make it less like RHEL?
Correct.
Literally "Community ENTerprise OS", yes:)
> And then Redhat generously offered to sponsor the project? And then all the trademarks and other minutiae of running the project were transferred to Redhat? And now Redhat changes CentOS to make it less like RHEL?
Correct.
Easier said than done, but CentOS's original developer is giving it some thought.
I always thought that Fedora was the next RHEL. Now it will be more like Fedora -> CentOS Stream -> RHEL. The previous owners of CentOS were all employed by Red Hat now and now they took control of it. R.I.P CentOS !
Containers aside, I've long considered RHEL the go-to for production servers with a commercial budget. Partly because they've always had one of the best assemblies of kernel people and other heavy-hitters, and are just generally credible for production.
With CentOS (before this latest news) possibly making a lot of sense for when you don't have the budget for RHEL, or don't yet have it, like for startups. Which then gives an easier upgrade path to nobody-ever-got-fired-for-buying-IBM/RHEL.
I don't have as much confidence in Ubuntu, and the last few months of monitoring security update regressions hasn't reinforced confidence. And the Grub problem this year, which could've bricked some remote devices for me, and where some other distros seemed more earnest and upfront about the problem. I've also grown skeptical of Snap (especially on workstations and servers, though I haven't yet ruled it out for appliances, as an easier path than Yocto).
For personal systems, I've been using Debian Stable for about 20 years (which I initially moved to because the APT network package management experience was vastly better than scouring various RPM sites or building from source, and later decided I also like the principles). And recent Ubuntu experience is making Debian compare favorably for some kinds of production use, though I'm aware of some of the substantial weaknesses of that.
Of course, then there's containers, which sometimes encourages a stripped-down distro within the container, and different requirements for what's hosting or orchestrating those.
With CentOS (before this latest news) possibly making a lot of sense for when you don't have the budget for RHEL, or don't yet have it, like for startups. Which then gives an easier upgrade path to nobody-ever-got-fired-for-buying-IBM/RHEL.
I don't have as much confidence in Ubuntu, and the last few months of monitoring security update regressions hasn't reinforced confidence. And the Grub problem this year, which could've bricked some remote devices for me, and where some other distros seemed more earnest and upfront about the problem. I've also grown skeptical of Snap (especially on workstations and servers, though I haven't yet ruled it out for appliances, as an easier path than Yocto).
For personal systems, I've been using Debian Stable for about 20 years (which I initially moved to because the APT network package management experience was vastly better than scouring various RPM sites or building from source, and later decided I also like the principles). And recent Ubuntu experience is making Debian compare favorably for some kinds of production use, though I'm aware of some of the substantial weaknesses of that.
Of course, then there's containers, which sometimes encourages a stripped-down distro within the container, and different requirements for what's hosting or orchestrating those.
Mind explaining a bit more about the weaknesses of Debian in prod? I'm a Debian fanboy and from what I can gather people are still hung up over the SSH keys security fiasco (which was [and handled] extremely bad ofc) a long time ago, but am obviously wrong here so would love some enlightenment from someone in the know
The keys incident was a good example of one general weakness that I'd want to vet: how easy is it for an arbitrary one of the numerous Debian package maintainer to introduce a change (accidentally or intentionally) that compromises the system? Before that incident, I'd already had mixed feelings about Debian-specific changes to upstream, and one of those turned out to be a whopper.
One thing that's reassuring: both of us thought immediately of the same incident, from years ago, so there's not like there's a stream of known defects discovered frequently, like in some other other areas of this general kind of system.
Another thing that's reassuring about Debian is that some of their principles or policies align with security. For example, in the past I reported an instance in which upstream code of a package was effectively phoning-home to upstream unnecessarily, and Debian took it seriously, and fixed it. I like that the intent is there, so hopefully they'll catch many problems before I have to, and not introduce new problems on top of upstream.
One thing that's reassuring: both of us thought immediately of the same incident, from years ago, so there's not like there's a stream of known defects discovered frequently, like in some other other areas of this general kind of system.
Another thing that's reassuring about Debian is that some of their principles or policies align with security. For example, in the past I reported an instance in which upstream code of a package was effectively phoning-home to upstream unnecessarily, and Debian took it seriously, and fixed it. I like that the intent is there, so hopefully they'll catch many problems before I have to, and not introduce new problems on top of upstream.