carlwgeorge

The source trees in a form suitable for modification (and pull requests) are here:

https://gitlab.com/redhat/centos-stream/rpms

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.

Mesa is kept current enough in CentOS that a backport isn't necessary. It's currently at version 25.0.7, same as Fedora 41.

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.

> But you skip over that.

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.

https://docs.fedoraproject.org/en-US/quick-docs/fedora-and-r...

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.

https://ubuntu.com/about/release-cycle#server-desktop-eol-ol...

https://access.redhat.com/support/policy/updates/errata#Life...

> 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.

https://access.redhat.com/compliance/fips

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.

CentOS is not a rolling release. It has major versions and EOL dates.

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.

You created an alt account with "centos" in the name just to complain about CentOS. Yeah, it's the hatters that are the weird ones here.

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.

It's the same major version, so it's extremely compatible. Plus if you run into something that doesn't work the same, you just discovered what's going to break for your workload on your RHEL system when the next minor version is released.

People that actually care about the distro being sustainable are quite happy with the changes. Sorry you don't get it.

To call it "completely different" is false. They are built differently, but the end result is still 90-95% the same software versions (because it has to be as the major version of RHEL). In fact, the way it is built differently is a massive improvement over the old process. The old CentOS was put together by 2-4 people at a time, with long delays after the corresponding RHEL releases, with no ability to actually fix bugs or accept contributions. The new CentOS (CentOS Stream) is built by thousands of engineers, literal subject matter experts who can actually fix bugs you report to them, or even better merge a contribution you submit. Also, the branding wasn't reused, the branding is for the whole CentOS Project, which still exists and is more active than ever. Also, you can still use CentOS in your dev environments, and it works great for that because you can prepare your production workload for upcoming changes in the next RHEL minor version ahead of time. You can also get free RHEL for dev environments, for the things you need to validate with the same minor version as your production RHEL environments.

For testing environments Red Hat will literally give them free RHEL. Problem solved.

Red Hat pays more people to work on open source than any other company I'm aware of. I am one of these people. I challenge you to find a single open source project included in a Red Hat product that doesn't contain contributions from Red Hat employees. Maybe a few exist, but the vast majority include Red Hat contributions, because we contribute all over the open source ecosystem.

Rocky and Alma are vulnerable to these CVEs too, as is RHEL. As a matter of fact, CentOS Stream 9 already has the fix to one of the CVEs. The rebuilds have to wait for it to show up in RHEL before they can rebuild it.

Absolutely agree, but one small point of clarification. One of the referenced CVEs (CVE-2023-1249) is rated low. The other two (CVE-2023-0590 and CVE-2023-1252) are rated moderate.

CVE-2023-0590 is already patched in C9, meaning the fix will likely will be shipped in RHEL 9.2. The other CVEs will probably get fixed as well (in CentOS first!), but when the RHEL maintainers are ready to, not based on some arbitrary deadline from a third party. Lower severity CVE fixes are routinely delayed until future minor versions, so this is nothing new, just an example of a security researcher not understanding how RHEL works.

> RockyLinux is by the guy who did CentOS, and seeks to follow it's principles.

Not quite. Back in 2003, when folks were first coming up with the idea of creating a distro that matched RHEL as closely as possible, Greg Kurtzer (the Rocky founder) explicitly stated that he would be interested in helping host it, but that he was "totally not interested" in leading it.

https://web.archive.org/web/20040909231336/http://www.caosit...

It wasn't until much later (~2019) that he started trying to retcon history by claiming he was the original CentOS founder.

While it's true that a good number of RHEL users don't use EPEL due to the lack of vendor escalation, there are many that do use it. In fact, they tell Red Hat that specific EPEL packages being available in the next version of EPEL block them from migrating to the next major version of RHEL. The feedback finally got loud enough that Red Hat decided to provide headcount to the Community Platform Engineering (CPE) group to create an EPEL team focused on improving EPEL (this is my team at work).

https://communityblog.fedoraproject.org/cpe-to-staff-epel-wo...

That said, the "vendor escalate-able only" group is large enough that RHEL is significantly underrepresented in EPEL stats. My guess is that somewhere around 40-60% of RHEL customers use EPEL. For RHEL rebuilds, I would guess that it's probably in the high 90% range, so their numbers in EPEL countme stats are probably fairly accurate. CentOS Stream on the other hand is also underrepresented, as we have countme data for both EPEL 9 and CentOS Stream 9, which shows there are over twice as many instances without EPEL as instances with EPEL.

Keep in mind that the countme data only includes systems connecting directly to Fedora's MirrorManager. Sites that run their own local mirrors are not included. We will never have a complete picture of popularity between these distros. For example, Facebook runs "millions" (a direct quote from their engineers' conference talks, they don't publish exact numbers) of CentOS Stream instances, which is more than everything else in the EPEL countme metrics combined.