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, openSUSE Kalpa, 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?

KDE email, part two: use an email client

One of the many benefits of going to in-person sprints is you get to see how other people use their computers, and you can learn some workflow tricks from them. Or, you might notice areas of inefficiency and share tips of your own.

This post will be about the latter, on the subject of email.

Because during the sprint, I observed multiple people using email on their laptops in ways that are slow or ineffective:

  • Logging into webmail in a web browser
  • Switching between multiple webmail sites to manage multiple email accounts
  • Clicking on buttons in the webmail UI to delete or reply to messages

If you recognize yourself here, there’s a better way, I promise. 🙂 And I’d like to help you achieve it!

Back in 2024, I wrote about my email workflow and offered some general tips for managing email overload in KDE. I’m going to write more in depth about this topic, today starting with…

Use an email client app.

KDE has one: KMail. If it works well for you, use it! If it doesn’t, use Thunderbird instead, it’s fine. Don’t feel guilty for not using a piece of KDE software. Nobody’s gonna excommunicate you from KDE! I’m officially giving you permission.

Maybe you use an email client on your desktop but haven’t set one up on your travel laptop yet? Well, it’s time!

Because the important part is to consistently use an email client app of some sort. Why?

Way better for multiple accounts

Most of us have 2 or more email accounts. With webmail, this becomes a pain that scales linearly with the number of accounts.

With an email client app, you can manage multiple accounts’ worth of emails in one UI. When all your accounts are managed from one app, your brain doesn’t need to learn and remember multiple UIs, and and opening new email accounts doesn’t scale the mental burden at all.

Faster to use

An email client app lets you interact with emails using learnable and consistent keyboard shortcuts. Processing emails this way is super fast, so you can get done quickly and go back to something useful. Email sucks; life’s too short to waste time on it.

Easier to access

You can access the email client app easily using the Task Switcher, Overview, or Alt+Tab, rather than letting those webmail tabs get buried among your 75 normal browser tabs and 10 pinned tabs.

Easier to leave email mode

Quit the email client app when you want to stop receiving emails.

For webmail, you’re tempted to leave it open in a tab forever, which means to avoid being constantly tortured with email notification, you’ll have to turn them off entirely, so you stop noticing emails when they arrive. This is problematic for the “keep my email open all day” approach where the whole point is being able to action new emails immediately so they don’t pile up.

Using an app that can be turned off also facilitates being a “check email once a day” kind of person, if that’s your jam. Open the app, check your email, action the important ones, delete or archive all of them, then close the app. You can carve out 5-20 minutes for email, be free of email for the rest of the day, and still keep on top of everything!

Using good tools is enjoyable

Imagine trying to manage versions or debug code without git or gdb. It would take ages and the results wouldn’t be as good. Proficiency with these tools makes you feel like a bird soaring above the clouds or a wizard effortlessly wielding powerful magic, not some clod stumbling around in the mud.

Email clients are the same way. Learn powerful tools to bolster your professional skills and feel better about the process of participating in KDE, not just the outcomes.

The Thunderbird email client is the foundation of my email system. In conjunction with other techniques — which I briefly described in the earlier post and will flesh out in more detail over the coming weeks — this is currently my email situation:

Thunderbird email client window showing not too many emails

Those are all of my emails across 5 accounts. Here are just my KDE emails:

As you can see, this is completely manageable. It takes practically no effort to keep it this way, and there’s no feeling of dread when checking emails in the morning. If you’re drowning in email, you can get here too, I promise.

It starts with using an email client. If you aren’t regularly using one yet, it will take some up-front work, and some re-training, but it’s worth it: you’ll spend less time and mental resources on email and more of it on what actually matters — without taking the easy path of neglecting email and being perceived as a person who’s hard to contact or unreliable.

So get started today with KMail or Thunderbird!

Analyzing KDE Project Health With git!

I was reading the latest edition of Kevin Ottens’ excellent weekly web review and one particular article caught my eye: “The Git Commands I Run Before Reading Any Code“. In a nutshell, you can use the git version control tool to quickly assess a project’s health, what breaks, who’s a key figure, how bad emergencies are, and so on.

So useful!

I immediately wanted to apply this to KDE projects. So I took the commands from the post and made some shell aliases and functions for convenience:

# git repo analysis tools
alias what-changes="echo 'What changes a lot?' && git log --format=format: --name-only --since='1 year ago' | rg -v 'po$|json$|desktop$' | sort | uniq -c | sort -nr | head -20"
alias what-breaks="echo 'What breaks a lot?' && git log -i -E --grep='fix|bug|broke|bad|wrong|incorrect|problem' --name-only --format='' | sort | uniq -c | sort -nr | head -20"
alias emergencies="echo 'And what were the emergencies?' && git log --oneline --since='1 year ago' | grep -iE 'revert|hotfix|emergency|urgent|rollback'"
alias momentum="echo \"What's the project's momentum over the past 5 years?\" && git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c | tail -n 60"
alias maintainers-recently="echo \"Who's been driving this project in the past year?\" && git shortlog -sn --no-merges --since='1 year ago' | rg -v 'l10n daemon script' | head -n 30"
alias maintainers-alltime="echo 'And what about for all time?' && git shortlog -sn --no-merges | rg -v 'l10n daemon script' | head -n 30"
function repo-analysis {
    what-changes
    echo
    what-breaks
    echo
    emergencies
    echo
    momentum
    echo
    maintainers-recently
    echo
    maintainers-alltime
}

Now let’s run it on Plasma. Here’s plasma-workspace, the core of Plasma:

$ git clone ssh://git@invent.kde.org/plasma/plasma-workspace.git
$ cd plasma-workspace
$ repo-analysis
What changes a lot?
  1519  
    38 CMakeLists.txt
    29 shell/shellcorona.cpp
    24 runners/services/servicerunner.cpp
    21 wallpapers/image/imagepackage/contents/ui/config.qml
    19 libnotificationmanager/notifications.cpp
    18 shell/org.kde.plasmashell.desktop.cmake
    18 devicenotifications/devicenotifications.cpp
    17 kcms/lookandfeel/kcm.cpp
    16 wallpapers/image/plugin/model/packagelistmodel.cpp
    16 kcms/cursortheme/xcursor/xcursor.knsrc
    15 wallpapers/image/plugin/model/imagelistmodel.cpp
    15 applets/notifications/global/Globals.qml
    15 applets/devicenotifier/devicecontrol.cpp
    14 wallpapers/image/plugin/imagebackend.cpp
    14 shell/panelview.cpp
    14 .kde-ci.yml
    14 applets/systemtray/systemtray.cpp
    13 runners/services/autotests/servicerunnertest.cpp
    12 krunner/qml/RunCommand.qml

What breaks a lot?
   225 shell/shellcorona.cpp
   183 shell/panelview.cpp
    83 CMakeLists.txt
    74 applets/systemtray/package/contents/ui/main.qml
    71 applets/digital-clock/package/contents/ui/DigitalClock.qml
    63 klipper/klipper.cpp
    62 applets/notifications/package/contents/ui/NotificationItem.qml
    58 wallpapers/image/imagepackage/contents/ui/config.qml
    56 shell/desktopview.cpp
    56 libtaskmanager/tasksmodel.cpp
    54 shell/main.cpp
    54 applets/systemtray/systemtray.cpp
    53 shell/shellcorona.h
    52 krunner/view.cpp
    48 applets/digital-clock/package/contents/ui/CalendarView.qml
    47 runners/services/servicerunner.cpp
    46 wallpapers/image/imagepackage/contents/ui/main.qml
    45 applets/notifications/package/contents/ui/NotificationPopup.qml
    44 applets/systemtray/package/contents/ui/ExpandedRepresentation.qml
    43 startkde/startplasma.cpp

And what were the emergencies?
4f526a7bd1 Revert “applets/systemtray: Prevent popups from overlapping with the panel”
dca5788fee lookandfeel/components: Revert Plasma::setupPlasmaStyle
2c0fd34541 Revert “ContainmentLayoutManager: send recursive mouse release events too”
b6b230f4ff Revert “Read selenium-webdriver-at-spi-run location from CMake”
b8651b56f6 hotfix: Remove doc translations without actual doc
1f43f576e8 Revert “Add forceImageAnimation property to force animated image play”
f0349b6c81 hotfix: remove stray .po file
3ff7ae4269 Revert “CI: enable parallel testing”
83bebc7896 Revert “Limit evaluateScript execution at 2 seconds”
4f45f672be Revert “kcms/componentchooser: Don’t offer NoDisplay services”
3bf0ff8f56 Revert “Disable linux-qt6-next while the regression in Qt gets fixed”
80996f0633 Revert “kcms/wallpaper: set roleNames for WallpaperConfigModel”

