What a real LTS looks like: Kubuntu 26.04

Last year, Plasma developers canceled the long-term support (LTS) version of Plasma. Why?

We had a few reasons:

Almost nobody was using it; really only Kubuntu. Other discrete-release operating systems like Debian and openSUSE Leap generally ignored it.
It wasn’t a real LTS; we only backported some fixes for Plasma, and nothing for the Frameworks it was built upon, nor the Gear-aligned KDE apps it shipped with.
Our backporting of fixes was fairly blind since there weren’t CI resources to validate them, and nobody ever felt like testing them manually.

As a consolation prize for canceling the Plasma LTS product, we decided at the time to add an additional bug-fix release to the normal Plasma schedule, effectively lengthening the support period for each non-LTS Plasma version by 2 months — from 4 months to 6.

And as a result, there have been no Plasma 6 LTS versions.

…Until now!

Plasma 6.6 is now an LTS version. And not just Plasma 6.6 itself, but also a specific version of KDE Frameworks: 6.24, which will also receive backported bug-fixes. And Gear 25.12, too!

What changed?

It wasn’t a change to my or anyone else in KDE’s opinion of what a proper LTS product looks like. Rather, it was the Kubuntu Focus company stepping up to fund the creation of one, as announced today!

That’s right, Kubuntu focus is sponsoring a Plasma 6.6 LTS product for the next three years!

This consists of a couple of pieces:

First of all, Kubuntu Focus is sponsoring Techpaladin Software to fix bugs identified by Kubuntu 26.04 users. (full disclosure: I’m the CEO of Techpaladin Software). We’re not just backporting bug-fixes that happen to get made, but rather actively working with the Kubuntu folks to identify and fix pain points experienced by them and their users.

Plasma 6.6 will thus remain eligible for bug reports for the next three years, and we’ll do our best to get them fixed and backported.

Speaking of which, we’ll be backporting fixes for more than just Plasma 6.6 — relevant ones will also to Frameworks 6.24 and Gear 25.12, the versions that Kubuntu 26.04 ships with. The whole KDE part of the software stack!

Finally, Kubuntu Focus is sponsoring additional continuous integration resources owned by KDE e.V. to handle the load of validating changes made to these older versions. And they’ve been generous enough to sponsor more than was strictly speaking needed for the initiative, so KDE in general benefits from faster CI times even for non-LTS work!

We’re calling the whole thing the “Bullet-Proof KDE Initiative”.

This is what a real LTS initiative looks like, folks: people involved with an OS putting the resources into making a non-LTS upstream release into an LTS one, properly. With bug fixes — not just security fixes — backported to all levels of the software stack, not just the top one.

So I predict Kubuntu 26.04 promises to offer the best KDE experience of any Kubuntu release ever!

I know a lot of folks really enjoyed Kubuntu’s 24.04 release because of how it lined up with Plasma 5.27, which we made an LTS release for an extended period of time during the Plasma 6 transition. Well, this is the same thing, only with a great version of Plasma 6 included, and supported for even longer!

Aha, so you’re a sell-out who changed his opinions about LTS due to money!

My opinion remains the same: I don’t dislike LTS products — only fake ones that promise support but don’t actually deliver it. With this initiative, users of Kubuntu 26.04 get a real LTS product, with real support backed by a pair of commercial companies.

So this is all a commercial thing? KDE gone korporate?

It’s largely a commercial initiative between Kubuntu Focus and Techpaladin Software, yes — though KDE e.V. has signed off on the initiative and agreed to accept funding for the new CI resources.

Both companies are good citizens in the KDE ecosystem: KDE e.V. patrons, employers of engineers you’ve heard of, and providers of hardware and services to users of KDE software.

And the benefits accrue far beyond just the companies. Obviously Kubuntu 26.04 users benefit, even those who didn’t buy a computer from Kubuntu Focus. And as I mentioned earlier, all of KDE now has more general-purpose CI resources. Also, many of the LTS bugs that Techpaladin people have already fixed were affecting people on later Plasma versions, too! Everyone wins here.

So the commercial part is not a limitation on what anyone else gets for free or is allowed to do; it’s just an acknowledgement that creating a real LTS product costs money.

Wow, really cool! How can I help?

Anyone in the wider KDE community who’s interested in this kind of thing should feel comfortable backporting important and safe bug-fixes to the stable branches for Plasma 6.6, Frameworks 6.24, and Gear 25.12. There will be a Kubuntu CI runner that makes sure nothing breaks (at least, nothing that’s tested in the CI! So keep that test coverage high).

And if you happen to run discrete-release OS and would like to get in on the action, feel free to ship Plasma 6.6 and invest some of your own resources into it! It will be very welcome to see more people fixing bugs reported by LTS users that are still present on master, or backporting more recent bug-fixes to the LTS version. Again, everybody wins here!

Legal obligations vs social contracts

My post about responsibility for bug reports on old software versions the other day stirred up quite some discussion, and I wanted to drill a bit more into what I think is the crux of the dispute: the difference between legal obligations and the social contract.

When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: “make the source code available,” “don’t change the license,” and so on.

