History & Architecture
History
KDE Linux was conceived by a cabal of core KDE contributors in the offices of Tuxedo Computers during the early 2023 Plasma sprint in Augsburg, Germany. One of them — veteran KDE developer Harald Sitter — built and began refining a prototype, revealing it publicly during Akademy 2024 (slides, recording).
An alpha release followed at Akademy 2025 (slides, recording).
Reason for existence
- Be “the KDE operating system” so KDE can have direct relationships with hardware vendors and users
- Showcase KDE software in its most positive light
- Offer a high-quality UX competitive with or exceeding that of proprietary alternatives
- Don’t make users manually install device drivers, optional KDE features, etc.
- Be highly reliable, and easy to recover
- Improve KDE software deployed using containerized apps and image-based operating systems in general
- Any edition can be used as the main system by our developers for internal dogfooding purposes
Things we have consciously decided not to care about right now
- Proprietary NVIDIA kernel driver for graphics cards older than NVIDIA GTX 16xx (newer ones use the open-source kernel modules, which are included).
- VirtualBox - requires out-of-tree kernel modules, and other VM solutions work fine.
- Vendor-specific VPNs - require custom out-of-tree kernel modules
Architecture
Design
KDE Linux incorporates lessons learned from the earlier KDE neon project, and focuses on resilience, recoverability, user-friendliness, and low maintenance needs. The design is heavily inspired by systemd creator Lennart Poettering’s thoughts on operating system (OS) design and system extensions.
As such, KDE Linux is an “image-based” OS. This means the entire base OS is provided as one unit, rather than being split up into thousands of packages that are assembled into the final product on your computer.
Sometimes this model is called “immutable” because the base OS cannot be modified in the same way a traditional OS made of packages could. However, this terminology can be misleading; in KDE Linux, only /usr is provided in the form of a read-only image, and everything else on the system is modifiable like on any other Linux-based OS. And /usr is modifiable through the use of systemd extensions.
High-level implementation
systemd-boot is used as the bootloader.
The bootable image is an ISO-compatible .raw disk image built using mkosi. The base system comes from Arch Linux packages, with most KDE content built using kde-builder. Some KDE apps and 3rd-party apps are pre-installed Flatpaks.
/ is a read-write Btrfs volume. /usr is mounted on top of it in the form of an EROFS image/filesystem. Updating the system entails downloading a new one of these and its companion unified kernel image. 3-4 OS of these images and their UKIs are cached on disk at any given time, providing the ability to roll back in case of problems after updating
A small helper program updates /etc from the content in /usr/share/factory/etc in the active OS image for anything you haven’t changed yourself. Btrfs snapshots of /etc are generated automatically.
/home is a Btrfs subvolume.
User-facing apps shown in Discover come from Flathub.
No package manager is included, but multiple methods are available for installing software that’s not available as a Flatpak app. This is an evolving topic that’s likely to change over time.
Article contributed by Nate Graham under the CC-BY-4.0 license.