Month: May 2026

This month in KDE Linux: May 2026

Welcome to another edition of “This month in KDE Linux” — KDE’s in-progress operating system.

Infrastructure

This month we completed a major infrastructure project. Previously, our build process was generating Arch packages for KDE software and having mkosi install them; Hadi Chokr ported this to use KDE’s kde-builder tool to compile all KDE software directly. This change brings three benefits:

  • Better alignment with how developers compile KDE software themselves.
  • Improves distro-agnosticism, so we can more easily get non-KDE software from a different source in the future should the need arise.
  • Substantially faster by using a more effective caching system.

QA & testing

Another major focus this month was on improving KDE Linux’s automatic QA story. The project already has a basic “does it boot to the desktop?” test for every build, but we can do much better.

To that effect, Bhushan Shah and Thomas Duckworth worked on finishing up the OpenQA-based testing system prototyped by Kangwei Zhu last year. Once fully integrated, this promises to hugely improve our ability to catch bad builds before they’re released, and we can update it over time to catch even more failure conditions.

Harald Sitter also added a test using the existing system to make sure we don’t ship an image with broken file capabilities. We did ship one bad build that includes a regression here, so this new test ensures that it won’t happen again.

Security

After multiple security issues were discovered in the upstream Linux kernel last month, a few of us (Adrian Vovk, Hadi Chokr, and I) did a mini-audit of insecure and unused software included in KDE Linux. This resulted in a variety of positive changes:

Pre-installed apps

I implemented a service to install any new pre-installed Flatpak apps on people’s existing systems. It ignores any apps you’ve previously uninstalled manually.

Speaking of new Flatpak apps, I replaced KWalletManager and its configuration page in System Settings with the new KeepSecret app, packaged using Flatpak.

I also updated Ark’s nightly Flatpak packaging to include 7-zip support and generally synchronize it with the Flathub version.

Documentation

I migrated the project’s website and documentation to https://linux.kde.org, where everything lives now. I also added a few more pages.

Grab bag

Hadi Chokr set up /opt/local for being a supported location for installing compiled binaries. This is because the usual /usr/local location is read-only on KDE Linux. This is now documented here.

João Pedro Silva Sousa fixed a bug that could make installation fail if there happened to be two KDE Linux live USB disks plugged in at once.

And that wraps up May! There’s still lots to do, so if you’re a fan of the project, please help out:

“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:

  1. 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).
  2. 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.
  3. 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!
  4. Their developer communities do real QA to ensure that users are protected from most short-term and major regressions from upstream.
  5. Their user communities are large, with good documentation and support resources.
  6. KDE software is well-integrated and offers a good experience, with nothing obviously missing or broken.
  7. Their core package management systems are robust and integrated well into KDE’s Discover software center app.
  8. 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!

KDE email, part 3: don’t filter your email

This is part 3 in my series about email management, with the prior one being about using email client apps. This one is about trying to use email filtering to handle email overload.

You’re getting too much email

It’s a flood — no, a deluge! Hundreds of messages a day. Overwhelming. Demoralizing. Soul-crushing. The thought of even looking at your email provokes anxiety.

What to do?

Email filtering to the rescue! Use sieve (KMail even includes an app for it!) to implement a bevy of server-side filtering rules that send emails to different folders. So neat and tidy. So clean. So organized. So much better… not!

Filtering doesn’t work

You started with the problem of “I get too much email to comfortably handle”. With filtering, you’ve split up the “too much email” into multiple folders, but all those folders put together are still impossible to comfortably handle.

You may have told yourself that this system helps you prioritize, because the most important emails go to your inbox.

But it’s not true; an email’s importance can have much more to do with its content than the characteristics you’re probably using for filtering (sender, mailing list ID, subject line, etc).

For example:

You commented on a bug report, and then someone else replied to your comment with a question. The email notifying you about their reply got filtered into oblivion, so you missed it, and now that person thinks you’re rudely ignoring them, or negligent, or incompetent. That’s damage both to your reputation, and to KDE’s. This is what leads people to whine “KDE doesn’t care!” on social media.

Also, the properties you filter against change over time, which means mail filtering requires maintenance to keep the important emails in your inbox — maintenance that you’ll eventually tire of doing and neglect.

Which means some important emails will still be shunted away to folders you aren’t checking regularly. Which means you’re still missing them. Which means filtering hasn’t solved the problem of missing emails and being perceived as unreliable or rude.

