"Long term support" Unixes and versions of software in them

April 16, 2022

In a comment on my entry about how Firefox versions are relatively tightly tied to Rust versions and how this affects LTS Unixes, Tom said, in part:

[...] But, if Ubuntu LTS is going to have a version of rust that is relevant to users (rather than just as a build dependency), they should really package a up-to-date version of rust as well, since it has the same support period as does Firefox.

The problem that all Unix distributions face sooner or later is that the people using them generally want the platonic ideal version of semantic versioning minor releases, namely updates that only fix bugs and improve things and never introduce backward compatibility problems or undesired changes. Apart from other problems with semantic versioning, the reality of life is that almost no modern open source project works this way for very long, including languages. Rust has stopped accepting cargo.toml files that it used to (cf), Go has significantly changed how the toolchain worked (cf), and even C compilers have broken compilation of existing things by adding new warnings (cf).

(And languages are often the conservative things here. Many things with GUIs undergo much more change much faster. Firefox and Chrome are arguably two poster children for this.)

The state of modern software is that almost nothing holds to the ideal of semantic versioning minor releases over the span of a few years, much less the five years that is the common duration for modern "LTS" releases (although they may or may not make this clear in their version numbers). This is true for the latest releases of software, and it's also almost always true for the supported versions, because very few software projects support old releases for multiple years, especially three or four or five years. The consequence is that whether you keep up with the latest versions or just the latest supported version, sooner or later you'll have to install an update that isn't fully backward compatible. Some of the time, this will make people unhappy (although some of the time the change will be in an area that they don't care about).

(Note that not all projects follow semantic versioning in their version and release numbers. I think both Rust and Go would say that they don't, for example. And semantic versioning is ultimately a social understanding anyway.)

This leaves Unix distributions with three choices. They can not pretend to be stable over the long term, they can be stable over the long term with old software versions, or they can be "stable" over the long term with newer versions of eg Rust with the hopes that this won't introduce too many changes that upset people. Most Linux distributions pick either the first or the second, with as little of the third as they can get away with. If nothing else, this leaves people with a relatively clear choice; you can accept churn with the benefit of being relatively current, or you can accept stale software in order to get long periods of low or no churn.

Comments on this page:

Or you manage your own stack and dependencies yourself and use the distro for everything else. That said, Rust’s cavalier attitude to stability and backwards compatibility, specially the absurd bootstrapping process contrasts poorly with Go’s cautious approach.

By Joseph at 2022-04-17 07:30:01:

There is a fourth option:

- make installation of multiple versions of tools and libraries a first class citizen

- support packaging that allows a program full control of its dependencies so that it in effect becomes a statically compiled binary. Nix, flatpak, snap and yes even docker are examples of this

- provide LTS version of the tools/libraries where everything else is buy beware and wholly unsupported by the Linux distro

Now there are costs to this approach:

- patching security vulnerabilities becomes much harder.

- disk utilization can grow substantially (imagine every python program including a full install of python)

- network utilization grows and could become problematic on a low speed internet connection

I am not sure how this will breakdown on the consumer side but for the server? Oh the users have made their choice. Docker containers are ubiquitous. Installing software via a deb on a Linux server where it depends on a distro dependencies is quickly becoming a thing of the past. Or in other words: the debate over dynamic linking and static linking was had and the dynamic linking crowd lost resoundingly.

By Miksa at 2022-04-21 08:49:33:

I suspect distros will come to the realization that you can't support all the software in LTS release with the original version. Red Hat came to this conclusion on RHEL 8 with their appstream system. Go and Rust are kept up to date, and with something like PostgreSQL there are several versions available, 9.6, 10, 12 and 13, but only 12 is supported for the full RHEL lifetime. Version 12 was also introduced with 8.1.1, so you would have been forced to do at least one major upgrade.

Written on 16 April 2022.
« I need (or at least want) a new virtual machine (GUI) environment
Where Linux's load average comes from in the kernel »

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

Last modified: Sat Apr 16 22:13:24 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.