On 19/12/2020 21.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? I never said that. I just assume that the amount x of use cases CentOS can not cover plus the amount y of users that need 3rd party drivers is greater than 5%. So yes, you are right, it is an assumption by myself, but so has been the assumption of 95% by Karsten. There are many 3rd party driver / kernel modules you probably do not need. That is good for you, but other people depend on these. I wish all software/hardware I use would be supported 100% by upstream kernel, sadly this is not the reality. Even if they are supported upstream, hardware vendors often supply backports for EL (e.g. AMD ROCm). > > >> 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. > > 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. > > There's really very little changing, here. The point releases are going > away, so the date of kernel updates is less predictable, but the > solution hasn't changed at all: If you use a binary 3rd party kernel > module, you need a process in place to block kernel updates until your > 3rd party kernel modules are available It's not that simple. Currently we have a kernel build 4.18.0-x.y in CentOS 8. As Trevor already told you, kABI changes only (there might be exceptions) happen when x is changed. x is fixed for a particular minor release. In practice this currently (i.e. with CentOS Linux) means that at some point all 3rd party drivers will support a particular kernel version x and all its updated versions x.y. I.e. we are good to upgrade to this particular minor release. We can even update the kernel within this minor release to get security fixes. With CentOS Stream x is changing frequently, y does not exist at all. In the best case, the same build x used in a minor release is also available in CentOS Stream (actually it should be available in any case). Up to this point everything seems fine as you said, I "just" lose the opportunity to update the kernel as long as any 3rd party driver I have installed is not yet available for version x+? [1]. Nothing new, just like it has always been? Here's the tricky part: In CentOS Linux I can update the kernel only changing "y" and retaining kABI compatibility to fix security issues. In CentOS Stream these security fixes will be part of a new kernel version x+? not having any guarantee about kABI. Any kernel version x.y released in RHEL will NOT be available in CentOS Stream. Maybe this somewhat longer explanation helps you to understand this issue. [1] One should also note here that I need to have installed this particular kernel version x as it will not be available from official repositories once x+1 is released. Which in turn means that I somewhere have to store ALL ever release kernel (and directly dependent) rpms as I never know which version "x" will be used for the next minor release and hence be the "chosen" version all 3rd party drivers/kernel modules will be built against. Peter > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel s