Hacker News new | ask | show | jobs
by fevangelou 1064 days ago
So AlmaLinux decides to stick to CentOS Stream (which "sits" between RHEL and Fedora in terms of "stability" as I understand). Basically what RHEL wanted these clones to do.

Rocky Linux on the other hand seems to take a more adventurous path by teaming up with SUSE on the new RHEL fork, whenever that comes. In the meantime it's not 100% clear how Rocky will continue working (they referenced some workarounds but not specifically how they'll get the source code from RHEL).

And Oracle will also work on their own fork.

Right...

8 comments

Oracle and Rocky say they will continue to duplicate RHEL exactly ( though Oracle never duplicated the RHEL kernel ).

SUSE says they will “fork” RHEL with it being a bit unclear if this will be a “bug for bug” copy or not.

Alma will base off CentOS Stream to create a distro that is RHEL ABI compatible.

Of all these, I think the Alma path best reflects the community values that everybody has been on about. The others are driven more by commercial interests than “community values”. That is ok, as long as you are honest about it.

> ( though Oracle never duplicated the RHEL kernel )

Doesn't Oracle ship both the RHCK (a duplicate of the RHEL kernel) and the UEK (their own kernel)?

Yes, that‘s correct.
> The others are driven more by commercial interests than “community values”.

The first time I read this line, it didn't sit right with me... but after thinking on it, you're not wrong. I don't think Rocky's choice to stay bug-for-bug is necessarily driven by commercial interest, at least not overtly.

One of the big benefits of "bug-for-bug compatibility" with a support-licensed "Enterprise Linux" is the fact that you end up with an incredibly broad user base running the same systems code everywhere, whether or not they're paying for support. This means that non-licensed systems are helping to uncover bugs and incompatibilities, and it also means that issues reported by enterprise customers and fixed by RedHat get filtered out to everyone else as a matter of course.

At the end of the day, yes: commercial interest is the common factor underpinning this mechanism. However in Rocky's case (as with the original CentOS before being EEE'd by RH/IBM) the conscious motivation is to build something that brings a maximum number of people together in pursuit of a stable, production-ready Linux distribution. And even if the result is "we do this because it helps our users make or save money," as you said -- that's okay.

Oracle applies changes relative to CentOS Stream, see for example:

    rpm -qp https://yum.oracle.com/repo/OracleLinux/OL9/baseos/latest/x86_64/getPackageSource/glibc-2.34-60.0.2.el9.src.rpm --changelog | head -n 25
So I don't think they aim for exact bug-for-bug compatibility.
Oracle didn't aim for perfect compatibility either, they basically said they will try their best
> (which "sits" between RHEL and Fedora in terms of "stability" as I understand).

There is no meaningful upstream link between Fedora and RHEL after a RHEL release has been forked off, so it doesn't make any sense to say that CentOS Stream sits between Fedora and RHEL.

Basically: Red Hat takes a Fedora release, heavily tweaks it, and makes a new version of CentOS Stream. After hardening, that version of CentOS Stream then becomes the basis for a new major version of RHEL. Thereafter, that version of CentOS Stream is the upstream for "minor" releases of RHEL.

Patches which are destined to land in that release of RHEL, go through the standard testing process, and land in CentOS Stream (aside from embargoed security fixes that hit RHEL first, then Stream). It's the one and only "direct" upstream of RHEL, and it's a very close upstream. Closer than, say, Debian Testing and Debian Stable. It's more like if you had Debian Stable and then there was some additional variant of Debian which just ensured that everything apart from security fixes was held back until fixed-interval point releases.

This isn't true. Firstly Fedora is always the start of the next version of RHEL. Secondly even for the current RHEL all changes go upstream first, which means they go into Fedora. Thirdly there are some packages which are rebased to Fedora every minor RHEL release (I know of the mingw packages, and a lot of the virt stack, but there are others too).
> some additional variant of Debian which just ensured that everything apart from security fixes was held back until fixed-interval point releases.

a.k.a. stable-proposed-updates

Debian Stable point-releases are not truly 'fixed interval' of course, but close enough.

