KDE Linux: September Report, BuildStream, and run0

Nate Graham has published the September report on KDE Linux, KDE's next-generation operating system. September was a slow month, which the team attributes to Akademy 2026 and All Systems Go! 2026: preparation, attendance, and recovery. Harald and Nate gave presentations on the project at both events, and contributors Sky Poincet and Philip Grant carried the maintenance load in their absence.

The project remains in alpha but is shifting focus toward stability and polish on the way to its Beta milestone, which it is now 85 percent of the way toward.

How KDE Linux Works Today

KDE Linux is not a classic Arch distribution and ships no package manager for the installed system. The OS is delivered as an image: /usr sits in a read-only EROFS image, updates swap the entire image atomically against a new version, older images remain available for rollback, and applications are installed primarily through Flatpak.

Arch comes into play only when building those images: pacman and the Arch repositories assemble the base system components, and the package manager is removed from the finished image. For development this is convenient, KDE gets a current distribution with a large package pool without having to build and package large parts of an OS itself. Long term, though, this approach conflicts with KDE Linux's release plans.

run0 Replaces sudo and pkexec

Hadi Chokr replaced sudo and pkexec with wrappers that call systemd's run0 tool. run0 requests privileges through polkit and runs the requested process in a freshly spawned environment without being a SUID binary itself. The practical effect: fewer SUID binaries on the system that could serve as privilege escalation targets.

BuildStream: The Big Open Question

The report spends most of its length on BuildStream, a build tool stewarded by the Apache Foundation. If you know Yocto, BuildStream is comparable: it compiles and packages software from arbitrary sources. KDE Linux currently builds its OS image from Arch Linux packages using mkosi. The skunkworks project in the background would replace those Arch packages with the same software stack built by KDE itself, using BuildStream.

The problem with the current approach is concrete, not hypothetical. As Hadi Chokr described in a September blog post, the KDE software stack depends on the ABI versions of certain non-KDE libraries that pacman provides. When Arch moved faster than KDE Linux could follow, the result was bricked images. KDE started pinning fixed Arch snapshots for its image pipeline to stop the breakage, but that only partly fits a distribution whose infrastructure is built for continuous updates.

The release plans make it worse: KDE Linux will not be a rolling release, unlike Arch. When branching for a stable release, the team would have to accept whatever Arch contains at that moment, regressions included, or maintain an Arch snapshot fork, which means doing packaging work anyway. Building from source with BuildStream gives full control over software versions and makes it easier to add things Arch does not package.

The BuildStream variant is based on the FreeDesktop Flatpak SDK, the same foundation GNOME OS uses, so maintenance would be shared across the three projects' contributors. The decision is expected in October.

How You Can Help

KDE Linux is looking for help in several areas: user support on discuss.kde.org, issue reporting, documentation merge requests, Flatpak packaging fixes, and OS development itself.