[Wolves] CentOS

[Chris Ellis]

On Wed, Dec 9, 2020 at 12:52 PM Adam Sweet via Wolves
<wolves at mailman.lug.org.uk> wrote:
>
> On 08/12/2020 18:23, Chris Ellis via Wolves
> <wolves at mailman.lug.org.uk> wrote:
> > Looks like CentOS is dead, at least as we know it!
> >
> > https://blog.centos.org/2020/12/future-is-centos-stream/?utm_source=rss&utm_medium=rss&utm_campaign=future-is-centos-stream
> >
> > Ironically it looks like Red Hat is restructuring CentOS along the
> > lines of the relationship SUSE has with openSUSE.
>
> Lots of good discussion on this on the Birmingham and Shropshire lists
> already, but I'll add my 2p.
>
> I can understand the financial motivation to push CentOS users towards
> RHEL for those that need the rock solid OS and new releases every few
> years. I can understand that a rolling release distro that sits "just
> ahead" of RHEL's development meets the needs of a subsection of its
> users, but that phrase 'just ahead' is doing an awful lot of the work in
> that sentence and this is ultimately a disaster for the people that use
> CentOS because they need the stability and QA that Red Hat provides, but
> can't afford to pay for Red Hat. There's a debate there about business
> viability, but sometimes money is tight.
>
> I had wondered what was in it for Red Hat when they brought the CentOS
> team in-house but figured that it enabled CentOS users to buy support
> from RH when they needed it, which was money that RH otherwise wouldn't
> have seen.
>
> I see there's already significant backlash about this and many saying
> this may well be IBM's influence. Red Hat has always been an exemplary
> custodian of Open Source as far as I'm aware. They pay lots of people to
> work on things that need to be done but don't directly benefit their
> business, but this is really going to upset the apple cart for a lot of
> people.
>
> A key thing I noted from the Birmingham list is that as recently as 1st
> Dec, the CentOS website said CentOS 8 (released in Sept 2019) was
> supported until 31 May 2029, but now that date is 31 December 2021 when
> it becomes a rolling release sitting 'just ahead' of RHEL development.
> That means people have been installing version 8 for over a year
> believing they will get 10 years of security patches and the rug has
> been pulled out from under them. As Tim Williams points out, people make
> long term business decisions based on these things. If it had been
> announced ahead of release then people could make informed choices about
> installing it.
>
> As it happens, this doesn't affect me, or any of my customers to my
> knowledge but I wonder about all those appliance style products that use
> CentOS as a base. Nagios XI, another Nagios based system called OP5
> Monitor and other things like ClearOS all use CentOS as a base OS. There
> must be loads of others.
>
> I can't help thinking this will shaft existing CentOS 8 users and
> ultimately push many people to either Ubuntu, Debian or SUSE.
>
> > People looking for a new enterprise distro, should take a good look at
> > openSUSE Leap.  All the slow and stable benefits of old fangled
> > releases but for free.  Leap shares the kernel and core runtime
> > packages with it's enterprise counterpart SLES.  Infact the upcoming
> > iteration of Leap/Jump will be sharing these dependencies in a binary
> > identical way.
>
> Chris, for the benefit of discussion can you explain the relationship
> between SLES, openSUSE and what Leap and Jump are in terms of cost and
> release cycle?

There are a few facets.  SUSE uses openSUSE as the interface with upstreams
and as an upstream for SLES.  So changes are first committed to openSUSE, then
flow down.  The openSUSE packages are full open and anyone can fork and raise
requests against them via the open build service.  This development happens in
what is called Factory / category specific repos.

For Leap the kernel, core userspace packages are 100% shared.  As such Leap
follows all the validation, testing processes of SLES.  With Leap
following the life cycle
of SLES.  SLES has a service pack approach, which correlate with the minor Leap
releases.  IE: SLES 15 SP1 == Leap 15.1, SLES 15 SP2 == Leap 15.2,
etc.  In general
upgrades between service packs are pretty straightforward and easy.
These releases
are usually on an 18 month schedule with a 6 month support overlap
IIRC.  Leap then
has the ability to have newer versions of less core stuff and things
installed from other
repos.

Currently the openSUSE and SLES build systems are separate.  This is because
the SLES's build system is 100% offline, since all contributions are
audited.  This
means that currently SLES and Leap are separate builds of the same source.  Jump
(the next iteration of Leap) is going to be using binary identical
packages which have
been built by the SLES, then pushed to openSUSE.  The aim of this is to improve
security and process efficiencies.

>
> Ad

Chris

>
>
> --
> Wolves LUG mailing list
> Homepage: http://www.wolveslug.org.uk/
> Mailing list: Wolves at mailman.lug.org.uk
> Mailing list home: https://mailman.lug.org.uk/mailman/listinfo/wolves