4 ms·

I don't see anywhere that GP said an LTS patch would take effort. They said the upgrade path to the next LTS would. If you are talking about upgrade from LTS

I don't see anywhere that GP said an LTS patch would take effort. They said the upgrade path to the next LTS would. If you are talking about upgrade from LTS to LTS, can you give an example project where that is effortless? And if so, how do they manage to innovate and modernize without ever breaking backwards compatibility?

x86x87 3y ago
Here: "it's easier to go from 1.20.1 to 1.20.5 than to 1.21, because there's less chance of breakage and less things that will change, but the process is pretty much the same" LTS to LTS is another story. But the point is that L=LongTerm so in theory you're only going to do this exercise twice in a decade. > manage to innovate and modernize without ever breaking backwards yeah. fuck backwards compatibility. that is for suckers. how about stopping the madness for a second and thinking about what you are building when you build it?
- pixl97 3y ago
  > in theory you're only going to do this exercise twice in a decade. So I've seen things like this in corporations many times and it typically works like this... Well trained team sets up environment. Over time team members leave and only less senior members remain. They are capable of patching the system and keeping it running. Eventually the number of staff even capable of patching the system diminishes. System reaches end of life and vendor demands upgrading. System falls out of security compliance and everything around it is an organizational exception in one way or another. Eventually at massive cost from outside contractors the system gets upgraded and the cycle begins all over again. Not being able to upgrade these systems is about the lack of and loss of capable internal staff.
  - x86x87 3y ago
    What is the cost of keeping it "up to date" vs doing this exercise once every say 7 years? Are most software systems even around for 7 years?
    - p_l 3y ago
      I've recently worked in a high profile company where it took them long and painful to move from CentOS 6 to 7 (over a year long effort, IIRC, finished for prod in 2021? but with some crucial corp infra still on 6 in 2022). In 2022 they had to start a new huge effort do deal with migration off CentOS7, and the problems were so painful it was considered reasonable to build a Linux distro from scratch and remove all traces of distro dependency from the product (SaaS)
      - pas 3y ago
        that sounds really interesting, can you elaborate on the challenges? why was it so important for them to move off CentOS7, and why didn't they move to RHEL or Alma or Rocky or whatever similar?
        p_l 3y ago
        US Government woke up to the fact that allowing vendors waivers on requirements for upgrades ends up with nothing ever happening. CentOS7 is EOL'd next year. Additionally, there was fun of FIPS-140 and OpenSSL older than 3.0. Alma and Rocky were considered, but that would still involve (possibly similarly painful) migration as with CentOS 6 -> 7. Have you seen pricing for RHEL? We're talking hundreds thousands of systems. I never seen raw stats, but I would have been totally unsurprised to see them hit million instances across all clouds used, at least occassionally. Decoupling software from distro dependencies was seen as a way to future proof deployment story and avoid situations like we had with CentOS 7, where they really, really would have liked upgrading some stuff for newer APIs, but couldn't due to mess with OS-provided dependencies.
        pas 3y ago
        decoupling meant something like using "distroless" or static builds (musl?) or simply shipping everything on an alpine/ubuntu/debian/whatever image? (and previously there was no containerization, but now there is)
    - pixl97 3y ago

x86x87 3y ago

Here: "it's easier to go from 1.20.1 to 1.20.5 than to 1.21, because there's less chance of breakage and less things that will change, but the process is pretty much the same" LTS to LTS is another story. But the point is that L=LongTerm so in theory you're only going to do this exercise twice in a decade. > manage to innovate and modernize without ever breaking backwards yeah. fuck backwards compatibility. that is for suckers. how about stopping the madness for a second and thinking about what you are building when you build it?

pixl97 3y ago
> in theory you're only going to do this exercise twice in a decade. So I've seen things like this in corporations many times and it typically works like this... Well trained team sets up environment. Over time team members leave and only less senior members remain. They are capable of patching the system and keeping it running. Eventually the number of staff even capable of patching the system diminishes. System reaches end of life and vendor demands upgrading. System falls out of security compliance and everything around it is an organizational exception in one way or another. Eventually at massive cost from outside contractors the system gets upgraded and the cycle begins all over again. Not being able to upgrade these systems is about the lack of and loss of capable internal staff.
- x86x87 3y ago
  What is the cost of keeping it "up to date" vs doing this exercise once every say 7 years? Are most software systems even around for 7 years?
  - p_l 3y ago
    I've recently worked in a high profile company where it took them long and painful to move from CentOS 6 to 7 (over a year long effort, IIRC, finished for prod in 2021? but with some crucial corp infra still on 6 in 2022). In 2022 they had to start a new huge effort do deal with migration off CentOS7, and the problems were so painful it was considered reasonable to build a Linux distro from scratch and remove all traces of distro dependency from the product (SaaS)
    - pas 3y ago
      that sounds really interesting, can you elaborate on the challenges? why was it so important for them to move off CentOS7, and why didn't they move to RHEL or Alma or Rocky or whatever similar?
      - p_l 3y ago
        US Government woke up to the fact that allowing vendors waivers on requirements for upgrades ends up with nothing ever happening. CentOS7 is EOL'd next year. Additionally, there was fun of FIPS-140 and OpenSSL older than 3.0. Alma and Rocky were considered, but that would still involve (possibly similarly painful) migration as with CentOS 6 -> 7. Have you seen pricing for RHEL? We're talking hundreds thousands of systems. I never seen raw stats, but I would have been totally unsurprised to see them hit million instances across all clouds used, at least occassionally. Decoupling software from distro dependencies was seen as a way to future proof deployment story and avoid situations like we had with CentOS 7, where they really, really would have liked upgrading some stuff for newer APIs, but couldn't due to mess with OS-provided dependencies.
        pas 3y ago
        decoupling meant something like using "distroless" or static builds (musl?) or simply shipping everything on an alpine/ubuntu/debian/whatever image? (and previously there was no containerization, but now there is)
  - pixl97 3y ago