4 ms·

Terrible news. This will hold back progress like usual. We need shorter release cycles with less risky upgrade paths, not this nonsense.

JshWright 5y ago
This way Canonical can keep charging for ESM contracts... Gotta get that sweet legacy maintenance revenue.
kyrofa 5y ago
You have options if you want something like that. Use a rolling release distribution like Arch. For commercial use, this ESM model is spot on.
zamadatix 5y ago
Companies on extended support releases of versions distros want a specific version of packages with security patches for a product lifecycle not an increased frequency of OS changes.
moralestapia 5y ago
Sorry to break it to you, but plenty of people prefer stability over novelty.
- awill 5y ago
  I think it's a little more nuanced than that. If I'm building something new, I generally want a new kernel/OS underneath. Especially if what I'm building can take advantage of it (improvements to filesystems, networking stack etc..). After I've launched my service, I want stability over everything else. So here, I'd launch on the newest Ubuntu available, and stick with it for quite a long time.
  - moralestapia 5y ago
    >I generally want a new kernel/OS underneath Huh? That's weird, Linux, OSX and Windows kernels have been battle-tested and hardened for like 30 years or so now. I can't imagine what kind of application would need a different kernel to start with. Aside from security concerns (which you didn't mention, plus one could argue an LTS is safer), could you give a specific example of: >what I'm building can take advantage of it (improvements to filesystems, networking stack etc..)
    - orf 5y ago
      io_uring is one example, among many.
      - moralestapia 5y ago
        https://news.ycombinator.com/item?id=26745275 https://news.ycombinator.com/item?id=26745275 Is it really worth it to jump into a completely new feature to get marginal improvements on the most basic stuff (io, networking, etc...), all of this, in exchange of working with unstable APIs and unproven security vectors? My answer is no but I can picture people who would say yes. I guess it's a matter of personal preference (plus I work on stuff that has to be reliable, above everything else).
        orf 5y ago
        It depends on what you’re building?
        awill 5y ago
        yea, if you're building a distributed system that will need to scale to handle millions of TPS, then networking, IO, filesystem etc.. improvements can be significant.
    - sbuttgereit 5y ago
      I read those comments as assuming new versions of those battle tested lineages... not newly created kernels or OSes. The last statement seems to make that intent clear.
      - moralestapia 5y ago
        I read those comments as "OP doesn't even know the difference between a kernel and a distro". The whole statement seems to nake that premise clear :^)
- jklinger410 5y ago
  Novelty? Fixes roll out constantly with new software. Wanting the latest best-working software for desktop is not novel.
  - marssaxman 5y ago
    If fixes were all that rolled out, I'd be happier about new software. Since the fixes invariably come bunded up with a lot of other changes I neither need nor want, it's rarely clear that the "latest" software is the "best-working".
stusmall 5y ago
You have the option to do that. Keep up on the most recent Ubuntu. It's easier and saves you money and pain in the long run. Hopefully whatever train wrecks of organizations that need 14.04 are paying enough in support contract to help subsidize Canonical for the rest of us.
tomc1985 5y ago
Dear god no. If upgrade cycles slow down to like 3x what they are I'd be quite happy
handrous 5y ago
What progress is it holding back?
ch_123 5y ago
This way, Canonical gets paid by the people who want to stay on old versions - meaning more investment in new versions. I strongly suspect that this long-term support costs the customer a lot more than it costs Canonical to support the old versions
dleslie 5y ago
On the Linux Desktop, we'd have shorter release cycles with less risky upgrade paths if it weren't for the belligerence of the Gnome development team.
Zababa 5y ago
> We need shorter release cycles with less risky upgrade paths, not this nonsense. Why do "we" need shorter release cycles?
ghshephard 5y ago
Good lord no - if I can run my current laptop for 10 years on 20.04 - I'll be more than happy to do so. I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... Save the new operating systems for new hardware, bus standards, innovative GUIs, etc... Let me just keep pounding away 12-hours/day without a hiccup on my current gear.
- Arnavion 5y ago
  >I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... So either your applications and browsers come from the distro's package repo, in which case when their upstreams update to newer versions that require newer dependencies your distro doesn't have, your distro will be stuck on older versions lacking the innovation you seek. Or you use flatpaks or snaps, which don't have that problem because the flatpak / snap bundles the newer libraries, but then the stability of the OS doesn't help you. And you're still stuck with an old flatpak / snap daemon that could cause problems with new flatpaks / snaps, and with an old kernel that could be missing syscalls that the newer libc's inside the flatpaks / snaps require. Eg I remember discovering that 16.04 and earlier don't have the getrandom syscall, which made it impossible to run a newer OS's Docker container since its libc expected it. To be clear, I'm all for people wanting to remain on supported OSes for a decade. I'm just pointing out that expecting "innovation" is incompatible with that.
  - The_Colonel 5y ago
    > I'm just pointing out that expecting "innovation" is incompatible with that. No, it's not. There's a huge difference between "let me update these 2 apps which I care about" and having to upgrade the whole system to get those 2 new updated apps.
    - Arnavion 5y ago
      Perhaps you should read the two preceding paragraphs to see the problem with that expectation instead of assuming the third paragraph was written in isolation.
MeinBlutIstBlau 5y ago
The majority of commercial enterprise doesn't upgrade on a whim. My company was still using Windows 7 this year.
amalantony06 5y ago
Doesn't Debian do exactly what you've said?
cies 5y ago
> We need shorter release cycles with less risky upgrade paths Either you speak for yourself or you have no clue how a market works. Long term support i know to be paid for by enterprise: hence there IS demand.

