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 :-)