What’s the project’s momentum over the past 5 years?
   148 2021-05
    87 2021-06
    62 2021-07
    85 2021-08
   121 2021-09
   106 2021-10
   146 2021-11
   190 2021-12
   191 2022-01
    84 2022-02
   168 2022-03
   130 2022-04
   146 2022-05
   141 2022-06
   136 2022-07
   107 2022-08
   232 2022-09
   234 2022-10
   181 2022-11
   150 2022-12
   154 2023-01
   161 2023-02
   156 2023-03
   156 2023-04
   163 2023-05
   137 2023-06
   186 2023-07
   190 2023-08
   275 2023-09
   226 2023-10
   283 2023-11
   157 2023-12
   131 2024-01
   147 2024-02
   249 2024-03
   180 2024-04
   188 2024-05
   158 2024-06
   128 2024-07
   146 2024-08
   169 2024-09
   156 2024-10
   116 2024-11
    98 2024-12
   145 2025-01
   126 2025-02
   120 2025-03
   116 2025-04
   131 2025-05
   131 2025-06
   132 2025-07
   115 2025-08
   110 2025-09
    97 2025-10
   147 2025-11
   114 2025-12
   140 2026-01
   131 2026-02
   119 2026-03
    44 2026-04

Who’s been driving this project in the past year?
  116  Vlad Zahorodnii
  113  Nicolas Fella
   87  Christoph Wolk
   82  Fushan Wen
   78  Nate Graham
   66  Kai Uwe Broulik
   48  Bohdan Onofriichuk
   37  Harald Sitter
   34  Tobias Fella
   31  Marco Martin
   30  David Edmundson
   25  Akseli Lahtinen
   21  Ismael Asensio
   17  David Redondo
   16  Niccolò Venerandi
   15  Bhushan Shah
   11  Alexander Lohnau
   11  Kristen McWilliam
    9  Oliver Beard
    9  Shubham Arora
    8  Alexey Rochev
    8  Han Young
    8  Philipp Kiemle
    7  Albert Astals Cid
    6  Aleix Pol
    6  Méven Car
    5  Devin Lin
    5  Joshua Goins
    4  Alexander Wilms
    4  Arjen Hiemstra

And what about for all time?
 1543  Fushan Wen
 1497  Marco Martin
 1374  Kai Uwe Broulik
 1030  David Edmundson
  772  Nate Graham
  658  Alexander Lohnau
  551  Aleix Pol
  548  Nicolas Fella
  438  ivan tkachenko
  385  Eike Hein
  264  Sebastian Kügler
  250  Martin Gräßlin
  238  Harald Sitter
  232  Martin Klapetek
  223  Jonathan Riddell
  207  Vlad Zahorodnii
  194  David Redondo
  190  Friedrich W. H. Kossebau
  189  Laurent Montel
  144  Bhushan Shah
  134  Christoph Wolk
  134  Ismael Asensio
  126  Lukáš Tinkl
  121  Niccolò Venerandi
  117  Méven Car
  105  Natalie Clarius
   91  Konrad Materka
   80  Vishesh Handa
   80  Volker Krause
   79  Ivan Čukić

ShellCorona both changing and breaking a lot is no great surprise to me; it’s fiddly and complicated. We need to do something about that. The number of emergencies doesn’t look too bad, and momentum feels fine too. The project also appears to have a nice healthy diversity of contributors. Excellent!

It’s been quite illuminating to run these tools on KDE projects that I’m both more and less familiar with. Give it a try!

This month in KDE Linux: March 2026

KDE Linux logo

Welcome to the March 2026 edition of development news for KDE Linux, KDE’s up-and-coming general-purpose operating system.

I’m going to try to publish one of these posts every month, so you get this one just two weeks after the last one! Despite the abbreviated timeframe, the weeks were fairly busy in KDE Linux land.

Hardening updates against breakage

Probably the most consequential thing to happen was several users experiencing a series of bad updates that rendered the system unbootable.

