The KDE project has launched the publication of test assemblies of its own distribution, KDE Linux Testing Edition. These test assemblies are available for installation on the main KDE Linux page on KDE.org. System images, weighing 5.2 GB, can be used to create bootable USB drives for operating in Live mode. KDE Linux is designed to be a reference implementation of the Linux display for the KDE desktop and applications, optimized to work seamlessly with KDE technologies. Development is carried out directly by KDE without intermediaries, allowing for close monitoring of the development process. The assemblies will be updated daily to reflect the current state of project components. The target audience for KDE Linux Testing Edition is KDE developers and users interested in quality control, testing new features, and identifying errors.
However, it is important to note that KDE Linux does come with some restrictions. For example, it does not support older NVIDIA GPUs, only supporting those based on Turing (GTX 16XX) and newer. This is due to licensed restrictions that prevent the inclusion of proprietary modules for old GPUs. Additionally, the distribution only offers a graphic session based on Wayland.
Looking ahead, the KDE project plans to introduce different editions of KDE Linux – an Enthusiast Edition for enthusiasts and experienced users, providing access to the latest releases and beta versions of KDE Plasma, and a Stable Edition offering final releases after additional testing and stabilization. Overall, KDE Linux is positioned as a versatile product suitable for KDE developers, regular users, and OEM equipment manufacturers.
KDE Linux is built on the ARCH Linux package base but is presented as a single, indivisible image rather than separate packages. Updates are installed using an Atomic update mode, with repeated assemblies supported to allow verification of the distribution assembly process. All user (/home) and system data are stored in encrypted sections, and the distribution uses Systemd-boot as a bootloader.
Updates are managed through two disk sections – the update is loaded into a passive section that becomes active after reboot, while the previously active section becomes passive and awaits the next update. In case of issues post-update, users have the option to rollback to a previous system state. BTRFS snapshot mechanism is used to switch between different system states, and updates are installed using the atomic mechanism with the help of the systemd-sysupdate component.