Comment by pavon | Hacker News Reader

Comment by pavon | Hacker News Reader

Parent Full thread

That is a good point, however I've not heard of too many cases where organizations intentionally skip RHEL releases. Systems that are being actively developed do regularly upgrade through each RHEL release, and the 10 year support just lets them be lazy about how quickly they do so. The only systems I see intentionally riding out the 10+ year support are deprecated systems that are already announced to sunset by the time RHEL support ends.

The five year reign of RHEL7 was too long and did result in the very issues you bring up, but the ~3 year duration of RHEL 5,6 & 8 was short enough to avoid problems due to attrition in enterprise settings (unlike startups which have higher turnover, and not counting bus factors of one - no release cycle can't solve that).

And like others have pointed out, automation doesn't help as much when moving between releases. We have everything configuration controlled with kickstart and ansible and/or docker, and it is great for reproducibility within a release cycle, but it doesn't save much time or knowledge between releases. And Ubuntu is even worse in that regard despite having a shorter release cycle.

It's one of the things that ground Yahoo to a halt. We spent years migrating from RHEL-4 to 6, then RHEL-6 to RHEL-7, and by the time the projects were pretty much complete, the next sunset was approaching. My cynicism comes from seeing the bad things that "Enterprise Linux" enabled there.

Admittedly, Yahoo was an extreme case. It never solved the really building problem - the culture from the early days was to compile, ship and forget. Once a RHEL-6 package was pushed to our dist/yinst system (packages), it would never be rebuilt unless it was 1) necessary, or 2) It was time to try and figure out how to build it on RHEL-7.

A lot of effort was spent in the later years to try and address this (by burning the old tech stack to the ground), but the culture was pervasive for the longest time. If 10-year-RHEL didn't exist we would have been forced to address the building processes.

If it's hard or error prone, then do it frequently until you get the process nailed down.

If it's hard or error prone, then do it frequently until you get the process nailed down.

Major life lesson -- practice makes perfect.

Practice makes something permanent. Wether that is perpetual perfection or perpetual mediocrity depends on the person.

The average person could practice violin for 500 years and never be invited to play Carnegie Hall.

If the average person were in an exceptionally good environment, they would likely get (much) better over time.

Oh my sweet summer child. There are plenty of enterprises still on RHEL 6, paying extra to keep patches coming. I bet there are still some on RHEL 5. Large, global companies. And of course there are many environments where software and hardware stay frozen for years. Telecoms, factory floors, automotive, finance, disconnected edge devices of all types... they test the absolute crap out of those systems, and pay for every certification availabl, and then leave them running for a decade.

The ability to stay abreast of major version updates is a wonderful attribute of many environments, but definitely far from all.

In 2017 I led a (painful) project to migrate from RHEL5 to Ubuntu 16. Since then, it has been pretty easy to go to 18 then 20, soon 22. The previous migration was in 2010 and was from RedHat 6 (not RHEL) to RHEL5. These projects were for projects that are "ghost deprecated" in that not much time is spent in talking about them but they are critically important to the business, as profit centers and cost drivers, but not the new flashy stuff. So we saved $10s of millions of dollars in hardware savings mostly due to the improved schedulers in 4.0.x series of kernels compared to 2.6.28 kernel. The same image became the basis of the containerized version that was rolled out a bit later.

22 might be difficult depending on what you use from Ubuntu 's repositories; they are converting apt apps to snaps.

>That is a good point, however I've not heard of too many cases where organizations intentionally skip RHEL releases. Systems that are being actively developed do regularly upgrade through each RHEL release, and the 10 year support just lets them be lazy about how quickly they do so.

Industry specific - but finance world, we still had straggling RHEL5 machines up until a year or two ago and still have a bunch of RHEL6 machines and have basically NO RHEL9. The vast majority of the machines are all sitting on RHEL7/8.

I feel somewhat called out. By time we finished migrating from centos6 to centos8, centos8 was being shot in the face. Talk about "fun times".

>I've not heard of too many cases where organizations intentionally skip RHEL releases.

I assume you mean major releases. Less common than minor releases but, especially for air-gapped equipment, it's not that unusual.

Reply on news.ycombinator.com