Harald Sitter has root-caused everything and is working on making the issues impossible to experience in the future. But this is the reason why https://kde.org/linux recommends against deploying KDE Linux’s Alpha release on your non-technical uncle’s computer or across the accounting department at work!

“Wait, you told me this distro uses atomic updates that can’t ever make the system unbootable, you filthy liar!”

Well, it turns out that our updates weren’t as atomic as intended. 😬 You see, a system update in KDE Linux consists of multiple steps:

  1. Download an image file that contains the OS
  2. Download a “unified kernel image” (UKI) that tells the boot manager about the OS image
  3. Reboot, choosing the boot manager’s entry for the new OS image
  4. During the boot process, relevant changes from the new OS image are deployed to /etc, which is not immutable

A fairly serious bug in systemd’s newly-released version 260 made step 1 fail silently while step 2 succeeded. Thus, the boot manager would let you try to boot into a non-existent OS image, which would fail. Eek.

But no problem, right? Just roll back to the previous OS image!

Well, here’s where a bug in step 4 broke that. Our custom system for deploying changes to /etc was not hardened against the case where the OS image was missing but the boot manager let you try to boot into it anyway; doing so would erase much of the content in /etc and prevent booting into a known-good OS image. Oops.

Fortunately, KDE Linux includes built-in Btrfs snapshots of /etc, so there’s a documented set of recovery steps. And Harald Sitter has since improved error logging for this situation and fixed the bug on our side so rolling back from a botched update won’t damage /etc anymore.

Our focus now shifts towards implementing a system to automatically roll back and forward /etc as you roll back and forward OS builds, so each OS build is permanently associated with the version of /etc it was known to work with. This would have also prevented the issue.

In addition, we’re looking into merging steps 1 and 2 as much as possible so this type of failure can’t even happen in the first place.

But that wasn’t all the “excitement” around updates: systemd-260 also opted the “sysupdate” functionality that KDE Linux uses out of systemd’s API stability guarantee, and then broke compatibility — resulting in Discover being unable to update the system. updatectl update in a terminal window remained working.

Fortunately, Akseli Lahtinen has already adapted Discover’s sysupdate support to the new approach in systemd-260, so that’s working again.

We also uncovered a few more bugs introduced by systemd-260, including https://github.com/systemd/systemd/issues/41303 and https://github.com/systemd/systemd/issues/41299. And if anyone from Systemd is reading, https://github.com/systemd/systemd/issues/41288 is also a highly relevant issue; this really shouldn’t happen.

I’ve been told that sysupdate is expected to return to the API compatibility guarantee in systemd-261 or -262, so expect some more churn here. If it gets too bad, we’ll consider rolling back to systemd-259 (or even -258, since -259 broke many TPM chips).

Thankfully there’s also good news!

Better memory management

I tweaked the parameters of our zram setup to stop causing system freezes when close to the limit. I also fixed our “out of memory” handler so that it works, and now memory-hogging apps will be terminated instead of letting the whole system freeze.

This whole endeavor came out of some deep research into memory management that I expect to yield more positive changes in the future.

More user-friendly handling of incompatible packages

Thomas Duckworth integrated a component he’s been working on that displays sane feedback when you try to open a package or app that isn’t supported on the system, like a Windows .exe or a .rpm package.

A dialog informs the user that RPM packages are not supported on KDE Linux, and suggests alternative courses of action

Better out-of-the-box hardware support

John Kizer pre-installed usbmuxd, which makes plugged-in Apple iOS devices visible in Dolphin and file dialogs. So now you can, for example, plug in one such device and copy pictures off of it.

Thomas Duckworth fixed an issue that prevented non-NVIDIA systems from fully sleeping. This workaround was only needed for systems with NVIDIA GPUs, and no longer takes effect for systems with other GPUs.

Vishal Rao slightly increased the amount of time that the OS image chooser is visible on screen, making it less likely that you’ll miss it entirely when using KDE Linux with a TV or a slow monitor that takes a while to turn on.

Better out-of-the-box software support

Hadi Chokr added support for mounting optical disk images.

I added support for SSTP VPNs, and also for encoding audio on CDs using the Opus format, indexing really old Microsoft Word documents, and opening archives compressed with more types of compression algorithm.

Internationalized “command not found” handler

