Hacker News Reader

Comment by SEJeff | Hacker News Reader

Centos stream still exists and it is in fact the actual upstream of rhel.

CentOS was the downstream of RHEL, and much more people used it than RedHat/IBM knew or wanted to admit. I can argue that at least 90% of their users (by the number of installs) didn't even need any help to configure/troubleshoot that either.

But with a very IBM move and with some tunnel vision, they got triggered by the few people who abuse RedHat license model and rugpulled everyone. More importantly universities, HPC/Research centers and other (mostly research) datacenters which were able to sew their own garments without effort.

Now we have Alma, which is a clone of CentOS stream, and Rocky which tries to be bug to bug compatible with RHEL. It's not a nice state.

They damaged their reputation, goodwill and most importantly the ecosystem severely just to earn some more monies, because number and monies matter more than everything else for IBM.

Remember. When you combine any company with IBM, you get IBM.

> they got triggered by the few people who abuse Red Hat license model and rugpulled everyone

Alma is not a clone of CentOS Stream. You can use Alma just like you were using CentOS. It's really no different than before except for who's doing the work.

I agree that communication was bad. But why do you believe that Red Hat isn't able to screw up on their own?

> Alma is not a clone of CentOS Stream.

I'll kindly disagree on this with you. Reading the blog post titled "The Future of AlmaLinux is Bright", located at [0]:

> After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be binary compatible with RHEL.

> The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle.

> We will also start asking anyone who reports bugs in AlmaLinux OS to attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place.

So, it's just an ABI compatible derivative distro now. Not Bug to Bug compatible like old CentOS and current RockyLinux.

TL;DR: Alma Linux is not a RHEL clone. It's a derivative, mostly pulling from CentOS Stream.

> I agree that communication was bad. But why do you believe that Red Hat isn't able to screw up on their own?

Absorption and "Rebranding and Repositioning" of CentOS both done after IBM acquisition. RedHat is not a company anymore. It's a department under IBM.

Make no mistake. No hard feelings towards IBM and RedHat here. They are corporations. I'm angry to be rug-pulled because we have been affected directly.

Lastly, in the words of Bryan Cantrill:

> You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end.

[0]: https://almalinux.org/blog/future-of-almalinux/

> Absorption and "Rebranding and Repositioning" of CentOS both done after IBM acquisition. RedHat is not a company anymore. It's a department under IBM.

You're wrong. CentOS Stream was announced September/October 2019, too close to the IBM announcement to be an IBM decision; it had been in the works for quite some time before, and in fact this all started in 2014 when Red Hat acquihired CentOS.

From 2014 to ~2020 you were under the impression that nothing had changed, but Red Hat had never cared about CentOS-the-free-RHEL. All that Red Hat cared about was CentOS as the basis for developing their other products (e.g. OpenStack and OpenShift), and when Red Hat came up with CentOS Stream as a better way to do that, Red Hat did not need CentOS Linux anymore.

Anyhow, I've been through that and other stuff as an employee, and I'm pretty sure Red Hat is more than able to occasionally fuck up on its own, without any need for interference from IBM.

Bug for bug is a sham and always was. It's a disservice to users to only clone something.

Underneath it all, compatibility is what matters. At AlmaLinux we still target RHEL minor versions and will continue to do so. We're a clone in the sense of full compatibility but a derivative in the sense that we can do some extra things now. This is far, far better for users and also let's us actually contribute upstream and have more of a mutually beneficial relationship with RH versus just taking.

I'll say it depends.

Sometimes the hardware or the software you run requires exact versions of the packages with some specific behavior to work correctly. These include drivers' parts on both kernel and userland, some specific application which requires a very specific version of a library, so on and so forth.

I for one, can use Alma for 99% of the time instead of the old CentOS, but it's not always possible, if you're running cutting edge datacenter hardware. And when you run that hardware as a research center, this small distinction cuts a lot deeper.

Otherwise, taking the LEAPP and migrating to Alma or Rocky for that matter is a no-brainer for an experienced groups of admins. But, when computer says no, there's no arguing in that.

If you're running cutting edge datacenter hardware, CentOS is a better fit now than it ever has been before. It will be the first to get support for new hardware within a major version, ahead of RHEL and all it's derivatives. It is possible that some hardware doesn't get support within the current major version of any of these related distros, and you'll have to wait until the next major version, which CentOS also does first before the rest.

We don't change the expected versions. We might patch/backport more to them if there are issues, but the versions remain.

Basically the goal is still to fit the exact situation you just brought up. I'm not aware of this ever not being the case if it weren't to be the case for some reason, then we have a problem we need to fix.

All of the extra stuff we do, patch, etc. is with exactly what you just stated in mind.

I'll be installing a set of small servers in the near future. I'll be retrying Alma in a couple of them, to give it another chance.

