Ubuntu 14.04 and 16.04 lifecycle extended to ten years | Hacker News Reader

Ubuntu 14.04 and 16.04 lifecycle extended to ten years

ubuntu.com

183 pointsinput_sh86 comments

I'm not an Ubuntu user (CentOS 7 on my server, will probably move to Rocky 9 when that releases), but it's easy to see why Ubuntu has been successful.

RHEL has 10y support, but historically has released their OS every 4-5 years, which is far too long. Imagine you're releasing a new product 4 years after the last RHEL. If you're doing anything with an area that has a lot of kernel/OS innovation, you're miles behind.

With Debian, I believe it's confusing what their extended support is. They don't guarantee more than 3 years, but usually extend it later. That makes sense for Debian, but not for businesses that need to decide on an OS for their project.

Then comes Ubuntu. Totally free without having to resort to third party rebuilds (like Rocky) with 5 years of support. And you can pay for 10y support. It's not surprising Ubuntu is way ahead of RHEL on public clouds. Red Hat should be doing more to target the startup scene. Those are the enterprises of the future.

I'm still salty about the Centos 8 debacle, this increased my work load a lot. Will never touch anything Red Hat again.

Red hat set their user base on fire with their centos debacle whether they admit it or not.

Look, IBM has to start navigating that product into a mountainside at some point. It's always best to start with user goodwill so the knowledgeable individuals start bailing out. They have to get the number of experts down to a level where IBM has most of them under contract to their customers. That way in 20 years they can cease real support and development while still getting millions in annual revenue.

This is sickeningly accurate and hurt to read.

This is probably the first time in history where Oracle is the nice guy here ;)

I personally ended all my projects' support for RHEL and CentOS a few weeks after that went down. They were already a massive pain in the ass to support, and had a smaller userbase than other Linux distributions (<10% for RHEL and CentOS combined is typical). For me, that was the straw that broke the proverbial camel's back.

I don't really think that IBM/RedHat really saw CentOS as a gateway to RHEL, but as a source of lost sales. I think CentOS had great indirect value to them. It let people like me create, test and support software on RHEL without having RHEL licences. I neither want nor need them, nor could I justify them in the absence of paying customers to underwrite the cost. CentOS gets used for test environments, home use, self-supporting commercial use etc. I don't think many of those would really result in conversions to paying RHEL subscriptions. But they do serve to introduce people to the RHEL ecosystem.

Maybe the strategy makes commercial sense. I don't know, or particularly care. But as an exercise in destroying a community which provided the extended support and software ecosystem around your core product, I think that was a strategic blunder. There are an awful lot of people who now won't be recommending RHEL to their customers, and the willingness of third-parties to test and support their software on RHEL has taken a hit, and that in turn reduces the value of using RHEL.

Where I work we had an enterprise RHEL license but it got too expensive. So I converted all our systems to CentOS. Then CentOS went away, not doing it again. We're moving to Ubuntu.

The original debacle was splitting off their non enterprise users to Fedora.

It set me on the path of experimenting with Gentoo, Debian, and Ubuntu.

Redhat has some excellent engineers, and I have made heavy use in the past of eCos in particular for embedded systems --- I've never understood why they continue to make grand decisions that alienate their customers.

You should really try openSuSE if you were using CentOS. Only 18 months of support but it's quite good. We are using that and Debian, and Ubuntu 18 on the dev machines but will also switch those to Debian, since Ubuntu 20 is quite annoying with snaps, cloud config and all that crap.

+10 for openSUSE Leap, it's a fantastic System, and for long running stuff (like Oracle DB's etc) buy one SLES (10y support) License, for everything else openSUSE leap (up to date apps, performance and compatibility)

In my opinion Ubuntu’s success also has a lot to do with ease of usage. Getting into Docker, Kubernetes, etc. years ago it was very clear that development for the whole cloud native ecosystem was happening on Ubuntu just from how easy it was to “apt-get install” everything. I think that focus for development created a smoother user experience that led to enterprise usage as well. Both were solid, both had the tools supported, but one required a little less setup sometimes.

So, lack of SELinux and the like?

