Comment by dralley | Hacker News Reader

Comment by dralley | Hacker News Reader

Parent Full thread

The CentOS Stream transition was a shift from the "throw it over the wall" model of open source like Android to a more collaborative approach.

Example: As a user of (original) CentOS, you discover a bug. Where do you report that bug? The Red Hat Enterprise Linux bug tracker, because CentOS is just a clone and the community has no real ability to fix things. Then what? You wait until a Red Hat employee gets around to looking at it, and then wait until the next patch release which might be up to 6 months away.

Now repeat with the new model.

As a user of either CentOS Stream or one of the RHEL clones such as Alma Linux, Rocky Linux, Oracle Linux, etc. you discover a bug. Where do you report that bug? The CentOS Stream bug tracker, upstream for RHEL and thus also upstream for all RHEL clones. CentOS Stream is a community project, so the community (including yourself, and including maintainers for Alma / Rocky / Oracle Linux) can actively contribute to and drive the fix onwards to completion and test it afterwards, wheras before it would sit in internal nightly builds for a few months.

Both the community and Red Hat benefit from aligning incentives that way. However, I understand why there was a lot of frustration about the way it was announced and implemented. It could have been handled better.

disclosure: I work for Red Hat, but not on anything related to RHEL or CentOS Stream.

People used CentOS because it was extremely stable. It was the safest dsitribution to pick for a long-term support version of something, e.g. if you are distributing hardware to customers and you know you will have to maintain support for that hardware for 5-10 years. Companies that want this don't really care about community bugfixing and all that. They're happy with security patches so that their products look good in security audits, and will apply their own patches for other problems if they hurt their own product.

CentOS Stream is the exact opposite of all of that, with no upside at all for this model. It will push numerous companies away from IBM RedHat entirely. Especially as it is widely seen as the start of IBM creating a bigger moat around RHEL, so there is little confidence that future clones of RHEL won't see a similar fate one way or another. And while finding a bug and not being sure who to report it to is bad, finding out that your Linux distro was buried by your maintainers half-way through the lifecycle and won't get any new updates would be disastrous.

They can just use Alma Linux now, Red Hat does not see anything wrong with that.

For now. That may well change soon, who knows? They saw nothing wrong with CentOS until a year or two ago, for years.

It cannot change because of how copyright works. If you mean dropping CentOS Stream, that of course can happen but then all the Alma Linux folks have to do is go back to how CentOS was developed in 2010.

It's also not that Red Hat saw something wrong with CentOS Linux. To put it simply, between 2014 and 2019 Red Hat learnt that the company needed a free RHEL upstream more than they needed a free RHEL downstream. CentOS Stream is all about sharing participation to the CentOS community so that everybody does what they need and they don't have to ask mom Red Hat. Just read https://www.theregister.com/2021/07/09/centos_stream_greg_ku... ("Greg Kurtzer: Red Hat did the right thing and the new scenario is better than the old").

In fact, a lot of effort went towards making it possible to ship RHEL's upstream as a rolling release. Consider that ten years ago you had to ask specifically, months in advance, about updating a package in a RHEL minor release. In 2010, a quality engineer and I spent a few weeks working on grep just to make sure that the bugs were fixed in Fedora before RHEL 6 forked, because otherwise we'd be stuck with those bugs for years. These days I could just open a merge request on CentOS Stream and ask to update to a newer version of grep.

Disclaimer: I work for Red Hat, but not as a spokesperson

I may be off, but hey. As I understood it at the time, the reason wasn’t “OMG there are folks not paying us for the bits” but rather “we have this number of engineers, they can work either on CentOS Linux or on Stream” and Stream is more of a benefit to Red Hat as an upstream for RHEL.

What kind of Stockholm Syndrome is required for a user to believe that a transition from "bug-compatible with FIPS-certified stable releases" to "no-promises best-effort ABI stability" is desireable because now we get to do our own tech support?

I'll never in my life understand this. It's like Red Hat took the time they should have used to talk to their customers and spent it writing a Guide To Enjoying Eating Shit to lecture everyone about how great things are now.

I'd respect the company a lot more if they just said "we bought all this CentOS stuff and it turned out to be a money pit so we're throwing it out and making it a part of the beta testing process" instead of this relentless gaslighting that anyone on Earth wanted this.

This is only a very small benefit to CentOS Stream. Most users would never report bugs but still suffered the loss of a LTS CentOS.

CentOS has always had minor updates. Current support for CentOS Stream releases (Stream 8 and Stream 9) is comparable to old CentOS major releases.

Not really; ABI and kABI breaks came only with minor releases. With Stream, they come randomly.

Also, Stream support period is much shorter than the corresponding major release (e.g. Stream 8 till May 2024, RHEL 8 till 2029).

Reply on news.ycombinator.com