RHEL Compatability
Posted by NoonDread@reddit | linux | View on Reddit | 18 comments
It has been a while since Redhat closed its source code to the general public. Have any of the distributions that follow RHEL been able to maintain their compatablity with RHEL?
In other words, did Redhat succeed in supressing clones of RHEL?
NaheemSays@reddit
"Closed its source to the general public" was never the case. The git repos are still there in centos stream.
You got sold marketing by companies that then wanted to sell you their paid for products.
abotelho-cbn@reddit
That's not true. You can't build binaries I identical to RHEL from publicly available sources. Stream is not the same.
gordonmessmer@reddit
Today, Red Hat is actively maintaining RHEL 9.5, 9.4, 9.2, 9.0, and 9-major. In the old model, they'd be publishing build artifacts for 9.5 right now, but you wouldn't be able to build packages identical to 9.4, 9.2, 9.0, or 9-major. Why is 9.5 the "right" release branch, and not any of the others? Why not the more stable 9.4 branch?
abotelho-cbn@reddit
I'm not sure what you're supposed to be arguing here.
I'm not saying not being able to build the latest RHEL release from public source is good or bad. I'm just stating it's not possible. It's Red Hat's right to keep those sources exclusively to their customers.
You can build a compatible release, sure. That's what AlmaLinux does. But Stream is so often out of sync with the latest RHEL (forward or backwards) that it's not just valid to say you can build something from the exact sources RedHat uses to build RHEL.
Someone was literally just talking about OpenJDK the other day on an EL subreddit. OpenJDK just wasn't being kept up to date on Stream. OpenJDK, one of the single most popular runtimes in enterprise environments. If that's not a perfect example, I don't know what is.
gordonmessmer@reddit
I'm saying that today, Red Hat is maintaining 5 branches of RHEL 9. In the past, you'd be able to build one of them (9.5). Today, you can build one of them (9-major). It is no less possible to build a branch of RHEL today than it was in the past.
The old process also broke frequently, leading to out-of-date packages in the public git repos. This isn't new. It's imperfect, for sure. If you need that source, you should report the out of date git repo. Participating in the process is a fundamental part of Free Software development.
abotelho-cbn@reddit
Is 9-major a release of RHEL? A branch of code isn't the same.
gordonmessmer@reddit
Yes, 9-major is a release branch.
abotelho-cbn@reddit
I didn't realize RHEL provided 9-major binaries and package repositories. Sorry!
MatchingTurret@reddit
Actually, you can. The ingredients are all there, they just don't tell you the exact recipe.
NaheemSays@reddit
if you look at the builds and build numbers you can see which centos stream the RHEL build is off and then can backport the patches from later updates to the report to match the errata etc.
As an example, latest kernel in Stream for Stream 9 is 5.14.0-532. The important bit here is the ending: 532. The next build in Stream will be 533. However the same build for RHEL (if this kernel made it to RHEL stable release) would be 532.x(.y) and will have all or some patches in 533 (or even 534, 535 etc) backported onto 532.
AutoModerator@reddit
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
daemonpenguin@reddit
They did not succeed. Virtually all of them still have complete, bug-to-bug compatibility with RHEL. AlmaLinux seems to be the only odd one out, maintaining ABI compatibility, but also issuing its own security patches.
gordonmessmer@reddit
There is no such thing as a "bug for bug compatible" build of RHEL, and there never has been. For one, Red Hat does not publish build root info that would be required for reproducible builds (and they never have).
The old CentOS QA people periodically tried to tell users that, “We came up with the phrase “bug-for-bug” compatible during EL5 as a GOAL to aim for. CentOS was NEVER bug-for-bug compatible.”
But more importantly, a RHEL major release is a sequence of 11 minor releases, most of which are maintained for 4-5 years. RHEL is a minor-version stable release model. That isn't true of Rocky Linux, AlmaLinux, or CentOS Stream. Those systems are all one release stream per major release. They're a major-version stable release model.
From my point of view, the phrase never made sense. Like Aleksandra Fedorova, Red Hat Senior Principal Engineer, I share the view that RHEL does not aim to be "bug for bug compatible" with itself. Red Hat fixes bugs that affect their customers. Every patch that Red Hat ships breaks bug for bug compatibility with itself.
gordonmessmer@reddit
Red Hat did not close its source code to the general public. RHEL source code is more complete today than it was in the past, and is more readily available.
Before CentOS Stream, Red Hat published an incomplete portion of its code. A RHEL major release is a collection of 11 minor releases, most of which are maintained for 4-5 years, but Red Hat published the source code for only the first 6 months of each release, not the full life cycle. Furthermore, the source code that they published was actually a build artifact, not the original source used by RHEL. The RPM build process packages most of the source used during a build as a "src.rpm." In the old process, that src.rpm was unpacked after the build and published. But that process stripped out tests, etc, that are critical to maintaining a software distribution that's actually production-ready. The process that's used today includes all of the source for packages, and it's published in a manner that can be readily consumed by developers and collaborators.
jlmacdonald@reddit
You could honestly Google this so quickly.
Rocky Linux.
NoonDread@reddit (OP)
I asked because, for instance, AlmaLinux dropped the effort of being 1:1 compatible:
https://almalinux.org/blog/future-of-almalinux/
jonspw@reddit
Trying for 1:1 was always pretty dumb anyway, in hindsight.
levensvraagstuk@reddit
IBM wants to make money and does not really like open source.