You may think you know what “long-term support” means when picking a Linux distribution and version, but judging by the multitude of utterly wrong takes and deeply confused users I come across online, I’m starting to get the feeling that in fact, no, you don’t know what it means. KDE’s Nate Graham is seeing the same confusion, and has published a blog post going over what LTS really means in the Linux world.
People seem to think that an LTS release means it’s going to be more stable, have fewer bugs, and receive support for a certain set period of time. The reality is that only that last one really applies, sort-of. LTS generally means you’re going to be using a Linux distribution version where you’ll get security fixes and possibly maintenance updates for a set number of years, but you won’t be getting updates with new features or other updates that aren’t security fixes.
The purpose of an LTS release is to more or less freeze itself and its packages in time, so that users know exactly what they’re getting. However, part of being frozen in time means any bugs, crashes, and hardware support are also frozen in time. The end result is that LTS releases will often have wildly outdated package versions, and those outdated package versions will most likely contain a ton of bugs and issues that have long been fixed in subsequent releases – subsequent releases you’re not getting, because you’re on an LTS release.
LTS releases are fairly stable and reliable as long as you use the most popular software from their included software repositories. So in the circumstances when this stops being the case, I think sometimes people can feel betrayed. They think, “I thought this was supposed to be stable! Why didn’t anyone fix this bug yet? Where’s my long-term support?”
But Debian, Ubuntu, and Kubuntu never promised any level of stability, reliability, or absence of bugs. They promised that the version-locked software in their repos would receive security fixes for a certain number of years. Ubuntu and Kubuntu also offered a certain amount of non-guaranteed best-effort hardware compatibility improvements and non-security bug fixes.
↫ Nate Graham
This causes major problems for upstream developers. People who use an LTS release will be using versions of packages that are out of date and full of bugs that have already been fixed in later versions, but they don’t know that, so they end up reporting these old bugs that have been fixed ages ago as if they’re new. If you’re an LTS user and you experience a persistent bug and subsequent crash in Kwin, you’re most likely going to complain at the Kwin developers, even if the Kwin developers have already fixed this bug 18 months ago. Every week there’s at least a few developers in my Fedi timeline rolling their eyes at Debian users reporting bugs fixed ages ago and getting mad when told they should complain at Debian developers for not backporting the fix.
So many LTS users seem to think that LTS equals increased stability, fewer bugs, and fewer crashes, but that’s just not what LTS is for or what it claims to offer. Sticking to specific (major) versions of packages means not you’re not only missing out on new features and changes – which might be desirable for you – but also on bug fixes.
With LTS, as they say, the bugs are also stable.
*nod* Bugs are stable, and so are workarounds.
This is why I mix Kubuntu LTS with Flatpak and have a custom script to only update nVidia drivers during a reboot so the kernel module and libGL don’t get into that “Can’t do 3D acceleration. Version mismatch.” state.
More or less “Anything which could require a reboot to fix/undo or which could introduce a new ‘crash back to login screen’ condition goes LTS. Everything else, when the upstream offers it, instead leverages how easy Flatpak makes it to roll back a buggy upgrade and pin an old version”.
(Speaking of which, I keep forgetting to look into why BasKet Note Pads isn’t on Flathub when so many other KDE applications are. If it were Flatpak easy to check the newest release and flatpak-builder easy to make new builds, I’d check if a bunch of usability regressions that slipped into 24.04 LTS got fixed and, if not, make my own patches… whether or not upstream wants to merge them.)
> Speaking of which, I keep forgetting to look into why BasKet Note Pads isn’t on Flathub when so many other KDE applications are.
Because it has 0 active developers. https://invent.kde.org/utilities/basket/-/commits/master?ref_type=heads
ssokolow, just in case I was too subtle : you could become upstream 😉 I’m already busy in KDevelop and Amarok.
Unfortunately, I’m struggling to make time to review PRs for my existing hobby projects.
Where you really see this is around opinions on Wayland. For the last few years, the Internet has been full of opinions about Wayland that were anchored to whatever packages the “stable” distros had settled on in the past. Things are much better now that many of these distros have released new “stable” or “LTS” versions that use much newer packages. But the effect is still there. I see complaints every day or claims that Wayland will “never” do things that it does perfectly well already on the systems that I use.
It is not just Wayland. That is just an example that stands out to me. Any new and rapidly developing software has this problem. A lot of the “common knowledge” around NVIDIA feels the same.
If the software is already mature, being locked into an old version may not seem that bad. But it really reflects poorly on software that has improved a lot since the last LTS. There is a reason most LTS distros exempt some packages (like web browsers) from the “stability”.
I’m glad you’re pointing this out in a way that people will understand, and you are right. I think the confusion comes from these distributions absolutely advertising and delivering stability. It’s just the _other_ “stable.” The package versions and thus configuration compatibility are perfectly stable in the same way ancient stone ruins are stable. They’re not livable, but all the unstable bits wore away centuries ago.
The kind of stability LTS releases provide is that of never having to drop into single user mode to fix a configuration that broke with the last update — because there weren’t any updates, only security patches.
Usually “stable” refers to the stability of the package repo/tree, everything else is a bonus.
“stable” should probably be rebranded as “predictable” or “consistent”.
Sadly human and dev nature means we value “new features” and “new for the sake of new” over stable. The same devs who complain about old bugs being raised are the same ones that prioritise new features. Why? They are much more fun and gratifying to work on. Especially when you’re working on this stuff as a free volunteer. A bug free project that hasn’t needed an update on two years is considered abandoned instead of done. So someone will remake it in rust.
@Adurbe
“Stable” in most of the Linux world really means static. I refers to the fact that things do not change (usually the version numbers) and does not really address behaviour at all. I guess you could consider that “consistent”. It does not at all guarantee that things will be “predictable”.
My biggest problem with stable distros is that I constantly see people that use them fighting against them. There is almost always something that is not there or too old that people want to work around. With the rise of Flatpak this is more manageable as Flatpak pushes those problems into a sandbox at least. Distrobox too. But I see plenty of people adding applications and dependencies to their systems that create all kinds of reliability and compatibility issues. Based purely on the way I work, I have spent far less time fighting my distro and fixing problems since moving to more up-to-date distributions (even, or maybe even especially, ones that people claim to be problematic due to their lack of “stability”). I am looking for a distro that “just works” and the stable distros never do that for me.
The fact that regular users started relying on LTS releases is a bit of an accident IMHO. The whole idea behind them was to provide enterprise deployment with a long-term stable environment to base their internally developed software on, avoiding the churn of continuous updates. I guess that’s still a use-case (otherwise RedHat wouldn’t be supporting extremely old distros) but for end users it is really a misnomer.