You still have AppArmor or whatever, it wasn’t really an OS specific tool or configuration process. To me it was more like - less bugs, because the dev was done on Ubuntu and so more got addressed. Less configuration, because they made sure to get the packages or kernel modules in upstream for an easy install for new devs, or it comes installed, as opposed to having to add a new repo and go get it. Less barriers, even if the barrier is just one extra command. These quality of life things that made it easy to do dev on Ubuntu, particularly for cloud native tooling right when everyone was shifting to those stacks, also made it easy for Ops teams to adopt it. More novice users who want low barrier to entry meant more StackOverflow answers available to troubleshoot it. Lots of intangibles that might strike a hardcore Sysadmin as irrelevant when choosing an OS but I think they made a strong difference.

I agree, but isn't that because they release so often? With RHEL releases every 4-5 years, getting the latest docker or kubernetes running would mean waiting years, or creating a frankentein RHEL with updated dependencies. Or just use Ubuntu to test it out, and maybe deploy to prod with that (or wait a much smaller amount of time for Ubuntu LTS).

It’s interesting how Ubuntu captured mindshare on desktop first and extended that to server. Very back to front in a way given the ‘year of the Linux desktop’ joke

That's probably very accurate. It's something Red Hat didn't consider, but there's value in a developer using the same OS they're using on their production servers. Very few use Fedora on servers, and very few use RHEL on desktops. Ubuntu covers both with one product.

Yup. I also think the other players underestimate how that mind share would play out on amateur sys admin tasks content on the web.

"Real" sysadmins may look down on amateur self hosters dabbling...but they still use google. And if the google all seeing eye sees a lot of ubuntu tinkering among amateurs that's what they'll show to the sys admins

When .net core came out and we decided to move to Linux, we asked our devs if they were familiar with a specific distro. All of the ones who had used Linux were familiar with Ubuntu, less than 10% had tried fedora. We made the decision then and there, and we're happily surprised when we compared the support packages. Not that Ubuntu is perfect (they love strong arming their house I'm house tech like cloud init, snaps) but they're better than red hat and have full commercial support.

Generally speaking I agree we need to force the rest of the industry into a more ephemeral mindset for infrastructure.

BUT this looks like it is only for ESM, which you need an Ubuntu Advantage subscription for.

If that's the case, then this makes sense. Let Canonical make some more money off those who are willing to pay, big enterprises are slow to do anything.

Ubuntu Advantage is also free for personal use (for a few devices), so you can take advantage of that if you're not a business and are too lazy to update every couple of years.

I'm a home Ubuntu and Debian desktop user. I've been using the free Ubuntu 14.04 ESM support since LTS support dropped. I've been fairly happy with it.

Using an old distro with it's old shared libs and old compilers is definitely not for the normal home user ubuntu demographic that wants things to work easily. But for curmedgeons that hate change and can deal with editing some cmake/etc and source header lines here and there it's liberating. I'd like to use Debian more but 5 years just isn't enough.

May I ask for your line of reasoning here? I always thought people don't want to update to avoid doing the extra work, but if you go down manual patching and compiling a software to make it work with an older OS version, that doesn't look like saving time, at least at first sight.

I like to keep hardware systems with their contemporary software. If my compiler and libs become so old as to become annoyingly restrictive I eventually assemble a new computer with new software and add it to the mouse/keyboard sharing span. But that doesn't mean I want to get rid of the system I've built up. You can say, "Use a VM for old software" but a well broken in box makes things a lot simpler. A new computer every 5-10 years isn't that demanding. I have physical machines for the gtk1, gtk2, gtk3, and now gtk4 eras that I still use every day.

There are also cases where modern versions of software are not better. Text to speech software is really important to me and Festival TTS modern versions (1.9 vs 2.0) just don't have good sounding voices. Luckily I still have my Ubuntu 10.04 box around to do that task.

Canonical keeping the base system stable and secure so I can build my source compiled userspace sand castles on top without constant (ie, every couple years) breakage is great.

Wish I had known that earlier. I spent a bunch of time updating a non-critical server over the summer. I even debated shutting it down rather than updating.

Wow, I didn't know that. Also, only 75 USD per virtual server. For some reason I had a much higher number in my head. Happy to pay this (and support the Ubuntu team) to keep some old boxes up for a couple more years.

If you have a cluster of virtualization hosts, you can license each physical server for 225 a year. It will then cover all vms on that physical host. I went over this multiple times with Canonical reps before purchasing as it seemed too good to be true, but it is. It doesn't even matter what hypervisor you are using.