I made the “command not found” handler display translated text if you don’t use your KDE Linux system in English. Thanks a lot to Albert Astals Cid for helping me with the details here!

Smarter settings

Yago Raña Gayoso disabled screen locking and update checking while in the live session, as these don’t really make sense there. Yago also disabled canceling the installation in the middle, as this is not supported right now and would produce a broken system.

Thomas Duckworth configured the sudo command-line tool to display a little “*” for every character you type, instead of nothing. This matches the standard behavior in password fields that people are familiar with.

I configured the cp and rsync command-line tools to preserve metadata (such as modification times, extended attributes, and ACLs) when copying files.

Fixed spellchecking, at least for English

I fixed our spellchecking setup by installing the English backend for hunspell, and removing the redundant aspell to save some space. These language packages can be quite large, so it’s not super feasible to ship them all in the image right now. In the future we’ll be building a system to let them download at runtime.

KRunner helps the user spell "itinerary" by suggesting it in response to being asked if "itineray" is a word

Technical changes

Thomas Duckworth fixed an issue that made newly-installed OS images sometimes get de-prioritized in the OS image chooser for no good reason.

Akseli Lahtinen set the $SSH_ASKPASS environment variable to to point to KSSHAskPass by default, smoothing out some SSH-based workflows.

Hadi Chokr added ~/.local/bin to every user’s default $PATH variable, allowing kde-builder and other user-installed binaries to work without an extra setup step.

How you can help

Does this project sound exciting? I hope it does! We’re building a general-purpose operating system for normal people, aiming to integrate all components out of the box in a way that rivals Windows and MacOS. If you’d like to help out with the project, there are multiple ways.

If you’re an adventurous and technical person, install KDE Linux and report issues.

If you’re good at writing, KDE Linux’s documentation can always use improvement. Submit merge requests here.

KDE Linux leans heavily on Flatpak, so fixing packaging or code issues in Flatpak-packaged apps is very helpful.

You can even help us build the OS itself! The Beta milestone is currently 71% complete, and there’s plenty to do:

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

This month in KDE Linux

Another month has gone by since the last time I wrote about KDE Linux, KDE’s upcoming new operating system. The project hasn’t stood still! Here’s an assortment of what’s gone on recently:

Real sizes for system updates

Aleix Pol Gonzalez and Harald Sitter built the machinery to allow update sizes to be calculated for delta updates. This means the sizes listed in Discover are no longer “Unknown”. Instead, you’ll see a real number:

Better tools for extending the OS

Lasath Fernando started building out the new Kapsule system, which is a tool for installing software in long-lived containers with great integration with Konsole and the rest of the OS. Before this, we experimented multiple options for experts to extend the system — including Homebrew, Distrobox, and Nix — but none really hit the sweet spot. They were too limited, too dangerous, too complex, too ephemeral, or too something else.

Kapsule deeply integrates with Konsole, which makes sense because a terminal window is a major interface for touching or extending the system in this way. Integrations with Kate and Discover are planned, too. In other words, we want to go all in on this promising new technology for the “extending the system” story for experts and software developers.

You can read more about Kapsule in these blog posts.

Moving to better infrastructure

Harald did a lot of work to upload KDE Linux images to a better location, in preparation for far higher server loads in the future as the OS gains users and rolls out a user-focused edition.

Pre-installed backup system

I pre-installed KDE’s Kup backup system, which is really quite nice! Basic documentation can be found here.

APFS filesystem support

Hadi Chokr turned on support for reading from and writing to disks formatted with Apple’s APFS filesystem.

Safer Homebrew, ydotool, and AMD GPUs

renner03 put in place a safety mechanism that prevents Homebrew packages from breaking the system in case you install Homeberew and any of its packages would otherwise conflict with system files. Now, the Homebrew packages break instead.

Note that we still don’t recommend Homebrew. But now you can use it without endangering the rest of the system.

I made the ydotool automation tool safer; now it’s an off-by-by-default system service you need to authenticate to turn on.

I also put in place a workaround for total system freezes affecting AMD GPU users. This stubborn AMD driver issue has been unfixed for months, so a workaround here is appropriate.

More languages in pre-installed Flatpak apps

Guilherme Marçal Silva fixed an issue that made the pre-installed Flatpak apps only usable in English.

Longer time for installation

Jonar Harer bumped the installation timeout from 30 minutes to 1 hour to account for slower devices.

