5 ms·

6 years seems like an incredibly long time to me. It's a bit of a shame, but looks like industry really didn't come out to support the idea. 2 years on the oth

6 years seems like an incredibly long time to me. It's a bit of a shame, but looks like industry really didn't come out to support the idea. 2 years on the other hand seems incredibly short? Am I wrong?

LinuxBender 3y ago
That's 2 years of the upstream LTS kernel. I would expect that major Linux distributions such as Redhat RHEL and Canonical's Ubuntu would continue to do their extended patch cycles against one of the upstream snapshots as they have done in the past. I think 2 years for upstream LTS is probably fine if the vendor patching methodology remains true. This also assumes that the usage of smaller distributions such as Alpine are more commonly used in very agile environments such as K8's, Docker Swarm, etc... Perhaps that is a big assumption on my part.
inferiorhuman 3y ago
6 years may seem like a long time, but check out what the competition is doing. Oracle is supporting Solaris 10 for 20 years, 11.4 for 16 years (23 years if you lump it in with 11.0). HP-UX 11i versions seem to get around 15 years of support. It really depends on what you're doing, a lot of industries may not need such long-term support. 6 years seems like a happy medium to me, but then again I'm not the one supporting it. I expect the kernel devs would be singing a different tune if people were willing to pay for that extended support. https://upload.wikimedia.org/wikipedia/en/timeline/276jjn0uo65zngws02n9iabdtnhic97.png https://upload.wikimedia.org/wikipedia/en/timeline/276jjn0uo...
- wkat4242 3y ago
  Are those really competition anymore? They're just legacy now IMO and their long term support requirements are a result of this, companies that haven't gotten rid of them by now aren't likely to do it any time soon. I hate seeing them go. I wasn't such a fan of Solaris but I was of HP-UX. But its days are over. It doesn't even run on x86 or x64 and HP has been paying Intel huge money to keep itanium on life support, which is running out now if it hasn't already. At least Solaris had an Intel port but it too is very rare now.
  - kube-system 3y ago
    Theres a lot of people who haven't got rid of old Linux systems these days too. RHEL 6 from 2010 is still eligible for extended support.
    - structural 3y ago
      There's still a decent population of RHEL 5 systems in the wild. Last year I was offered an engagement (turned down for a few reasons) to help a company upgrade several hundred systems from RHEL 5 to RHEL 6 and start planning for a future rollout of RHEL 7. Outside of tech focused companies, 10+ year old systems really are the norm.
      - SoftTalker 3y ago
        > Outside of tech focused companies, 10+ year old systems really are the norm. It's because outside of tech companies, nobody cares about new features. They care about things continuing to work. Companies don't buy software for the fun of exploring new versions, especially frustratingly pointless cosmetic changes that keep hitting their training budgets. Many companies would be happy with RHEL5 or Windows XP today from a feature standpoint, if it weren't a security vulnerability.
        wkat4242 3y ago
        The problem about "things continuing to work" is really that many security fixes require updated architecture too. This is really why it's so hard to do LTS. It's not only about wanting new features.
      - worthless-trash 3y ago
        What feature did they need in el7 that wasn't there in el9 ? What was their logic ?
      - inferiorhuman 3y ago
        At megacorp (years ago) we were transitioning to CentOS 7 (from 6) and just starting to wind down our 32-bit windows stuff in AWS. I'm sure there are plenty of legacy Linux systems out there, but I wonder how many folks are actually paying for them. CentOS/RHEL 6 was already pretty long in the tooth, but being the contrarian I am, I was not looking forward to the impending systemd nonsense.
kube-system 3y ago
Depends on where the computer is at, I guess. On a desk, 6 years is a pretty long time. In an industrial setting, 6 years is not very long of a lifecycle.
- dathinab 3y ago
  consider that it's 6 years after release of the kernel version so likely <5 years since release of the hardware in the US likely <4 years since release of hardware outside of the US likely <3 years since you bought the hardware and if you buy older phones having only a year or so of proper security updates is not that unlikely So for phones you would need more something like a 8 or 10 year LTS, or well, proper driver updates for proprietary hardware. In which case 2 years can be just fine because in general/normally only drivers are affected by kernel updates.
Gigachad 3y ago
What kind of breaking change would take longer than 2 years to deal with? The reality is that people wait out the entire 6 year period and then do the required months work at the end. If you make the support period 2 years they will just start working on it sooner.
- Retric 3y ago
  Many perhaps most projects don’t last 6 years, thus punting can save people a great deal of time.
