On 19/12/2020 20:37, Trevor Hemsley via CentOS-devel wrote: > On 19/12/2020 20:09, Gordon Messmer wrote: >> On 12/19/20 1:13 AM, Peter Georg wrote: >>> However I disagree on one point: You mention CentOS Stream can cover >>> "95% (or so)" of the current users. As long as 3rd party drivers are >>> not working with CentOS Stream the number will be lower. >> >> >> Do you have a reason to think that > 5% of users need 3rd party drivers? >> >> >>> In my opinion, the only way to guarantee compatibility is by 100% >>> kernel ABI compatibility. >> >> Stream is going to continue to get the same kernel that RHEL gets, >> it's just going to get updates earlier. > > No, it's not, That's the point. It's going to have the unstable kernel > from the NEXT point release so it will not be the same kernel as the > current RHEL point release. Case in point, RHEL 8.3 has 4.18.0-240 > series kernels, Stream had changed to a 4.18.0-257 kernel within 2 or 3 > days of CentOS 8.3 being released. > >> In the past, users with binary 3rd party drivers would need to wait a >> while after a point release before they could update their kernel. In >> CentOS Stream, they'll have to wait a while after a kernel package >> update before they can update their kernel. > > And that change happened on a predictable, approximately 6 month > interval. And required the third party drivers to be rebuild once per > point release and usually, by the time the CentOS build was done, those > drivers were already rebuilt and already available since they had been > done for the preceding RHEL point release. > > So we're going from a once every 6 months rebuild to a once every time > the RHEL kernel developers feel like changing. Those changes were > abstracted from the CentOS and RHEL kernels by the fact that KABI > changes only happened (intentionally!) at point releases. Now that will > change whenever someone in the kernel development team commits a > breaking change. So we're going from a rebuild the drivers every 6 > months to rebuild the drivers whenever RH feel like breaking it. That > could be once a month or once a week or every time the kernel is updated > or even once every 6 months like stable RHEL (though the chances of that > are slim IMO). And since RHEL will still be using the old kernel series, > that means that the third party yum repos have to invent a new way to > cater for both RHEL and Stream since they will be different. > > Trevor This whole argument is all a matter of perspective, from which side of the fence you are looking. As a *developer* of 3rd party driver packages *for RHEL*, CentOS Stream will work well for me as a CI develop system to help me develop driver packages for the *next* RHEL release (8.4). I get to see what changes are *coming* and can develop against them. That said, I kind of already had that ability from the old RHEL point release betas but I gather moving forward we will get far more kernel updates to Stream than we have to date. To be clear, we develop for RHEL. We will not be developing *for* Stream, but we may well use Stream to help develop for the next RHEL point release. So for me as a developer, Stream is fine. But for my users, the 2 million or so people who use and depend upon the software package we distribute, Stream is a non-starter. These packages are developed for RHEL (and CentOS Linux as a binary compatible clone). Stream is not a replacement for CentOS Linux. CentOS Linux is dead, gone (or rather going). Those Enterprise Linux users viewing Stream as a replacement to CentOS Linux, they are trying to bash a square peg into a round hole if they have a requirement to use 3rd party drivers.