Hacker News Reader

Comment by neilv | Hacker News Reader

Can someone confirm or fill in details?

* CentOS used to be a free rebranding of RHEL.

* IBM effectively cut off CentOS.

* Rocky Linux is the replacement free RHEL-compatible distro, but is higher effort to maintain than CentOS was.

* "Rocky Linux from CIQ" is a commercial product that is attempting to compete with RHEL, by being lower-cost essentially-RHEL while still satisfying some is-there-a-company-behind-it "compliance" checkboxes that companies require?

* "Rocky Linux from CIQ - Hardened" offers some supposed security improvements that vanilla RHEL doesn't?

View on HN

>CentOS used to be a free rebranding of RHEL.

CentOS was a binary/functionally compatible build of RHEL without the RHEL branding.

>IBM effectively cut off CentOS.

Red Hat (not IBM) made the decision to end CentOS Linux and move their focus toward CentOS Stream.

>Rocky Linux is the replacement free RHEL-compatible distro...

Rocky Linux is one of many choices for a RHEL-compatible distribution. I would also say CentOS Stream is also a viable choice. It works well from my own personal experience.

>but is higher effort to maintain than CentOS was.

Speaking as the lead of Release Engineering, it does require quite a bit of effort to maintain Rocky Linux. It can be especially time consuming during May and November when releases are scheduled, given that it's volunteer time.

As for CIQ, who knows what they offer or what it is they are actually doing with our distribution. Is it to check a box? Probably, given the way I've seen some companies act around these sorts of things. Does it offer security improvements? Who really even knows.

> Red Hat (not IBM) made the decision to end CentOS Linux and move their focus toward CentOS Stream.

The fact is that Red Hat killed centos a little after it was acquired by IBM. Who decided this is not something that we'll learn (or even care anyway).

It’s unthinkable that RedHat killed CentOS without the OK from IBM.

> Rocky Linux is one of many choices for a RHEL-compatible distribution. I would also say CentOS Stream is also a viable choice.

One of the main value propositions of RHEL (and RHL before it) is that each distro version has a fixed ABI throughout (kernel included), making it a valid compilation target for binary-only software. Neither Stream nor even Alma are that.

Also, many software vendors don't support Centos stream.

Some very important hardware vendors don't either. Can't use GPUDirect Storage with Mellanox OFED on Centos Stream. Works fine under Rocky.

Push off if you think Alma isn't this. The differences are miniscule and basically amount to Alma's customers preferring to have some stream back ports first effectively.

If Rocky is claiming they're better their either breaking rules or lying. And if the community believes them I'm just going to walk away and talk to the business small medium and large putting their money where it matters, not in more CIQ FUD.

>One of the main value propositions of RHEL (and RHL before it) is that each distro version has a fixed ABI throughout (kernel included), making it a valid compilation target for binary-only software. Neither Stream nor even Alma are that.

Maybe for current point releases of RHEL and derivatives, building against CentOS Stream may not be that great of an idea. For example, EPEL has different build targets that build against RHEL or CentOS Stream to account for the differences between point releases such as libraries (especially qt libraries!) and also to make the transition easier for their users between point releases when running a dnf update on the next RHEL point release.

As a side tangent: In my opinion, I think vendors should be compiling software against CentOS Stream to ensure compatibility and validation for the next RHEL point release, which should work for the next point release of RHEL, Rocky Linux, AlmaLinux, and even Oracle Linux. I've not seen many vendors do this, though.

