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.
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.
a.k.a. stable-proposed-updates
Debian Stable point-releases are not truly 'fixed-interval' of course, but close enough.
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.
For some definition of community.
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.
Fascinating. No wonder why Red Hat got a little irritated.
And that I think I am finally understanding the differences between Alma and Rocky.
And what exactly do you mean by "builders' community", do you actually mean "Red Hat"?
By "not participate in" do you mean "not pay your employer"? Which we do, actually. Just wired a good chunk of money to Red Hat the other day, ostensibly earmarked for supporting the Fedora project.
> ostensibly earmarked for supporting the Fedora project.
Thanks for that. I never said you don't support the rpm-/Fedora-based ecosystem as a whole, and I appreciate that you also do so monetarily.
> I never said you don't support the rpm-/Fedora-based ecosystem as a whole,
Er. Really?
Maybe this dichotomy prompted the whole "hackers and hobbyists" imagined threat.
In the case of EL, Fedora and CentOS Stream are communities that office both users and builders, but the two groups congregate in different places. For example EPEL is targeted at the user community but it is outside the focus of the builder community. ELN is of interest to builders but it is outside the focus of the user community.
All users can choose to contribute (with bug reports, code, whatever) at either the upstream or the distro level; or they can just be users. Builders are a (very small) subset of the people who consume a distro, and like all users they can choose how much to participate in the community and whether to be contributors or not.
But that ship sailed, the good of the downstream users' contributions are not enough to cancel out the negative net value of the builders' bad behavior.
However: unfortunately part of what you said is true. Red Hat apparently took this decision because of some new facts that caused the negative from the "rebuilders" to increase, and the decision had the potential of hurting the users of the rebuilds.
Fortunately it's clear now that there are multiple ways for the downstreams to adapt[1]. Users will be able to keep their distros and—if they wish—contribute in a number of ways to the community. And builders and Red Hat will be able to collaborate in a shared place which is ELN for major released and Stream for minor releases. In a sense this removes excuses from Red Hat and should make everyone feel safer.
[1] you could say despite Red Hat's change, and I accept that. But it's also thanks to Red Hat going overall beyond the requirements of the open source licenses, with things such as Stream and the UBI source container.
This also decides the Alma vs Rocky question for me. Rocky wins.
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.
Doesn't Oracle ship both the RHCK (a duplicate of the RHEL kernel) and the UEK (their own kernel)?
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
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.
At least that's my understanding fromwhat I've read.
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!
Weren't they spinning up virtual machines on public clouds, running their scripts, and getting the source from those VMs?
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...