As I said, in some cases Rocky is a better CentOS replacement than Alma is.

But to be crystal clear, I do not discount Alma as a distribution or belittle the effort behind it. Derivative, clone or from scratch, keeping a distro alive is a tremendous amount of work. I did it, and know it.

It's just me selecting the tools depending on a suitability score, and pragmatism. Not beef, not fanaticism, nothing in that vein.

Sustainability is one of the core reasons why we are not using RHEL SRPMs to build AlmaLinux. RH doesn't want us doing that, and doing so would be unsustainable and bring into question the future of AlmaLinux as it can, and likely will, turn into a game of cat/mouse getting those SRPMs :)

Let us know if you have any issues!

Red Hat bringing CentOS in-house (well before IBM entered the picture) was IMO one of the first in a string of expedient decisions that were... unfortunate. When I was at Red Hat I loudly argued against some of the ways things were handled but I also understand why various actions were taken when they were.

I'd also argue that CentOS classic was mostly bug for bug compatible but probably close enough for most. It shared sources but did use a different (complex) build system as I understand it.

That closeness allowed CentOS to be a drop-in replacement for RHEL for thousands of installations and exotic hardware combinations. Unfortunately, we don't have this capability anymore. Rocky bears most of that load now.

Despite being a debian/ubuntu guy, I usually used CentOS for production deployments because it would be easy and seamless to upgrade to RHEL when I hit the big leagues.

Not anymore. I just use the latest ubuntu LTS and call it a day.

IBM/RedHat was soo predictably short sighted on this.

So you say "it would be easy and seamless", but did you ever actually do it and upgrade to RHEL? Because most people throw that out as a supposed sales pipeline that was lost, but the real life metrics indicate that almost never happened.

In one case, yes.

The free LTS/distro and pay for support if you feel like it never really worked financially. Maybe Canonical is profitable at this point. It's not Red Hat (or SUSE for that matter.)

There are many large organizations that pay for RHEL support. Supercomputers, for example. These organizations also benefited from being able to spin up analog installs of CentOS on local machines for testing. Not anymore. I expect RHEL's market dominance in these areas to diminish over time.

HPC was always a tough sales area for Red Hat and RHEL.

In general, while RHEL is obviously still an important revenue source, there's also a lot of focus on OpenShift going forward which has done of pretty good job of covering (and more) inevitable RHEL declines moving forward.

All the HPC I've used in the past was always RHEL... I wouldn't have imagined it was a tough sales area for RedHat, at least in the past.

For testing environments Red Hat will literally give them free RHEL. Problem solved.

No, they won't. I'm talking about the users of HPC centers, not the maintainers. The supercomputer cluster is at NASA or DoE and running RHEL, but the user is some grad student in Caltech or whatever. The grad student needs the analog environment to run their code before their scheduled time on the big iron.

But CentOS Stream is not CentOS.

They are completely different products just reusing branding to confuse what people are asking for.

RHEL Developer is closer, as a no-support, no-cost version of RHEL, but you still have the deal with the licence song and dance.

CentOS gave folks a free version that let you run some dev environments that mostly mirrors prod, without worrying about licences or support. CentOS stream doesn't do this out of principle. It's upstream.

To call it "completely different" is false. They are built differently, but the end result is still 90-95% the same software versions (because it has to be as the major version of RHEL). In fact, the way it is built differently is a massive improvement over the old process. The old CentOS was put together by 2-4 people at a time, with long delays after the corresponding RHEL releases, with no ability to actually fix bugs or accept contributions. The new CentOS (CentOS Stream) is built by thousands of engineers, literal subject matter experts who can actually fix bugs you report to them, or even better merge a contribution you submit. Also, the branding wasn't reused, the branding is for the whole CentOS Project, which still exists and is more active than ever. Also, you can still use CentOS in your dev environments, and it works great for that because you can prepare your production workload for upcoming changes in the next RHEL minor version ahead of time. You can also get free RHEL for dev environments, for the things you need to validate with the same minor version as your production RHEL environments.

It is different, otherwise why would then explain at length at how it is better?

But for all practical purposes, that is dropping CentOS. They completely changed the identity of the product, so the fact it has the same branding isn't going to placate anyone.

People that actually care about the distro being sustainable are quite happy with the changes. Sorry you don't get it.

so? That just means that it is not necessarily compatible with the current version of rhel deployed on our servers

It's the same major version, so it's extremely compatible. Plus if you run into something that doesn't work the same, you just discovered what's going to break for your workload on your RHEL system when the next minor version is released.

so it's not the same. Which means that it is not equivalent to what centos was. It's highly, but not fully, compatible. centos was "fully". You can't use it to test on the current version of rhel, where with centos you could. You can't say they're equivalent and then start listing the differences that make them not

Reply on news.ycombinator.com