[CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/

On Fri, Dec 11, 2020 at 6:43 AM Louis Lagendijk <louis at fazant.net> wrote:
>
> On Thu, 2020-12-10 at 20:02 -0500, Konstantin Boyandin via CentOS-devel
> wrote:
> >
> >
> > What's not nice is that CentOS community will inevitably be
> > disrupted
> > and dispersed.
> >
> > Unless the RH announcement was a shortsighted and dumb sacrifice to
> > Money, I assume they just brush away what they consider "unnecessary
> > expenses". In any case, I continue to evangelize open source, Linux
> > included, it's just CentOS and RH that won't be promoted (by me) any
> > more.
> >
> I interpret the Centos change of direction as indicative of the change
> in direction for RedHat: RHEL has become much less important as IBM
> focuses on web applications, cloud tooling etc. That is where the money
> is and that is what they bought RedHat for. So RHEL has to optimize OS
> costs as is it no longer key. So it is only logical to optimize the
> development process and outsource some of the testing to the public in
> Centos Stream, and not waste resources on a true free competitor for
> RHEL.
>
> Now For Stream I am mainly worried about 2 things:
> 1 - the kernel and its impact on drivers from Elrepo and other external
> repos (OpenZFS!). Not important for RHEL, but important for people that
> use old hardware that requires drivers not in RHEL.

Others have expressed this concern, and it's a good one.  It would be
interesting to see if someone could create a CentOS Stream SIG that
did automated rebuilds of those drivers with every Stream kernel
update.

> 2 - the frequency of updates from Centos stream, which will require
> much more frequent updates. As some updates will be security fixes
> skipping frequent updates is not an option....

There are probably ways that people can still selectively update based
on what changed, but it is true that Stream will have a more frequent
cadence.  However, it's worth pointing out that the update frequency
isn't the same across the entire package set.  We have packages in
RHEL that rarely update, and if they do they are for bugfixes.  Only a
portion undergoes a lot of activity every minor release.

josh