Wie SteamOS für einen Wohnzimmer-PC geforkt wurde

 (iliana.fyi)
1 Punkte von GN⁺ 2024-01-01 | 1 Kommentare | Auf WhatsApp teilen
  • SteamOS 3 „Holo“ ist eine Arch-basierte Distribution für das Steam Deck, doch um das Problem beim Aufwachen aus dem Suspend auf einem Wohnzimmer-PC zu beheben, musste ein Kernel-Commit zurückgenommen und sogar das rootfs-Image direkt geforkt werden
  • Die Update-Struktur nutzt ein A/B-Verfahren: Ein neues schreibgeschütztes rootfs wird auf die inaktive Partition installiert und anschließend wird neu gestartet; /etc bewahrt Änderungen per overlayfs
  • Die Kernel-Patches von Valve entstehen aus Source-Tarballs wie linux-neptune-61-6.1.52.valve9-1.src.tar.gz auf dem pacman-Source-Mirror: Daraus wird ein Bare-Git-Repository geklont, anschließend werden Pakete mit eigenen Tags und PKGBUILD gebaut
  • Beim Repacking des rootfs wird rootfs.img.caibx aus einem SteamOS-RAUC-Bundle extrahiert und zu einem Image zusammengesetzt; danach folgen Btrfs-UUID-Änderung, Paketaustausch, Änderung der buildid, Austausch der Update-URLs und RAUC-Zertifikate und schließlich erneutes Bündeln als RAUC bundle
  • Ein eigener Webserver liefert live.json; wenn QueryUrl, ImagesUrl und MetaUrl von steamos-atomupd geändert werden, lassen sich auch bestehende SteamOS-Installationen auf das eigene Image aktualisieren

Warum SteamOS für einen Wohnzimmer-PC geforkt wurde

  • SteamOS 3 „Holo“ ist eine Arch-basierte Linux-Distribution von Valve Software für den tragbaren PC-Gaming-Handheld Steam Deck
  • Das Update-Verfahren ist als atomares A/B-Update aufgebaut: Ein neues schreibgeschütztes rootfs wird auf die inaktive Partition heruntergeladen, dann wird in diese Partition neu gestartet
  • Nutzer können steamos-devmode ausführen, die rootfs-Sperre aufheben und die pacman-Datenbank normalisieren, um das System wie eine gewöhnliche Linux-Distribution zu behandeln
  • Ziel war es, statt eines leicht zu umgehenden Wegs über steamos-devmode einen sauberen Fork zu erstellen, bei dem das rootfs-Image selbst verändert werden kann
  • Auf dem Wohnzimmer-PC funktionierte SteamOS fast vollständig, nur das Aufwachen aus dem Suspend schlug fehl
    • Andere Distributionen mit Mainline- oder Stable-Kernel konnten auf demselben Computer aus dem Suspend aufwachen
    • Nach dem Auffinden der Valve-Kernelquellen und einem git bisect stellte sich heraus, dass ein Commit, der offenbar das Aufwachen aus dem Suspend auf Steam-Deck-Hardware behebt, auf diesem PC Probleme verursachte
    • Diesen Commit zurückzunehmen und den Kernel selbst zu bauen, war der unmittelbare Auslöser für die gesamte Arbeit
  • Eine direkte Nutzung von Arch oder Ähnlichem wäre ebenfalls möglich gewesen, doch wenn schon eine Linux-Distribution für Spieleausführung angepasst werden muss, ist es vorzuziehen, auf das von Valve getestete Paketset zu setzen

