CentOS - Dec 2020 - https://blog.centos.org/2020/12/future-is-centos-stream/

On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen <lowen at pari.edu> wrote:
> On 12/9/20 12:10 PM, Brendan Conoboy wrote:
> > While I'm not sure how we'll get there, it seems like the
> > mutually satisfying end result would be one where third party binary
> > drivers work with CentOS Stream kernels.  Let's see what we can
do.
> >
> So, I want to address this part a bit.  In MANY cases, it's not a
> third-party driver that ELrepo packages; it's an in-kernel driver that
> Red Hat has decided to disable.  Such as the megaraid_sas driver I need
> for my servers.
>
Ah yes, that's a great call-out.  I'm not sure what the plan is there
(or
if there is one), but to me it seems like the sort of thing a SIG would
build.

-- 
Brendan Conoboy / Linux Project Lead / Red Hat, Inc.

On 10/12/2020 03:55, Brendan Conoboy wrote:
> On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen <lowen at pari.edu> wrote:
> 
>> On 12/9/20 12:10 PM, Brendan Conoboy wrote:
>>> While I'm not sure how we'll get there, it seems like the
>>> mutually satisfying end result would be one where third party
binary
>>> drivers work with CentOS Stream kernels.  Let's see what we can
do.
>>>
>> So, I want to address this part a bit.  In MANY cases, it's not a
>> third-party driver that ELrepo packages; it's an in-kernel driver
that
>> Red Hat has decided to disable.  Such as the megaraid_sas driver I need
>> for my servers.
>>
> 
> Ah yes, that's a great call-out.  I'm not sure what the plan is
there (or
> if there is one), but to me it seems like the sort of thing a SIG would
> build.
> 
Well, yes, about 10 years too late for those discussions I'm afraid ;-)

And besides, why on earth would Red Hat remove support for older 
hardware that you (understandably) no longer want to commit resources to 
maintaining, only to turn round and commit resources to maintaining them 
in a SIG? That's why you guys reached out to us (elrepo) in the first place.

Il 2020-12-10 04:55 Brendan Conoboy ha scritto:
> On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen <lowen at pari.edu> wrote:
> 
>> On 12/9/20 12:10 PM, Brendan Conoboy wrote:
>> > While I'm not sure how we'll get there, it seems like the
>> > mutually satisfying end result would be one where third party
binary
>> > drivers work with CentOS Stream kernels.  Let's see what we
can do.
>> >
>> So, I want to address this part a bit.  In MANY cases, it's not a
>> third-party driver that ELrepo packages; it's an in-kernel driver
that
>> Red Hat has decided to disable.  Such as the megaraid_sas driver I 
>> need
>> for my servers.
>> 
> 
> Ah yes, that's a great call-out.  I'm not sure what the plan is
there
> (or
> if there is one), but to me it seems like the sort of thing a SIG would
> build.
Brendan, can you clarify the following points?
- are you going to keep stable ABI between Stream kernel releases, or 
should we expect each kernel to break 3rd party drivers/modules?
- what/how many synchronization points are going to be with RHEL 
releases?
- what about security updates? Will they be released *before* the 
corresponding RHEL secure patch, or should we expect the (slow) current 
update cadency?
- is an upgrade path from Stream-8 to Stream-9 planned, or the usual 
"total server rebuild" will be necessary?

Full disclosure: the main CentOS point was to be 100% compatible, down 
to the specific kernel used, with RHEL. To get that, we lived with: a) 
comparatively few packages, b) not-working yum security-only updates and 
c) very restrictive selinux policies.

I am heavily invested in CentOS/RHEL ecosystem and I opened many bug 
reports/enhancement requests in the past years, so I would really like 
to continue using CentOS. However, using Stream seems to removing the 
key selling point (ie: total RHEL compatibility) without clear benefit.

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8