Canonical pushes Ubuntu LTS support even further - if you pay Last year, Canonical increased its paid extended support lifespan to 12 years. Now, it's increasing it again, to 15 years ... for a price. Canonical's announcement puts the main news right into the title: Canonical expands total coverage for Ubuntu LTS releases to 15 years with Legacy add-on. This is an extended version of its …
As the sub-title says, one wonders if this new program is simply an attempt to hold the record for longest possible support offering by a commercial Linux outfit.
Even so, I have little doubt there will be takers, which means it'll generate at least some revenue for Canonical. It's the kind of thing which likely resonates with CTO's and IT Directors and such.
Though to me 15 years seems an awfully long time to stay on a release, support contracts or not.
I find one of the incentives to upgrade to a new release is the rest of the world. If you're stuck on a distribution that uses Python 3.4 (assuming it's new enough to have made it to V3) then a lot of stuff needs a newer rev. Similarly with other things, you're still getting upgrades that don't include features from newer releases, and occasionally you learn that the functionality you crave does exist in the latest revision.
One of the challenges with this is that the entire stack gets further and further behind to the point that when you actually have to move because there is no more support the jump is now so many versions that failure is pretty much assured.
It is one of the reasons why HMRC and many councils struggle. There comes a point where endlessly extending support is self-defeating.
The OS is only part of this legacy or extended support. A question could by "Why are the applications not being updated?".
If there is no support on that either then as a business it becomes more risky. What happens if there is a major failure or security flaw? You are potentially in an even worse bind as you find everything is back in the dark ages.
Change for the sake of change is the way IT makes money. It is a loop that businesses and consumers are locked into as it is seen as continuous improvement (in the loosest sense.....)
It should not be like this but businesses and users demand constant updates because it that does not happen it is considered "outdated". That the actual functionality people use is a tiny amount of all the new bug-ridden crap that is added appears to be irrelevant.
LTS kernels are supported for 2 years. The Linux civil infrastructure project will support kernels (in a much reduced capacity) for 10 years.
¿Who will be patching/backporting stuff to a 12 year old kernel? ¿A colaborative effort of RH, Suse and Canonical? ¡Yeah, right!
Let alone a 14.5 y.o. one.
Wait until cannonical start to attach strings, and support the distro in name only because everything in the stack from the kernel upwards will have to be "slightly" upgraded to much newer versions, even thoug the distro is still called "Trusty Tahr" ¡Yeah, right!
I mean, if Cannonical offers it, they better fullfill the promise _correctly_.
Is better to promise 7 years and deliver correctly and in full, than promise 15 and deliver 11, weasel out of the other 4.
Trust me. Once you renege of your promise, the backlash will be much more damaging that having reduced support windows.
Red Hat doesn’t backport all fixes for 10 years, only high/critical ones once they’re in the later stage of maintenance. They also only run with a subset of kernel functionality (e.g. SELinux yes, AppArmor no) and are very cautious over which network protocols and drivers are compiled in. They also are very, very careful to ensure that they do not add new features later on in the support cycle, so if a hypothetical TLS 1.4 standard pops up, they won’t add it if the release is beyond 5 or 6 years old.
Canonical will do similarly but with a slightly different take. They will have certified hardware which runs on stock kernels if the drivers are stable, and then everyone else will use HWE kernels with shorter support lifespans. Also, they will get some patches for free from Debian LTS and Extended LTS projects, since they always base their LTS releases on Debian Testing when it’s at a key point that’s “close enough” meaning not all the work will be theirs until very late on,
You're looking at it from the wrong end og the telescope. The people who are interested in this are not those looking to install the newest shiny. They are people who need to run something developed for that platform and which is performing a critical function not easily replaced. Are they going to take the risk of asking will it run on the latest version of libxml2, let alone the latest version of Python?
They probably don't even want any patches or for it to be "slightly" upgraded. They're paying the money because some fiat says the platform must be "supported" and the reality is that it has to stay just as it is, doing just the job it was installed to do, no more and certainly no less.
And if you've got a working thing that is staying just as it is, why isn't it sitting in a VM with a modern Linux in front of it to ensure that it's fed and watered and its byproducts collected through properly monitored apertures - why does it need support that might change things?
Fifteen years is enough that you could be running a 386 kernel, user-space and application perfectly reasonably inside qemu on an M4 Mac.
Who buys this "extended support"?
I can't believe that a laptop user of Ubuntu (like me) would pay up.
Maybe an organisation with thousands of laptop end users might......but are there any organisations like this?
Maybe an organisation with thousands of server instances might.......but how many of these organisations are there?
Maybe Liam could provide some insight into the likely customers for this deal?
In our case the cost of migrating to newer (and more systemd-infested) version was greater than simply paying for a few critical machines to be supported without monkeying around. If you just install and use it for a laptop/desktop it is probably not an issue, but if you have things like syslog-forwarding, build scripts, and customised plugins for Nagios, etc, such an OS change is not trivial.
Another example, which is not applicable to us, is you can pay more for added support response time and help with specific issues if you lack the technical ability to do so. Again, if you use Linux to avoid the MS tax, forced obsolescence of hardware, etc, then it is not worth it, but if you are using Linux for a stable and moderately-malware-free option for business critical work then it makes a lot of sense.
Typically machines where upgrading is nontrivial. eg app depends on some library where there's been a compatibility break between old and new versions - PHP5 and Python 2 being some older examples. It's easier to pay for LTS than to invest time in porting the code. Maybe the app has no future (was due to be decommissioned but its replacement timeline has slipped) and it just needs to hang in there for a bit longer.
Another one is proprietary apps that are built for an older OS, eg linking with libpng12, libncurses5, libtinfo5, libudev0 are ones I come across regularly. Personally I just hack these (symlink libudev0 to libudev1, seems to work) but if it's a regulated environment maybe you can't do that. Again it's not always trivial to update to a newer version of the app, especially if there are unwanted changes to other functionality (ie version N+1 is not a drop in replacement for N)
"if it's a regulated environment"
This is surely the key to it. Regulated environments that require applications to be certified and the applications themselves are only certified to run on a specific platform. Just the sort of environment that doesn't sit well with forced upgrades.
> Maybe Liam could provide some insight into the likely customers for this deal?
It's mainly for servers.
Ubuntu was originally designed as a desktop distro: to be an easy-to-use replacement for Windows. However, it came out was 21 years ago. That's bags of time for kids to explore a free, easy, desktop Linux, get comfy with it, then grow up and get jobs. When they need an OS to run stuff on and there's no budget, they tend to naturally go with the familiar one.
Ubuntu Server appeared soon afterwards: first release 5.10 I think from a very quick Google.
After a while, a visible result of familiarity with the desktop version was was lots of servers running Ubuntu.
Servers make money. Companies will pay money for help and support on servers, for tools that help manage fleets of servers, for automation and so on. Even if the server OS is freeware you can make money off the back of server OSes.
So although Ubuntu remains a highly visible desktop OS, it also puts effort into its server version, because that makes money.
If you spend some time building a server tool that works, on a given version of the OS and with specific matching versions of VMs and server apps and config, and it works fine and does what you need, then as others have pointed out, it makes sense to keep it just as it is for as long as it still does the job. If that means paying for critical security updates, that is no big problem: it's cheaper than rebuilding the whole shebang on newer components every other year.
So, a paid service: critical fixes for old versions of server OSes and the server apps layered on top.
As it happens you can run it on a desktop as well, if you so wish.
I tend to think keeping stuff running on an old but supported OS is in the long term not such a good idea,
It is going to have to happen at some time so why not do it when you still may have institutional knowledge.
After 5 years it is quite possible you may not have the people who know why it was built the way it was.
Perhaps a newer OS may have solutions to the issues you had to work around but what if no one remembers what they were?
Finally often the OS is only what the software stack sits on and whilst you can patch the OS what about what is is running on it?
Well only my 2d.
What about some very expensive piece of equipment, something so expensive it was scheduled to be amortised over a couple of decades? Something whose drivers were written over a decade ago by a vendor long closed down. In tha sort of environment issues are not going to be solved by new versions of the OS, they're going to be created by them.
Now imagine you're about to purchase s new piece of equipment of that nature. Would you want its controlling S/W to run on an OS whose vendor is not only promising such longevity but visibly delivering it on their earlier versions or would you want it to run on Windows?
For the 10 year ESM you can get that for free just by registering if it is non-commercial use, It also includes the kernel live-patch facility to update some modules without a reboot.
Yes, I was sceptical as well as it sounds a lot like DIY brain surgery with the attendant risks but it seems to work a lot of the time, though occasionally you get an update that does require a reboot.
If you are commercial you can now pay for just a couple of machines, which suits us, as originally they were a bit MS-like in only wanting big customer's money, which always seems a daft policy...
> With the launch of Ubuntu Pro, all of the packages in Ubuntu Universe get the same security maintenance commitment from Canonical as packages in Ubuntu Main.
They want to support almost ~40,000 packages for 15 years? When it was "only" the ~2000 packages in the main repo, sure, maybe. But with the universe repo? Never ever is that going to work out! Shuttleworth must have completely lost it now.
> ...or are we back in mainframe territory where mortals aren't allowed to discuss such things?
I didn't ask because like most things in big business, the more you buy, the cheaper it gets.
It's called Wright's Law and about 15 years ago it became more accurate for predicting the price of computer chips over time than Moore's Law.
https://www.ark-invest.com/wrights-law
Doesn't everyone know the old joke?
A firm's financial director is interviewing a range of accountants for a potential job.
He meets a junior candidate, and asks him "what's 2 plus 2?"
The nervous junior says, "er, 4, sir?"
He is escorted out.
The director meets a mid-level accountant. He asks him "what's 2 + 2?"
The mid-level chap cautiously says "well, preliminarily, I'd say in the range of about 3 to 5."
He is sent to wait outside.
The director meets a senior candidate. He asks the chap "what is 2 + 2?"
The senior accountant stands up, walks to the door, quietly closes it, comes back, sits down, and asks "what number did you have in mind?"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2026
