It’s interesting to note that a Linux kernel LTS releases get only one more year of support than FreeBSD release series (which have KBI guarantees and get both security and feature back ports). A kernel module built for FreeBSD 12.0 in December 2018 is expected to work with the whole 12.x release series, which is supported until the end of this year.
If you’re building an appliance and want long-term support for kernel stability, maybe Linux isn’t the right choice?
The free LTS model is on its way out. The S part just costs too much human effort and is relatively unrewarding if you don’t personally need it. As people move to declarative environments instead of ad hoc installations, this will result in fewer people capable of providing the support needing it for their own projects. Thus, LTS will shrink.
And for those windows XP servers that are running CNC mills and elevators… let’s not kid ourselves. They only got service pack 3 on them if service pack 3 was out at time of installation. Effort into long term support was wasted as these boxes were installed and then never patched again.
That’s fine if you don’t have any custom kernel modules or patches. Linux is pretty good at keeping ABI stability but explicitly reserves the right to break the KBI routinely. If you are building any kind of appliance, you need to either upstream all of your patches (and then they might still be broken, but at least they’ll be kept in a state where they compile) or stick to an LTS release.
The free LTS model is on its way out. The S part just costs too much human effort and is relatively unrewarding if you don’t personally need it. As people move to declarative environments instead of ad hoc installations, this will result in fewer people capable of providing the support needing it for their own projects. Thus, LTS will shrink.
I suspect the people who need an LTS are already getting it from the downstreams they’re paying (i.e. RH, SUSE, etc.). They already have their own patchsets.
And for those windows XP servers that are running CNC mills and elevators… let’s not kid ourselves. They only got service pack 3 on them if service pack 3 was out at time of installation. Effort into long term support was wasted as these boxes were installed and then never patched again.
Right, I almost never see embedded devices get a kernel patch, let alone an update. For airgapped i.e. CNC machines, why would they ever? For IoT devices exposed to a network, perhaps there’s some social and technical reasons why they don’t get updated that should be addressed.
Fortunately the “this runs a huge system which has to be supported” companies are also (usually) companies which can hire their own support people or pay for the supported edition which will inevitably be created by someone. Sure, there are exceptions, but not that many.
I wonder though how will that mesh with the EU rules about extended support for updates from the personal electronics producers.
It’s interesting to note that a Linux kernel LTS releases get only one more year of support than FreeBSD release series (which have KBI guarantees and get both security and feature back ports). A kernel module built for FreeBSD 12.0 in December 2018 is expected to work with the whole 12.x release series, which is supported until the end of this year.
If you’re building an appliance and want long-term support for kernel stability, maybe Linux isn’t the right choice?
Related
https://lobste.rs/s/lzoj54/on_future_free_long_term_support_for_linux https://lobste.rs/s/z1ninh/lts_15_years_not_5
The free LTS model is on its way out. The S part just costs too much human effort and is relatively unrewarding if you don’t personally need it. As people move to declarative environments instead of ad hoc installations, this will result in fewer people capable of providing the support needing it for their own projects. Thus, LTS will shrink.
Basically as https://lobste.rs/s/i7zzyo/immutable_reprovisionable_anti and https://mullvad.net/en/blog/2023/9/20/we-have-successfully-completed-our-migration-to-ram-only-vpn-infrastructure/ (lobsters story removed for this one) become more mainstream, the need for LTS will be reduced. If you can inexpensively upgrade, on your own schedule, why keep servers around for a few years between rebuilds?
And for those windows XP servers that are running CNC mills and elevators… let’s not kid ourselves. They only got service pack 3 on them if service pack 3 was out at time of installation. Effort into long term support was wasted as these boxes were installed and then never patched again.
That’s fine if you don’t have any custom kernel modules or patches. Linux is pretty good at keeping ABI stability but explicitly reserves the right to break the KBI routinely. If you are building any kind of appliance, you need to either upstream all of your patches (and then they might still be broken, but at least they’ll be kept in a state where they compile) or stick to an LTS release.
I suspect the people who need an LTS are already getting it from the downstreams they’re paying (i.e. RH, SUSE, etc.). They already have their own patchsets.
Right, I almost never see embedded devices get a kernel patch, let alone an update. For airgapped i.e. CNC machines, why would they ever? For IoT devices exposed to a network, perhaps there’s some social and technical reasons why they don’t get updated that should be addressed.
Fortunately the “this runs a huge system which has to be supported” companies are also (usually) companies which can hire their own support people or pay for the supported edition which will inevitably be created by someone. Sure, there are exceptions, but not that many.
I wonder though how will that mesh with the EU rules about extended support for updates from the personal electronics producers.