Yep, I had no idea until reading this announcement that it's free for 3 machines (or 50 if you're a "community member", whatever that is). I promptly registered and added my home server.

If I had an Ubuntu desktop I'd pay for the first tier of Advantage since it's pretty cheap, but sadly their physical server pricing is too much for home use (225). Maybe they could make it 25 for the first server or two or offer a more crippled tier... dunno.

True, i think virtual Servers and real hardware should be the same price, since pci-passthrue, the driver problems can be "potentially" the same, with 75$ for hardware much more "hobbyist" would happily pay that.

On the other hand...Proxmox.

> we need to force the rest of the industry into a more ephemeral mindset

What a despicable position. 5–10 year stability is something the tech industry should be aiming for, minimum—not trying to stamp it out as if someone who achieves it is doing something wrong.

Consider the Dell Chromebook 13 (7310; Lulu). It blew me away last summer to realize that this 2015-era notebook which could be had for $200–300 was still the best option among everything else I evaluated in 2020. Five years to make progress in hardware and yet _every_ other option promised only to be a step backwards. (A phenomenon separately documented here: <https://drewdevault.com/2020/02/18/Fucking-laptops.html>) Manufacturers of course do offer systems today are offering systems with slightly better CPUs or more RAM, but invariably they demand compromising on the ergonomics of either the Lulu's MacBook-quality touchpad, the 67Wh battery that lasts 6–10 hours, the form factor of its 13-inch matte screen and carbon fiber body, the silent fan, or on price—these are companies that expect you fork over at least $1000 more than the putative value of the one already unpacked sitting on the desk—just to have a system that is worse!

Against every signal saying that it would be a mistake, I actually swallowed my reservations about paying the price for a newer system. I was partially reassured by the support lead of one prominent Linux laptop vendor saying that they "promise" that I'd be happy with the purchase, and that it would be better than the Lulu. Sure enough, it gets here; the touchpad is dogshit, the fan is only able to modulate between "screaming loudly" and "screaming very loudly", and I'm left feeling a mixture of horrible dread/remorse while asking myself "is this a joke?" It got packed up and sent back and refunded, and I promptly turned around and spent 1/3 of the refund on a second refurbed Chromebook 13 and left the remaining 2/3 in my bank account.

Aside from the goofy Chromebook keyboard layout, the only downside to these devices? It's that, despite being on par with Purism's flagship notebook at the time (that also sold with a 50+% higher price tag in comparison to this notebook's original retail price), Lulu went largely unnoticed by the community. So newer Ubuntu releases silently broke the graphics, which means upgrading to 18.04 and 20.04 is a non-option. In the midst of this, we get unqualified opinions in the comments here that implicate people who want to stick with 16.04 (because a system that boots is better than one that doesn't) as threatening to "hold back progress" (clearly we've got different definitions of progress) and others cluelessly pontificating that upgrading is "easier and saves you money and pain in the long run" (again, somehow we have a different ideas of how to measure which numbers are bigger than others).

"Dell Chromebook 13"

I think there are enough Laptops that don't suck. And Ubuntu should basically run on most laptops. Fingerprint reader? I don't care.

For the older ones, how about a DELL XPS 13? Or Thinkpad? lenovo carbon x1?

You can get a decent latop for 200-800 USD. I love the DELLS XPS 13/14. But sometimes I get greedy and wish I had 16GB instead of 8GB.

RE: your laptop blog, the laptop market mirrors the problems with the modern desktop OS:

- Apple is closed source, trying to abuse its users AND developers with the pointless app store, OSX was a big improvement when released but basically doesn't evolve and breaks all your software with major releases, and seems openly hostile to open source, Java, Docker/containers. Stubbornly sticks to its UNIX variant and doesn't even offer a linux-ish compatbility layer (even worse considering the lack of native container support)

- Windows: where do I start. two desktops? Tiles is horrible. The UI actively hates its users. Security continues to be bad, although not as bad as the XP days. The only saving grace is WSL is basically evolving windows to becoming a UI for a linux core, which is the only actual glimmer of progress. I actually am cheering for Microsoft to get really big in Azure as the anti-AWS and at some point deciding to go all in with Linux and doing Windows as the UI for basically free to chase all that IAAS dollar.

- Linux: still completely fragmented. Treading water on UIs, not solving fundamental problems, still hardware support headaches. But the worst is that Linux, despite winning the IAAS OS wars, won't properly organize on the desktop front.

Here's a list of major entities whose funding of a real desktop on linux for small small fractions of their financial resources to make a secure, supported, easily upgraded/patched/rolled out OS would be in their great interest:

- Intel, AMD, NVidia: allows them to surface all their hardware innovations and features to the desktop without having to lobby/beg/pray Microsoft adds support to their OS. Instead, you make Microsoft chase/feel pressure to keep up.

- Dell/HP/Lenovo: cheaper hardware for their customers. Ability to directly update the OS with support for their specific firmwares and all its foibles. Maybe even support/push/innovate hardware rather than always following Apple?

- Nintendo and Sony (game consoles / set top boxes): They're already in millions of homes. Neither of these companies can handle a full OS, but they can piggyback on Linux.

- anyone with an IAAS cloud (except Microsoft): Why doesn't AWS want to take over the business desktop? Or oracle cloud, or Google compute, or IBM cloud? You are getting all that sweet IAAS money for servers, why not people's desktops?

- US intelligence and military: ransomware is cyber warfare enemy #1. Do you really want your defense being waiting for Microsoft to release a patch? When a huge number of people using their OS don't pay for it and won't upgrade? And for our military applications, do you want a closed source OS, or an open source one that you can audit? The US military should be throwing a billion dollars at Linux every year.

- EU... everything: Who made Linux? A goddamn European. Do you want to wrest technical software leadership from the US and Microsoft? Well, the author and many/most core committers are in the goddamn EU. It is sitting in your backyard. Now add it all the things I said about the US military: you can avoid (software) backdoors because the code is auditable. You can keep US, Russian, China intel from eating your lunch every day. The EU should be throwing a billion a year at Linux.

- China: Same thing as the EU: do you want closed source Microsoft OSs running on your machines? Do you want Google controlling the OS of all the phones your people use, or Apple? China should be throwing a billion at Linux every year too.

What should be happening is that Linux is getting 10 billion a year to improve itself: security, features, support, etc.

But... it doesn't.

I mean, there should be literally 100,000 core committers each getting funded 100k/year for their first and only job. What actually should be happening is probably 100 billion a year between concerned militaries, governments, corporations, etc, basically funding a worldwide army of a million committers.

Torvalds should be eligible for a (quite ironic given his temperment) Nobel peace prize just from what he has already done.

> we need to force the rest of the industry

Or we could, you know, not force anything and just work together to solve problems instead.

Different industries, environments, and individuals all have vastly different requirements and _your particular_ mindset and methods do not fit all use cases.

In what use case is non-ephemeral IT infrastructure necessary?

Spacecraft come to mind. Missions take a long time to come to fruition and there are already enough variables to consider. Fixing the mission control computer configuration as far in advance as possible removes one more variable from the equation.

That entire industry needs a level of reliability several orders of magnitude more than any other industry. They couldn't redeploy servers even if they wanted to. I'm by no means an expert Space Systems Engineer. But any NASA technicians reading my original comment would probably agree with me in the general case. Space stuff certainly does not fall under the general case, because it's not possible.

Hi, spacecraft flight software engineer here. If I agreed I wouldn't have commented. It's not that we need several orders of magnitude more reliability than any other industry, it's that for some reason most other industries have decided to accept several orders of magnitude less reliability than they need. The day-to-day pain of dealing with a constant barrage of bugs that never get fixed and forced updates that introduce new bugs on top of the old ones makes me consider just giving up on technology and living in a cabin in the woods semi-seriously on at least a monthly basis.

Embedded systems

My company still has machines we made in 1950 that customers use in their business. They buy replacement parts from us. While we would love if each of those customers spent half a million dollars every few years to replace those old machines, we can't force them to do that. We can make some money from replacement parts though, so long as we are willing to set out sights low enough. Things that old are mostly mechanical so it is easy for someone to learn how to support them, and it saves the customers a lot of money. In the end we are proud that things we made 70 years ago are still being used in the real world for their original purpose.

You should learn the same: take pride in the fact that things you wrote years ago are still useful. Part of that means write good code so that it is easy to fix any newly discovered hack, without having to update everything else to the latest.

This is very interesting - and bravo for making something that lasts so long. Can you share anything more about what those machines do and why they are so durable?

In general most older machinery was designed to be repairable. Often using industry standard sizes for things such as motors, bearings, relays, screws, etc. As long as you can get (or make) the parts and are willing to maintain the equipment, you can keep using it.

Indeed. It’s often the case too that it becomes outdated - more modern designs are more efficient etc. I’m probably more intrigued / surprised that it’s economically effective to keep a seventy year old machine working.

Using physical hardware for as long as possible is absolutely the right mindset. For cost, reliability, environmental reasons, and many more.

This post was about an operating system (Software).

People shouldn't be using code that is no longer supported (support it yourself or don't use it, it's dangerous).

And people should be rebuilding their infrastructure from scratch as often as possible. That's the only way to prove you've built something reliable, auditable, and correct.

VMs and containers make that very easy and achievable for even the smallest of teams.

Linux goes to great lengths to support lots of different (and old) hardware. Linus has said many times, if you maintain it, it can stay.

Maybe moving forward that's true as efficiency hits limits, but you really shouldn't use old hardware if the new hardware so outstrips it's efficiency that switching to the new hardware amortizes the cost of the new hardware plus the cost to decommission the old hardware

In the real world you see companies running the same old unpatched distro for years. I had a contract job at a company that hadn’t updated one of its systems in over 3 years. Several systems with 1200+ day uptimes. Nobody wanted to update anything since it might break. Even a reboot was frowned upon. This was at a “real company” with 1000’s of employees and a huge IT staff. Truly sad.

The issue with software is that software is still in its infancy and we have a hard time to build software, which is "nice" to use and will work in 10 years time. This becomes especially worse with modern stuff connected to a network, where security plays a major role. And it is bad with Web stuff, where compatibility with "advanced" features can be a problem with future clients.

Very true. It is something we as an industry need to learn.

And yet one can find 20 year old software in many domains that just keeps plugging away. The problem isn't infancy. It's an industry that monetizes planned obsolescence and chases shiny. Many of us might as well sell bellbottoms followed by skinny jeans followed by bellbottoms.

This is microsoft-like in terms of how long the system is supported. Hats off to Canonical.

Also, there is a way to "cheat" if you have 16.04 on your desktop and still wants security updates: https://www.omgubuntu.co.uk/2021/09/ubuntu-16-04-security-up...

Note that 16.04 is reasonably well supported on modern hardware because of hardware enablement updates and you can use modern software with snaps, appimages and flatpak.

Just like everyone else seems to think, this is the monetization model I can get behind.

Does that mean there will be another ten years of 32-bit support, or is that already out of 14.04 at this point?

Thanks

I got the gist that "We cannot support old SW for so long" but that action makes things more manageable to upgrade.

I have several SWs that are hard-depended on the OS version.

I like Ubuntu's LTS releases, and prefer upgrading from/to each one. For some reason I skipped 18.04 though.

I mean if there is demand why not. They presumably already have the skill and capacity so can just keep trucking

Nice one!

great!

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

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

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.

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.

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

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.

>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..)

io_uring is one example, among many.

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).