You might also notice the absence of a warranty, or silence about responsibility for bug reports.

So let’s return to the question:

Who’s responsible for bug reports on old software versions?

An accurate legal reading is “Nobody, unless you’ve signed a work contract with a developer or purchased a commercially-sold OS.” But it’s also not the whole picture, because there’s another potential non-obvious legal obligation:

Trademark

Trademark law varies across the world, but at least where I live in the USA, “unregistered trademarks” are a thing, and in a professional context, you’ve got a legal obligation not to violate a product’s trademark — registered or unregistered — by referring to it as something that it isn’t, or changing it and saying it’s still what it originally was.

Ah, but how much to you have to change it before that kicks in? That’s definitely not something that I — a non-lawyer — am qualified to assess. And my understanding is that this varies a lot across the world’s legal regimes, too.

But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer’s own bug fixes) probably doesn’t count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.

Which brings me to what I think is the most important part:

Doing only the legal minimum

“Follow the terms of the license agreement.” “Don’t mis-represent trademarks you don’t control.” “Don’t steal.” “Don’t murder.”

These are good places to start. But what if that’s all anyone ever did — the bare legal minimum?

I think the world would be a pretty miserable place. There’s no law requiring anyone to love you or soothe your feelings when you’re upset. There’s no law requiring you to find a source of joy or direction in life, or help others unbidden.

What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.

Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you’ll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.

Applying the social contract to this situation

Let’s say that I write an app, and someone distributes it with a feature patched in that I didn’t write, or a visual change that I didn’t make. How mad at them am I going to be?

If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they’ve created what I believe to be a derivative work that reflects poorly on the original.

No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.

But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I’ll even reach out and ask them to submit their change upstream and help maintain it. There’s a 0% chance I’m going to threaten to invoke trademark law or give them a hard time about it.

That’s the power of respecting the social contract that exists between us.

But what is the FOSS social contract?

Like the definition of “derivative work”, it’s unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can’t contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the “FOSS social contract”:

Using FOSS

If you didn’t pay any money, appreciate what you’ve gotten for free. It’s a modern miracle.
Understand the basic software lifecycle of the OS you’re using, and choose the one that suits your needs the best.
Accept the “no warranty” clause. Understand that support may be slow, and that if you need it fast, you’ll need to pay for it.
If you don’t like the software you’re using, use something else.

Bug reporting

Endeavor to report bugs in the right place, to the best of your ability.
Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.
Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.
Treat people kindly with the benefit of the doubt, even if they don’t respond to your bug report in a timely manner, or at all.
If your needs are urgent, pay a person or company to address them; don’t make demands of people working for free.

Software development

Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
If you aren’t distributing your own software in a way that’s suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren’t doing it in exactly the way you would prefer.
Work with your distributors to help them showcase your software in the best light. They don’t know it as well as you do.
Don’t piss off too many of your users. You’re doing this for them, not just for yourself.
Only make your software publicly available via a FOSS license if you’re willing to accept people using it or distributing it in ways you might not have expected or preferred.

Software distribution

Do your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.
Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.
Clearly communicate your OS’s software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.
If you meaningfully change the software you distribute (outside of backporting the developers’ own bug fixes or similar), accept that you’ve created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).
If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own, or remove it entirely if you don’t have the resources to offer support for old software.
Only create an OS in the first place if you’re willing to take responsibility for the support needs of the people who will use and depend on it.

Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We’d end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it’s my hope that we can all aspire towards these ideal with our actions and words.

Who’s responsible for bug reports on old software versions?

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn’t as critical.

Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.

Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.

If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.

This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.

But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.

So a way to make this approach more feasible is to reduce your OS’s scope of concern.

For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.

It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.

What’s not the solution?

Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.

This is the worst of all worlds!

Users get outdated software that’s full of bugs and security holes fixed long ago
Software developers get un-actionable bug reports from angry and confused users
Distributors get frustrated communications from software developers that damage or destroy important relationships

Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.

How do I know this?

Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:

In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.

In 2026, they’re up to 71%.

This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.

So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.

“Long-Term Support” doesn’t mean what you think

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:

Debian Stable says:

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.

Ubuntu says:

LTS stands for long-term support — which means five years of free security and maintenance updates

Kubuntu says:

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.

Start with Fedora KDE or Kubuntu

I regularly read questions from new users on Reddit and KDE’s discussion forum asking what Linux-based operating system they should start out with, or asking for help after choosing an unsuitable one.

Inspired by a recent example on Reddit, I decided to write this post for them.

Not for you, O advanced reader who is happily using NixOS, Gentoo, or Hannah Montana Linux! If you’re content, I’d encourage you to do something more useful with the next five minutes of your life. These minutes are for for your friend who’s currently using Windows.

A major problem our corner of the world faces is that there’s absolutely terrible information about which Linux-based operating system to choose when you’re ready to make the move:

https://distrowatch.com/ shows approximately five billion options and provides no real guidance for making a decision.

Asking “what Linux distro should I use” to a search engine, an AI, or YouTube returns a veritable graveyard of bad advice, link-spam blog posts, and interactive “help me choose a distro” websites that will steer you wrong 100% of the time.

