My last post about good beginner-friendly KDE-focused operating systems sparked some discussions about the concept of “Long-Term Support” (LTS) releases.
But what does this term mean? It’s a bit generic-sounding, making it easy to interpret as meaning almost anything. So let’s go to the source: how the term is defined by the operating systems using it! Here are the non-commercial ones:
Security updates are provided by Debian security team for three years. This generally means that each stable release is supported for its whole life plus an extra year (or so) after a new version of stable is released. In addition, further security support is provided by the LTS and LTS/Extended projects.
LTS stands for long-term support — which means five years of free security and maintenance updates
The latest Long Term Support (LTS) version of the Kubuntu operating system for desktop PCs and laptops, Kubuntu 26.04 [is] supported with security and maintenance updates, until April 2029.
(I didn’t include openSUSE Leap because its marketing material doesn’t use this term, though what it offers is fairly similar in practice)
So these operating systems are fairly consistent about what “Long-Term Support” means to them:
- Each discrete OS release will continue receiving updates for a certain number of years.
- Those updates will include fixes for security issues.
- Those updates may include whatever “maintenance” means; Ubuntu & Kubuntu promise this, Debian doesn’t say.
- Those updates will not include any new features, UI improvements, or other non-bug-fix releases from the software’s developers. That is to say, each piece of software is effectively locked to a specific version for the life of the release.
That’s it! So let’s look at what’s NOT promised:
- Lack of bugs
- Lack of crashes
- Fixes for non-security issues
- Personal support for issues you encounter
- Support for newer hardware devices (Ubuntu offers “hardware enablement” kernels for desktop installs by default, but they come with no stated guarantees and don’t cover the parts of hardware support that go beyond the kernel)
That doesn’t mean an LTS release of Debian, Ubuntu, or Kubuntu will be devoid of these things. It just means they aren’t promised. Probably you’ll get a lot of them anyway, but there’s no guarantee.
I think this is where some of the persistent confusion around the LTS topic comes from.
LTS releases are fairly 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 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.
That’s it!
So it’s important to understand what you’re actually getting with an LTS-style OS. And maybe it’s not for you. There are plenty of other options for people with different desires:
I want newer software
If you’re a software developer or a technology enthusiast, you may want to get software on or closer to its developers’ release schedules. This will give you a stream of new features, UI improvements, and fixes for bugs. In this case, the better option is a rapidly-updating OS like Arch Linux, openSUSE Tumbleweed, Fedora KDE, or one of their children.
The trade-off here is that you may have to live with some things that are currently working getting broken after updating. In other words, the bugs are unstable, unlike in an LTS OS where the bugs are stable.
I personally fall into this group, which is why I use a rapidly-updating OS and not an LTS OS.
I want fewer bugs
I think a lot of people choose an LTS OS to experience fewer bugs, but this is generally not a strength of the LTS product. When an LTS OS freezes on a specific set of software, all the bugs in those versions of the software are frozen, too. Unless the LTS OS provider fixes any of those bugs themselves or backports fixes for them, users will be exposed to them for the lifetime of the release.
With a rapidly-updating OS, when software developers fix bugs in their software, you’ll get those bug-fixes quickly. As long as the software itself is becoming less buggy over time, a rapidly-updating OS shipping software close to its developers’ release schedules will likewise become less buggy over time.
It’s not all puppies and rainbows, though. A fast pace of change means more opportunities for those developers to accidentally introduce new bugs, and also for the introduction of integration issues: bugs caused by software being mis-configured or incompatible with other software. LTS OSs excel at minimizing integration issues between software, because a frozen set of software isn’t a moving target for QA testing.
So in a lot of ways, this choice boils down to whether you’re more bothered by software bugs or by integration issues.
I want better hardware support
If the manufacturer of your device didn’t provide much or any Linux software support for it, a rapidly-updating OS is likewise a better option here. You’ll quickly get all the components that improve hardware support, not just the parts in the kernel.
I want a true reliability guarantee
If time is money for you, this makes sense. And to get it, you’ll need to pay for a commercially-supported operating system. For example, Canonical offers “Ubuntu Pro” with a level of support that includes the following:
Build with confidence with 24/7/365 phone and ticket support. Get prompt help when something breaks on any of the packages in the Ubuntu Main and Universe repositories, including the most widely used open source applications and toolchains. Our 24/7 plans now include SLAs not only for initial response times, but also for ongoing follow-up updates ensuring continuous visibility and faster remediation throughout the lifecycle of your support case.
Wow! Now that’s support. It costs $300 per year for workstations (servers are over 5x as much).
Red Hat and SUSE offer similar services at similar prices.
And they aren’t cheap! But if time is money, those prices may look pretty reasonable. And you’ll get to talk to a perky and friendly person over the phone when you encounter a covered problem, and someone will to take direct responsibility for getting a fix delivered.
What about Flatpak and Snap?
In principle, these technologies allow an LTS-style OS to offer the best of both worlds: a stable base with apps updating more rapidly.
In practice, what you get is a mixing of both worlds. The base OS retains its LTS characteristics, while apps become rapidly-updating, giving you some exposure to breakage coming from new versions alongside more features, UI improvements, and fixes for existing bugs.
We’re spoiled for choice in our ecosystem, which means everyone can find a free software operating system that matches their needs and desires. But you have to know what those needs and desires are, and also successfully map them to the available options! Hopefully this blog post has helped explain what the LTS-style operating systems offer, and who should use them.
Adventures in Linux and KDE 
Although it’s difficult to define “LTS” in brief, I think the details matter a lot, and I think a lot of your readers are getting the details wrong. On two points, it’s important not to infer the inverse from the distribution’s statements.
> Those updates will include fixes for security issues.
Updates to free LTS distributions will include security fixes, but not all security issues will get fixes.
> Those updates will not include any new features, UI improvements, or other non-bug-fix releases from the software’s developers
Free LTS distributions don’t promise any new features, but they also don’t promise “no new features.”
Regarding security:
Updates will typically include the most critical security issues for the most common packages, but the labor required to issue security fixes is limited, so users should not expect full coverage. Important packages might not get patches for less important issues, and less important packages might not get ANY patches at all.
That’s important for KDE and their users, because Qt appears to fall into the distribution’s definition of “less important” packages. Both Debian 12 and Ubuntu 24.04 were affected by CVE-2023-51714 and CVE-2024-36048. Qt published a patch for each of those issues, but neither distribution fixed either one.
Ubuntu is a little more clear about this than Debian. On Ubuntu, KDE and Qt appear in the “Universe” component, about which Canonical says, “Canonical does not provide a guarantee of regular security updates for software in the universe component.”
The vast majority of software on an Ubuntu system is in the “Universe” component, where even security fixes aren’t expected. Debian doesn’t differentiate, so users have less information about what to expect, but we can infer their prioritization based on the lack of patches .
Regarding features:
Free LTS distributions tend to be very conservative about feature updates, and while upstream projects are still maintaining the components they ship, feature updates will be infrequent. As time goes on, it becomes more difficult to patch security issues without upstream support, and feature updates will become more common.
Debian users can read the NEWS posts that accompany minor releases for information about updates, including feature updates.
https://security-tracker.debian.org/tracker/CVE-2023-51714
https://security-tracker.debian.org/tracker/CVE-2024-36048
https://help.ubuntu.com/community/Repositories
https://www.debian.org/News/
LikeLike
The classic example is wine. There is really never a point to use a “stable” release of Wine instead of the development version.
The other idea of course involves around breaking user space.
If not coding, could AI help us to get more tests, do better static analysis? could it help to analyse crash reports?
Do we need more rich crash reports?
Coining somthing like “Real stability”.
LikeLike
I think LTS versions are seen as having fewer regressions. Many people aren’t expecting anything because it’s already working well overall.
As a result, updates are seen solely as a potential risk of regression and nothing more. It’s therefore not surprising that they are reluctant to accept them.
LikeLike
For the context of the article, yes, that’s all true. Just a shame that you focused on Debian, Ubuntu and Kubuntu, as if that’s what defines the Linux ecosystem. It doesn’t.
Debian LTS is mostly a joke, when a release becomes “LTS” its maintenance moves to a different, much smaller team than the one which manages the current version. What bugs the LTS team may or may not fix is also mostly up in the air. So yes, expecting more stability from Debian LTS is unrealistic.
On Ubuntu (and all the other *buntus), LTS means LTS packages (which is a small subset of all the distro packages, packages which mostly directly come from Debian) are frozen and during the support period bugs may or may not be fixed. Which, again, you are correct in pointing out that this doesn’t necessarily mean less bugs.
But that’s the Debian side.
On the Red Hat side (which unfortunately you only mentioned when talking about support fees), things are slightly different. Fedora is the cutting edge distro which sees latest packages and rapid updates, which means there are issues occasionally (although nowadays pretty rare).
Fedora snapshots which have shown to be stable end up in CentOS Stream, which sits downstream of Fedora and upstream of RHEL. This is where remaining bugs are fixed and CentOS Stream also sees frequent updates to get those fixes out. As a consequence, CentOS Stream is very stable and it’s no surprise that Meta runs its infrastructure on it.
Lastly, specific CentOS Stream releases are then selected to become the next RHEL release. At which point they have seen at least three levels of testing and bug fixing. What ends up in RHEL is rock solid, and yes, users can and do to see a lot less bugs from this “LTS” version.
This is also true for all the RHEL clones.
The other difference is that Red Hat doesn’t just fix bugs, they actively back-port new features into older packages so even though a package’s major version number remains unchanged.
As a developer, I find the RHEL side of Linux much more stable than the Debian/Ubuntu side, also because all the LTS distros (RHEL, Rocky Linux, Alma Linux, Oracle Linux) are essentially the same and don’t require all the individual adaptions that are necessary with Debian based distros.
LikeLike
Maybe, what we are seeking is not actually LTS or stable immutable OS, but something like a Vanilla Kernel. A Kernel plus the essential rest, that would itself be a single Kernel package but maintained as a whole.
Yeah. maybe we need a Kernel+ project and package. If all systems use systemd why shouldn’t it be considered an extended Kernel, same for core utilities. Kernel+ would then be shared by all Linux distros, subdistros so to speak.
LikeLike
This is largely what KDE Linux intends to become: a small base system consisting of a bootloader, kernel, systemd, and device drivers. All the GUI software would then be delivered by the in-development “flatpak-next” version of Flatpak, which looks like it will resolve all the issues we have with the current implementation.
LikeLike
Not to mention that with Bootc (and previously RPM-OSTree) you have atomic updates and rollbacks.
LikeLike
I mostly agree with @Aubergino but one thing is not mentioned: RHEL’s repositories are tiny compared to Fedora’s, let alone Debian’s.
If you use EPEL (which is a great 3rd party repo) or similar you’re breaking the LTS promise again.
Also, Debian is a community of developers: the security and bug fixing is made by volunteers, so you can’t expect the level of thoroughness provided by the likes of RH, Canonical or Suse, especially if you take into account the size of the supported repositories.
Full disclosure: I’ve been a Linux SysAdmin for 20+ years, mainly working with RHEL derivatives (CentOS, Alma, Rocky) but also some Ubuntu/Debian. In the desktop I have used (personally and professionally) Slackware, Debian, SuSE (before the split SuSE/openSuSE), Kubuntu, Slackware again, and now Fedora since a couple of years.
LikeLike
Although not mentioned here, FreeBSD does actually provide updates of the style that Nate is asking for (KDE is within its ports system), while also providing a stable operating system base.
Definitely would not recommend it to beginners, however it is very nice if you have compatible hardware and are experienced. Debian testing is slightly similar.
It is definitely fair to point out that LTS releases do not fix bugs. Debian’s current stable version has a bug in sddm preventing you from unlocking your screen, and it has not been fixed.
LikeLike