|
|
| (7 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| “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 [https://neon.kde.org KDE Neon].
| | #REDIRECT [[KDE Linux]] |
| | |
| {{ Warning | This page serves as a design document, thus information presented here should be considered a snapshot of the ongoing discussion, not final decisions. }}
| |
| | |
| This page has lots to talk about, please consult the table of contents on the left :)
| |
| | |
| == Goals ==
| |
| | |
| TL;DR: 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.
| |
| | |
| Goals in detail:
| |
| * Be "The KDE operating system"
| |
| * User-friendly; high-quality UX
| |
| * Doesn't break, or at least easy to recover
| |
| * Keeping security in mind
| |
| * No packaging knowledge needed to develop for it
| |
| * Focus on modern technologies
| |
| * Attractive for our hardware partners
| |
| * Any edition can be used as the main system by our developers for internal dogfooding purposes
| |
| * Support switching between editions/release schedules at any time
| |
| * Exercise codepaths for containerized apps and immutable base systems, to improve KDE software deployed using these technologies in other environments
| |
| | |
| === Non-goals ===
| |
| Does not have to support the runtime installation of kernel modules. This will prevent the out-of-the-box installation of, for example:
| |
| * Proprietary NVIDIA kernel driver (NVIDIA GPUs must either be new enough to use the open-source kernel modules that can be distributed in-tree, or else use Nouveau)
| |
| * VirtualBox
| |
| * Vendor-specific VPNs that require custom out-of-tree kernel modules that cannot be redistributed with the kernel due to license incompatibility
| |
| | |
| Does not have to support the use case of developing low-level system components like the kernel, drivers, systemd, etc., as this can be troublesome with an immutable base OS.
| |
| | |
| == Target audience and use cases ==
| |
| | |
| It should have multiple editions using different release schedules, suitable for different kinds of users. Ideas:
| |
| * '''Testing edition''': built from git master and released daily. Like Neon Testing. ''For QA people, Plasma developers, and Patrick Silva.
| |
| * '''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. ''For KDE enthusiasts, power users, and influencers.''
| |
| * '''Stable edition''': ships only released software on a delayed schedule, based on TBD quality metrics. ''For everyone else.
| |
| ''
| |
| == 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 with nice boot theming
| |
| * 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 Kalpa
| |
| * 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)
| |
| * 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 ===
| |
| | |
| {{Input|1=<nowiki>
| |
| # 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
| |
| </nowiki>}}
| |
| | |
| === 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.
| |
| | |
| {{Input|1=<nowiki>
| |
| DESTDIR=~/kde ninja install && sudo systemctl restart systemd-sysext.service
| |
| </nowiki>}}
| |
| | |
| == Prototype ==
| |
| | |
| The code is currently located [https://invent.kde.org/sitter/kde-linux here]. Note that it is '''not representative of the final product''' and exists as an experimental playground for now.
| |
| | |
| === Installation ===
| |
| ==== GUI ====
| |
| Use [https://apps.kde.org/isoimagewriter/ ISO Image Writer]
| |
| | |
| ==== Terminal ====
| |
| * [https://files.kde.org/kde-linux/ Download] the latest <code>.raw</code> file
| |
| * Attach a USB drive
| |
| * Use <code>lsblk</code> to find the right <code>/dev/node</code>. e.g. <code>/dev/sda</code>
| |
| * <code>sudo dd if=kdeos.raw of=/dev/sda bs=4M</code>
| |
| * <code>sudo sync</code>
| |
| * Reboot into the USB stick
| |
| * no password on SDDM
| |
| | |
| ==== Install ====
| |
| * run Calamares from the desktop or menu
| |
| | |
| ==== Updates ====
| |
| | |
| Until discover gets support the following needs running
| |
| | |
| {{Input|1=<nowiki>
| |
| git clone https://invent.kde.org/sitter/kde-linux
| |
| cd kde-linux
| |
| sudo ./update.sh update
| |
| </nowiki>}}
| |
| | |
| === VM ===
| |
| | |
| ==== virt-manager ====
| |
| | |
| * File -> New VM
| |
| * Import existing disk image
| |
| * [Forward]
| |
| * Select from disk
| |
| * Set arch as OS
| |
| * [Forward]
| |
| * Set resources
| |
| * [Forward]
| |
| * [x] Customize configuration
| |
| * [Finish]
| |
| * Config window opens
| |
| * Make sure at the bottom it says Firmware: UEFI
| |
| * [Add Hardware]
| |
| * Add a storage of some reasonable size
| |
| * [Finish]
| |
| * In the boot options item:
| |
| * check VirtIO Disk 2 and move it above 1
| |
| * [Apply]
| |
| * [Begin installation]
| |
| | |
| === Local Development ===
| |
| | |
| In order to speed up local builds, you can create a `mkosi.local.conf` file in the root of the repository with the following content:
| |
| | |
| {{Input|1=<nowiki>
| |
| [Content]
| |
| Environment=LOCALE_GEN="en_US.UTF-8 UTF-8" # replace with your locale`
| |
| Environment=MIRRORS_COUNTRY=us # replace with your country code`
| |
| Environment=PARALLEL_DOWNLOADS=50 # if your internet connection is fast
| |
| | |
| # Only uncomment this after you have done a complete build once
| |
| #Environment=KDE_BUILDER_ARGS="--no-src --install-only"
| |
| </nowiki>}}
| |
| | |
| You need to be using the BTRFS storage driver for docker, otherwise this won't really work.
| |
| | |
| If your host filesystem uses BTRFS (like KDE Linux), you can just add the following to /etc/docker/daemon.json
| |
| {{Input|1=<nowiki>
| |
| {
| |
| "storage-driver": "btrfs"
| |
| }
| |
| </nowiki>}}
| |
| | |
| [https://docs.docker.com/engine/storage/drivers/btrfs-driver/#configure-docker-to-use-the-btrfs-storage-driver official docker documentation explaining this]
| |
| | |
| If you don't use BTRFS in your host machine, you can still create a BTRFS volume backed by a file like so:
| |
| {{Input|1=<nowiki>
| |
| systemctl stop docker.socket docker.service || true
| |
| fallocate -l 64G /store/docker.btrfs
| |
| mkfs.btrfs /store/docker.btrfs
| |
| [ -d /var/lib/docker ] || mkdir /var/lib/docker
| |
| mount /store/docker.btrfs /var/lib/docker
| |
| systemctl restart docker.socket docker.service
| |
| </nowiki>}}
| |
| | |
| Then you can run:
| |
| | |
| {{Input|1=<nowiki>
| |
| ./build_docker.sh --incremental
| |
| </nowiki>}}
| |
| | |
| == Related projects ==
| |
| | |
| === Differences from other immutable distros ===
| |
| (e.g. Kinoite, Kalpa, SteamOS)
| |
| | |
| 1. '''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
| |
| | |
| 2. '''Relies on systemd tooling.''' This means it benefits from the bulk of development done on Systemd outside of KDE. So for example, updates use systemd-sysupdate rather than something like RPM-OStree.
| |
| | |
| 3. '''No packaging knowledge required to develop it.''' Packages are used to build the base OS, but not produced or altered.
| |
| | |
| 4. '''Offers multiple release schedules.''' This lets every user choose their personal preference with respect to newness vs stability. Should that preference change, switching to a different schedule is safe and painless.
| |
| | |
| === 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 and EOL plan ==
| |
| OS images are served from https://files.kde.org/kde-linux.
| |
| | |
| The EOL contingency plan is to push a final update shipping ships an OS image that transforms the system into a completely different distro, to be chosen at the appropriate point in time (i.e. which distro team we have a good relationship with that could take on all the new users when the time comes).
| |
| | |
| == Governance ==
| |
| | |
| TODO
| |
| | |
| == Promotion ==
| |
| | |
| TODO (name and branding, public image, effect on relations with other distros and hardware partners)
| |
| | |
| == Communication ==
| |
| * [https://go.kde.org/matrix/#/#kdeos:kde.org Matrix room]
| |
| * [https://invent.kde.org/sitter/kde-linux/-/issues Gitlab issues]
| |
| | |
| == Ideas ==
| |
| See [[🍌/Obstsalat]]
| |
| | |
| == External Resources ==
| |
| | |
| * Presentation by Harald Sitter at Akademy 2024 ([https://conf.kde.org/event/6/contributions/202/attachments/135/171/The%20Operating%20System.pdf slides], [http://www.youtube.com/live/gTxRaBEUe-I?t=25936 recording]).
| |