I get it. Filtering is tempting. But it’s just covering up the actual problem. There are only three real solutions to “too much email”:

1. Spend more time processing emails

For a busy professional like you, email is a task list that other people can add items too.

This is terrible, but it’s also a professional obligation, so you need to block out time to handle those tasks somehow. Yet spending tons of time on it will burn you out!

So minimize this to only what’s absolutely necessary to avoid your inbox becoming more full over time. Make the “number of emails in the inbox” trend-line negative. Which means you need to…

2. Get fewer emails

Every minute you put into reducing emails will pay you back 100x over the next few years.

  • The project you’re regularly working on or monitoring via a website? Turn off email notifications; you’ll see stuff on the website.
  • That mailing list for a project you haven’t had any involvement with in years? Unsubscribe.
  • Merge requests for a project you’re only tangentially interested in? Un-watch in your notification preferences.
  • Notifications about things happening in real-time? Switch to a daily digest in your email preferences, or unsubscribe and set aside a time to check that thing manually.
  • Marketing emails for literally everything? Unsubscribe.
  • News? Unsubscribe unsubscribe unsubscribe! You’ll learn about anything important in another way.
  • Emails about bills and payments you have to make? Put them on auto-pay, then delete the “payment submitted” emails without even looking at them.

And so on. In the “email as task list” model, you have to reduce the number of people, groups, and companies who can assign you email-tasks, or you’ll go mad. Do it, do it now!

C’mon, kill those emails!

3. Increase speed of processing emails

A key part of this is using an email client, which I wrote about earlier. Learn your tools! Use keyboard shortcuts. Aggressively delete and archive emails after you handle them. I like automatic color tagging, which I wrote about back in 2024. There are lots of techniques to process emails faster, and I’ll write about some of them later.

But focus on solving the problem, rather than hiding it.

The important part is to see email as a job skill you can commit to getting better at, just like programming, debugging, or source management using git. Don’t accept that you suck at email, give up, and hide the problem under the rug. Get better! Filtering is a tool that holds you back and prevents you from learning stronger email management skills.

Ditch the filtering habit. It’ll be hard at first, but you can push through that and solve the real problems of too much email, un-optimized workflows, and fear of managing email due to lack of the first two.

You can do it! I believe in you!

This month in KDE Linux: April 2026

Welcome to another edition of “This month in KDE Linux”!

Infrastructure remained a major focus this month, with multiple outages and bugs in Arch’s package archive leading to Harald Sitter creating a local mirror for KDE Linux. This substantially increased build delivery reliability.

Harald also worked on improving the speed of delta updates. This is experimental and in-progress, so you have to opt in; See the bottom of https://community.kde.org/KDE_Linux/Delta#Status

Beyond that, a number of features are under development but did not quite complete yet, so expect to hear about them next month.

This month, Hadi introduced a terminal handler to prompt you to add execute permissions to scripts lacking it when you try to run them:

Hadi also moved our console handling to the newer userspace Kmscon software, which we’re using in place of the built-in console from the Linux kernel. Text looks way better now!

Thomas Duckworth implemented screen reader support for the installer.

Jonas Harer and Daniele Me made the default zsh config even better. It really is a joy to use now!

Aidan turned on IPv6 privacy addressing by default, improving privacy a bit when using IPv6 connections.

I made KDE’s ksshaskpass dialog be the thing that prompts you for the password to unlock your encrypted ssh keys, which also allows you to have it save them in the system’s password storage system if you’d like. I also simplified the process of setting up an ssh agent to automatically add your keys, and documented how to flip the final switch to turn it all on.

I also documented how to persistently change kernel parameters, in case you need some extra ones (for example, turning on the experimental Xe driver for your newer Intel GPU).

Finally, I flipped the switch to have KDE Linux use the new Union theming system by default for QML apps. If the results in non-Flatpak QML apps like Discover, System Settings, Info Center, and Emoji Picker look no different… that’s perfect!

That’s all for April, folks! I’ll see everyone for the May report, or ideally, sooner. Because, as you can see, while KDE Linux is being developed by multiple people (good for project health), the number of changes is a bit low (bad for project velocity). There’s plenty to do, so if you’re a fan of the project, please help out:

And if you’re already using KDE Linux, let us know how your experience has been! Is it good? What can we do better?