Partitionen und Update-Struktur von SteamOS

  • Ein SteamOS-System verwendet acht Partitionen
    • Die EFI system partition enthält den Stage-1-Bootloader und Metadaten zur Auswahl des A/B-Partitionssets
    • Jedes A/B-Set enthält GRUB als Stage-2-Bootloader, das Root-Dateisystem und eine /var-Partition
    • Der restliche Speicherplatz wird von einer einzelnen home-Partition belegt
  • Beim Booten werden zusätzlich mehrere Pseudo-Dateisysteme eingehängt
    • Fast ein Dutzend Verzeichnisse wie /var/log, /root, /nix werden per Bind Mount aus /home/.steamos/offload eingebunden, um Daten dauerhaft zu speichern
  • /etc wird per overlayfs behandelt
    • Änderungen werden in /var/lib/overlays/etc/upper gespeichert
    • Einträge, die üblicherweise in /etc erhalten bleiben müssen, etwa machine-id oder NetworkManager-Verbindungen, bleiben bestehen
    • Nicht veränderte Konfigurationsdateien können aktualisiert werden
    • Dieses Verfahren ermöglicht in einer A/B-Partitionsstruktur sowohl das Beibehalten von Konfigurationsdateien als auch Updates, ganz ohne Paketmanager-Logik
  • Systemupdates werden gestartet, wenn der Steam-Client oder ein Terminalnutzer steamos-update ausführt
    • Dieser Befehl startet das Python-Programm steamos-atomupd-client
    • Der Client sendet aktuelle OS-Informationen und die Update-Channel-Einstellungen des Nutzers an die URL in /etc/steamos-atomupd/client.conf, um nach neuen Updates zu suchen
  • Wenn ein neues Update vorhanden ist, antwortet der Server mit dem Pfad zu einem RAUC bundle
    • Der Client lädt das Bundle herunter und führt rauc install aus
    • RAUC prüft die Bundle-Signatur und sucht nach rootfs.img.caibx
    • Mit casync extract werden neue Image-Chunks heruntergeladen und auf die inaktive rootfs-Partition geschrieben
    • Ein Post-Install-Skript synchronisiert selektiv Daten von der aktiven /var-Partition in die inaktive /var-Partition und ändert die Stage-1-Bootloader-Konfiguration auf der EFI system partition, damit in das neue Partitionsset gebootet wird

Pakete aus Valves Kernelquellen bauen

  • Valve verwendet in SteamOS einen stark modifizierten Linux-Kernel; die Quellen sind downloadbar
  • Die Quellen des aktuellen SteamOS-Images finden sich auf Valves pacman-Mirror unter sources/holo-3.5 und sources/jupiter-3.5
  • Zum Zeitpunkt des Schreibens war der Kernel des Stable-Images 6.1.52-valve9-1-neptune-61; der zugehörige Source-Tarball ist 2,9 GiB groß
  • Der Tarball ist so groß, weil er den vollständigen Linux-Git-Tree enthält
    • Im Tarball befinden sich unter anderem PKGBUILD, config, config-neptune und archlinux-linux-neptune/
    • archlinux-linux-neptune/ ist kein normaler direkt nutzbarer Working Tree, sondern ein Bare Repository
  • Das PKGBUILD verweist als Source auf ein privates GitLab-Repository in der Form git+ssh://git@gitlab.steamos.cloud/jupiter/linux-integration.git#tag=$_tag
    • Ein direkter Clone oder ein Link auf Commits ist nicht möglich
    • Aus den makepkg-Quellen lässt sich ein Snapshot mit der vollständigen Commit-Historie jedes Tags erhalten
    • Dank dieser Struktur konnte der Commit, der den Suspend des Wohnzimmer-PCs kaputt machte, per Bisect gefunden werden
  • Die Arbeitsweise besteht darin, das Bare Repository in einen normalen Working Tree zu klonen und eigene Branches und Tags zu pflegen
    • Das Beispiel erstellt aus dem Tag 6.1.52-valve9 einen Branch my-branch
    • Eigene Änderungen werden auf einen separaten Git-Host hochgeladen, und die source im PKGBUILD wird auf dieses Repository und ein eigenes Tag geändert
    • Als Beispiel-Repository dient linux
  • Kernelpakete lassen sich mit makepkg bauen
    • makepkg MAKEFLAGS=-j$(nproc) oder ein Update von /etc/makepkg.conf ist nützlich, wenn es sich nicht um eine kleine VM handelt
    • Soweit untersucht, nutzten auch SteamOS-spezifische Pakete eine ähnliche Struktur mit einem Git-Repository als erster source
  • Um spätere Schritte zu erleichtern, wird ein eigenes pacman-Repo eingerichtet
    • Pakete werden in ein Verzeichnis gelegt, dann wird repo-add $REPO_NAME.db.tar.zst [PACKAGES...] ausgeführt und das Ergebnis auf einen Webhost hochgeladen
    • Dieses Repo hilft später auch dabei, dass Werkzeuge korrekt funktionieren, falls steamos-devmode ausgeführt wird