With that said, the differences that AlmaLinux have should not cause incompatibilities (and if there are, I can't see them being anything more than minor issues). This means that builds on an AlmaLinux build root should allow the software to still work on the others. Any of the distributions in the family should be fine as build targets.

> Red Hat (not IBM) made the decision to end CentOS

I don't understand what you mean here? Wasn't Red Hat already owned by IBM when this decision was made?

The planning to swap the RHEL/CentOS relationship (i.e. CentOS Stream) long predated even the "intent to acquire" announcement from IBM, and of course the actual acquisition as well.

Hey just want to take the opportunity to say thanks for your efforts with releng. I'm always pleasantly surprised by how quick and effective you folks are with getting updates built, validated, and shipped when upstream has a release.

Looking forward to Rocky 10!

Some further context:

- Greg Kurtzer, CIQ's founder and CEO, is the creator of Rocky Linux and the president & owner of the Rocky Enterprise Software Foundation.

- Many of the Rocky Linux maintainers are CIQ employees.

- The EULA for CIQ's commercial version of Rocky Linux is just as restrictive as the terms that Red Hat used to cut off RHEL source code availability. Notably, there's a section saying that customers may not "provide, license, sublicense, sell, resell, rent, lease, share, lend, or otherwise transfer or make available the Software to any third parties, except as expressly permitted by Ctrl IQ in writing".

https://ciq.com/legal/eula/rocky-linux-from-ciq/

" .... The license granted in this Section 4 is conditioned upon Customer’s and its Authorized Users ’compliance with this Agreement. To the extent that the Software provided to you is not under an open source license, ...."

missed that part?

Now check the RHEL EULA wrt distributing the SOURCES of the FOSS based binaries.

Welcome to Hacker News, I'm glad my comment encouraged you to join the site :)

RHEL's EULA has a similar sentence, "This Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license." That's what I meant by "just as restrictive". Both services are subscriptions where continued access to the software provided by the subscription is conditional on the subscriber not giving third parties access to the service. CIQ's EULA also says that subscribers may not "access the Software in order to build a competitive product or services", which seems ironic considering their business model.

Yet RH publicly threatened to close your account/subscriptions when you DO exercise the rights of FOSS binaries if you download and redistribute the sources. This is different than giving 3rd parties access to the mentioned SERVICE [that would be equivalent to sharing your user name and passwords]. CIQ on the other hand actively distributes the sources of Rocky via the OpenELA and other githubs [Warewulf etc.]. Needless to say, but the GPL is about your rights downstream and not 'look we have upstream policies first [in Stream] but if you do redistribute sources of GPL stuff, your account is gone!'. No comparison in my book. Finally, logically, if you still find otherwise, then if CIQ is wrong then also RH is wrong and then also put the onus on BOTH.

> Rocky Linux is the replacement free RHEL-compatible distro

Wasn't (isn't) there another CentOS replacement that was created around the same time? Are they still around? Are there alternatives or is Rocky pretty much it?

You are thinking of Alma, and I believe they are still going, though a lot seemed to be up in the air.

What's up in the air?

https://wiki.almalinux.org/release-notes/

There were some press releases where the company behind it looked like it may be pulling out of the space. Though I'm not seeing them now when I do a quick search.

AlmaLinux is a non-profit foundation. It is not run by any company. Lots of companies sponsor it in various ways but no company controls it.

Both comments are correct.

AlmaLinux was originally launched by CloudLinux. It was then transferred into a new purpose specific foundation.

Alma is no longer binary-compatible with RHEL. Nothing wrong with that decision, but that makes it "RHEL like" and not "RHEL compatible."

AlmaLinux is still 100% compatible with RHEL. Any suggestions otherwise is FUD.

This change: https://almalinux.org/blog/future-of-almalinux/ means that Alma is no longer covered by STIGs and other RHEL-specific certifications. Rocky is usually permitted to piggyback on such things. This has directly affected deployments (my team spent time migrating from one o the other as a direct consequence). Compatible, sure, but that is a narrow view of the value CentOS provided.

STIGs are not inherited. It absolutely does not work that way.

I think you're reading into the changes completely wrong. AlmaLinux has power to actually do things, fix issues, contribute real and meaningful changes, all while maintaining 100% compatibility. A lot has been done already, with plenty more to come, with 0 compatibility issues.

I cannot speak for AlmaLinux, but it's incorrect to say they're not compatible. They are most definitely still compatible with the upstream distributions. Yes, they have made some changes that make them quite different from the upstreams, but this was their choice and it works for their community and their overall goals. I personally don't see any issues with what they've chosen to do, but that's my extremely narrow view as all clients I work for only use RHEL or Ubuntu.

In regards to STIG, this makes me think of the "scap-security-guide" package that helps the openscap package run tests for compliance like PCI-DSS and HIPPA (among other things). While it is true that we mark ourselves as a "derivative" of RHEL in that package, it doesn't mean we have any certifications or the like and we certainly do not claim to have such certifications. The only thing we actually have officially is a CIS benchmark set at cisecurity.org.

AlmaLinux on the other hand appears to be upstreaming themselves into the content itself, which I think is pretty cool (https://github.com/ComplianceAsCode/content/tree/master/prod...). I've always wanted to see Rocky Linux do the same thing for the past few years, but I don't know what it would take. I've asked our security team some weeks back to look into what has to be done, so maybe something will happen. I just know it will take a long, long time to get things figured out either way. (As much as I'd like to look into it myself and work with the security team, I just don't have the time in between my personal life, day job, and the project.)

Thanks for your insightful reply. I think we can all agree that compliance is quite a complex and generally annoying endeavor to take on.

This is just categorically wrong. Alma is no longer a 1:1 binary copy of RHEL due to the licensing changes RedHat made in 2023, but it is absolutely still binary compatible.

No, community is more stable and professional.

Frankly given I get less issues than my Rocky counterparts working 1 rack over my look of "I told you so", every time, says it all.

I'm curious -- what issues are your counterparts experiencing?

nosey neighbor problem

Reply on news.ycombinator.com