Outstanding issues

KDE Linux is still an alpha product with lots of bugs and rough edges. We had our second dev call yesterday and discussed the road to a beta release, which will include user builds. We’re going to be focusing on a number of high priority issues and will consider the other beta-milestoned issues to be done on an “if we can” basis.

Get Involved!

Progress on KDE Linux is steady but nonetheless rather slow. Help is greatly appreciated. In addition to installing it and reporting issues, there are lots of development task that need doing:

While you support others, who supports you?

The world of free and open-source software (FOSS) is full of big-hearted, altruistic people who love serving society by giving away their labor for free. It’s incredible. These folks are supporting so many people by providing the world with high quality free software, including in KDE, my FOSS community of choice.

But while they do it, who’s supporting them? We don’t talk about this as much.

A recent Reddit post by a volunteer developer burning out reminded me of the topic, and it’s not the first one. Denis Pushkarev of core-js wrote something similar in 2023, and we’re probably all familiar with this XKCD comic:

The topic is also not limited to the FOSS world; it’s broadly applicable to all volunteer activities. Can’t feed the homeless in a soup kitchen if you’re sick and sneezing into the soup! Can’t drive to the library to teach adult reading classes if your car’s broken down.

In order to support others, you need support yourself! Who can provide that support? Here are a bunch of cases that work:

  • Yourself in the present (with a job — related or unrelated to your FOSS work)
  • Yourself in the past (retired)
  • Your partner in the present (married to a primary or sole income-earner)
  • Your partner in the past (partner left you lots of money after death or divorce)
  • Your parents in the present (you’re their dependent)
  • Your parents in the past (born rich or received a big inheritance later)
  • The state (disabled, a student, or on a similar program)

All these cases work. They provide enough money to live, and you still get to work on FOSS!

There are lots of other good options, but here are some of the bad ones that don’t work:

  • Other people via donations: you never get enough donations, and if you put the effort into fundraising required to make it work, that becomes your job.
  • Yourself in the future: if you’re living off loans, you’re screwing over future you!
  • Nobody: if you’re eating up your savings, you’ll eventually run out of money and be destitute. If you’re fortunate enough to live in a place where “The state” is an option, it will be at a diminished standard of living.

We must always answer for ourselves the question of how we’re going to be supported while we continue to contribute to the digital commons. If you don’t do it for a living, it’s a critically important question. Never let anyone guilt-trip you into doing volunteer work you don’t have the time or money for! It’s a sure road to burnout or worse.

Airplane safety briefings tell people to “put on your mask before helping others.” Why? Same reason as what we’re talking about here: you can’t support others if you’re not first supported yourself. If you try, you’ll fail, either immediately, or eventually. You must be properly supported yourself before you can be of use to others.

Busy months in KDE Linux

It’s been few months since I last blogged about KDE Linux, KDE’s operating system of the future. So I thought it was time to fill people in on recent goings-on! It hasn’t been quiet, that’s for sure:

Project health is looking good

KDE Linux hit its alpha release milestone last September, encompassing basic usability for developers, internal QA people, and technical contributors. Our marketing-speak goal was “The best alpha release you’ve ever used”.

I’d say it’s been a success, with folks in the KDE ecosystem starting to use and contribute to the project. A few months ago, most commits in KDE Linux were made by just 2 or 3 of us; more recently, there’s a healthy diversity of contributors. Check out the last few days of commits:

The next step is working towards a beta release. This is something we can consider the equal of other traditional Linux OSs focused on traditional Linux users: the people who are slightly to fairly technical and computer-literate, but not necessarily developers. Solidly “two-dots-in-computers” users. We’re 62% of the way there as of the time of writing.

First public Q&A and development call

KDE Linux developers held their first public meeting today! The notes can be found here. This is the first of many, and these meetings will of course be open to all.

In this first meeting, devs fielded questions from technical users and discussed a number of open topics, coming to actionable conclusions on several of them. The vibe was really good.

If you want to know when the next meeting will be held, watch this space for a poll!

Delta updates enabled by default

After months of testing by many contributors, we turned on delta updates.

Delta updates increase update speed substantially by calculating the difference between the OS build you have and the one you’re updating to, only downloading that difference, and then applying it like a patch to build the new OS image.