Root filesystem beziehen und mounten

  • Da keine Release-Engineering-Skripte gefunden wurden, wurde der Ansatz gewählt, ein vorhandenes Root filesystem nach Bedarf neu zu packen
  • Das Skript ohne Erläuterungen und Kommentare liegt unter fauxlo
  • Übliche Wege, ein SteamOS-rootfs-Image zu erhalten, sind der Kauf eines Steam Decks oder das Herunterladen des Steam-Deck-Recovery-Images; beides erfordert jedoch die Zustimmung zum Steam End User License Agreement
  • Die aktuelle Release-Version lässt sich aus dem Snapshot-JSON ermitteln, das offenbar als Fallback-URL des Update-Systems dient
    • Zum Zeitpunkt des Schreibens war die Stable-Version 20231122.1
    • Für den Preview-Channel gibt es ein separates Snapshot-JSON
  • Der rootfs-Download folgt derselben Reihenfolge wie steamos-atomupd-client
    • Die .raucb-Datei, ein RAUC bundle, wird heruntergeladen
    • Aus dem Bundle, einem SquashFS-Dateisystem, wird rootfs.img.caibx extrahiert
    • Mit casync extract werden Chunks aus dem .castr Store geholt und rootfs.img erzeugt
    • Die URL des .castr Store ergibt sich, indem in der RAUC-Bundle-URL .raucb durch .castr ersetzt wird
    • Dieses Verhalten ist in steamos-atomupd fest verdrahtet
    • Das Automatisierungsskript liegt unter fetch-current.sh
  • Die benachbarten Dateien .img.zip und .img.zst sind kein rootfs, sondern separate bootfähige Recovery-Images
    • Aus einem Recovery-Image kann auch die rootfs-Partition extrahiert und im nächsten Schritt verwendet werden
    • Sie war jedoch nicht bitgenau identisch mit dem per RAUC und casync bezogenen Image, und zum erneuten Erstellen eines Update-Bundles werden diese Werkzeuge ohnehin benötigt
  • Vor dem Ändern des rootfs muss die Filesystem-UUID geändert werden
    • Wird beim Update von einem bestehenden SteamOS-Image auf ein Custom-Image die UUID nicht geändert, haben zwei unterschiedliche Filesystems dieselbe UUID
    • Dieser Zustand kann Probleme verursachen
    • Ein Beispiel ist btrfstune -fu rootfs.img
  • Valve verwendet ein Btrfs-Image mit zstd-Kompression
    • Um die Kompression während der Änderungen beizubehalten, wird es mit mount -o compress=zstd rootfs.img rootfs gemountet
    • SteamOS nutzt die readonly-Subvolume-Eigenschaft von Btrfs, daher wird sie mit btrfs property set -ts rootfs ro false deaktiviert
  • Änderungen an Paketen wie dem Linux-Kernel können Skripte auslösen, die /dev und /proc benötigen
    • devtmpfs und proc werden unterhalb des rootfs gemountet
    • Auf /tmp, /run, /var und /home wird tmpfs gemountet, damit nicht in Verzeichnisse geschrieben wird, die im gebooteten System gemountet werden
    • Die /etc/resolv.conf des Hosts wird per Bind Mount eingebunden, damit Namensauflösung im chroot funktioniert

