KDE Linux experiences | AksDev

KDE Linux experiences

Posted on 2026-08-21 by Akseli Lahtinen<br>I daily drove KDE Linux for almost a year and I liked it, but I'm also switching<br>back to Fedora KDE. Here's my ramblings about it all.

I daily drove KDE Linux for almost a year and I liked it, but I'm also switching<br>back to Fedora KDE. Here's my ramblings about it all.

KDE Linux is the hot new Linux distro from KDE themselves.<br>At the moment it uses Arch Linux as it's base but with heavy modifications and changes.<br>You can read more about it on the site, but to sum up: It's an atomic/"immutable" distro that<br>does not have any kind of package management outside of installing flatpaks.<br>(Do note that they're epxerimenting on using buildstream instead of Arch Linux.)

As one of the KDE devs I've been daily driving it on my desktop, which I use for both<br>work and leisure (gaming).

The following text can be quite technical as I am viewing this through my developer workflow lense,<br>though I will also touch on regular user things.

Upsides

For general purpose computing and KDE dev, things are looking great!

Honestly, it works rather well, considering the alpha status. And for development purposes,<br>the nightly builds of the newest hottest stuff from our git repos is very nice: I don't<br>have to build everything myself every morning.

Though there are some issues with that too: Sometimes the servers are not producing a new image,<br>for reason or another, so I may end up building things myself anyway. Some other times,<br>there is an image that just has some broken change in. Luckily in those situations I can just boot<br>a previous image and use that.

What I really liked though was the systemd-sysext workflow.<br>Sysext is a tool that allows me to layer my changes to the system on top of the previous stuff.<br>So when the system is running /usr/bin/konsole it actually runs my self-built /home/akseli/Projects/kde/usr/bin/konsole.<br>As far as the system is concerned, it's in the same path.

What we currently do in other distros is some environment flag magic to run things from the build-path,<br>instead of /usr/bin/. It also works fine, but can be a bit more brittle, especially when testing<br>something like a login manager.

The workflow is simple:

I build my changes to an app, Plasma desktop component, etc. using kde-builder.

I refresh the sysext with run0·systemd-sysext·--always-refresh=yes·refresh;

sudo works too, i use run0 because it has the popup so I notice it after a long build.

The changes are now live on my system!

Apps may need to be restarted sometimes of course.

If something goes wrong, I can just clean the sysext folder.

It feels more robust and easier to manage.

So on this front, KDE Linux has been really fun to work with.<br>Perfect for testing and development of all the KDE Plasma stuff.

When it comes to applications from flatpaks, they usually work fine, but they can have the<br>typical flatpak issues: Some app needs a permission to a folder that it can't see, so you have to<br>turn off the app, add permissions, turn back on the app, yadda yadda. Apps that use XDG portals<br>properly usually work fine, though there's a bug somewhere in the stack that when the system updates<br>(the atomic image of the OS changes), the portal forgets the folder paths and you have to reopen the<br>file for the path to refresh.

When it comes to gaming stuff, Steam Flatpak has worked really well. I have not noticed any issues<br>compared to the native package. Same with Bottles, all has been just fine and nice. Though sometimes<br>there has been bugs with running games, such as games not locking your cursor properly, but they're<br>often gone with the next update as more people spot these bugs now.

Downsides

With anything more complex than what the system is intended for, things get difficult.

As an atomic distribution, it is expected that any dev tools that are not already installed on the machine,<br>such as your favorite terminal tools or text editors, you will have to either to download them from the<br>internet like a Windows user (plop the binary in ~/.local/bin), or use Distrobox/Kapsule/Toolbox... etc.

Container workflow feels cumbersome to me most of the time. For KDE work, since all the tools to build and<br>run applications are already installed on the system, it's rather effortless.<br>But when I want to continue a game project like my Artificial Rage<br>game project, I would have to enter a distrobox, install all the things, then edit and build the application<br>inside that container. And when I switch a project, it's expected I create a new container for that, and so on.

I don't really like that. I prefer my tools to just be available on the host so I can run them without<br>messing with containers: I have bad memory and am terrible with context switching, so I keep forgetting<br>changing or creating containers.

What I did instead was create bunch of dumb scripts called dbi that<br>are a wrapper for installing tools and "exporting" them from the distrobox so I can use...