The whole issue of "support longevity" raises an issue I've been pondering, is 10-year support a good thing from a security perspective? At work we use Ubuntu LTS which has only a five year support cycle (you can pay for an extra five years) but, even with that, issues have arisen. Although they do security and bug fix updates, the package versions remain basically the same. So, if a package is on version 1.2.3, it remains 1.2.3 with bug fixes and security patches for the life of the distribution. Does Red Hat/CentOS do the same thing?
The reason I ask is I ran into an issue where OpenVPN was updated in a later release to support a more robust security architecture which wasn't available until I upgraded. A configuration change could have addressed a security weakness in the older version so that the issue wasn't one of a security patch. However, the change required a lot of effort to implement.
Now I'm wondering about packages in general.
________________________________
From: CentOS <centos-bounces@xxxxxxxxxx> on behalf of Lamar Owen <lowen@xxxxxxxx>
Sent: Monday, December 14, 2020 10:57 AM
To: CentOS mailing list <centos@xxxxxxxxxx>
Subject: [EXTERNAL] Re: CentOS 8 future
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Harriscomputer
Leroy Tennison
Network Information/Cyber Security Specialist
E: leroy@xxxxxxxxxxxxxxxx
P:
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com<http://www..com>
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.
If you prefer not to be contacted by Harris Operating Group please notify us<http://subscribe.harriscomputer.com/>.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote:
> My only concern ATM is whether RH can change its CentOS 7 maintenance
> plans as well, all of a sudden.
This is what bothers me, too, but in a slightly different way. Even for
the GPL software, Red Hat actually doesn't have to provide public access
to the source code; the only thing required by GPL is that those who
receive binaries must be able to get sources. So, even though it has
been said that the source will be available, well, it was also said that
C8 would be supported to 2029. There are enough packages in RHEL with
non-GPL licenses where it would be very difficult to rebuild the whole
distribution without them, and RH is not required by those licenses
(MIT, BSD, and others) to redistribute those modified sources even to
people who have been distributed binaries. So, while I want to believe
that the sources will remain available, that belief relies on trust,
which unfortunately is less abundant these days.
So while using another rebuild seems to be a good stopgap solution, I do
wonder if it will prove to be sustainable post-2021. I'm personally
looking at which of the four (that we know about) to possibly go to; I
just really doubt I am going to use Oracle; Rocky isn't really there yet
and is very young; Springdale is available, mature, and academically
supported (nothing wrong with that, just a statement); CloudLinux OS
Project Lenix isn't yet released. Out of the bunch, Springdale would be
my first choice right now because it's been around a very long time and
is available now. C8 is supposed to be around until end of 2021, so
there is some time for the dust to settle and the way to become more
clear, though. But CentOS 8 Stream is only an option for me if the
hardware driver KABI synchronization issue is solved and stays solved.
RHEL? Under the current subscription models we just can't afford it.
(Cost also keeps SLES out of the running.)
But I'm now seriously considering just simply going to something that is
both older than Red Hat, fully and totally open, extremely
well-supported by a diverse developer community, and used by a whole lot
of people. Yes, that's Debian; until I realized where the name came
from (Deb and Ian) it read to me like a play on 'deviant.' The 'stable'
period is shorter, for sure. The tradeoffs are pretty simple:
guaranteed openness versus less change for ten years.
So, let's look at that last piece. CentOS 6's support just ended; what
have the last nine years and three months of actual C6 support looked
like? I supported several C6 machines, and there were distinct
challenges early on, at least for the first four years or so. Since
then, on the server, it's been very stable, but really old; key pieces
of infrastructure software we use slowly became unusable on C6 due to
the old versions of specific packages, and either a third-party repo
with newer packages or a newer CentOS was needed.
Third-party repos have improved over the years, but some of the earlier
C6 machines I installed had packages from Linuxtech, Dag, ATrpms,
City-Fan (one particular DVD burner that just had to have the non-wodim
cdrtools for some reason; yes, I know all the warnings about that repo),
and others. Having EPEL and Dag both package a few things that I
needed, but package them differently, introduced me to package pinning
and repo priorities.... I don't miss those days. Seriously stable in
the core repos means very little when you need much less stable
third-party repos to get actual work done. That's also why Fedora isn't
really an option, just too much package churn; been there, done that, a
few years ago.
So I've started re-evaluating just why I use CentOS anyway; the answer
really boils down to the fact that I started out with Red Hat Linux in
1997 (I live in North Carolina, and I've always liked supporting local
companies) and I just really don't want to change; it feels like I've
wasted so much effort if I change now (that was the reason I stuck with
it through the Fedora-RHEL split years ago, too, and went with a RHEL
rebuild, first WBEL then CentOS). But the reality is not nearly so
stark; a vast majority of the information and skills I've picked up in
these years are portable to other distributions; so it's not wasted
effort. Well, other than RPM packaging skills; those are a bit less
portable. Whenever I've built from source I've tried to either build my
own RPM for it or rebuild the Fedora RPM for it, and so I have a local
repo of those packages, making reinstall much easier. So it becomes a
tossup: small change to another rebuild now, possibility of major change
later, or bite the bullet and go ahead and get the major change over
with and only have small changes later.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
