CentOS - Jun 2020 - Blog article about the state of CentOS

On 17/06/2020 20:06, Noam Bernstein via CentOS wrote:
>> On Jun 17, 2020, at 3:02 PM, Phil Perry <pperry at elrepo.org>
wrote:
>>
>> Nothing has changed in this regard for as long as I've been a
CentOS user or been involved in the CentOS community.
> 
> This is the essence of the question, to me.  I agree that _in_principle_
nothing has changed, and I don't even see any disagreement with that in the
list.  However, there is a separate question, and that is whether _in_practice_
the lag between RHEL and CentOS updates has increased with CentOS 8.  I
don't know what the answer is, because I'm not paying attention since
I'm far from adopting CentOS 8, but it's a legitimate (and in fact
empirical) question.
> 
I get what you are saying, but what difference does it make if it has? 
What does it matter if the lag is 1 week, or 1 month, or more? The only 
reason it will matter to you is if you are trying to do something with 
CentOS that is time critical - e.g, publicly facing server that needs 
security updates, using CentOS on test servers to validate production 
releases for RHEL, etc. At which point you probably should be using RHEL 
if it is important to you, not CentOS, and it was a mistake to deploy 
CentOS in those roles in the first place.

People need to hold their hands up and say, I took a gamble that CentOS 
would get updates out quick and I wouldn't get hacked in a week, and now 
updates are taking a lot longer my gamble is no longer paying off and I 
need to get myself a RHEL subscription or switch to Ubuntu or whatever 
other flavor you like the taste of. Coming here and complaining when 
(you) made a bet and lost doesn't achieve anything.

On my home file server for example, which is not connected to the 
internet, what does it matter if the release is 1 month or 3 months out 
of date? I can install the server in the knowledge it's going to work, 
and be supported with updates for 10 years and I can largely forget 
about it. My el5 box ran for more than 10 years until the hardware 
eventually died.

> On Jun 17, 2020, at 3:32 PM, Phil Perry <pperry at elrepo.org> wrote:
> 
> I get what you are saying, but what difference does it make if it has? What
does it matter if the lag is 1 week, or 1 month, or more? The only reason it
will matter to you is if you are trying to do something with CentOS that is time
critical - e.g, publicly facing server that needs security updates, using CentOS
on test servers to validate production releases for RHEL, etc. At which point
you probably should be using RHEL if it is important to you, not CentOS, and it
was a mistake to deploy CentOS in those roles in the first place.
And yet in practice many of us have found CentOS to be perfectly adequate for
such applications in the past, up to and including CentOS 7.  If this is no
longer true for CentOS 8, for whatever reason, it's useful to know.  I'm
not saying RHEL doesn't have its place - just that perhaps the boundary in
the range of applicability between it and CentOS has therefore also changed.

								Noam

Am 17.06.20 um 21:37 schrieb Noam Bernstein via CentOS:
>> On Jun 17, 2020, at 3:32 PM, Phil Perry <pperry at elrepo.org>
wrote:
>>
>> I get what you are saying, but what difference does it make if it has?
What does it matter if the lag is 1 week, or 1 month, or more? The only reason
it will matter to you is if you are trying to do something with CentOS that is
time critical - e.g, publicly facing server that needs security updates, using
CentOS on test servers to validate production releases for RHEL, etc. At which
point you probably should be using RHEL if it is important to you, not CentOS,
and it was a mistake to deploy CentOS in those roles in the first place.
> 
> And yet in practice many of us have found CentOS to be perfectly adequate
for such applications in the past, up to and including CentOS 7.  If this is no
longer true for CentOS 8, for whatever reason, it's useful to know.  I'm
not saying RHEL doesn't have its place - just that perhaps the boundary in
the range of applicability between it and CentOS has therefore also changed.
> 

The answer is not inherently in the distribution itself. Make your
analysis about your needs an requirements and the choice is then yours.