Pakete ersetzen und Image-Metadaten ändern

  • Das eigene Repository wird als erster Repo-Eintrag in /etc/pacman.conf hinzugefügt
    • Dadurch haben eigene Pakete Vorrang, selbst wenn in Valves Repo Pakete mit neuerer Version liegen
    • Auch nach einem späteren Ausführen von steamos-devmode können eigene Pakete erneut installiert werden
  • Ein Beispiel-Repo-Stanza verwendet [fauxlo], Server = https://fauxlo.ili.fyi/pacman/$arch und SigLevel = Never
    • SigLevel = Never erlaubt Pakete auch ohne Paketsignatur
    • Um GPG-signierte Pakete zu installieren, muss der pacman-Keyring befüllt werden
    • Statt den leeren Keyring unter /etc/pacman.d/gnupg anzufassen, wird ein neuer Keyring auf tmpfs befüllt
  • Die Paketinstallation erfolgt in der Form pacman --sysroot rootfs --noconfirm -Sy linux-neptune-61
    • Im tatsächlichen Skript wird -y vermieden und nur die Datenbank des eigenen Repos hinter pacman synchronisiert
    • Dadurch lässt sich der Zustand anderer Repositories auf den Zeitpunkt fixieren, zu dem das ursprüngliche Image gebaut wurde
    • Das ist eine Entscheidung, um die im Image-Diff sichtbaren Änderungen zu reduzieren
  • steamos-atomupd liest die aktuelle Image-Version und Build-ID aus /lib/steamos-atomupd/manifest.json; falls diese Datei fehlt, wird /etc/os-release verwendet
    • Wenn die Build-ID des vom Server bereitgestellten Updates mit der des aktuellen Images identisch ist, wird das Update abgelehnt
    • Sie ist außerdem nützlich, um zu erkennen, welches Image gerade läuft
  • Die Build-ID muss zwingend das Format YYYYMMDD.N haben
    • Passt das Format nicht, beendet sich steamos-atomupd mit einem Python-Traceback
    • Um manuelles Hochzählen zu vermeiden, kann für N HHMMSS oder ein Unix-Timestamp verwendet werden
    • Sowohl buildid in manifest.json als auch BUILD_ID in os-release werden geändert
    • Ein Bash-Skriptausschnitt dafür befindet sich in repack.sh
  • RAUC nutzt X.509-Zertifikate für die Vertrauenseinstellungen
    • Das vertrauenswürdige Zertifikat liegt in /etc/rauc/keyring.pem
    • Ein einfaches self-signed certificate reicht aus
    • Das neue Zertifikat wird nach rootfs/etc/rauc/keyring.pem installiert
  • Auch die URLs in rootfs/etc/steamos-atomupd/client.conf werden auf den eigenen Server geändert
    • QueryUrl
    • ImagesUrl
    • MetaUrl
  • Solange die Größe des 5-GiB-Btrfs-Images nicht überschritten wird, sind weitere Änderungen möglich
    • Wenn ein SteamOS-Gerät im Netzwerk beispielsweise als hostname.local gefunden werden soll, kann rootfs/usr/lib/systemd/resolved.conf.d/00-disable-mdns.conf entfernt werden
    • Das ließe sich auch über die /etc-Overlay-Konfiguration überschreiben, wurde aber als umständlich eingeschätzt
  • Änderungen, die sich ohne Image leicht durchführen lassen, sollten grundsätzlich nicht ins rootfs aufgenommen werden
    • Firefox ließe sich zwar im rootfs installieren
    • Dann müsste das Image aber bei jedem Firefox-Sicherheitsupdate erneut repackt werden

