Old zombie Linux distribution versions aren't really doing you any favours

November 18, 2018

One bit of recent news in the Linux distribution world is Mark Shuttleworth's recent announcement that Ubuntu 18.04 LTS will get ten years of support (Slashdot, ServerWatch). As it happens, I have some views on this. First, before people start getting too excited, note that Shuttleworth hasn't said anything about what form this support will take, especially whether or not you'll have to pay for it. My own guess is that Canonical will be expanding their current paid Ubuntu 12.04 ESM (Extended Security Maintenance) to also cover 18.04 and apparently 16.04. This wouldn't be terribly surprising, since back in September they expanded it to cover 14.04.

More broadly, I've come to feel that keeping on running really old versions of distributions is generally not helping you, even if they have support. After a certain point, old distribution versions are basically zombies; they shamble on and they sort of look alive, but they are not because time has moved past them. Their software versions are out of date and increasingly will lack features that you actively want, and even if you try to build your own versions of things, a steadily increasing number of programs just won't build on the versions of libraries, kernels, and so on that those old Linuxes have. Upgrading from very old versions is also an increasing problem as time goes by; often, so much has changed that what you do is less upgrading and more rebuilding the same functionality from scratch on a new, more modern base.

(Here I'm not just talking about the actual systems; I'm talking about things like configuration files for programs. You can often carry configuration files forward with only modest changes even if you reinstall systems from scratch, but that only works so far.)

You can run such zombie systems for a long time, but they have to essentially be closed and frozen appliances, where absolutely nothing on them needs to change. This is very hard to do on systems that are exposed directly or indirectly to the Internet, because Internet software decays and must be actively maintained. Even if you don't have systems that are exposed this way, you may find that you end up wanting to put new software on them, for example a metrics and monitoring system, except that your old systems are too old for that to work well (or perhaps at all).

(Beyond software you want to put on such old systems, you're also missing out on an increasing number of new features of things. Some of the time these are features that you could actively use and that will improve your life when you can finally deploy them and use them. I know it sounds crazy, but software on Linux really does improve over time in a lot of cases.)

Having run and used a certain number of ancient systems in my time (and we're running some now), my view is that I now want to avoid doing it if I can. I don't know what the exact boundary is for Linux today (and anyway it varies depending on what you're using the system for), but I think getting towards ten years is definitely too long. An eight year old Linux system is going to be painfully out of date on pretty much everything, and no one is going to be sympathetic about it.

So, even if Ubuntu 18.04 had ten years of free support (or at least security updates), I'm pretty certain that neither you nor we really want to be taking advantage of that. At least not for those full ten years. Periodic Linux distribution version updates may be somewhat of a pain at the time, but overall they're good for us.


Comments on this page:

By Jukka at 2018-11-19 07:00:25:

I agree: ten years is too long and indeed carries the zombie-issue you describe.

Then again, many things are also moving too fast.

Therefore, an interesting corollary: what would be an optimal support time from a maintenance perspective? How to quantify such an optimum? Pushing packets versus serving Web 2.0?

We’ve recently moved from every Ubuntu release to every Ubuntu LTS release. We realized we weren’t as interested in updated software versions, except for PHP, which we were already getting from Ondřej Surý’s PPA. (Which happened after the migration to Ubuntu. The PPA lets us get new versions on our own time-table, and upgrade them app-by-app. The PPA versions are co-installable, so each app can determine whether it wants the system default, or a specific phpX.Y-fpm socket.)

Anyway, if we had to give up the PPA, a one-year cycle for releases (matching PHP’s one-year cycle) with 6 months overlapping support would suit us. Two years is already kind of long in the general case, and I wouldn't even want to run a server distro more than 3 years past its initial release.

But there are important differences in our environments. We’re merely serving some web apps from AWS. We don’t offer compute service, and we don't have firewall instances (we have WAF.)

Written on 18 November 2018.
« Some notes about kernel crash dumps in Illumos
When Prometheus Alertmanager will tell you about resolved alerts »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 18 22:43:43 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.