One could argue that the gap between disclosure of one security issues
and the update via RHEL subscription is to big. Then a contract with
the upstream developer of the corresponding software component is a
better choice then relying in RHEL, right?

--
Leon

On 6/17/20 3:32 PM, Phil Perry wrote:
>
> On my home file server for example, which is not connected to the 
> internet, what does it matter if the release is 1 month or 3 months 
> out of date? I can install the server in the knowledge it's going to 
> work, and be supported with updates for 10 years and I can largely 
> forget about it. My el5 box ran for more than 10 years until the 
> hardware eventually died. 
EL5... how modern...? from a production application server VM, not 
internet-connected:
[root at c6-2850 ~]# ssh root at 10.1.x.y
root at 10.1.x.y's password:
Last login: Tue Jan 28 19:53:32 2020
unknown terminal "xterm-256color"
unknown terminal "xterm-256color"
[root at localhost root]# cat /etc/centos-release
CentOS Linux Advanced Server release 2.1AS (Slurm)
[root at localhost root]#

This one has to be hard reset every day or two (virsh reset rhel2.1) 
since the bridge to the guest just dies randomly, and a reboot inside 
the guest hangs hard before finishing the reboot.? The hard reset has to 
manually load the ethernet kernel module after it's booted up so far; if 
the ethernet module loads too soon it will never connect.... haven't 
found the reason for that, either, just run a pinging script every 
fifteen minutes on the host to check for connectivity and 'virsh reset 
rhel2.1' when it fails.? The appserver is hard reboot resilient, and the 
software does a very specific task, and there's no budget for a 
rewrite.? At least I did upgrade it from Red Hat Linux 5.2 a couple of 
years ago (the RHL5.2 box, an old AMD K6/2-450 with 128MB of RAM, ran 
almost continuously for 20 years).

Thanks, CentOS!

On 17/06/2020 21:05, Lamar Owen wrote:
> On 6/17/20 3:32 PM, Phil Perry wrote:
>>
>> On my home file server for example, which is not connected to the 
>> internet, what does it matter if the release is 1 month or 3 months 
>> out of date? I can install the server in the knowledge it's going
to
>> work, and be supported with updates for 10 years and I can largely 
>> forget about it. My el5 box ran for more than 10 years until the 
>> hardware eventually died. 
> EL5... how modern...? from a production application server VM, not 
> internet-connected:
> [root at c6-2850 ~]# ssh root at 10.1.x.y
> root at 10.1.x.y's password:
> Last login: Tue Jan 28 19:53:32 2020
> unknown terminal "xterm-256color"
> unknown terminal "xterm-256color"
> [root at localhost root]# cat /etc/centos-release
> CentOS Linux Advanced Server release 2.1AS (Slurm)
> [root at localhost root]#
> 
> This one has to be hard reset every day or two (virsh reset rhel2.1) 
> since the bridge to the guest just dies randomly, and a reboot inside 
> the guest hangs hard before finishing the reboot.? The hard reset has to 
> manually load the ethernet kernel module after it's booted up so far;
if
> the ethernet module loads too soon it will never connect.... haven't 
> found the reason for that, either, just run a pinging script every 
> fifteen minutes on the host to check for connectivity and 'virsh reset 
> rhel2.1' when it fails.? The appserver is hard reboot resilient, and
the
> software does a very specific task, and there's no budget for a 
> rewrite.? At least I did upgrade it from Red Hat Linux 5.2 a couple of 
> years ago (the RHL5.2 box, an old AMD K6/2-450 with 128MB of RAM, ran 
> almost continuously for 20 years).
> 
> Thanks, CentOS!
> 
Indeed!

You have clearly had more success with the longevity of your hardware 
than me. I was plagued with expanding capacitors about 15 years ago 
which killed off most of my hardware at the time, and the replacements 
were taken out of service as they subsequently died meaning I'm 
exclusively running el7|8 now :-)