rootfs aushängen und RAUC bundle erstellen

  • Nach Abschluss der Änderungen wird das Filesystem wieder als read-only markiert
    • btrfs property set -ts rootfs ro true
  • Nicht genutzte Blöcke werden mit fstrim -v rootfs discardet
  • Zum Aushängen ist umount --recursive rootfs nützlich
    • Damit lassen sich auch die zuvor gemounteten Pseudo-Dateisysteme gemeinsam behandeln
  • Vor dem Erstellen des RAUC bundle werden casync store und Blob-Index erzeugt
    • Beispiel: casync make --store=rootfs.img.castr bundle/rootfs.img.caibx rootfs.img
  • Das RAUC bundle benötigt drei Dateien
    • manifest.raucm
    • rootfs.img.caibx
    • UUID mit der Filesystem-UUID
  • manifest.raucm enthält Update-Informationen und Informationen zum rootfs-Image
    • compatible=steamos-amd64
    • version=$version
    • sha256
    • size
    • filename=rootfs.img.caibx
  • Die Datei UUID wird mit blkid -s UUID -o value rootfs.img >bundle/UUID erzeugt
  • Sobald die drei Dateien vorbereitet sind, wird rauc bundle ausgeführt
    • Zertifikat und Schlüssel werden mit --signing-keyring, --cert und --key angegeben
    • Das Ergebnis ist rootfs.img.raucb
  • rootfs.img.raucb und rootfs.img.caibx werden auf den Webserver hochgeladen, auf den ImagesUrl in client.conf zeigt
    • Beide Dateien müssen im selben Verzeichnis liegen

Eigener Update-Server und Anwendung

  • Der für QueryUrl und MetaUrl verwendete Webserver muss JSON-Dateien bereitstellen
  • In einer einfachen Konfiguration reicht eine einzelne live.json
    • Das Objekt .minor.candidates[0].image muss mit /lib/steamos-atomupd/manifest.json im Image übereinstimmen
    • update_path ist der Pfad, den der Update-Client an ImagesUrl anhängt, um das Bundle herunterzuladen
  • Die Beispielkonfiguration für Caddy rewritet die Requests, die steamos-atomupd an QueryUrl und MetaUrl sendet, auf live.json
    • /updates wird auf /live.json rewritet
    • /meta/*/*/*/*.json und /meta/*/*/*/*/*.json werden auf /live.json rewritet
    • file_server browse wird verwendet
  • Die tatsächlichen QueryUrl und MetaUrl von SteamOS scheinen mehr Logik zu enthalten, doch auch mit dieser Konfiguration kann steamos-atomupd ein neues Update finden
  • Es gibt Logik, die ein Update vermeidet, wenn das bereits beworbene Image aktuell ausgeführt wird
  • Um eine bestehende SteamOS-Installation auf das eigene Image zu aktualisieren, müssen /etc/rauc/keyring.pem und /etc/steamos-atomupd/client.conf geändert werden
    • steamos-readonly disable ist nicht nötig
    • Die Änderungen landen im /etc-Overlay
    • Nach dem Ausführen von steamos-update sollte erwogen werden, diese Änderungen aus /var/lib/overlays/etc/upper zu bereinigen
  • Es scheint möglich, eines der Valve-Recovery-Images so zu ändern, dass das rootfs durch ein eigenes Image ersetzt wird, um eine modifizierte SteamOS-Variante zu installieren; dieser Weg wurde jedoch nicht getestet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-01
