7 ms·
To quote Jeff: > Here's how it used to work: > Red Hat would grab a copy of Linux They would add magic sauce that makes it Red Hat Enterprise Linux > They wo
by parasense 3y ago
To quote Jeff:
> Here's how it used to work:
> Red Hat would grab a copy of Linux They would add magic sauce that makes it Red Hat Enterprise Linux
> They would release a new version.
> They would update a source code repository with all the data required to build it from scratch
A few remarks. The "add magic sauce" part is gone, all the secret sauce, or black box machinery is out in the open in CentOS stream. Red Hat no longer does any RHEL development behind the corporate firewall, and does everything out in the open in CentOS Stream. There is one caveat for security CVEs, but effectively those go into CentOS Stream and RHEL at the same time when the CVE embargo expires.
What this comes down to is wilfully ignoring CentOS stream. All the clones of RHEL can simply track CentOS stream, and even replicate all the "Secret Sauce" that is the CentOS Stream CI/CD workflow. The process of replicating RHEL is so much easier today than ever before.
- geerlingguy 3y agoTwo thoughts: > The process of replicating RHEL is so much easier today than ever before. Doing so bug-for-bug requires more effort than it did a few weeks ago. And they're basically doing that work in parallel with Red Hat itself (duplication of effort). Also, making a change like this (forcing Rocky and AlmaLinux to change in the middle of the 9.x release cycle), when the previous change (killing CentOS) was _also_ in the middle of the 8.x release cycle, with not even 24 hours warning... makes me feel this change was not _only_ made "to make CentOS and RHEL development better." If that were the case, the changes would be announced with at _least_ weeks (if not months) of warning, so the community could plan for it instead of getting blind-sided... now twice in a row.
- CrLf 3y agoWhy do bug-for-bug with RHEL at all? Why not turn Alma and Rocky into stable distributions in their own right? If this pushes RHEL into oblivion, why should anyone care? The Debian ecosystem isn't centered on Ubuntu, it's centered on Debian. Comparisons between the two ecosystems are invalid because of this simple fact. It would be nice to see the "Red Hat" ecosystem recenter around something which isn't a direct source release of a commercial product. Alma and Rocky should rebase on CentOS Stream for starters, and then try to get closer to Fedora as an upstream. (BTW, I speak as someone who did corporate systems administration for years and understands the use case of replacing RHEL licenses with free CentOS installs perfectly.)
- bluedino 3y ago> Why do bug-for-bug with RHEL at all? Why not turn Alma and Rocky into stable distributions in their own right? Because the whole point is for them to be 'compatible'. Many of the users are running software that needs to be on RHEL/CentOS/Rocky/etc or it won't be supported. Sure, there are users who just want a stable OS, but the real point of Rocky/Alma is to have a 100% RHEL-compatible, but free distro.
- bonzini 3y agoThere are many levels of compatibility. ABI compatibility is perhaps the least stringent, bug compatibility is the most picky.
- chasil 3y agoI'm not certain that much more effort is required. Untraceable uploads with Onionshare over a Tor browser would conceal the origin of source RPMs that did not bear fingerprints. Once captured, all that is really required is the updated SPEC file, and any modified sources or patches (if I remember my RPM internals correctly). Alma could maintain such an Onionshare instance. If the SPEC and patch files are specifically GPL, I'm not sure that Alma could be compelled to forego them.
- jzb 3y agoLet me preface this by saying, Jeff owes Red Hat nothing and he's free to stop "supporting" RHEL for any or no reason at all. That said, "grab a copy of Linux" seriously, gloriously, hilariously handwaves away so many things that Red Hat does to create a RHEL release. Red Hat pulls together hundreds or thousands of upstreams to create RHEL, participates in many of them, tests all that together, helps partners certify software against it, etc. etc. etc. It's true, Red Hat doesn't "own" the Linux kernel, but it's done a ton to help develop it over the years. But RHEL is not merely the kernel nor any single upstream. RHEL is a product that comprises thousands of packages all tested together and then released as a supported product. What Red Hat is trying to guard is not the source code to any single or even groups of projects. It's trying to preserve and capture the value it created from all those parts. Coincidentally, that value is what businesses, competitors, and the community are clamoring for and not the source code alone. They want that single point-in-time snapshot that everybody agrees on as a de facto standard because the overall community has never been able to agree on another workable standard that would allow targeting applications across the board. And that standard has a name, and it's RHEL. And it belongs to Red Hat. You can have all the pieces and assemble them yourselves if you like. But nobody is entitled to certify it as (officially or unofficially) RHEL except Red Hat. If that angers you, I heartily encourage folks to build Debian up as the standard we all certify against. Or start your own business that overtakes Red Hat and earns the place RHEL has today. Mark Shuttleworth took potshots at Red Hat's business model with RHEL for years, and it seems to me that they're doing a very similar thing now with Ubuntu Pro by holding back updates to packages after 5 years and charging for updates to the Universe and Main repos.
- Pet_Ant 3y agoI think the main thrust of all of this is to de-commodify Linux. To make RHEL really be in people's minds it's own operating system outside of Linux. It's hard to do when it's really just a ball of generic open source components. Hence, this hostile behaviour. They don't want to be Linux, they want to be RHEL and ask not about the man behind the curtain.
- jzb 3y agoJust the opposite, I think. Red Hat is fighting the idea that the operating system is a commodity, and demonstrating that the RHEL subscription does have value. Red Hat's competitors have tried really really hard to undermine RHEL as something of value. The cloud providers like AWS and Azure provide their own base Linux distros to run workloads on. They'd love to cut Red Hat out of the picture. Oracle wants to convince customers to give it all their money to run workloads, hence Oracle Linux -- that's based on RHEL. If RHEL were, as you say, "a ball of generic open source components" then you wouldn't see all this wailing and gnashing of teeth about making it harder for Alma and Rocky to claim "bug for bug" compatibility with RHEL. Nobody would care. Note that this has been going on for more than 20 years, and this isn't the first time. I've been writing about this on my blog, but we've seen this story before and the only thing that has changed are the names of the vendors / projects and the version numbers. (See: https://dissociatedpress.net/2023/06/26/red-hat-and-the-clone-wars-ii-a-history-of-the-early-2000s-linux-landscape/ https://dissociatedpress.net/2023/06/26/red-hat-and-the-clon...)
- redundantly 3y ago> What this comes down to is wilfully ignoring CentOS stream. All the clones of RHEL can simply track CentOS stream You are willfully ignoring that CentOS Stream is upstream of RHEL. CentOS was downstream of RHEL. Oracle Linux, Alma Linux, and Rocky Linux are all downstream of RHEL. Feel free to argue all day about how similar CentOS Stream is to RHEL. Go ahead and argue how much it doesn't matter to you that it's now upstream. The fact of the matter is whether it's upstream or downstream does matter to a lot of users and companies. It does matter that IBM is trying to block access to open source code and is trying to restrict its subscribers from redistributing that same open sourced code. IBM is causing extreme harm to the open source ecosystem that they profit from.
- jwitthuhn 3y ago> The process of replicating RHEL is so much easier today than ever before. I would argue that it was easier a few weeks ago when they made source rpms available publicly.