KDE Linux: Difference between revisions
m ++ |
Fill in some of the blanks |
||
| Line 8: | Line 8: | ||
== Goals == | == Goals == | ||
Create a bulletproof OS showcasing the best of KDE that we can proudly recommend to users and OEMs, with a coherent "here's how you get it" story. | |||
It should never break, and if it does anyway, this should be detectable and roll-backable to the previous OS partition. Maybe even call home and inform about breakage so we can pull the update. Can do this with systemd-sysupdates. | |||
== Target audience and use cases == | == Target audience and use cases == | ||
It should have multiple editions suitable for different kinds of users. Ideas: | |||
* '''Developer edition''': built from git master and released daily, including debugging tools and KDE dev environment. Like Neon Developer. | |||
* '''Enthusiast edition''': ships released software, and releases to users on upstream KDE's schedule, like Neon User. Additionally, when there are any beta releases, ships the beta. | |||
* '''Stable edition''': ships only released software on a delayed schedule, based on TBD quality metrics. | |||
== Requirements == | == Requirements == | ||
| Line 19: | Line 24: | ||
== Architecture == | == 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 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) | 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) | ||
Revision as of 21:18, 18 September 2024
“KDE Linux” is a work-in-progress name of a KDE-owned general-purpose Linux distribution proposed at Akademy 2024. Not to be confused with KDE Neon.
Warning
TODO: background, motivation
Goals
Create a bulletproof OS showcasing the best of KDE that we can proudly recommend to users and OEMs, with a coherent "here's how you get it" story.
It should never break, and if it does anyway, this should be detectable and roll-backable to the previous OS partition. Maybe even call home and inform about breakage so we can pull the update. Can do this with systemd-sysupdates.
Target audience and use cases
It should have multiple editions suitable for different kinds of users. Ideas:
- Developer edition: built from git master and released daily, including debugging tools and KDE dev environment. Like Neon Developer.
- Enthusiast edition: ships released software, and releases to users on upstream KDE's schedule, like Neon User. Additionally, when there are any beta releases, ships the beta.
- Stable edition: ships only released software on a delayed schedule, based on TBD quality metrics.
Requirements
TODO (UX, minimum hardware requirements, maintainability, independence, etc.)
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 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
TODO (prior art; how are we different from Neon, from Kinoite, from other immutable distros)
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.