This Month in KDE Linux: September 2026

Thursday, 1 October 2026  |  Nate Graham

#This Month in KDE Linux   #KDE Linux  

Welcome to this edition of This Month in KDE Linux, dedicated to KDE’s next-generation operating system.

September was a bit of a slow month for KDE Linux, the result of multiple contributors preparing for, attending, and recovering from Akademy 2026, and then later All Systems Go! 2026.

But it was hopefully not all for naught; Harald and Nate gave a presentation about the project at Akademy:


…And then Harald gave another one at All Systems Go!


Anyway, most work consisted of infrastructure and code maintenance, documentation improvements, and small bug fixes. Sky Poincet and Philip Grant did a lot of the heavy lifting while Harald and Nate were absent, which is much appreciated.

Despite us still calling KDE Linux an alpha release, the project is maturing to focus on stability and polish, a classic application of the Pareto principle (colloquially known as the “80/20” rule).

One interesting project did land in September, though: Hadi Chokr replaced sudo and pkexec with wrappers that call the more modern and secure run0 tool. This reduces the number of SUID binaries that can be used for privilege escalation attacks.

BuildStream

This is probably a good time to talk about BuildStream. What’s BuildStream?

If you know what Yocto is, BuildStream is basically Yocto but stewarded by the Apache Foundation.

If you don’t, then the easiest wasy to explain BuildStream is that it’s a tool for compiling and packaging software from arbitrary sources. In the same way that mkosi currently builds KDE Linux an OS image from distro packages, BuildStream builds an OS image from individual projects’ source code — bypassing distro packages entirely.

KDE Linux has had a skunkworks project going on in the background that replaces the base OS’s Arch Linux packages with basically the same software stack, but built by us, using BuildStream. The project is quite close to a “shall we integrate it or not?” decision point.

If we do, the result should behave identically and users won’t even notice the change — an advantage of KDE Linux being image-based rather than package-based.

So here’s an obvious question: why are we considering doing a huge amount of work ourselves to rebuild what we’re already getting for free with Arch? KDE Linux has been able to inherit everything that makes Arch awesome, really accelerating its development.

But ultimately Arch is a rolling release OS, and KDE Linux does not plan to be a rolling release OS. The user and stable editions will have discrete, time-based releases. If we stick with Arch, at the moment we branch for a new release, we have to either accept whatever’s in Arch (which could include regressions that we miss) or polish a fork of Arch for some amount of time (which entails doing a bunch of packaging work ourselves anyway).

So while BuildStream offers other advantages too, the big win would be allowing us to have total control over the software versions we build, and making it easier for us to add new things that aren’t currently packaged by Arch (here are some examples).

We wouldn’t be doing it all ourselves, either. The BuildStream-based KDE Linux variant is based on the FreeDesktop Flatpak SDK, same as GNOME OS. So maintenance will be shared across all three projects’ contributors.

This project has consumed quite a bit of time over the past few months, and we’ll be plugging away in October, hopefully to the point where we can make a decision about it one way or another.

How you can help

KDE Linux is making steady progress towards its Beta milestone, and remains 85% of the way there.

There’s lots to do! If you’re a fan of the project, please help out; there are many ways:

Comments