π: Difference between revisions
Nest some sections appropriately |
Migrate Related Projects section |
||
Line 81: | Line 81: | ||
DESTDIR=~/kde ninja install && sudo systemctl restart systemd-sysext.service | DESTDIR=~/kde ninja install && sudo systemctl restart systemd-sysext.service | ||
</nowiki>}} | </nowiki>}} | ||
== 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. | |||
== Communication == | == Communication == |
Revision as of 19:50, 20 September 2024
βKDE Linuxβ (codenamed βProject Bananaβ) 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.
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.
- "The KDE operating system"
- Quality experience
- Doesn't break, or at least easy to recover
- Keeping security in mind
- No packaging knowledge needed
- Focus on modern technologies
- Useful to our users
- Useful to our hardware partners
- Useful to our developers
Non-goals
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.
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.
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, software separation, security model, deployment, OEM mode; proposed solution, alternatives, trade-offs for each section
updates
systemd-sysext
systemd-sysext allows us to overlay developer content on top of /usr without impacting the base system.
Setup
# create directories mkdir -p ~/kde/usr/lib/extension-release.d/ # create an extension-release file cp /usr/lib/os-release ~/kde/usr/lib/extension-release.d/extension-release.kde # make the ID ignored so updates don't break the extension sed -i s%^ID=.*%ID=_any%g ~/kde/usr/lib/extension-release.d/extension-release.kde # owned by root so it can't be removed sudo chown root:root ~/kde/usr/lib/extension-release.d/extension-release.kde # enable the extension sudo mkdir /var/lib/extensions/ sudo ln -s $HOME/kde /var/lib/extensions/kde sudo systemd-sysext merge sudo systemd-sysext
Use
Use DESTDIR=~/kde to install stuff and then restart systemd-sysext. Beware that when changing polkit/dbus stuff you also want to restart those services as they don't necessarily pick up changes.
DESTDIR=~/kde ninja install && sudo systemctl restart systemd-sysext.service
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.
Communication
Ideas
See π/Obstsalat
- Automatic QA (openqa? Selenium? quicktest?)
- Human QA tracking (test case management of some sort)
- Health reporting into Sentry to identify bad releases
- Support sending non-KDE crashes to Sentry
- Better kde-builder dependency definitions
- kde-builder to build release tags
- Explore systemd-homed
- Secure Boot
- ARM/RISC-V images?