Canonical Extending Ubuntu 14.04/16.04 LTS Support To Ten Years

[skeevy420]

And why the hell would a computer completely disconnected from the network ever need to be updated?

Ideally, they wouldn't. Necessary updates would be brought in some other way.

Hacking isn't the only reason to update and security fixes aren't the only fixes LTS brings. I'd really love it if someone from Red Hat could show some examples of industrial hardware bugging due to a bad software configuration and an update on an LTS release. Not like I keep a running tally of stuff like that.

[billyswong]

And why the hell would a computer completely disconnected from the network ever need to be updated?

Protecting against external files from USB sticks / SD cards? Also, "a machine that's basically running as an appliance" can be network connected.

[hwertz]

That assumes that software speed is proportional to factory output. If they're running something at a continuous rate (automated welding, 3d printing, etc), updating the software or computer won't magically make the hydraulics lift more weight or allow the wire welder to run 30% faster. That's where "cover my ass legally" LTS comes into play.

This sums it up nicely! There are many systems like this, no benefit whatsoever to running the "latest and greatest" when the existing system is feature-complete and fast enough.

Only reason I suggest moving to 20.04 in a case like this is for companies that insist on their software having available support contract, to be ready when 14.04 and later 16.04 go out of support. There's no tangible benefit to it when the system is already doing what it needs to.

[pegasus]

Ah, 10 years is such a nice round number for the youngsters ...
The other day I learned that we still have one scientific instrument from 1984, controlled from IBM PC, dual 5.25" floppies, running DOS 3.3. There's actually a full time employee just for hunting spare parts on ebay and keeping that thing alive.
Why? Because it's cheaper (and some would say more fun) than to reverse engineer and rework the complete control logic and interfaces of that thing. Any kind of LTS is beyond debate, for cases like this you need a dedicated person who is willing to make maintaining this relic his personal mission.

[Teggs]

'Why should Canonical do this' may return negative values, but 'Why would Canonical do this' may have a simple enough explanation. If some of their 14.04 and 16.04 customers told them 'If we have to upgrade we will... to your competition', then it falls into line.

[Paradigm Shifter]

Canonical are doing this to compete directly with RedHat and SuSE, who already offer support contracts for ten years. It's mindshare and business and marketing; little more.

I've never really understood why there is so much fuss over long term support. But then, I've never understood why so much "mission critical" equipment I deal with runs Windows, either. Sure, I've had updates break things in Linux (which is the usual panic-stricken justification for refusing to develop/support their software on Linux, or the even more laughable "it's too difficult") but I've also had updates break things in Windows. Actually, I've had updates break things in Windows way more often than I have in Linux.

I had the fun a few years ago to be voluntold that I was now supporting a piece of critical equipment that was still running Windows 3.1 (so not quite as bad as pegasus' DOS 3.3 run, but still...). As an experiment, when the controller PC died and I had to find a replacement PSU (that was not fun) I sourced the newest motherboard I could find with an ISA slot (required for the custom controller card) which ended up being a Pentium 4 board, installed Linux on it, cloned the 100MB HDD of the temporarily dead PC and got everything working in a virtual machine. Were the users pleased? Answers on a postcard.

[debrouxl]

This is not true at least for Red Hat. Red Hat backport security fixes from moderate impact up in all packages for entire 10 years. Only in the extended support (additional 3 years) it's limited to just a subset of packages and important/critical CVEs.

Many security issues do not get CVE IDs, though. Look no further than the Linux kernel. And in user-space, the vast majority of the issues I reported to the respective projects' maintainers over the past few years didn't get CVE IDs either, because neither myself, nor the equally unpaid maintainer spent time on the matter. Although OOB reads and pure DoS (e.g. divide by zero) were far more common, there were memory corruptions among them - I remember one of them triggering bitter complaints from the memory allocator.

The top distros with security support are usually doing an alright job propagating fixes for vulnerabilities which received CVE IDs; however, proactive backports of fixes for un-numbered vulnerabilities are much less common, even in popular packages. That's why fast-paced / short-lived distros, or even rolling release distros, and their fresher software are certainly a better solution, from a security POV, than 2+-year-old distros which receive comparatively few security backports. Newer versions sometimes add fresh vulnerabilities which the outdated versions in outdated distros don't have, but on average, for most code bases, the number of bugs and security bugs is decreasing.