Rocky Linux has not teamed up with SUSE. The announcement from SUSE included that CIQ is teaming up with them. CIQ != Rocky Linux. CIQ != the Rocky Enterprise Software Foundation. We might use whatever they come up with to make an additional distro later.

Rocky Linux, as it is, will always be 1:1 with RHEL. We are dedicated to providing 1:1 "bug for bug" Rocky Linux, for both 8 and 9, for the full duration of their life cycles. Broken promises from CentOS are the reason we started Rocky Linux in the first place, we're not going back on anything we've already committed to.

I believe we (Rocky Linux) were pretty specific about how we're getting source in the announcement at <https://rockylinux.org/news/keeping-open-source-open/>. SRPMs from UBIs, cloud instances, etc. The only intentional omission are the additional legal loopholes we've discovered to get source, that we're keeping in our back pocket. We want to keep those backup methods to ourselves so that Red Hat doesn't close off too many at once, should they choose to try to screw over our community again in the future.

> screw over our community

For some definition of community.

From my observation point, I see that Rocky already has some sizeable following. Esp, from research community.
We do indeed. Adoption numbers are promising <https://rocky-stats.tiuxo.com/auto.html> but community size is enormous as well. 9071 folks on https://chat.rockylinux.org, ~300 folks on IRC, ~4100 folks on the forum, etc.

Adoption by many large organizations / businesses was also quite fast. And may have even caused us some trouble, I suspect the attention garnered by NASA's use of Rocky Linux had something to do with instigating Red Hat's recent antics.

The charts really look impressive. I didn't expect such an uptake. The funny thing is, people have tried it first (ephemeral instances), then started to migrate.

Fascinating. No wonder why Red Hat got a little irritated.

What are you trying to imply here Paolo?
That there is a community around enterprise Linux that you chose not to participate in, and that is the Fedora ELN/CentOS Stream community.

And that I think I am finally understanding the differences between Alma and Rocky.

The difference was painfully obvious about 3-4 months in, this only confirms it. Everyone here keeps asking why would one pick AlmaLinux over literally anything else, while I'm sitting here asking myself how would anyone risk running his business on a distribution built on such a shady foundation, from sources obtained in a metaphorical back alley. Feels like a lawsuit waiting to happen, I wouldn't want to be on the receiving side of that for sure.
We participate in the Enterprise Linux community just fine. Our community members report bugs and throw patches at upstream projects, run SIGs creating value for EL, maintain Fedora and EPEL packages, etc.
You're talking about the users' community (and I have nothing to complain about that) and generic upstream; however I am talking about the builders' community instead.
Thank you for that.

This also decides the Alma vs Rocky question for me. Rocky wins.

You were very clear
For what it's worth I've been using Fedora 38 and it's been very stable. I moved from Ubuntu LTS's for years and have been super happy.

Any Fedora/RH devs/maintainers/employees reading this thank you for everything! If any of you are ever in Berlin beers/cola/etc are on me!

Fedora has definitely been winning big lately. Solid OS!
I know reading is hard, but the Rocky Linux project and SUSE have not teamed up. That is an entirely CIQ endeavor. The project's blog post from some time ago also explains the two avenues they're going down for their clone.
Tomayto, tomahto.

P.S. for other commenters. A fork is NOT a distro. If someone forks a project (as the shape of a fork implies), they go their own way. So if Oracle and SUSE fork RHEL, good luck on standardizing "enterprise" Linux.

What then is the point of Alma? How is it not just Fedora or a beta-version of RHEL?
Fedora and regular CentOS Stream aren't ABI compatible with RHEL. With AlmaLinux being based on the equivalent upstream RHEL release, most software should work like on RHEL. (That's because small differences in security fixes don't usually impact whether programs work (that's the entire point of them).)

At least that's my understanding fromwhat I've read.

CentOS Stream is ABI compatible with RHEL. It has to be, because RHEL minor releases are produced from CentOS Stream. Nothing can go into Stream that wouldn't go into RHEL.
> In the meantime it's not 100% clear how Rocky will continue working (they referenced some workarounds but not specifically how they'll get the source code from RHEL).

Weren't they spinning up virtual machines on public clouds, running their scripts, and getting the source from those VMs?

When did rocky announce their partnership with SUSE?