• taladar@sh.itjust.works
    link
    fedilink
    arrow-up
    28
    arrow-down
    8
    ·
    4 months ago

    Personally I think it would be of great benefit if Enterprise vendors just stopped doing that extremely long term support. It just enables the people who want to pretend they can stop the world around them and those people are bad for everyone, especially in a security context but also because they pretend that “stability” is achieved by using old versions.

    • caseyweederman@lemmy.ca
      link
      fedilink
      arrow-up
      9
      ·
      4 months ago

      I hope that the community at large can wrestle kernel livepatching away from the commercial distros. No reason the big names should have a monopoly on that.

      Even where those are concerned, it’s not a silver bullet for seamlessly jumping major kernel versions, but it’s a start.

      • fruitycoder@sh.itjust.works
        link
        fedilink
        arrow-up
        3
        ·
        4 months ago

        I think Arch has FOSS support kernel live patching Nixos also has an open issue where they seem to be discussing an implementation they might consider.

        With upstream support and kpatch being FOSS I think the willingness is just low to maintain patches at a distro level and announcing it as a thing you can do yourself has limited audience.

        I agree its super cool though and with containers and some of systems work for system level reboots and portable services I see a lot of potential for high uptime systems (like my laptop lol).

    • corsicanguppy@lemmy.ca
      link
      fedilink
      arrow-up
      10
      arrow-down
      3
      ·
      4 months ago

      Personally I think it would be of great benefit if Enterprise vendors just stopped doing that extremely long term support. It just enables the people who want to pretend they can stop the world around them and those people are bad for everyone, especially in a security context but also because they pretend that “stability” is achieved by using old versions.

      This is how I know you need to learn more about the Enterprise, about long-term support, and stability. Everything you wrote sounds like “Smoke detectors and seat belts are for chumps”

      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        6
        arrow-down
        1
        ·
        4 months ago

        I know a lot more about those topics than I ever wished I would.

        Stability doesn’t magically appear because you leave the version number unchanged. Stability is the result of qualified people (hint: people backporting patches in 100s of projects they barely know aren’t very qualified in comparison to the main developers of those projects) making well-informed changes to a project and then testing them.

        Old versions with backports are still new versions, just new versions with a smaller user base and less testing.

        Stability is also much harder to achieve if you do certain tasks rarely, e.g. only every 10 years, since nobody will remember how to do them.

        Upstream supports those old releases only begrudgingly because every feature that needs support across all versions in use is held back by those extremely long term support versions.

        I am not objecting to the goal of stability, I am objecting to the snakeoil that pretends you can achieve it by using the same version number all the time basically with a forked branch of the code that contains cherry-picked changes.

    • fruitycoder@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      Agreed at a certain point supporting an old enough ABI is just a practice in preservation and shouldn’t be where any serious work is done on.

      There are still companies that treat software development as if they craving stone for future generations instead of living collections of logic, idioms, and ideas (that reasonbly should be expected to adapted or replaced as conditions change!)

  • caseyweederman@lemmy.ca
    link
    fedilink
    arrow-up
    11
    ·
    4 months ago

    I do like the point about encouraging the major distros to combine their efforts on kernel versions. Everyone would benefit from that (which is why they don’t do it, not when they’re making money off of extended LTS services)

  • AutoTL;DR@lemmings.worldB
    link
    fedilink
    English
    arrow-up
    9
    ·
    4 months ago

    This is the best summary I could come up with:


    This support extension is good news for anyone still running older kernels in production, but also, in context, slightly puzzling.

    OpenELA came together in August 2023 as a cooperation between Oracle, SUSE, and Rocky Linux backers CIQ.

    The thing is, though, that kernel 4.14 is not used by any of the obvious candidate distros from Red Hat or RHEL derivatives.

    After OpenELA contacted us to tell us about the announcement, we asked why this particular version, and if there was any connection with AWS or Amazon Linux 2, but although we gave them a few working days, at the time of writing we have had not heard from them.

    Currently, each of the the bigger distro vendors maintain their own kernel versions, and they all work separately.

    Our feeling is that it would be beneficial for the greater Linux world if more of the enterprise vendors could agree to work together on the LTS kernels, for instance by ensuring that long-term supported distros used the upstream long-term supported kernel versions.


    The original article contains 616 words, the summary contains 169 words. Saved 73%. I’m a bot and I’m open source!