It depends on what you’re building?

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.

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.

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 :^)

Novelty? Fixes roll out constantly with new software. Wanting the latest best-working software for desktop is not novel.

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".

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.

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

What progress is it holding back?

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

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.

> We need shorter release cycles with less risky upgrade paths, not this nonsense.

Why do "we" need shorter release cycles?

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.

>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.

> 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.

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.

Of course I read them. But the very special case of docker and some hypothetical problems don't invalidate the concept.

Fair. Particularly the point you make about Docker not being compatible with 16.04 - and, I will make the following confession - everything I said in that post applied to my work system - which is a linux laptop - and almost everything I do there is predicated on things like new python modules, new vscode innovations, new pandas releases - all sorts of things that don't really benefit from the latest and greatest. And, yes - as your OS gets older you need to start to rely on alternative repos like https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa for important things. I guess the point I was trying to make is that I wish, and would pay for (or have my company pay for) distros that just kept everything packaged and running smoothly for 5 year cycles (10 years is probably a bit much, I'll grant you that), understanding that yes, when it comes to innovations like containerization or hypervisors - you might have to bite the bullet and move forward an OS release.

At home - I'm a MacOS user, and work very hard not to upgrade the to a new OS in the first month it's released, and am quite comfortable upgrading to a new laptop every 4-5 year.

So, I like new things for my personal environment. It's just my work environment that I want to stay the same for as long as possible.

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

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

> 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.

Reply on news.ycombinator.com