Famous YouTuber Linus Sebastian has probably made tens of thousands of dollars repeatedly and somewhat hilariously choosing bad options in front of a camera.

With so little to go on, people can be forgiven for making bad choices. So today I’d like to share my personal recommendations — at least for KDE-centric options! KDE maintains https://kde.org/distributions/, which includes four pretty good ones. But I’m going to be bold and recommend only two of them:

Choose Fedora KDE or Kubuntu

Both Fedora KDE and Kubuntu share a lot of positive traits:

Secure Boot is supported, so you can install them on devices that ship with secure boot enabled (which is most sold in the 15 years or so).
Included software repositories are large, so you’ll probably be able to get most or all of the apps you need without having to add third-party sources.
Software from their built-in repositories is updated reasonably quickly, meaning newer hardware and software are generally well-supported. For Kubuntu, this is only the case if you upgrade every 6 months rather than sticking with the LTS versions, so do that!
Their developer communities do real QA to ensure that users are protected from most short-term and major regressions from upstream.
Their user communities are large, with good documentation and support resources.
KDE software is well-integrated and offers a good experience, with nothing obviously missing or broken.
Their core package management systems are robust and integrated well into KDE’s Discover software center app.
Popular proprietary software and media codecs are easy to make available during initial installation or setup, and don’t de-stabilize the system as a result of doing so.

There’s just a lot to like here.

But are Fedora KDE and Kubuntu perfect? No. In particular, both are made from mutable packages assembled on your system. This means:

If a system upgrade gets gets interrupted in the middle by a power cut or hardware failure, the system can end up unbootable without intervention by an expert.
Without manual maintenance, long-term installations can end up drifting out of sync with what a new installation would provide, introducing weird issues that are hard to debug.
Adding third-party software repositories is tempting but unsafe, and can introduce package conflicts that render the system unable to update without intervention by an expert.
If you tinker too deeply without knowing what you’re doing, you can accidentally damage these systems in a way that requires intervention by an expert to repair.
Major system upgrades take a long time to complete, with multiple reboots (as long as you keep the “offline updates” feature turned on, which is at least a bit safer than in-place updates).

So, not perfect. But, I think, good enough.

What about the immutable OSs? They solve those problems!

Indeed they do! For whose who aren’t familiar, there’s a new crop of operating systems on the horizon, so-called “immutable” OSs — a terrible term since it implies they’re completely locked down and unchanging, which are not the case.

These operating systems offer some form of a read-only core OS, plus various mechanisms for overlaying software on top of it while preventing the core from being damaged over time. This improves safety around system updates in particular.

Practical options here include Aurora, Fedora Kinoite, Bazzite, Kalpa Desktop, and KDE’s own in-progress KDE Linux. Valve’s highly-successful SteamOS is also in this category, though as of early 2026, it’s not yet intended for general-purpose usage on arbitrary hardware the way the others are.

I feel as strongly that this model of operating system represents the future as I do that said future has not yet fully arrived for everyone.

The truth is, while these OSs solve many longstanding problems in traditional package-based operating systems, they also also introduce a plethora of difficult-to-avoid rough edges and paper cuts for general use. Those who work on these OSs need to smooth out those rough edges before their work can go mainstream. I’m personally involved in an effort to do so for KDE Linux, and I’ll be the first to admit it’s not there yet.

But I don’t like Fedora KDE or Kubuntu!

If you already have a preferred OS, you’re not in the target audience for this article. 🙂 You’re opinionated and competent enough that you can probably make anything work, and whatever you’ve ended up using likely perfectly suits your own personal tastes.

New users have none of your skills or opinions; they need a general recommendation for something that’s good enough, safe enough, and not too weird. That’s what I’m writing about here.

To be clear, I’m not saying other Linux-based OSs are bad. On the contrary, many are great, and better in a lot of ways than the two I’ve mentioned. Fedora KDE and Kubuntu have other annoyances beyond just “being made of packages” that I wrote about earlier: neither sets up any kind of emergency rollback system by default; their tentative forays into the realm of Snap and Flatpak as additions to their traditional packages complicate things unnecessarily; and I don’t love their goofy wallpapers. These operating systems could be even better for sure.

But whaddaya gonna do, nothing’s perfect. What I’m saying here is that I think these two are good enough to be the best choices for new users in the KDE world.

Well OK, but why should I listen to you, anyway!?

Ideally you shouldn’t; you should do your own research and make your own decisions. But that can be hard if you’re starting from square one and you don’t know what to look for!

So I’d say the important part is to look for other options out there that share the same traits I wrote in bold text in the “Choose Fedora KDE or Kubuntu” section. Those are what will make a Linux-based OS easier and more comfortable to adopt.

But no matter what you choose, have fun and see it as an adventure! Switching your operating system out for another one is something most people will never do; you’re automatically an interesting person for even making the effort.

If you run into problems, ask humans for help. Don’t ask AI, and don’t go looking for personal workarounds that will only benefit you and might break in the future. Be a part of the community; learn and grow, and help others do the same.

Good luck!