What a rug pull. This is something expected from one man distros but it suck for everyone to be tossed into what now pile.
The bug level or not of CentOS was not its selling point, but compatibility:
> Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®.
* https://en.wikipedia.org/wiki/Bug_compatibility
If I want a better balance between stability and longevity I run Ubuntu/Debian, which have LTS releases every two years: code that isn't too old, nor 'too new'.
Here's an example: about a half year ago the host of linuxunplugged.com (a pretty popular podcast IMO) invited representatives both from Alma Linux and from Rocky Linux. The Alma guy was happy to be on the show and showed up a few hours before it started to chat with community members. The Rocky guy asked if any other distributions will be there, and then sent a passive-aggressive email where he declined to participate because "we're not interested in being compared against other distributions", or something to that extent.
This small example pretty much sums up their entire attitude.
FWIW, I've been using https://almalinux.org for the past few months on a couple of dozen servers and it's been smooth sailing.
(I've also been using Oracle Linux and it too worked fine. If only it were not Oracle…)
I understand that if your goal was to use CentOS to validate a specific and highly critical workload for eventually running in production on Redhat systems (taking into account the version lock dance to make sure that you indeed have the exact same package versions on both environments, meaning a lot more hassle and delays in bug fixes and security updates that simply following the regulars updates), then Rocky/Alma/AnyRebuild will be better for you.
If your goal was already to run production on CentOS, with frequent updates for security, the theory would be that you will be even better served by CentOS Stream. My take is that it is the most popular case.
What am I missing?
Many high-availability workloads require a fixed operating-system baseline, where the only changes are security updates and high-priority bug fixes.
And even these changes may need to be triaged to determine if the updates are even worth risking uptime.
One example would be a hospital network with medical equipment workstations and backend servers. You don't want your ultrasound or key-hole surgery not working because a CentOS Stream update bug. Fixed operating baselines are important for many users.
And I'd probably describe it as less of a "bleeding-edge" rolling release, more a "boring-edge" rolling release. Yes it's a rolling release, but packages are going in as a final shakedown before release into RHEL, so it's really quite far away from experimental.
And I've not really noticed any material difference from pre-stream. I'm still able to use my CentOS boxes in the same way as I did before - in some cases as build boxes for things to be deployed onto RHEL boxes.
(And, to be honest, those example use cases are probably places where I would be seeking to use a commercially supported distribution, rather than a community supported one. Albeit a community supported distribution that copies/replicates a commercially supported distribution.)
From RedHat's announcement blog and Centos website: CentOS Stream "a continuously delivered distribution that tracks just ahead of Red Hat Enterprise Linux".
And indeed, I have read that all packages currently going into Stream 8 follow exactly the same testing and validation procedures than for entering Redhat Proper.
But of course, this holds true only for released RedHat versions. Meaning that Stream 8, is currently just ahead of RedHat 8.5 and will soon start to incorporate changes planned for 8.6 (so nothing like a "bleeding-edge test environment to test new changes" as you put it).
As for Stream 9 which was release recently, it is indeed the stabilisation socle based on fedora 34 that will eventually become RedHat 9. Once RedHat 9 released, Stream 9 branch will be stabilized and once again be "just ahead" of the impending RedHat 9 rpms.
In any case, I am not sure that hospitals should be running/updating self supported OS on surgical equipments without proper testing anyway.
Stream 9 is currently tracking RHEL 9.0, it shifted from the 9.0 Beta back around August. As we approach the ~May release for RHEL 9.0 GA, Stream 9 will start tracking RHEL 9.1 changes.
A key difference between Stream 8 and Stream 9 is the way the distribution is built. Stream 8 is a technically another rebuild project by the CentOS team, but one that rebuilds newer branch packages from RHEL engineering. In Stream 9, RHEL engineers are doing the builds themselves and are directly involved in the entire process.
There's a possibility that Stream 8 may adopt the Stream 9 workflow, but I'm not certain. With an EOL of 2024, it might not be considered a priority.
That was 2014; if this was the original plan, they took their sweet time with it.
Red Hat also offered a conversion procedure the last time I looked, but it replaced every installed RPM with equivalents from its own repositories. This is quite violent, and it would be far from my first choice for a critical system.
The whole point of CentOS was to be 100% compatible with RHEL, right down to the packages and binaries. For literally this kind of scenario. I don't see how that's "violent." I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages.
The code is the same, yes. The "binaries" are not, necessarily. The build environment isn't exactly the same and there have been bugs experienced in CentOS that weren't in RHEL and vice versa.
So it was never 100% compatible, more like 99.5%. The exceptions are rare edge cases but they do exist.
The thing is, they were almost exactly the same distro, so in any meaningful sense you could switch from one to the other by switching the release files, some yum support stuff, I think the kernel?, and some miscellaneous branding if you cared. But 99% of packages were functionally the same, so yeah I don't see replacement being a problem per se, but it also didn't seem very necessary.
In my experience major updates like this are discussed annually with eval, testing, and milestones set weeks and months apart. The transitions are often pushed a year or more when issues come up. Resources are dedicated to all of this.
It sounds like there are a lot of similar options with relatively easy transitions (away from Red Hat), but you still have to choose who you trust going forward and carryout the transition.
Sorry not sorry, but large outfits expecting to coast on a free offering don’t get sympathy from me.
That's why working at FB or Google is like going back in time as far as monitoring UIs, etc.
Some of the clever large companies took advantage of "site-wide support licenses." For example, Netflix paid MySQL AB $40,000/year for MySQL site support so they didn't have to hire any MySQL DBAs. Just keep filing support tickets. :)