CentOS - Apr 2021 - Centos versions in the future?

On 4/30/21 2:32 AM, Gionatan Danti wrote:
>
> Don't get me wrong: I understand that Stream is the way forward and 
> that things are not going to change, and this is fine. But trying to 
> ignore the key differences (shorter support, unknown upgrade from 
> Stream-8 to Stream-9, broken kABI, etc) is not useful to anyone.

 ??? 1: shorter support

CentOS support was not nearly as good as some people make it out to be.? 
(I don't mean to denigrate the work of the CentOS maintainers, at all.? 
I don't think this is a fault of theirs, only a realistic assessment of 
the consequences of the downstream placement of CentOS relative to 
RHEL.)? Each CentOS minor version was supported for (on average) five 
months.? At the end of that five months, there was (on average) no 
support for one month until the next minor release was ready and updates 
resumed.? Compare that to RHEL, in which every major release had 
continuous support without gaps for ~10 years and additionally, many 
minor releases had support for two years.? I will happily take Stream's 
uninterrupted life cycle over CentOS's longer but discontinuous life cycle.

Criticism of Stream on this point rests entirely on the idea that 
CentOS's life cycle was the same as RHEL's, but that has never been
true.

 ??? 2: Unknown upgrade path

https://wiki.centos.org/FAQ/General#How_do_I_upgrade_from_one_major_release_to_another.3F

"Upgrades in place are not supported nor recommended by CentOS"

https://access.redhat.com/solutions/21964

Red Hat does have *limited* support for in-place upgrades, but that is 
fairly recent.

Again, criticism of Stream on this point rests on the idea that CentOS's 
upgrade path was the same as RHEL's, but that is not the case.

 ??? 3: kABI changes

kABI changes in CentOS with every minor release, and the best solution 
here is probably to treat all kernel updates the same way you treat 
CentOS minor update today.? Use DKMS.? Build reproducible package sets 
with Katello, or Pulp, or reposync, or Spacewalk.? Test them.? Promote 
those to production when they're ready.

That's the same thing that we do, today, in enterprise environments.

> Stream is a *different* product, because is avoid (for the good or the 
> bad) basically *all* things that make RHEL so special. And lets face 
> it: kABI and long/quality support from RedHat are the only two things 
> which make RHEL special. Stripping them from CentOS

CentOS has *never* had support from Red Hat.? If you want to run a 
stable, supported production environment while you complete testing of a 
new minor release, you can get that from RHEL but not CentOS.? If you 
want to apply only security updates to a production environment to 
reduce risk (in the sense of both security and stability risks), you can 
get that from RHEL but not CentOS.? If you want to call an engineer for 
support when you have a problem in production, you can get that from 
RHEL, but not CentOS.

So, I will agree with you on one point: Support is the thing that makes 
RHEL valuable.? The product is excellent, but it's not the product that 
Red Hat's really selling, it's the support.? It's the things that
their
engineers do so that you don't have to, as their customer.? And CentOS 
has never offered that.

Of course, you can fill some of those gaps with your own engineering, 
but if you're filling those gaps with local engineering today, you 
should be able to fill them using Stream, too.

.

.

.

%<
>
> CentOS has *never* had support from Red Hat.? If you want to run a 
> stable, supported production environment while you complete testing of 
> a new minor release, you can get that from RHEL but not CentOS.? If 
> you want to apply only security updates to a production environment to 
> reduce risk (in the sense of both security and stability risks), you 
> can get that from RHEL but not CentOS.? If you want to call an 
> engineer for support when you have a problem in production, you can 
> get that from RHEL, but not CentOS.
So what is it you expect?, get an enterprise quality OS for free, and 
also expect highly paid, expensive, engineers to support your need for 
assistance on a whim for free too? Of course RHEL is very good at 
supporting their distros/releases, I use it often enough, because it is 
paid for (by my employer). You get what you pay for, and I have the 
impression that you using Centos and the support you DID get, probably 
didn't cost you a penny. I used both for the longest while, RHEL at 
work, Centos at home. Centos, as the (free) RHEL 'twin', is going away, 
so be it. Now I switched to RHEL both at home and of course still at 
work, RHEL even supports that, both.
>
> So, I will agree with you on one point: Support is the thing that 
> makes RHEL valuable.? The product is excellent, but it's not the 
> product that Red Hat's really selling, it's the support.? It's
the
> things that their engineers do so that you don't have to, as their 
> customer.? And CentOS has never offered that.
>
> Of course, you can fill some of those gaps with your own engineering, 
> but if you're filling those gaps with local engineering today, you 
> should be able to fill them using Stream, too.
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos