Comment by helen___keller | Hacker News Reader

Comment by helen___keller | Hacker News Reader

Parent Full thread

I appreciate the blog. I was pretty alarmed by the announcement, and I think as you mention a lot of it boiled down to that devilish-sounding line:

> If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options

But, after reading your message I can partially see your point of view, in particular your gist seems to be that in the chain of development, CentOS Stream will sit where RHEL used to be, thus if you believed in RHEL as a boring, stable, reliable OS in the old world then so too should CentOS Stream be a boring, stable, reliable OS in the new one.

This logic makes sense, with one exception: this assumes that the standard for release quality remains unhindered pre/post swapping the position of RHEL / CentOS.

Before, Red Hat was incentivized to make sure RHEL releases were solid gold because paying customers were on the receiving end. CentOS releases were downstream of solid gold, making CentOS solid gold as well.

Now that the positions are reversed, what incentive does Red Hat have to make sure things are stable and low-risk before shipping to CentOS Stream? This is ultimately a matter of trust: if CentOS Stream gets a bad release, no paid enterprise server explodes. Quality no longer aligns with profit motive, a terrifying insight.

> This logic makes sense, with one exception: this assumes that the standard for release quality remains unhindered pre/post swapping the position of RHEL / CentOS.

There's another issue, which I haven't seen talked about so far. With CentOS downstream from RHEL, there were the Release Notes: before updating from CentOS 8.x to CentOS 8.y, you could read the CentOS release notes (and the voluminous RHEL release notes corresponding to it) to see if there was any breakage to expect for your use case. For the security updates within a release, you could follow https://lists.centos.org/pipermail/centos-announce/ (sadly non-working for CentOS 8) and/or the voluminous RHEL errata pages corresponding to it.

With Fedora, before every update I glance at https://admin.fedoraproject.org/updates/ to see if there is any known issue with the update I'm about to do; this has saved me more than once (for instance, there was a broken selinux-policy update which would relabel the whole /home not long ago). I recall Debian had something similar (which shows you any release-critical bug recently filed for the packages you're about to install). Will CentOS Stream have something like that? If I run "dnf update" and see it's about to update bash, is there anywhere I can look to see what changed, and whether someone complained about the update?

Great point also. I am going to pass your question to some people that I hope can answer it.

I got a response. It looks like this is not currently implemented, but some details are still being worked out so it's possible we could get something like that. A digest has been requested before and thought is going into what it would look like and what any technical hurdles would be.

I also learned a new command that I'm adding to my toolbox:

    dnf changelog --upgrades

Thanks for the response, and thanks for reading. You make a terrific point:

> This logic makes sense, with one exception: this assumes that the standard for release quality remains unhindered pre/post swapping the position of RHEL / CentOS.

I don't really have an answer for that. It does seem like it would come down to "trust" and as a skeptical person I don't like that very much.

As I think about it more, while we have realigned some economic incentives for the better, it does seem (in addition to your points) there might also be an "incentive" to break CentOS from time to time, just to remind enterprises who are using it that "RHEL" is the gold standard and CentOS is "unsupported" D-: Knowing Red Hat and many of the volunteers that work on these projects, I would be shocked (and indeed would quit my job immediately) if such a thing were to happen, although it would be hard to prove.

That said such a thing would no doubt backfire. There would be outrage of course, and it would hurt the CentOS brand (which also hurts RHEL since these days the two are inextricably linked). We all fully expect another distro to "take the place" of old CentOS as a bug-for-bug rebuild (I'm excited about Rocky Linux personally) so not will there still be an option for that, but competition is great for quality of projects :-D

Anyway, much appreciate the comment :-)

I'll keep mulling it over as well.

>>it would hurt the CentOS brand

That ship has sailed. Even if what you say is true, the public reaction this is change has tarnished all the Brands, CentOS, RHEL, RedHat, and IBM...

It will be a very long time to rebuild the trust, and honestly if RedHat stays the course and refuses to support CentOS 8 for the full life cycle I think CentOS will usage (and RHEL usage) will drop off a cliff

I have already seen several software vendors with RHEL only official support announcing they are working on debian and ubuntu certification, and since it seems CentOS Stream at the most will only be supports for a 5 year life cycle down from 10, I am not sure why I would not move to debian at this point. debian is just as stable, the one thing CentOS had over it was the 10 year support, that is gone now

This still seems a little sensational. Fedora would be the explosion here. If Stream is a release candidate they still have every reason to keep it stable so RHEL updates more quickly.

That probably depends, how strongly Stream and RHEL actually are going to be linked. If this relation is indeed similar to current situation, but centos and RHEL changing places, then there isn't much point holding QA until RHEL release. Actually, there is going to be good initiative: when you upstream is unusable, because too buggy and untested, then what? Whole point of Stream seems to be usable base to RHEL.

Reply on news.ycombinator.com