On 2/26/21 6:14 PM, Nico Kadel-Garcia wrote: > On Fri, Feb 26, 2021 at 9:34 AM Johnny Hughes <johnny at centos.org> wrote: > >> But from a user perspective, packages built from source code that will >> become the next RHEL minor release in less than 6 months is absolutely >> as "stable" and "usable" as any enterprise distribution out there >> besides RHEL. The fact that it has a 5 year lifetime and is free is as >> good as any released distribution out there. > > It doesn't necessarily work, without all the other bits being updated > at the same time. I'm particularly thinking of the "yum update > --security" update that included curl-libs and broke wget until you > did "yum update wget" or "yum update" for all components. There was > also the "python3" versus "python36" adventure in RHEL 7, which is > ongoing, and I anticipate similar adventures if and when python 3.8 is > released for CentOs 8 Stream^H^H^H^H RHEL 8. I try to play nice, and > have worked with updates to various components (published to third > party repos, in particular) that were broken when the base OS got > updates. I'm particularly concerned about breaking EPEL components. > yum --update security has never, ever worked in CentOS Linux .. not in any version. It will also not work on CentOS Stream. > This is an unavoidable risk of beta environments, whose updates of > critical components and libraries may occur at any time and without > any warning, kind of like the announcement of CentOS 8 stopping the > publicaiton of point releases. I'm very skeptical, due to a lot of > scar tissue, that critical daily use components like "awscli" from > EPEL will not be broken on an entirely unpredictable basis with an > update in CentOS Stream to, say, the "PyYAML".Python module. Python > and many other modular tools, can be very vulnerable to one component > being upgraded without the rest being upgraded. > It is not a beta environment. It is continuously released. Huge difference. This process is faster and more agile than, for example, the RHEL process. Will there be more issues in the code? Probably. But, you are not starting out with untested and unreleased code .. you are starting out with things that have been tested in Fedora and the upstream projects (GNOME, OpenOffice, Apache, OpenSSH, OpenSSL, etc) for a long period of time already. This software gets pulled out at tree freeze time and stabilized. Everything else that happens is happening to that Enterprise (and frozen / stabilized code). It is not like you are rolling in items from Rawhide, etc. >> I get it, people want what they had. Hell, I want it too. If / When >> the other downstream RHEL source code builds happen, use them if that is >> what you want. None of that requires bashing CentOS. CentOS is not >> bashing any of those distros. > > It's very difficult to trust CentOS right now. Production grade > services are... very mistrustful of "beta platforms", with good > historical reason. The answer seems to be "Get RHEL." Then move on to another distro. I will do my best work regardless of if anyone actually uses this or not. It will be available, use or don't use it, totally up to you.