4 ms·

You CAN upgrade RHEL (or CentOS Stream, or Alma, or Ubuntu) every 3 years if you want. Some people do it. Nobody forces you to live out the entire lifecycle o

You CAN upgrade RHEL (or CentOS Stream, or Alma, or Ubuntu) every 3 years if you want. Some people do it. Nobody forces you to live out the entire lifecycle on one release. Some people appreciate having the option to pick and choose when the transition happens though.

stouset 2y ago
Funny, because we’ve been on RHEL. After one round of calcification, upgrading our datacenters for each future RHEL release took years of concerted efforts. We actually lost ground every year.
- hedora 2y ago
  I've supported others that use RHEL. If you like software archeology, it's the OS for you: > This bug was fixed in 2002, then regressed in 2005 and fixed again in 2007 in mainline, but in RHEL, they botched the '02 and '05 back port, so '02 breaks it, but '05 doesn't. Now, let me tell you about secondary effects of patches in unrelated subsystems. We have three interesting "type A" examples introduced in ... > ... and that's why it's completely acceptable to run half the fortune 500 off of Linux 2.6.19-RHEL.... in 2025. > What, you're running 2.6.20? What a hoot!!! We like to kid. You're not serious? You are? You work at the local nuclear plant? > backs out of conference room slowly, then bolts down the hallway screaming "run for your lives!" once they have clear view of the elevator
  - dralley 2y ago
    > What, you're running 2.6.20? What a hoot!!! We like to kid. You're not serious? You are? You work at the local nuclear plant? The local nuclear power plant is hopefully not connected to the internet. It shouldn't be surprising that such systems run old software.
    - hedora 2y ago
      Not all mission critical bugs are security holes.
      - dralley 2y ago
        Is a system that has been working fine for 10 years more, or less likely to have a mission critical bug than a system rebuilt on 4 month old code? HN tends to think a lot about what's good for what's good practice for hyperscalers with massive profit margins and capital expenditures, and not as much about what's good for industries where margins are thin and downtimes have massive real-world consequences. What kind of software architecture do you suggest for, say, the embedded OS on a bus-sized, $200 million ASML EUV lithography tool? Do you really think it's a great idea to pull every update without recertification to the control systems of that nuclear power plant, or the system that renders MRIs at the radiologist? I'm not saying let them rot for decades, but caution is prudent sometimes.
        stouset 2y ago
        FWIW I 100% concede that there are uses for LTS systems. For things where active development means releasing a new product that customers replace their old one with, go for it. For systems not under active development like a nuclear plant control system, go for it. I don’t think those audiences make up a significant mass of HN readership, so my comments aren’t targeted at them. For your SaaS company with 20 services and growing? You will have less pain from constantly upgrading than you will from adopting LTS releases.
deleted 2y ago
[deleted]

stouset 2y ago

Funny, because we’ve been on RHEL. After one round of calcification, upgrading our datacenters for each future RHEL release took years of concerted efforts. We actually lost ground every year.

hedora 2y ago
I've supported others that use RHEL. If you like software archeology, it's the OS for you: > This bug was fixed in 2002, then regressed in 2005 and fixed again in 2007 in mainline, but in RHEL, they botched the '02 and '05 back port, so '02 breaks it, but '05 doesn't. Now, let me tell you about secondary effects of patches in unrelated subsystems. We have three interesting "type A" examples introduced in ... > ... and that's why it's completely acceptable to run half the fortune 500 off of Linux 2.6.19-RHEL.... in 2025. > What, you're running 2.6.20? What a hoot!!! We like to kid. You're not serious? You are? You work at the local nuclear plant? > backs out of conference room slowly, then bolts down the hallway screaming "run for your lives!" once they have clear view of the elevator
- dralley 2y ago
  > What, you're running 2.6.20? What a hoot!!! We like to kid. You're not serious? You are? You work at the local nuclear plant? The local nuclear power plant is hopefully not connected to the internet. It shouldn't be surprising that such systems run old software.
  - hedora 2y ago
    Not all mission critical bugs are security holes.
    - dralley 2y ago
      Is a system that has been working fine for 10 years more, or less likely to have a mission critical bug than a system rebuilt on 4 month old code? HN tends to think a lot about what's good for what's good practice for hyperscalers with massive profit margins and capital expenditures, and not as much about what's good for industries where margins are thin and downtimes have massive real-world consequences. What kind of software architecture do you suggest for, say, the embedded OS on a bus-sized, $200 million ASML EUV lithography tool? Do you really think it's a great idea to pull every update without recertification to the control systems of that nuclear power plant, or the system that renders MRIs at the radiologist? I'm not saying let them rot for decades, but caution is prudent sometimes.
      - stouset 2y ago
        FWIW I 100% concede that there are uses for LTS systems. For things where active development means releasing a new product that customers replace their old one with, go for it. For systems not under active development like a nuclear plant control system, go for it. I don’t think those audiences make up a significant mass of HN readership, so my comments aren’t targeted at them. For your SaaS company with 20 services and growing? You will have less pain from constantly upgrading than you will from adopting LTS releases.

deleted 2y ago

[deleted]