Hacker-News-Kommentare

  • Ich mag solche Beiträge, in denen jemand die Software/das OS seiner eigenen Geräte tiefgehend anpasst. Schön ist auch, dass man sich beim Steam Deck keine Sorgen um Tivoization machen muss.
    Am interessantesten fand ich im Artikel die /nix-Partition. Ich wusste nicht, dass das Steam Deck nixpkgs unterstützt; beim Nachlesen stellte sich heraus, dass es zwar keine Standardinstallation ist, man es aber auf das Gerät bringen kann, ohne das gesamte OS zu forken.

    • Nix ließ sich ursprünglich auf jedem *nix-OS installieren, ohne „das gesamte OS zu forken“.
      Den Nix-Store kann man an einem beliebigen beschreibbaren Ort ablegen, und dann muss man $PATH nur auf ein Verzeichnis mit symbolischen Links zeigen lassen.
    • Weiß jemand, welche Teile von nixpkgs auf dem Steam Deck genutzt werden? Ich verwende nixpkgs selbst ziemlich viel und bin neugierig, habe aber leider kein Steam Deck.

  • Ein wirklich gründlicher und interessanter Beitrag. Persönlich würde ich wohl nie so weit gehen.
    Mit Linux habe ich nur in meiner Raspberry-Pi-Zeit herumgespielt, und selbst da vielleicht zu 1 %, daher wirkt der Autor auf mich beeindruckend.

    • Ich war in einer ähnlichen Situation wie der Autor. Über eine ziemlich lange Zeit musste ich aus einem sehr speziellen Grund meinen eigenen Red-Hat-Kernel bauen: um die RMRR-Prüfung zu umgehen und eine GPU an eine Windows-VM durchzureichen.
      Ähnlich wie https://github.com/kiler129/relax-intel-rmrr, aber das ist nicht mein Repository.
      Die eigentliche Ursache ließe sich nur durch ein ROM-Update des Herstellers beheben, aber mein alter DL360 wird von HPE nicht mehr unterstützt.
      Der Patch selbst ist nur eine Änderung in einer Zeile, aber Kernel-Updates sind mühsam. Man muss das SRPM herunterladen, und da es kein Git-Repository gibt, das SRPM entpacken, den Patch anwenden, danach neu bauen und installieren.
    • Wenn man einen Fernseher will, könnte es bald wirklich keine Auswahl mehr geben.

  • Es gibt bereits Distributionen, die auf SteamOS-Komponenten basieren und auf die Nutzung mit PC und Controller zugeschnitten sind. ChimeraOS enthält sogar EmuDeck, ein Zusatztool für das Steam Deck, und läuft in meiner Umgebung ziemlich problemlos.

  • Ich habe eine GPU bestellt, um Steam Headless auf meinem unRaid-NAS-Server als schickes Docker-Image laufen zu lassen und mich von einem Windows-Laptop aus mit einem Client wie Moonlight zu verbinden.
    Wenn das gut funktioniert, ist das deutlich besser, als zusätzlich Gaming-Desktop-Hardware zu kaufen, während das NAS die meiste Zeit im Leerlauf ist. Allerdings muss ich die Nvidia-Karte im Leerlauf halten, wenn sie nicht genutzt wird. Hoffentlich geht das mit einem Aufruf von nvidia-persistenced.
    1: https://github.com/Steam-Headless/docker-steam-headless

    • Ich habe ziemlich viel Zeit damit verbracht, fast dasselbe mit GOW zum Laufen zu bringen. Es war deutlich schwieriger als erwartet, und um die X-Server-Konfiguration hinzubekommen, brauchte ich sogar einen HDMI-Dummy-Stecker.
      1: https://github.com/games-on-whales/gow
    • Als weitere Alternative kann man eine KVM mit GPU-Passthrough starten und per cloud-init Sunshine und das Spiel ausführen, oder einfach direkt einen Monitor verwenden.
      https://kubevirt.io/user-guide/virtual_machines/host-devices...
      Deklaratives, cloud-natives Starten von Spielen!
      kubectl apply -f crysis.yaml
    • Sieht gut aus. Im Moment nutze ich Sunshine + Moonlight, werde aber bald die Steam-Headless-Performance testen.
    • Ziemlich interessant. Merkt man bei lokalem Netzwerk-Streaming auf diese Weise Grenzen bei Eingabeverzögerung oder Bildqualität?
    • Nett. Ich stelle mir schon länger ein Setup vor, bei dem man rundenbasierte Hotseat-Spiele wie Civilization auf einem Server laufen lässt und per Browser remote darauf zugreift, damit man mit Freunden jederzeit und überall lange Runden spielen kann.

  • Heute habe ich RAUC(https://rauc.io/) kennengelernt. Ich hatte mich gefragt, wie Valve den A/B-Update-Ansatz umgesetzt hat.

  • Vermisst man nicht ein bisschen Netscapes Meteorregen-Favicon?

  • Interessanter Beitrag. A/B-Upgrades wirken etwas übertrieben. Wenn etwas schiefgeht, kann man schließlich eine Live-Distribution starten oder ein Recovery-System einer älteren Version auf einer separaten Partition installieren.
    Nachdem ich in den letzten Jahren NixOS genutzt hatte, bin ich wieder zu Arch zurückgekehrt; davor hatte ich Arch schon lange verwendet, und ich glaube, die Sorgen des Autors gehen daneben.
    Arch ist definitiv eine sehr ernsthafte und ausgereifte Distribution und vertrauenswürdiger als Valve.
    Der Grund für meinen Wechsel zu Arch war die Paketqualität. Das Haupt-Repository wird wirklich schnell aktualisiert, und im AUR gibt es viele nützliche Pakete.

    • Du und ich können eine Live-Distribution starten, aber die überwältigende Mehrheit der Computernutzer kann das nicht. Valve konzentriert sich eindeutig darauf, für Durchschnittsnutzer zu bauen, und Linux-Distributionen sind darin, so sehr ich sie mag, noch nicht besonders gut.
      Dass sich ein System nach einem fehlgeschlagenen Upgrade automatisch wiederherstellt, ist bei einem wartungsarmen OS heute fast unverzichtbar.
    • Man sollte nicht erwarten, dass Steam-Deck-Nutzer eine Live-Distribution booten müssen, um ein kaputtes Upgrade zu reparieren. Das sollte nahtlos und im Hintergrund passieren.
    • Machbar wäre es wohl, aber inzwischen gibt es Technik, die so etwas unnötig macht, und Festplattenspeicher ist auch nicht so teuer; warum sollte man es also nicht tun?
    • Das Steam Deck ist im Kern eher ein Chromebook für Videospiele, daher wirkt das schwer kaputtzubekommende Partitionsmodell von ChromeOS wie eine vernünftige Idee.
    • Kannst du Beispiele dafür nennen, dass du wegen der Arch-Paketqualität von NixOS gewechselt bist?
      Ich halte die Qualität der NixOS-Pakete im Allgemeinen für hoch.

  • In letzter Zeit habe ich ein Legion Go, ein Gaming-Handheld, in die Finger bekommen und beschäftige mich dadurch mehr mit Linux. Früher wirkte es auf mich wie endlos vergeudete Bastelzeit, und weil die Kompatibilität mit Dingen, die ich tatsächlich nutzen wollte, eingeschränkt war, habe ich es gemieden.
    Als ich über unveränderliche Dateisysteme las und darüber, dass traditionelles Linux beliebiger Software allzu leicht Root-Rechte einräumt, wurde ich neugierig.
    Im Moment nutze ich NixOS. Das kann definitiv zu vergeudeter Bastelzeit werden, ist aber gut zum Erkunden. Man kann verschiedene Komponenten leicht ausprobieren und, wenn man sie nicht behalten will, bis auf etwas Verschmutzung in ~/.config vollständig entfernen. Auch das Patchen vor der Installation ist trivial, sodass sich Kernel-Patches, die Linux auf ungewöhnlicher Hardware wie Gaming-Handhelds nutzbar machen, leicht hinzufügen lassen.
    Eine NixOS-Community namens Jovian rekonstruiert Valves beliebige SteamOS-Tarballs als getaggte Commits auf GitHub, sodass man sich die Quellen ansehen kann wie ein Valve-Mitarbeiter. Mit ein paar zusätzlichen Zeilen in der Nix-Konfiguration kann man seine eigene Kopie von SteamOS auf NixOS installieren.
    Das sind offensichtlich Linux-Experten, und am Quellcode sieht man, dass sie die Valve-Pakete unverändert übernehmen, abgesehen von einfachen Anpassungen wie dem Prüfen statt Hardcodieren der Position des Power-Buttons.
    Wenn man eine unverfälschte SteamOS-Erfahrung möchte, aber keinen eigenen Mirror für Valves Update-System betreiben will, oder wenn man Valves Quellen erkunden möchte, ohne 3-GB-Tarballs herunterzuladen, ist Jovian einen Blick wert.
    Installationsanleitung: https://jovian-experiments.github.io/Jovian-NixOS/getting-st...
    Valve-Quellen-Mirror: https://github.com/orgs/Jovian-Experiments/repositories?type...

    • Ich nutze Jovian-NixOS ebenfalls problemlos auf dem Steam Deck und kann es sehr empfehlen.

  • bazzite.gg macht das ebenfalls ausgesprochen gut. Auf AMD-Hardware funktionierte 120Hz VRR direkt, und HDR-Unterstützung kann man auch im Alpha-Test ausprobieren.

    • Von Bazzite hatte ich noch nie gehört.
      „Bazzite ist ein OCI-Image, das als alternatives Betriebssystem für das Steam Deck genutzt werden kann, und eine sofort spielbereite, SteamOS-ähnliche Umgebung für Desktop-Computer, Wohnzimmer-Home-Theater-PCs und mehrere Handheld-PCs.“
      https://github.com/ublue-os/bazzite/
      Selbst wenn man kein Interesse daran hat, lohnt sich die README. Die Liste der enthaltenen Dinge ist enorm lang, und besonders für Gamer oder Streamer sind viele Punkte dabei, die ziemlich cool und nützlich wirken.
    • Bazzite und unveränderliches Linux allgemein sind interessant.
      Ich habe mich nicht tief genug eingearbeitet, um es in einem HN-Kommentar knapp und perfekt zu erklären, aber im Kern liegt unter Root eine schreibgeschützte, verifizierte Linux-Distribution, auf die Pakete als Schichten aufgesetzt werden. Die Struktur ist stark von serverseitigen Containern inspiriert.
      Ziel ist es, sicherer, zuverlässiger, reproduzierbarer und leichter anpassbar zu sein als traditionelles Linux. Man schreibt die gewünschten Pakete in ein Container-Manifest; wenn ein Upgrade erscheint, führt man das Upgrade aus und installiert die Pakete anschließend wieder darüber.
    • Relevanter ist außerdem, dass man Bazzite relativ einfach forken kann, fehlende Pakete oder benötigte Einstellungen in ein eigenes Custom-Image einbaut und den Großteil der Infrastrukturarbeit GitHub Actions überlässt.
      https://universal-blue.org/guide/fork-your-own/
      Und weil es ein unveränderliches OS ist, kann man bei Problemen auf ein vorheriges Image zurückrollen.
    • Laut Steams Jahresrückblick war 2023 das erste Jahr, in dem ich ausschließlich unter Linux gespielt habe, einschließlich einiger Titel, die in diesem Jahr erschienen sind.
      Meistens lief das entweder auf dem Steam Deck oder in einer virtuellen Maschine mit GPU-Passthrough, jeweils mit Bazzite, und es ist wirklich gut gemacht.
    • Es überrascht mich, dass Bazzite nicht bekannter ist. Es ist genau das, wovon ich geträumt hatte, und bis vor Kurzem wusste ich nicht einmal, dass es existiert.

  • Wohnzimmer-PC — sagt man inzwischen HTPC oder „Media Center“ nicht mehr so oft?