JshWright 5y ago

This way Canonical can keep charging for ESM contracts... Gotta get that sweet legacy maintenance revenue.

kyrofa 5y ago

You have options if you want something like that. Use a rolling release distribution like Arch. For commercial use, this ESM model is spot on.

zamadatix 5y ago

Companies on extended support releases of versions distros want a specific version of packages with security patches for a product lifecycle not an increased frequency of OS changes.

moralestapia 5y ago

Sorry to break it to you, but plenty of people prefer stability over novelty.

awill 5y ago
I think it's a little more nuanced than that. If I'm building something new, I generally want a new kernel/OS underneath. Especially if what I'm building can take advantage of it (improvements to filesystems, networking stack etc..). After I've launched my service, I want stability over everything else. So here, I'd launch on the newest Ubuntu available, and stick with it for quite a long time.
- moralestapia 5y ago
  >I generally want a new kernel/OS underneath Huh? That's weird, Linux, OSX and Windows kernels have been battle-tested and hardened for like 30 years or so now. I can't imagine what kind of application would need a different kernel to start with. Aside from security concerns (which you didn't mention, plus one could argue an LTS is safer), could you give a specific example of: >what I'm building can take advantage of it (improvements to filesystems, networking stack etc..)
  - orf 5y ago
    io_uring is one example, among many.
    - moralestapia 5y ago
      https://news.ycombinator.com/item?id=26745275 https://news.ycombinator.com/item?id=26745275 Is it really worth it to jump into a completely new feature to get marginal improvements on the most basic stuff (io, networking, etc...), all of this, in exchange of working with unstable APIs and unproven security vectors? My answer is no but I can picture people who would say yes. I guess it's a matter of personal preference (plus I work on stuff that has to be reliable, above everything else).
      - orf 5y ago
        It depends on what you’re building?
        awill 5y ago
        yea, if you're building a distributed system that will need to scale to handle millions of TPS, then networking, IO, filesystem etc.. improvements can be significant.
  - sbuttgereit 5y ago
    I read those comments as assuming new versions of those battle tested lineages... not newly created kernels or OSes. The last statement seems to make that intent clear.
    - moralestapia 5y ago
      I read those comments as "OP doesn't even know the difference between a kernel and a distro". The whole statement seems to nake that premise clear :^)
jklinger410 5y ago
Novelty? Fixes roll out constantly with new software. Wanting the latest best-working software for desktop is not novel.
- marssaxman 5y ago
  If fixes were all that rolled out, I'd be happier about new software. Since the fixes invariably come bunded up with a lot of other changes I neither need nor want, it's rarely clear that the "latest" software is the "best-working".

stusmall 5y ago

You have the option to do that. Keep up on the most recent Ubuntu. It's easier and saves you money and pain in the long run. Hopefully whatever train wrecks of organizations that need 14.04 are paying enough in support contract to help subsidize Canonical for the rest of us.

tomc1985 5y ago

Dear god no. If upgrade cycles slow down to like 3x what they are I'd be quite happy

handrous 5y ago

What progress is it holding back?

ch_123 5y ago

This way, Canonical gets paid by the people who want to stay on old versions - meaning more investment in new versions. I strongly suspect that this long-term support costs the customer a lot more than it costs Canonical to support the old versions

dleslie 5y ago

On the Linux Desktop, we'd have shorter release cycles with less risky upgrade paths if it weren't for the belligerence of the Gnome development team.

Zababa 5y ago

> We need shorter release cycles with less risky upgrade paths, not this nonsense. Why do "we" need shorter release cycles?

ghshephard 5y ago

Good lord no - if I can run my current laptop for 10 years on 20.04 - I'll be more than happy to do so. I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... Save the new operating systems for new hardware, bus standards, innovative GUIs, etc... Let me just keep pounding away 12-hours/day without a hiccup on my current gear.

Arnavion 5y ago
>I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... So either your applications and browsers come from the distro's package repo, in which case when their upstreams update to newer versions that require newer dependencies your distro doesn't have, your distro will be stuck on older versions lacking the innovation you seek. Or you use flatpaks or snaps, which don't have that problem because the flatpak / snap bundles the newer libraries, but then the stability of the OS doesn't help you. And you're still stuck with an old flatpak / snap daemon that could cause problems with new flatpaks / snaps, and with an old kernel that could be missing syscalls that the newer libc's inside the flatpaks / snaps require. Eg I remember discovering that 16.04 and earlier don't have the getrandom syscall, which made it impossible to run a newer OS's Docker container since its libc expected it. To be clear, I'm all for people wanting to remain on supported OSes for a decade. I'm just pointing out that expecting "innovation" is incompatible with that.
- The_Colonel 5y ago
  > I'm just pointing out that expecting "innovation" is incompatible with that. No, it's not. There's a huge difference between "let me update these 2 apps which I care about" and having to upgrade the whole system to get those 2 new updated apps.
  - Arnavion 5y ago
    Perhaps you should read the two preceding paragraphs to see the problem with that expectation instead of assuming the third paragraph was written in isolation.

MeinBlutIstBlau 5y ago

The majority of commercial enterprise doesn't upgrade on a whim. My company was still using Windows 7 this year.

amalantony06 5y ago

Doesn't Debian do exactly what you've said?

cies 5y ago

> We need shorter release cycles with less risky upgrade paths Either you speak for yourself or you have no clue how a market works. Long term support i know to be paid for by enterprise: hence there IS demand.