KDE Linux
TODO: background, motivation
Goals
See 🍌
Target audience and use cases
See 🍌#Target audience and use cases
Requirements
These are the needs that the proposed solution has to fulfill for it to be considered acceptable:
Distributed by KDE directly.
TODO (UX, minimum hardware requirements that we have to support, maintainability, independence, etc.)
Non-requirements
Does not have to support the proprietary NVIDIA kernel driver. We can require that NVIDIA GPUs must either be new enough to use the open-source kernel modules that can be distributed in-tree, or else use Nouveau.
Architecture
Original architecture ideas for the project included the following:
- Reproducible builds, must-pass CI, automated UI testing
- Base OS is Arch-based. OS updates are some degree of rolling; snapshot based releases with relatively recent libraries
- Systemd-boot as the bootloader
- Btrfs as the filesystem
- Encryption of all mutable data (e.g. user homedir, and cache locations on /)
- Included recovery partition
- Read-only base system, like SteamOS, Kinoite, and MicroOS
- Atomic image-based A/B updates with rollback functionality
- Manual package installation happens transparently using a per-user or systemwide overlay
- Apps are from Flatpak (and maybe also Snap if it's not too hard and the UX is okay)
- Has nice GRUB (systemd-boot?) theming: https://blog.inadvisor.lt/bling-up-your-fedora-grub.
- Wayland by default
- Automatic user data backup system using Btrfs snapshots, with a nice GUI around it like Apple's Time Machine
- DConf-like configuration management UI suitable for enterprise and managed environments leveraging KConfigXT for everything
- Simple input method configuration for CJK and more
- "Troubleshooting hub" app
TODO (hardware support, file system, base disro, boot process, software separation, security model, deployment, updates and rollbacks, localization, OEM mode; proposed solution, alternatives, trade-offs for each section)
Related projects
Differences from other immutable distros
(e.g. Kinoite, MicroOS, SteamOS)
Principally, that it is distributed by KDE. This has several advantages:
- The chain of responsibility is never gated on a third party
- KDE and KDE e.V. can have a direct relationship with third parties using it, e.g. hardware OEMs
- KDE can explicitly recommend it without "picking favorites" from among other distro partners
TODO: differences on a technical level (e.g. another approach to updates / isolation? i.e. why this is not just a copy of Kinoite distributed by KDE)
Prior art
KDE Neon, KDE's first version of a self-made OS. Neon fulfills the "distributed by KDE" requirement, but fails on the reliability angle due to the Ubuntu LTS base that ironically becomes unstable because it needs to be tinkered with to get Plasma to build on it, breaking the LTS promise.
Roadmap
TODO (milestones)
Long-term maintenance
TODO (team and infrastructure requirements for long-term sustainability after release; update cycles; testing infrastructure; architectural future-proofness)
Governance
TODO
Promotion
TODO (name and branding, public image, effect on relations with other distros and hardware partners)
Communication
Prototype
The code is currently located here. Note that it is not representative of the final product and exists solely as an experimental playground for now.