As a result, each OS update should consume closer to 1-2 GB of network bandwidth, down from the 7 GB right now (this is if you’re updating daily; longer intervals between update will result in larger deltas). Still a lot, but now we have a mechanism for reducing the delta between builds even more.

This wonderful system was built by Harald Sitter. Thanks, Harald!

Integrating plasma-setup and plasma-login-manager

KDE Linux now delegates most first-user setup tasks to plasma-setup:

plasma-setup supports the use case of buying a device with KDE Plasma pre-installed where the user is expected to create a user account as part of the initial setup.

Thanks very much to Kristen McWilliam both for not only taking the lead to develop plasma-setup, but also integrating it into KDE Linux!

In addition, KDE Linux now uses plasma-login-manager instead of SDDM. This is a modern login manager intending to integrate more deeply with Plasma for operating systems that want that and use systemd (like KDE Linux does). Development was done primarily by David Edmundson and Oliver Beard, with assistance from Nicolas Fella, Harald Sitter, and Neal Gompa. KDE Linux integration work was done by Thomas Duckworth and Harald Sitter.

KDE Linux has been a superb test-bed for developing and integrating these new Plasma components, and now other operating systems get to benefit from them, too!

Better hardware support

As an operating system built for users bringing their own hardware, KDE Linux is fairly liberal about the drivers and hardware support packages that it includes.

Compared to the initial alpha release last September, the latest builds of KDE Linux include better support for scanners, fancy drawing tablets, Bluetooth file sharing, Android devices, Razer keyboards and mice, Logitech keyboards and mice, fancy many-button mice of all kinds, LVM-formatted disks, exFAT and XFS-formatted disks, audio CDs, Yubikeys, smart cards, virtual cameras (e.g. using your phone as one), USB Wi-Fi dongles with built-in flash storage, certain fancy professional audio devices, and Vulkan support on certain GPUs. Phew, that’s a lot!

Thanks to everyone who reported these issues, and to Hadi Chokr, Akseli Lahtinen, Thomas Duckworth, Fabio Bas, Federico Damián Schonborn, Giuseppe Calà, Andrew Gigena, and others who fixed them!

There’s still more to do. KDE Linux regularly receives bug reports from people saying their devices aren’t supported as well as they could be, or at all — especially older printers, and newer laptops from Apple and Microsoft. No huge surprises here, I guess! But still, it’s a big topic.

Better performance

Thomas Duckworth, Hadi Chokr, and I dug into performance and efficiency, improving the configuration of the kernel and various middleware layers like PulseAudio and PipeWire. Among them include using the Zen kernel, optimizing kernel performance, increasing various internal limits, and optimizing for low-latency audio.

Thanks very much to the CachyOS folks who blazed many of these trails, and whose config files we learned from.

Quieter boot process

Previously, the OS image chooser was shown on every boot. This is good for safety, but a waste of time and an unnecessary exposure of technical details in other cases.

Thomas Duckworth hid the boot menu by default, but made it show up if you mash the spacebar, or if the computer was force-restarted, or restarted normally very quickly after login. These are symptoms of instability; in those cases we show the OS image chooser on the next boot so you can roll back to an older OS version if needed.

Appropriately-set wireless regulatory domain

Different countries have different regulations regarding wireless hardware’s maximum transmit power. If you don’t tell the kernel what country your computer is located in, it will default to the lowest transmit power allowed anywhere in the world! This can reduce your Wi-Fi performance.

Thanks to Thomas Duckworth, KDE Linux now sets the wireless regulatory domain appropriately, looking it up from your time zone, and letting your hardware use all the power it legally can. It updates the value if you change the time zone, too! And also thanks to Neal Gompa for building the tool we integrated into KDE Linux for this.

The idea for this one came from reading CachyOS docs asking users do it manually. Maybe we have something worth copying now!

RAR support

Hadi Chokr added RAR support to our builds of Ark, KDE’s un-archiver. Now you can keep on modding your old games!

“Command not found” handler

I built a simple “command not found” handler that tries its best to steer people in the right direction when they run a command that isn’t available on KDE Linux:

Better Zsh config

KDE Linux now includes a default Zsh config, and it’s been refined over time by multiple people who clearly love their Zsh!

Thank you to Thomas Duckworth, Clément Villemur, and Daniele for this work.

