Hi, There have already been plenty of responses to yesterday's announcement. Still I wanted to express my opinion about this change, but not just simply say that it is bad and complain about it. After all it is what we probably have to deal with. So please excuse me that my response is longer than most others so far. Disclaimer: I honestly haven't read all of the previous posts as many of them are quite similar. Hence some of the topics/issues I'll mentioned have probably already been mentioned previously. Background (as I haven't really been active on this mailing list previously, just skip if you don't care): I'm working for a small group of physicists at a university in Germany. As part-time work we are running and maintaining several systems, including storage systems (glusterfs) and what people tend to refer to as "HPC". All these systems are currently running CentOS Linux 7 (x86_64) or 8 (aarch64 and x86_64). Relying solely on public funds all our work shall be public as well. For software this simply means Open Source everything. Hence our budget for software is 0. Still this does not mean we simply want to get everything for free: We try to get involved in open source projects as far as possible. The experiences vary substantially depending on the upstream management. With Red Hat they have been good so far. The announcement of discontinuing CentOS Linux 8 and solely focusing on CentOS Stream was shocking at first, however after thinking about it, we might actually switch to CentOS Stream. We already cherry pick changes from CentOS Stream to fix bugs in CentOS Linux now instead of waiting for the next RHEL minor release. Hence the switch to CentOS Stream might actually not be that big, but the consequences for required 3rd party software might be. This has been the reason why we chose CentOS in the first place: It is supported by any/most hardware vendors (Intel, nVidia, AMD, Mellanox, Fujitsu, etc.). With RHEL now being developed more in public (due to the availability of CentOS Stream) I expect that the time between Red Hat releasing a new major/minor release and the hardware vendor officially supporting it shrinks. Which is obviously good. However I doubt CentOS Stream users will benefit at all. Yes, hardware vendors might use CentOS Stream internally to verify their software will work with the next minor release early on, but I doubt that they will release software updates for CentOS Stream or even officially support it. From a QA perspective supporting CentOS Stream is a nightmare and simply impossible to do: You can never guarantee that you fully support CentOS Stream as it might change and break stuff the moment you publish your software. If at all you could say you support CentOS Stream as of "YYYY-MM-DD xx:xx:xx UTC". Which would mean that I have to have a local copy of any CentOS Stream release. And in case of relying on multiple 3rd party software packages it gets almost impossible as the chances of all choosing the exact same timestamp are very unlikely. Hence I expect no official support for CentOS Stream by any hardware vendor. Still I expect that for most the software released for the latest RHEL minor release will simply work as is (e.g. AMD ROCm and nVidia CUDA) most of the time. For other hardware vendors that have been bad at even supporting recent RHEL minor releases, I don't expect any changes and you might simply be out of luck. E.g., in our particular case, Fujitsu who are still only supporting RHEL 8.1. However this is already an issue nowadays (we "fixed" it by maintaining our own fork of the required code). Still CentOS Stream (or a probably upcoming sophisticated RHEL rebuild) is our best shot to support all hardware we have with one OS. A second issue is that we require packages from EPEL (already adressed in the FAQ), ELRepo and other 3rd party community driven repositories. Afaik most of these currently target RHEL and not CentOS (e.g. EPEL and ELRepo). The packages just work on CentOS Linux as well due to it simply being a rebuild. This is not the case for CentOS Stream. However, these being open source community driven projects, we all can get involved there to fix this issue by adding CentOS Stream as a target OS. In case of ELRepo it might be a good idea to use DKMS instead of kABI kmod for CentOS Stream. I know that the kABI is supposed to be consistent for a major EL release, and hence understand why ELRepo uses kABI-tracking kmod packages. However experience has shown that this is not always true. Some packages have to be rebuilt for a new minor release. CentOS Stream being a rolling release you never know when a rebuild is required and there is no way to have seperate repositories for the "old" and "new" version as you simply can't specify what is "old" and "new". Hence I already have a first proposal now to consider: Add DKMS to CentOS Stream. With CentOS Stream being a rolling release it makes sense to support DKMS. Currently this is, afaik, part of EPEL. Just my opinion about this announced change to CentOS. Once the devel repository for CentOS Stream is populated (currently empty) and Storage SIG (glusterfs) builds are available (currently they just point to CentOS Linux 8 packages, which probably work fine) I'll give it a try. Thanks for reading and have a nice day! Peter On 08/12/2020 15.06, Rich Bowen wrote: > The future of the CentOS Project is CentOS Stream, and over the next > year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat > Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a > current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end > at the end of 2021. CentOS Stream continues after that date, serving as > the upstream (development) branch of Red Hat Enterprise Linux. > > Meanwhile, we understand many of you are deeply invested in CentOS Linux > 7, and we’ll continue to produce that version through the remainder of > the RHEL 7 life cycle. > https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates > > CentOS Stream will also be the centerpiece of a major shift in > collaboration among the CentOS Special Interest Groups (SIGs). This > ensures SIGs are developing and testing against what becomes the next > version of RHEL. This also provides SIGs a clear single goal, rather > than having to build and test for two releases. It gives the CentOS > contributor community a great deal of influence in the future of RHEL. > And it removes confusion around what “CentOS” means in the Linux > distribution ecosystem. > > When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will > be to migrate to CentOS Stream 8, which is a small delta from CentOS > Linux 8, and has regular updates like traditional CentOS Linux releases. > 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. > > We have an FAQ - https://centos.org/distro-faq/ - to help with your > information and planning needs, as you figure out how this shift of > project focus might affect you. > > [See also: Red Hat's perspective on this. > https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux] > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos