Hacker News Reader

Bingo.

RHEL is a subscription mess when working across its zoo ("Is our dev mirror the Azure's managed RHEL repository with mismatching kernel headers? Or pass through to RHEL's with epol disabled? Or RHEL 8 with docker repos disconnected so they can push their podman alternative?"). Losing centos hurts. As soon as you get into basics like drivers or build tools, RHEL quickly goes off the rails, and centos gave a semi-predictable escape hatch.

GPU land is directly on this path, so I feel awful for enterprise IT admins we work with who just want to do a good job for their client hospitals, schools, businesses, etc. We help shield them most of the way by reducing the install to just a gpu driver + docker, but those deps still need basic pinned version ranges. RHEL makes getting those hard, and worse, as life happens, make it hard to get the right diagnostic tool versions (gcc 7, ...). It's a bad look for a 2020 infra vendor to charge an enterprise for reliable and predictable rollout sw/support when RHEL makes it a marathon to get the right major release of base layers like docker/gcc/drivers. Contrast this to our cloud users, who one-click launch, or our self-managed cloud/ubuntu/etc. ones, who can generally get the right drivers + docker stack up in 10-15 provided commands.

Watching the chaos spread into centos makes me even more nervous about critical software relying on RHEL, and we already had to have The Talk with enterprises wanting HPC/ML on RHEL before this..

You're saying it's a "gross mischaracterization." Does that mean you have more/better data than Red Hat/CentOS about CentOS usage?

> Literally every enterprise user I work with that has CentOS uses it specifically because it directly tracks RHEL. They don't want to pay for RHEL licenses in test/dev but need a binary compatible version to ensure they can get enterprise support in production should they hit an issue. Having different drivers/kernels/libraries is a non-starter.

Unless you are doing kernelly things then the small difference in kernel version will not be that big a deal. Also for most applications, dev/test is better on Stream since it represent RHEL next. If the next version of RHEL will break your app, you find out in dev/test instead of in production like you used to. I think it's worth considering if this isn't better for your use case than previously.

It's also not very hard to compile your own kernel if you really need an exact version. I do that sometimes on Fedora when I'm testing a driver I maintain. You can also just keep the RPMs from either previous releases as well (that's not a bad idea so even if you're building your own kernel you can extract the config file from it).

That is all well and good, but that is a different value proposition than what CentOS, until this point, was offering.

The original value proposition of CentOS was that it was a bug-for-bug compatible, drop-in replacement for Red Hat Enterprise Linux.

The entire value proposition of CentOS/RHEL was you don't have to do things like compile your own kernel. You have a relentlessly tested operating system with the certainty of knowing it is compatible with anything you could run on it. You don't want to manage multiple versions in the first place.

> Unless you are doing kernelly things then the small difference in kernel version will not be that big a deal. > It's also not very hard to compile your own kernel if you really need an exact version.

It isn't about having a specific version because the RHEL kernel backports features anyway. If you are compiling the RHEL kernel you might as well use the actual distribution that has been tested with it. What would be the point otherwise?

Yes, I think that use case falls in the 5% gap that had the rug pulled under them. But I really do believe 95% of CentOS users don’t really need that, hosting stuff like HTTP servers or containers. Stuff that really doesn’t need to match RHEL.

Web hosters and the like need stability and don't really care about the underlying distribution at all.

Those types of users will leave CentOS and never look back.

Binary compatibility is a myth: if you actually need 100% binary compatibility, then you need the actual binary from Red Hat because neither Red Hat nor any other commercial distro offers reproducible builds.

CentOS had to reverse engineer code drops from Red Hat just like Oracle or Amazon. Oracle will sell you a support contract claiming "binary compatibility" even when they are using a newer kernel than what's in RHEL.

They are trying to make lives easier to collaborate with their frienemies who all maintain a RHEL clone. That means calling CentOS what it actually is: upstream of RHEL.