It's not a totally different distro, it's a different variant of the same distro. Back when I was on the release team I would create builds, release them in CentOS Stream 8, then a few months later release them in CentOS Linux 8. It was the same content on a different schedule, released once it passed QA rather than batching up most updates into minor versions.
CentOS Stream has major versions and EOL dates, and thus is not a rolling release. It functions as the RHEL major version branch and follows the RHEL compatibility rules, so it's the same major version stability as RHEL.
While you may have considered bug-for-bug compatibility the main feature, it was a major point of frustration for many users and the maintainers. That model means you can't fix any bugs or accept contributions from the community. CentOS finally fixed both problems by moving to the Stream model.
CentOS Stream has major versions and EOL dates, and thus is not a rolling release. It functions as the RHEL major version branch and follows the RHEL compatibility rules, so it's the same major version stability as RHEL.
While you may have considered bug-for-bug compatibility the main feature, it was a major point of frustration for many users and the maintainers. That model means you can't fix any bugs or accept contributions from the community. CentOS finally fixed both problems by moving to the Stream model.
It warms my heart to see someone else recognize this. The bug-for-bug model that classic CentOS Linux followed was fundamentally broken. Sure there were lots of consumers, but without the ability to fix bugs or accept contributions it was dysfunctional. The underlying motivation of the CentOS Stream changes was resolving this conflict, so that bugs can be fixed and contributions can be merged, resulting in a more sustainable distro.
Each version of CentOS Stream is maintained for about 5.5 years, plenty to qualify as an LTS and significantly longer than Fedora (the base for non-LTS Bluefin).
> Heaven forbid you run RHEL on RHEL in containers, you’re gonna get fleeced.
You can run unlimited RHEL containers on a subscribed RHEL system. It's even set up where if you run a UBI container (a redistributable subset of RHEL content) on a subscribed RHEL system it automatically upgrades to full RHEL.
It's pretty common to reply to specific aspects of a comment. That's what the markdown quote notation is for (even if it doesn't render properly on this site).
> I think as a compressed timeline summary, mine was fair enough.
But it's not merely compressed, it's factually incorrect.
> I don't think "well, actually, this happened before that" is as important, TBH.
That tracks considering you write for a tabloid with a tumultuous relationship with accuracy.
> Around the same time, Red Hat discontinued its free Red Hat Linux and replaced it with the paid-for Red Hat Enterprise Linux and the free, unsupported Fedora Core.
This is a common misconception. RHEL and RHL co-existed for a bit. The first two releases of RHEL (2.1 and 3) were based on RHL releases (7.2 and 9). What was going to be RHL 10 was rebranded and released as Fedora Core 1. Subsequent RHEL releases were then based on Fedora Core, and later Fedora.
Then why does this article give "special thanks" to Fedora, but not Red Hat? Or point out the fact that the vast majority of the Fedora RISC-V porting work is being done by Red Hat employees?
Ubuntu Pro and RHEL are both 10 years for their standard lifecycle, with optional add-ons to go longer. Ubuntu's is called "Legacy Support" to get an extra 2 years, RHEL's is called "Extended Life-cycle Support" to get an extra 3-4 years.
> Kind of like how RHEL used to still provide contributions to CentOS for a long time (although I think that ended at some point too).
RHEL contributes to CentOS now more than ever.
CentOS started outside of Red Hat (2003), and didn't get any direct contributions from Red Hat. It built from RHEL sources, which is an indirect contribution that didn't involve any Red Hat employees. Later Red Hat hired most of the CentOS maintainers (2014), and contributed to CentOS by paying their salaries and providing hardware resources, but that was where the contributions ended. This was the status quo until 2021, which is when RHEL maintainers were onboarded to CentOS, drastically increasing the number of people working on CentOS.
DNF didn't start as a competitive fork of Yum, it started as the Python 3 rewrite of Yum from the same developers. It was really just Yum version 4, using a different name so it could be installed in parallel with Yum for an extended period of time. Yum changing algorithms was never on the table, as that Python 2 code had to get phased out. Fedora, CentOS, and RHEL switching to it was always the plan.
This blog post uses a really weak report as the source for its information. The survey used for the report only got 433 responses. Based on the percentages given in the report, RHEL-related distro usage breaks down like this among the respondents.
- 113 CentOS
- 93 RHEL
- 62 Fedora
- 50 Amazon Linux
- 44 Rocky Linux
- 35 AlmaLinux
- 29 CentOS Stream
- 15 Navy Linux
That's a hilariously small sample size, so small that I would say it's irresponsible to draw any real conclusions from it. Never mind the fact that the survey potentially confused respondents by not clarifying CentOS as CentOS Linux.
Meanwhile, CentOS Stream dnf countme data shows that 2.1 million unique systems are hitting the public mirrors, and Meta engineers have publicly stated in conference presentations that they run a fleet of "millions" of CentOS Stream systems using private mirrors. So you'll excuse me for not worrying about only having 29 reported users on a tiny survey.
That doesn't show any actual FIPS certificate numbers. Neither does the top link. If CIQ has any FIPS certificates I can't image why they wouldn't list them prominently to remove any doubt. That's what Red Hat does.
The planning to swap the RHEL/CentOS relationship (i.e. CentOS Stream) long predated even the "intent to acquire" announcement from IBM, and of course the actual acquisition as well.
So you say "it would be easy and seamless", but did you ever actually do it and upgrade to RHEL? Because most people throw that out as a supposed sales pipeline that was lost, but the real life metrics indicate that almost never happened.
If you're running cutting edge datacenter hardware, CentOS is a better fit now than it ever has been before. It will be the first to get support for new hardware within a major version, ahead of RHEL and all it's derivatives. It is possible that some hardware doesn't get support within the current major version of any of these related distros, and you'll have to wait until the next major version, which CentOS also does first before the rest.
https://gitlab.com/redhat/centos-stream/rpms