On 4/28/21 6:01 PM, Phil Perry wrote: > On 28/04/2021 23:28, Jonathan Billings wrote: >>> On Apr 27, 2021, at 11:32, Johnny Hughes <johnny at centos.org> wrote: >>> >>> You would be hard pressed to find many FUNCTIONAL differences between >>> Stream and CentOS Linux // just as you would be hard pressed to find >>> many differences between RHEL 8.2 and RHEL 8.3, for example. >>> >>> Are there some differences? Sure. >>> >>> If people don't want stream, then by all means , use something else. >> >> This is true within the narrow scope of just CentOS/RHEL, but if, for >> example, you rely on ELrepo for kmods for hardware that Red Hat >> dropped support for, you’ll be sadly unable to use those kmods on >> Stream (elrepo isn’t supporting Stream[1]). >> >> There will also be inconsistencies with other third party repos and >> commercial software that focus exclusively on RHEL when Stream gets >> major version bumps ahead of RHEL. Certainly it will be an opportunity >> for those vendors to get their product working on Stream, so they’ll >> be prepared for the next RHEL release. >> >> But this is why people are calling it a beta test for RHEL. Yes, Steam >> running with only their core repos and software from within CentOS is >> tested and QA’d. But if you want to use Stream in a larger software >> context, be prepared for missing support and unexpected breakages. The >> only use I will consider Stream for will be as a test for upcoming >> RHEL releases, not as something I will ever want actual users to >> touch. (And maybe that’s ok) >> >> 1. >> http://elrepoproject.blogspot.com/2021/01/elrepo-and-centos-stream.html?m=1 >> >> > > The other concern for me is security. I've not had time to track CVE's > in detail, but even a cursory look shows there are CVE's which have been > fixed in RHEL8.3 kernel releases which are still not fixed in the latest > Stream release [1] (which if truly upstream of RHEL should presumably > get the fixes first before they are backported to the RHEL point > releases), and others where the fixes eventually appeared weeks or > months later [2]. I know CentOS makes no claims as to security fixes > etc, but at least with RHEL->CentOS Linux rebuild, one could reasonably > expect that when a security issue was fixed in RHEL, CentOS would have > the same release and fix out the door within 24-48h. With Stream we are > seeing delays of months for security fixes in the kernel that have been > released in RHEL. The only time the Stream kernel is comparable to the > RHEL kernel from a security fix viewpoint is once every six months on > the day the next point release fork occurs. This all indicates Stream is > not of production quality and hence why people associate / use the term > beta software. > > [1] CVE-2020-25705 > [2] CVE-2020-29661 > CentOS NEVER made security fix claims :) The kernel dies currently lag behind slightly .. but this is something that will be fixed when the full process is implemented for stream. Right now, because of secure boot signing not being automated completely .. and because of different keys for CentOS and RHEL .. the kernel process is manual, not automated. But, this process is being worked on. How many people actually really update their kernels and reboot on the day those updates come out .. or the 1 or 2 days later that CentOS currently takes to build them? But yes, one does need to look for how to fix those issues.