dathinab 3y ago
6 years is way to short for some use-cases, like phones sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions. so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support then between starting to build a phone and releasing it 2 years might easily pass so that means from release you can provide _at most_ 4 years of kernel security patches etc. but dates tend to not align that grate so maybe it's just 3 years but then you sell your phone for more then one year, right? in which case less then 2 years can be between the customer buying your product and you no longer providing kernel updates that is a huge issue I mean think about it if someone is a bit thigh on money and buy a slightly older phone they probably aren't aware that their phone stops getting security updates in a year or so (3 years software support since release but it's a 2 year old phone) at which point using it is a liability. EDIT: The answer is in my opinion not to have even longer LTS but to proper maintain drivers and in turn being able to do full kernel updates
- xvilka 3y ago
  > sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions. These manufacturers should be punished by the lack of LTS and need to upgrade precisely because of that lazyness and incompetence.
  - charcircuit 3y ago
    Why not blame the kernel developers for being lazy and incompetent for not offering a stable API for driver developers to use? You don't see Windows driver developers having their drivers broken by updates every few months.
    - mschuster91 3y ago
      > You don't see Windows driver developers having their drivers broken by updates every few months. At the cost of Windows kernel development being a huge PITA because effectively everything in the driver development kit becomes an ossified API that can't ever change, no matter if there are bugs or there are more efficient ways to get something done. The Linux kernel developers can do whatever they want to get the best (most performant, most energy saving, ...) system because they don't need to worry about breaking someone else's proprietary code. Device manufacturers can always do the right thing and provide well-written modules to upstream - but many don't because (rightfully) the Linux kernel team demands good code quality which is expensive AF. Just look at the state of most non-Pixel/Samsung code dumps, if you're dedicated enough you'll find tons of vulnerabilities and code smell.
Ekaros 3y ago
All comes to cycle. When do you enter that 6 year LTS? Is there new LTS every year or every other year? If you enter 2 years in or even 4 years in. How much have you support left? Do you jump LTS releases. So one you are on is ending and there is brand new available? Or do you go to one before and have possibly only 2 or 4 years left...

LinuxBender 3y ago

That's 2 years of the upstream LTS kernel. I would expect that major Linux distributions such as Redhat RHEL and Canonical's Ubuntu would continue to do their extended patch cycles against one of the upstream snapshots as they have done in the past. I think 2 years for upstream LTS is probably fine if the vendor patching methodology remains true. This also assumes that the usage of smaller distributions such as Alpine are more commonly used in very agile environments such as K8's, Docker Swarm, etc... Perhaps that is a big assumption on my part.

inferiorhuman 3y ago

6 years may seem like a long time, but check out what the competition is doing. Oracle is supporting Solaris 10 for 20 years, 11.4 for 16 years (23 years if you lump it in with 11.0). HP-UX 11i versions seem to get around 15 years of support. It really depends on what you're doing, a lot of industries may not need such long-term support. 6 years seems like a happy medium to me, but then again I'm not the one supporting it. I expect the kernel devs would be singing a different tune if people were willing to pay for that extended support. https://upload.wikimedia.org/wikipedia/en/timeline/276jjn0uo65zngws02n9iabdtnhic97.png https://upload.wikimedia.org/wikipedia/en/timeline/276jjn0uo...

wkat4242 3y ago
Are those really competition anymore? They're just legacy now IMO and their long term support requirements are a result of this, companies that haven't gotten rid of them by now aren't likely to do it any time soon. I hate seeing them go. I wasn't such a fan of Solaris but I was of HP-UX. But its days are over. It doesn't even run on x86 or x64 and HP has been paying Intel huge money to keep itanium on life support, which is running out now if it hasn't already. At least Solaris had an Intel port but it too is very rare now.
- kube-system 3y ago
  Theres a lot of people who haven't got rid of old Linux systems these days too. RHEL 6 from 2010 is still eligible for extended support.
  - structural 3y ago
    There's still a decent population of RHEL 5 systems in the wild. Last year I was offered an engagement (turned down for a few reasons) to help a company upgrade several hundred systems from RHEL 5 to RHEL 6 and start planning for a future rollout of RHEL 7. Outside of tech focused companies, 10+ year old systems really are the norm.
    - SoftTalker 3y ago
      > Outside of tech focused companies, 10+ year old systems really are the norm. It's because outside of tech companies, nobody cares about new features. They care about things continuing to work. Companies don't buy software for the fun of exploring new versions, especially frustratingly pointless cosmetic changes that keep hitting their training budgets. Many companies would be happy with RHEL5 or Windows XP today from a feature standpoint, if it weren't a security vulnerability.
      - wkat4242 3y ago
        The problem about "things continuing to work" is really that many security fixes require updated architecture too. This is really why it's so hard to do LTS. It's not only about wanting new features.
    - worthless-trash 3y ago
      What feature did they need in el7 that wasn't there in el9 ? What was their logic ?
    - inferiorhuman 3y ago
      At megacorp (years ago) we were transitioning to CentOS 7 (from 6) and just starting to wind down our 32-bit windows stuff in AWS. I'm sure there are plenty of legacy Linux systems out there, but I wonder how many folks are actually paying for them. CentOS/RHEL 6 was already pretty long in the tooth, but being the contrarian I am, I was not looking forward to the impending systemd nonsense.

kube-system 3y ago

Depends on where the computer is at, I guess. On a desk, 6 years is a pretty long time. In an industrial setting, 6 years is not very long of a lifecycle.

dathinab 3y ago
consider that it's 6 years after release of the kernel version so likely <5 years since release of the hardware in the US likely <4 years since release of hardware outside of the US likely <3 years since you bought the hardware and if you buy older phones having only a year or so of proper security updates is not that unlikely So for phones you would need more something like a 8 or 10 year LTS, or well, proper driver updates for proprietary hardware. In which case 2 years can be just fine because in general/normally only drivers are affected by kernel updates.

Gigachad 3y ago

What kind of breaking change would take longer than 2 years to deal with? The reality is that people wait out the entire 6 year period and then do the required months work at the end. If you make the support period 2 years they will just start working on it sooner.

Retric 3y ago
Many perhaps most projects don’t last 6 years, thus punting can save people a great deal of time.

dathinab 3y ago

6 years is way to short for some use-cases, like phones sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions. so for some hardware it might mean that when it gets released you only have noticeable less then 6 years of kernel support then between starting to build a phone and releasing it 2 years might easily pass so that means from release you can provide _at most_ 4 years of kernel security patches etc. but dates tend to not align that grate so maybe it's just 3 years but then you sell your phone for more then one year, right? in which case less then 2 years can be between the customer buying your product and you no longer providing kernel updates that is a huge issue I mean think about it if someone is a bit thigh on money and buy a slightly older phone they probably aren't aware that their phone stops getting security updates in a year or so (3 years software support since release but it's a 2 year old phone) at which point using it is a liability. EDIT: The answer is in my opinion not to have even longer LTS but to proper maintain drivers and in turn being able to do full kernel updates

xvilka 3y ago
> sadly it's not rare that some phone hardware proprietary drivers are basically written once and then hardly maintained and in turn only work for a small number of Linux kernel versions. These manufacturers should be punished by the lack of LTS and need to upgrade precisely because of that lazyness and incompetence.
- charcircuit 3y ago
  Why not blame the kernel developers for being lazy and incompetent for not offering a stable API for driver developers to use? You don't see Windows driver developers having their drivers broken by updates every few months.
  - mschuster91 3y ago
    > You don't see Windows driver developers having their drivers broken by updates every few months. At the cost of Windows kernel development being a huge PITA because effectively everything in the driver development kit becomes an ossified API that can't ever change, no matter if there are bugs or there are more efficient ways to get something done. The Linux kernel developers can do whatever they want to get the best (most performant, most energy saving, ...) system because they don't need to worry about breaking someone else's proprietary code. Device manufacturers can always do the right thing and provide well-written modules to upstream - but many don't because (rightfully) the Linux kernel team demands good code quality which is expensive AF. Just look at the state of most non-Pixel/Samsung code dumps, if you're dedicated enough you'll find tons of vulnerabilities and code smell.

Ekaros 3y ago

All comes to cycle. When do you enter that 6 year LTS? Is there new LTS every year or every other year? If you enter 2 years in or even 4 years in. How much have you support left? Do you jump LTS releases. So one you are on is ending and there is brand new available? Or do you go to one before and have possibly only 2 or 4 years left...