Documentation moved to a more official location

KDE Linux documentation was wiki-based for the past year and a half, and benefited from the sort of organic growth easily possible there. However, it’s now found a more permanent and professional-looking home: https://kde.org/linux/docs.

This will be kept up to date and expanded over time just like the old wiki docs — which now point at the new locations. This work was done by me.

Easy setup for KDE development

KDE developers are a major target audience of KDE Linux. To that end, I wrote some setup tools that make it really easy for people to get started with KDE development. It’s all documented here; basically just run set-up-system-development in a terminal window and you’re ready! The tool will even tell you what to do next.

Saying hello to KCalc, Qrca, Kup, and new CLI tools

KDE Linux includes an intentionally minimal set of GUI apps, leaning on users to discover apps themselves — and if that sucks, we need to fix it. But we decided that a calculator app made sense to include by default. After much hemming and hawing between KCalc and Kalk (it was a tough call!), we eventually settled on KCalc, and now it’s pre-installed.

We’re also now including Qrca, a QR code scanner app. This supports the Network widget’s “scan QR code to connect to network” feature:

Next up is KDE’s Kup backup program for off-device backups! Kup is not nearly as popular as it should be, and I hope more exposure helps to get it additional development attention, too.

Finally, we pre-installed some useful command-line debugging and administration tools, including kdialog, lshw, drm_info, cpupower, turbostat, plocate, fzf, and various Btrfs maintenance tools.

This work was done by me, Ryan Brue, Kristen McWilliam, and Akseli Lahtinen.

Waving goodbye to Snap, Homebrew, Kate, Icon Explorer, Elisa, and iwd

Since the beginning, KDE Linux included Snap as part of an “all of the above” approach to getting software.

Snap works fine (in fact, better than Flatpak in some ways), but came with a big problem for us: It’s only available in the Arch User Repository (AUR). Getting software from AUR isn’t great, and we’ve been moving away from it, with an explicit goal of not using AUR at all by the time we complete our beta release.

Conversations with Arch folks revealed that there was no practical path to moving Snap out of AUR and into Arch Linux’s main repos, and we didn’t fancy building such a large and complex part of the system ourselves. So unfortunately that meant it had to go. We’re now all-in on Flatpak.

Homebrew was another solution for getting software not available in Discover, especially technical software libraries needed for software development. We never pre-installed Homebrew, but we did officially document and recommend it. However the problem of Homebrew-installed packages overriding system libraries was worse than we originally thought; there were reports of crashing and “doesn’t boot” issues not resolvable by rolling back the OS image, because Homebrew installs stuff in your home folder rather than a systemwide location. Accordingly, we’ve removed our recommendation, replacing it with a warning against using Homebrew in our documentation. Use Distrobox until we come up with something more suitable.

Another removal was Kate. Kate is amazing, but we already pre-install KWrite, and the two apps overlap significantly in functionality. Eventually we reasoned that it made sense to only pre-install KWrite as a general text editor and keep Kate as an optional thing for experts who need it.

We also removed Icon Explorer from the base image because developers who need it can now get a Flatpak build of it from Flathub.

Next up was Elisa. Local music library manager apps are not very popular these days, and the pre-installed Haruna app can already play audio files. So out it went, I’m afraid. Anyone who uses it (like I do!) can of course manually install it, no problem.

And finally, the iwd wireless daemon leaves KDE Linux. It was never enabled by default; it was just an option for those who needed it. And the one user who did need it eventually found a better solution to their wireless card issues. With news of Intel dis-investing in iwd, we decided it didn’t have a sunny future in KDE Linux anymore and removed it.

This work was done by me.

And lots more

These are just the larger user-facing changes. Tons of smaller and more technical changes were merged as well. It’s a fairly busy project.

You can use it!

It’s also not a theoretical project; KDE Linux is released and I typed this blog post on it! I’ve developed Plasma on it and run a business on it, too. It’s been my daily driver since last August.

You can probably install KDE Linux on your computer too, and become a part of the future. Even if you’re worried about using alpha software because you’re not a software developer or a mega nerd, it’s perfect for a secondary computer. KDE Linux is quite stable, and the OS rollback functionality reduces risk even more.

You can help build it!

If any of this is exciting, come help us build it! Working on KDE Linux is pretty easy, and there’s lots of support.