Il 2021-04-30 06:55 Gordon Messmer ha scritto:> Why do you think that?? Are RHEL (and CentOS) point releases backward > compatible or not?? If you trust point releases to work, why would you > hesitate to trust a distribution that resembles an upcoming point > release?Because it very often break kABI compatibility, with 3rd party module heavily affected. 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. 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 will produce a very different product. And, as a side note, things break more often on Stream-8 then CentOS8. Maybe Stream only needs to mature, but it still a different product. My personal opinion is that RH created Stream to give cloud vendors a place to experiment/repackage *before* adding that to the main RHEL distro. Stream really does not seem targeted at small sites / "normal" sysadmins, rather at large cloud vendors. Which, again, is perfectly fine unless trying to disguise it as an "almost-RHEL" distro. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8
On 4/30/21 4:32 AM, Gionatan Danti wrote:> Il 2021-04-30 06:55 Gordon Messmer ha scritto: >> Why do you think that?? Are RHEL (and CentOS) point releases backward >> compatible or not?? If you trust point releases to work, why would you >> hesitate to trust a distribution that resembles an upcoming point >> release? > > Because it very often break kABI compatibility, with 3rd party module > heavily affected. > > 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. > > 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 will produce a very > different product. And, as a side note, things break more often on > Stream-8 then CentOS8. Maybe Stream only needs to mature, but it still a > different product. > > My personal opinion is that RH created Stream to give cloud vendors a > place to experiment/repackage *before* adding that to the main RHEL > distro. Stream really does not seem targeted aSo, t small sites / "normal" > sysadmins, rather at large cloud vendors. > > Which, again, is perfectly fine unless trying to disguise it as an > "almost-RHEL" distro. > Regards. >Sure .. so block kernels and build your own in that situation. Or use something else. There are always edge cases. There are millions of CentOS users. What percentage use 3rd party modules (other than nvidia drivers). There are some, and this would be a problem for those people. So, IF another downstream distro works for you .. use it. Or use Debian or Ubuntu, or BSD. Use Alma or Rocky Linux. Buy RHEL. Any number of solutions.
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 CentOSCentOS 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.