Einführung in unveränderliche Linux-Systeme

 (dataswamp.org)
3 Punkte von GN⁺ 2023-09-19 | 1 Kommentare | Auf WhatsApp teilen
  • Unveränderliche Linux-Distributionen bereiten Upgrades nicht auf dem laufenden System vor, sondern wenden sie beim nächsten Start an, wodurch ein Betriebsmodell mit Rollback im Fehlerfall entsteht
  • Anders als der Name „unveränderlich“ vermuten lässt, können viele Bereiche des Systems weiterhin verändert werden; die tatsächliche Gemeinsamkeit liegt eher bei transaktionalen Updates und Rollback
  • NixOS·Guix stellen deklarative Konfiguration und einen schreibgeschützten Store in den Mittelpunkt, während OSTree-Systeme·MicroOS·Vanilla OS jeweils mit /usr, btrfs-Snapshots und A/B-Root-Partitionen arbeiten
  • Die Vorteile liegen darin, das System auch während Paketänderungen stabil zu halten und Probleme zurückrollen zu können; offen bleiben aber die Notwendigkeit von Neustarts, Konflikte mit Konfigurationsmanagement-Tools und die schwierige Nachverfolgung von Änderungen
  • Neu ist weniger der Snapshot selbst als vielmehr, Änderungen in einer Nicht-Live-Umgebung anzuwenden und sie in Bootloader und Benutzerwerkzeuge zu integrieren, damit sie leichter nutzbar werden

Der tatsächliche Umfang des Begriffs „unveränderlich“

  • Unveränderlichkeit bedeutet ursprünglich ein Objekt, das sich nicht verändert, wird bei einem Betriebssystem aber sofort unscharf
  • Linux-LIVE-CDs wirken unveränderlich, weil sie jedes Mal mit denselben Programmen booten und das Medium schreibgeschützt ist; während des Betriebs lassen sich aber weiterhin Dateien und Verzeichnisse anlegen oder Pakete installieren
  • Um heute im Allgemeinen als unveränderliche Linux-Distribution zu gelten, sind meist drei Bedingungen nötig
    • System-Upgrades werden nicht direkt auf dem Live-System durchgeführt
    • Paketänderungen werden beim nächsten Start angewendet
    • Ein Rollback auf den vorherigen Zustand ist möglich
  • Je nach Implementierung gibt es zusätzliche Funktionen, aber diese drei Punkte kommen den Mindestanforderungen für heutige „unveränderliche“ Distributionen am nächsten

Unterschiede zwischen den Implementierungen

  • NixOS / Guix

    • NixOS und Guix basieren auf derselben Implementierungsfamilie; Nix erschien erstmals 2003, und der Guix-Paketmanager wurde Anfang der 2010er Jahre aus Nix geforkt, mit dem Ziel, zu 100 % freie Software zu bieten
    • Beide Systeme unterscheiden sich stark von traditionellen Unix-artigen Systemen und machen Unveränderlichkeit zu einem Kernprinzip
    • Alle Pakete und erzeugten Build-Dateien werden als eindeutige Einträge in einem speziellen schreibgeschützten Verzeichnis gespeichert, das nur der Paketmanager verwenden kann
    • Das Betriebssystem selbst ist das Ergebnis des Paketmanagers, und der Nutzer beschreibt den gewünschten Systemzustand als deklarative Konfiguration
    • Diese Konfiguration umfasst Benutzer, Shell, installierte Pakete, laufende Dienste und deren Einstellungen sowie einzuhängende Partitionen und Optionen
    • Da Module Standardwerte liefern, müssen beim Anlegen eines Benutzers nicht UID, GID, Shell und Home-Verzeichnis alle manuell angegeben werden
    • Auch Dateien wie /etc/fstab oder /bin/sh sind schreibgeschützt und können nur über den Paketmanager verändert werden
    • Das Umschalten der Konfiguration ähnelt dem Umsetzen symbolischer Links und ist sofort möglich; beim Booten kann zur Rollback-Zwecken eine frühere Konfiguration gewählt werden
    • Abgesehen vom speziellen Store-Verzeichnis bleiben /home, /etc, /var usw. veränderbar; systemweite symbolische Links lassen sich zwar durch andere ersetzen, die Originalquellen selbst aber nicht ändern
    • NixOS gilt als gute Implementierung, wird aber trotz seiner Vorteile wenig übernommen, weil es sich zu stark von bestehenden Systemen unterscheidet

  • Endless OS

    • Endless OS ist ein frühes unveränderliches OS für Endnutzer und zielt auf ein robustes System, das auch in Ländern mit schwacher Internet- oder Stromversorgung nutzbar ist
    • Es basiert auf Debian, setzt für die Unveränderlichkeit aber auf OSTree
    • OSTree verwaltet das zentrale System-Image und fügt darüber Schichten wie Pakete hinzu; außerdem kann es ein neues System-Image für den nächsten Start vorbereiten
    • Paketänderungen werden auf eine neue Systemversion angewendet, die beim nächsten Start verwendet wird; beim Booten kann zur vorherigen Version zurückgekehrt werden
    • Die Partitionen sind überwiegend beschreibbar, aber /usr als von OSTree verwalteter Paketbereich wird schreibgeschützt eingehängt
    • Für /etc gibt es kein Rollback
    • Programme für Nutzer werden per Flatpak installiert, damit nicht nach jeder neuen Paketinstallation ein Neustart nötig ist
    • Das angepasste GNOME-Desktop wirkt wie ein Smartphone-Menü und soll für nichttechnische Nutzer vertraut sein
    • Die Installation von DevOps-Werkzeugen ist nicht besonders praktikabel, aber auch nicht unmöglich

  • Fedora Silverblue

    • Fedora Silverblue steht in der Nachfolge von Project Atomic, das Fedora / CentOS / RHEL unveränderlich machen wollte
    • Es verwendet rpm-OSTree, das RPM-Paketänderungen auf OSTree anwendet
    • Das System besteht aus einem einzelnen Kern-Image pro Release und darüberliegenden zusätzlichen Paketschichten
    • Installierte Paketschichten lassen sich auflisten; entfernt man ein Paket, wird der gesamte Stack neu aufgebaut, sodass nach der Entfernung keine Reste zurückbleiben
    • Dieser Neuerzeugungsprozess ist sehr langsam
    • Selbst nach einer Paketinstallation wird sie nicht auf das aktuell gebootete System angewendet, daher ist standardmäßig ein Neustart erforderlich; beim Booten kann eine frühere Systemversion gewählt werden
    • rpm-OSTree bietet eine Funktion, Änderungen für den nächsten Start per tmpfs-Overlay vorübergehend in das Live-System einzublenden
    • Die Mount-Politik ist mit Ausnahme von /etc, /root und /var schreibgeschützt; Home-Verzeichnisse liegen standardmäßig unter /var/home, was von Erwartungen abweichen kann
    • /etc wird nicht von rpm-OSTree verwaltet und daher auch nicht zurückgerollt
    • /usr/local ist ein symbolischer Link auf ein Verzeichnis in /var, wodurch sich Benutzeränderungen auch ohne RPM-Dateien leicht einschleusen lassen
    • Weil Paketinstallationen langsam sind und Neustarts erfordern, wird die Nutzung von Flatpak oder toolbox empfohlen
    • toolbox erstellt einen Fedora-Container ohne Root-Rechte, damit Entwicklungsbibliotheken oder Werkzeuge im Terminal genutzt werden können

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS ist ein unveränderlicher Spin des Rolling-Release-Systems OpenSUSE Tumbleweed und verwendet eine eigene Implementierung
    • Das gesamte System liegt auf btrfs-Snapshots, abgesehen von einigen Verzeichnissen wie /home und /var
    • Wenn Systemänderungen nötig sind, wird der aktuelle Snapshot als neuer Snapshot geklont, die Änderungen werden auf diesen angewendet und beim nächsten Start verwendet
    • Anders als bei OSTree-basierten Systemen ist auch /etc Teil des Snapshots und kann daher zurückgerollt werden
    • Innerhalb des neuen Snapshots kann per Shell jede Datei im Dateisystem verändert werden, was etwa nützlich ist, um Dateien zur Behebung von Treiberproblemen einzuschleusen
    • Solche Änderungen werden allerdings nicht nachverfolgt, sodass sich schwer garantieren lässt, ob das System noch in einem „sauberen“ Zustand ist
    • Änderungen werden mit dem Befehl transactional-update durchgeführt; dabei lassen sich Pakete hinzufügen oder entfernen oder in einem Shell-Zustand innerhalb des neuen Snapshots beliebige Änderungen vornehmen
    • /etc ist zwar Teil des Snapshots, aber immer lesbar; wird /etc im Live-Zustand verändert und danach ein neuer Snapshot erzeugt, wird diese Änderung sofort vererbt
    • Der Standardansatz geht davon aus, nach Updates täglich einen Neustart einzuplanen; da es sich um Rolling Release handelt, gibt es tägliche Updates, und vor dem Neustart profitiert man nicht von den neuen Paketen
    • Automatische Neustarts lassen sich deaktivieren
    • Eine Funktion wie bei Silverblue, Änderungen auf das Live-System anzuwenden, ist derzeit experimentell und noch nicht nutzbar
    • Stattdessen wird empfohlen, mit distrobox rootlose Container verschiedener Distributionen zu verwenden, um Benutzerwerkzeuge zu installieren

  • Vanilla OS

    • Vanilla OS basiert auf Ubuntu und ist ein neues unveränderliches System, das bald auf Debian als Basis umsteigen soll
    • Die Unveränderlichkeit wird mit ABroot umgesetzt
    • ABroot verwendet eine Root-Partition A, eine Root-Partition B und eine Partition für persistente Daten wie /home oder /var
    • Der Boot- und Änderungsablauf sieht wie folgt aus
      • Der erste Start erfolgt von A, und A wird schreibgeschützt eingehängt
      • Systemänderungen wie neue Pakete oder Änderungen an /etc werden auf B angewendet; eine Live-Anwendung per tmpfs-Overlay ist ebenfalls möglich
      • Nach dem Neustart wird von B gebootet, und bei Erfolg scannt ABroot die Unterschiede zwischen A und B und übernimmt die Änderungen von B nach A
      • Wenn es keine neuen Änderungen gibt, sind A und B immer identisch
    • Der Nachteil ist, dass ein Rollback nur bis vor dem Booten der neuen Version möglich ist
    • Sobald die neue Version gebootet wurde, werden die Änderungen auch auf die Partitionsseite des vorherigen Starts übernommen, sodass kein Rollback mehr möglich ist
    • Dieser Ansatz ist vor allem nützlich, um fehlgeschlagene Upgrades oder live getestete Änderungen rückgängig zu machen
    • Vanilla OS bietet den Paketmanager apx
    • apx ist ein Werkzeug vom Autor von distrobox und erlaubt nicht-root-Nutzern, Pakete aus verschiedenen Distributionen wie Arch Linux, Fedora, Ubuntu oder Nix zu installieren und wie eine lokale Installation zu integrieren
    • Vanilla OS, ABroot und apx sind noch jung und haben raue Kanten

  • Alpine Linux with LBU

    • Alpine Linux kann mit dem Befehl lbu in eine Konfiguration gebracht werden, die einer Unveränderlichkeit nahekommt
    • Dabei wird der Alpine-Installer als Standard-Boot-System verwendet und ein Tarball mit „gespeicherten Einstellungen“ erzeugt, der beim Start automatisch angewendet wird
    • Bei jedem Booten werden Verzeichnisse erneut entpackt und Pakete neu installiert; alles ist im Live-Speicher vollständig beschreibbar
    • Man startet immer von einem sauberen Zustand und wendet Änderungen darüber an; diese Änderungen lassen sich zurückrollen und neu beginnen
    • Die zuvor definierte Unveränderlichkeit erfüllt das jedoch nicht vollständig, weil Änderungen auf das Basissystem aufgebracht werden
    • Da das gesamte System im Speicher liegt und man selbst festlegen muss, was gespeichert und wiederhergestellt wird, ist ein hohes Verständnis nötig; außerdem kann das Archiv groß werden
    • Auch die Dokumentation ist knapp

Vorteile und betriebliche Einschränkungen

  • Vorteile

    • Bei Problemen lassen sich Änderungen zurückrollen
    • Transaktionale Updates helfen dabei, dass das System auch während Paketänderungen korrekt weiterläuft

  • Nachteile

    • Die Integration mit Konfigurationsmanagement-Tools wie Ansible, Salt oder Puppet ist sehr schlecht
    • Selbst wenn diese Werkzeuge für die Art der Anwendung von Paketänderungen aktualisiert wurden, stößt man schnell an Grenzen, sobald man das System wie ein normales System verwalten will
    • Dass nach Änderungen neu gestartet werden muss, ist lästig; bei NixOS und Guix ist aber nicht für jede Änderung ein Neustart nötig
    • OSTree-basierte Systeme sind nicht flexibel
      • Ein Beispiel: Wenn ein Netbook für Sound zusätzliche Dateien im ALSA-Verzeichnis braucht, lassen sie sich nicht hinzufügen, ohne ein Paket zu bauen, das genau diese Dateien ausliefert
    • Rollbacks sind eher blinde Rollbacks, weil sich schwer nachvollziehen lässt, welche Änderungen in welcher Systemversion enthalten waren
    • Programme wie Nix/Guix, die Verzeichnisse im Root-Dateisystem brauchen, oder systemweite Installationen nicht paketierter Software können schwierig sein

Fakten und Missverständnisse über unveränderliche Systeme

  • Unveränderlichkeit ist streng genommen fast ein falsches Versprechen, denn viele Teile des Systems bleiben weiterhin veränderbar
  • Unveränderlich bedeutet nicht zustandslos (stateless)
  • NixOS und Guix verfolgen das gesamte System mit stabilen Paketmanagern, und für die Quellen kann Versionsverwaltung eingesetzt werden; deshalb gelten sie als Implementierungen, die von Anfang an die richtige Philosophie hatten
  • Unveränderlichkeit wird oft mit Sicherheitsvorteilen verbunden, doch ein Angreifer mit Root-Rechten kann das Live-System manipulieren und auch die /boot-Partition verändern
  • Nichts verhindert das Einrichten einer Backdoor für den nächsten Start
  • Unveränderlichkeit verlangt Disziplin und Wartung
    • Man muss auf Versionsverwaltung achten
    • Zusätzliche Programme wie apx, distrobox oder devbox müssen getrennt vom System aktualisiert werden
    • Bei NixOS und Guix ist dieser Teil integriert

Was daran tatsächlich neu ist

  • Unveränderliche Betriebssysteme bekommen in der Open-Source-System-Community viel Aufmerksamkeit, doch unter demselben Begriff werden sehr unterschiedliche Implementierungen und Anwendungsfälle zusammengefasst
  • Der Name „unveränderlich“ weckt bestimmte Erwartungen, tatsächlich geht es eher um transaktionale Updates für Betriebssysteme
  • Transaktionale Updates selbst sind kein neues Konzept
    • Solaris und ZFS konnten beim Booten bereits einen System-Snapshot zur Auswahl stellen
    • FreeBSD scheint schon vor etwa zehn Jahren Ähnliches umgesetzt zu haben
    • Auch allgemeine Linux-Distributionen können mit btrfs-Snapshots beim Booten einen Snapshot auswählen
  • Wirklich neu ist, transaktionale Änderungen in einer Nicht-Live-Umgebung anzuwenden, das Ganze in den Bootloader zu integrieren und benutzerfreundliche Werkzeuge dafür bereitzustellen
  • Als weiterführende Lektüre wird Colin Walters “Immutable” → reprovisionable, anti-hysteresis empfohlen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-19
Meinungen auf Hacker News

  • Schön, Silverblue auf der Liste zu sehen, aber schade, dass Fedora CoreOS fehlt
    FCOS ist ein gutes OS für den Produktionseinsatz, hat sich seit der Übernahme von CoreOS stark weiterentwickelt und wirkt wie ein guter Mittelweg: leichter zu lernen und zu nutzen als Nix, während es dennoch die Unveränderlichkeit beibehält
    CoreOS Layering, das die FCOS-Entwickler hinzugefügt haben, ist eine mächtige Funktion: Definiert man den Systemzustand per Dockerfile, rebased FCOS auf diesen Zustand, und für die Serverkonfiguration reicht ein Neustart
    Wenn man für das nächste Projekt eine VM braucht, lohnt sich ein Versuch. Ich habe außerdem Bupy gebaut, ein Python-basiertes CLI-Tool, das das lokale Erstellen von Butane-Dateien auf einer Linux-Workstation erleichtert, und es gibt auch ein Beispiel, das Paperless NGX mit CoreOS Layering betreibt
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • Mich würde auch interessieren, was du von Flatcar hältst, einem weiteren Projekt aus der CoreOS-Familie
      Am schwierigsten fand ich, herauszufinden, wie man solche Projekte in Bare-Metal-Umgebungen einsetzen soll. VM-Images zu erstellen ist nett, aber in der Praxis will man oft auf ein vorhandenes Laufwerk installieren oder darunter einen ZFS-Pool haben und darauf installieren
    • CoreOS Layering sieht wirklich nützlich aus. Derzeit nutze ich openSUSE MicroOS auf ein paar Raspberry Pis und einem x86_64-Server, und einer der Gründe für MicroOS war, dass die Installation auf dem Raspberry Pi ziemlich einfach war
      Ich frage mich, wie schwierig es ist, CoreOS auf einem Raspberry Pi zu installieren. Einige Installationsanleitungen im Internet sehen recht kompliziert aus

  • Eine weitere Achse, die in solchen Vorstellungen unveränderlicher Systeme immer fehlt, ist der imagebasierte Ansatz
    Ich arbeite mit Leuten, die das deutlich besser können als ich, an https://universal-blue.org/, wo wir OCI-Container-Images auf Basis der Fedora-Silverblue-Grundversion und mehrerer Desktop-Editionen bauen
    Diese Images kann man mit rpm-ostree booten, genauer gesagt darauf rebasen. Das ist eine robustere Art, das System zu erweitern als Layering, und alle können dieselben Änderungen leicht erben oder nutzen. Eigene Images zu bauen ist ebenfalls sehr einfach
    VanillaOS und SUSE scheinen Ähnliches zu machen, aber wir sind kein OS-Projekt, sondern nur ein Downstream von Fedora. Offizielle Unterstützung durch Fedora ist ebenfalls in Arbeit, und schon der derzeit funktionierende Umfang ist meiner Erfahrung nach eine der robustesten und einfachsten Methoden für Aufgaben wie die Bereitstellung von Nvidia-Treibern

    • Etwas anderes Thema, aber um 2009 herum war ich beeindruckt von einem großen Hypervisor, auf dem Windows-Remote-Desktop-Hosts liefen. Ich glaube, es war Citrix
      Die VMs booteten aus einem Image, und sowohl das Image als auch die Delta-Disks lagen komplett im RAM. Die Benutzerprofile lagen auf Festplatten, aber ein Desktop-Host für 25 Personen war in etwa 4 Sekunden so weit gebootet, dass er Remote-Logins annehmen konnte
      Das war das am wenigsten schmerzhafte Windows-System zum Patchen
    • Ich bin etwas verwirrt, weil Fedora Silverblue doch auch imagebasiert ist, oder?
      Ich dachte, die Standardinstallation nutzt kein Layering und Layering kommt erst ins Spiel, wenn man zusätzliche RPM-Pakete installieren möchte
    • UBlue scheint die Images regelmäßig mit GitHub Actions neu zu bauen, um Paket-Updates zu übernehmen. Ich frage mich, wer die Kosten dafür trägt
      Ich frage mich auch, ob die Images von GitHub bereitgestellt werden, ob GitHub für ausgehenden Traffic Gebühren verlangt und was passiert, wenn viele Nutzer dasselbe Image herunterladen wollen

  • Mich interessieren vorkonfigurierte Systeme mehr als unveränderliche Systeme
    Hier stechen NixOS und Home Manager hervor, aber die Art der Konfiguration ist wirklich furchtbar. Ich möchte die gesamte Konfiguration in der Quellcodeverwaltung haben und wissen, dass der aktuelle Systemzustand dieser Konfiguration entspricht; alle anderen Änderungen sollen beim Neustart verworfen werden. Änderungen vor dem Neustart sollten idealerweise hervorgehoben werden
    Nach meiner begrenzten Erfahrung mit Dingen wie Silverblue kann man das Basissystem konfigurieren, aber sobald man anfängt, Anwendungen wie Firefox hinzuzufügen, landet man bei Flatpak, und ich weiß nicht recht, wie man die gewünschte vollständige Flatpak-Installation samt deren Konfiguration deklarieren kann
    Vermutlich gibt es eine Möglichkeit, Flatpaks gesammelt zu installieren und den Rest über Dotfiles zu erledigen
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

  • Das Problem, das ich mit Flatpak und dem unveränderlichen Ansatz insgesamt hatte, ist, dass man Dinge nicht auf eine Weise anpassen kann, die von den Entwicklern nicht unterstützt wird.
    Zum Beispiel synchronisiere ich meinen Kalender mit decsync, und soweit ich weiß, ist es nicht möglich, das decsync-Plug-in zu Evolution Flatpak hinzuzufügen.
    Solange solche unveränderlichen Systeme das Stapeln benutzerdefinierter Overlay-Dateisysteme für Anwendungsfälle, die die Entwickler nicht unterstützen können oder wollen, nicht als First-Class-Feature unterstützen, werden die Leute weiter veränderliche Systeme nutzen.

    • NixOS bietet genau diese Art von Kontrolle auf mehreren Wegen.
      Einige Pakete in nixpkgs sowie die meisten NixOS- und Home-Manager-Module stellen viele Optionen bereit, mit denen man Plug-ins, zusätzliche Pakete usw. konfigurieren kann.
      Nix bietet außerdem Overlays und Overrides, um eigene Pakete oder Varianten vorhandener Pakete hinzuzufügen, und man kann auch Teile eines Pakets austauschen. Wenn das immer noch nicht reicht, kann man Patches direkt in den Code einfügen oder aus einem Fork des Upstream-Repositorys bauen.
      Genau das ist tatsächlich einer der Aspekte, die ich an Nix am meisten mag. Weil es so einfach ist zu sagen: „Ersetze beim Bauen dieses Pakets diese Abhängigkeit durch meine Version“, trage ich häufiger zu Open Source bei.
    • Dinge wie „das decsync-Plug-in zu Evolution Flatpak hinzufügen“ sind bei Linux-GUI-Software sehr verbreitet.
      Außerhalb dieses Bereichs wird Software meist mit den benötigten Funktionen ausgeliefert. Solidworks hat mich zum Beispiel nie aufgefordert, optionale Abhängigkeiten herunterzuladen, während FreeCAD buchstäblich alle 15 Minuten irgendetwas verlangte, sobald man im CAD/CAM-/Simulations-/Rendering-Workflow zum nächsten Schritt überging.
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... ist dazu ebenfalls lesenswert.
      Der Kernpunkt ist, dass die „20 %, die alle nutzen“, nie dieselben sind. In den letzten zehn Jahren habe ich von Dutzenden Firmen gehört, die versucht haben, eine „leichte“ Textverarbeitung mit nur 20 % der Funktionen herauszubringen; die Geschichte ist so alt wie der PC: Ein Journalist schreibt einen Test, sucht nach der Wortzählfunktion, findet sie in den „80 %, die niemand nutzt“, und schreibt am Ende: „Schlanke Programme sind gut und Bloat ist schlecht, aber dieses verdammte Ding kann keine Wörter zählen, also ist es unbrauchbar.“
    • Wenn man so weit geht, benutzerdefinierte Overlay-Dateisysteme als First-Class-Feature zu stapeln, frage ich mich, ob man nicht einfach ein veränderliches System verwenden sollte.
      Das erinnert mich daran, wie vor zehn Jahren alle zu NoSQL gerannt sind und dann sofort in jedem Projekt das Schema neu erfunden haben.
    • Auch zu Flatpak-Anwendungen kann man Plug-ins hinzufügen; solche Plug-ins müssen als Erweiterungspakete gebaut werden.
      OBS ist ein Beispiel dafür. Auf Flathub gibt es mehrere OBS-Plug-ins der Form com.obsproject.Studio.Plugin.*.

  • Ich würde die Definition so fassen: Nachdem man beliebig viele Pakete installiert hat, sollte man sie zu einem beliebigen Zeitpunkt in der Zukunft in beliebiger Reihenfolge entfernen können und in einen Zustand gelangen, der äquivalent dazu ist, als wären sie von Anfang an nie installiert gewesen.
    Diese Definition würde einige Distributionen ausschließen, aber genau diese Eigenschaft ist meiner Ansicht nach der wichtige Teil dieses Konzepts.

    • Bei Systemen für Endnutzer scheint genau diese Eigenschaft praktisch unmöglich zu sein.
      Will man, dass beim Entfernen einer Textverarbeitung oder eines Texteditors auch alle damit geschriebenen Dateien verschwinden? Wenn man den Browser entfernt, sollen dann auch alle heruntergeladenen Dateien gelöscht werden? Falls nicht, gibt es keine verlässliche Methode zu unterscheiden, welche Dateien ein Programm automatisch erstellt hat und welche Dateien der Nutzer mit diesem Programm erstellt hat.
      Was während der Installation erzeugt wurde, lässt sich leicht entfernen, aber nicht alle späteren Änderungen.
      Man kann auch an den Fall denken, dass man die DNS-Implementierung wechselt und später den Standard-DNS-Server ändert. Wenn man den Provider entfernt und zur vorherigen Implementierung zurückkehrt, muss man entscheiden, ob man auch zum alten Server zurückkehrt oder die neue Serverkonfiguration beibehält. Persönlich würde ich nur den Provider wechseln und den neuen Server beibehalten wollen.
      Auch Verzeichnisse, die mehrere Maschinen gemeinsam nutzen, machen es schwierig. Wenn /home/${USER} ein NFS- oder Samba-Mount ist und dieselben Dateien auf mehreren Workstations genutzt werden: Wenn ein Programm Dateien im XDG-Konfigurationsverzeichnis anlegt und man dieses Programm auf einer Workstation entfernt, sollen dann die Dateien auf allen Maschinen gelöscht werden? Ein Paketmanager eines einzelnen Systems kann nicht wissen, ob alle Geräte identisch sein sollen oder nur das Home-Verzeichnis identisch sein soll.
    • Die Frage ist, wie tief man diese Eigenschaft anwenden möchte.
      Datenstrukturen mit eindeutiger Darstellung und verlaufsunabhängige Datenstrukturen sind einen Blick wert.
      Bei Blockgeräten, etwa SSDs, müsste man besonders darauf achten, dass Blöcke unabhängig von der Historie alloziert werden.
    • Diese Eigenschaft nennt man Reproduzierbarkeit: dieselbe Konfiguration erzeugt immer denselben Systemzustand.
    • Die Definition gefällt mir.
      Man könnte auch sagen, dass die Menge der Pakete ein Gitter bildet und dass es unabhängig vom Pfad genau einen Zustand gibt, wenn man eine bestimmte Teilmenge von Paketen erreicht hat.

  • Ich nutze Fedora Silverblue seit der Veröffentlichung, und das ist eindeutig die Zukunft
    Meiner Meinung nach sollten alle ostree verwenden

    • Silverblue fühlte sich für einen persönlichen Computer nicht flexibel genug an
      Vielleicht nutze ich Linux etwas zu improvisiert, aber keine Schreibrechte auf Ordner wie /usr oder /bin zu haben, hat mich etwa alle zwei Wochen wahnsinnig gemacht
      Zum Beispiel suchte ein von einem Ubuntu-Nutzer geschriebenes Skript nach einer Bibliothek mit Ubuntu-typischem Namen und Pfad, während Fedora für dieselbe Bibliothek einen anderen Namen verwendet. In so einem Fall ist mein Instinkt, einen symbolischen Link mit dem Ubuntu-Namen anzulegen, der auf die von einem Fedora-RPM verwaltete Bibliothek zeigt
      Tatsächlich musste ich aber das Skript forken, es lokal baubar machen, es so anpassen, dass es beide Bibliotheksnamen findet, lokale Tests ausführen, einen PR an upstream schicken und so weiter. Was sonst mit einer Shell-Zeile erledigt wäre, wurde zu einer 90-Minuten-Aufgabe
    • Ich nutze es seit einem Jahr und es ist wirklich gut. Ich frage mich, ob Red Hat weiß, was sie da haben. Nicht nur Silverblue, sondern Fedora selbst
      Ich habe in einer Quora-Antwort gelesen, dass das Budget für die Entwicklung von Windows OS auf Gehaltsbasis auf etwa 18 Milliarden Dollar geschätzt wurde. Wenn man sich vorstellt, Red Hat würde 2 Milliarden Dollar in Fedora investieren und es zum Firefox der Desktop-OS-Welt machen: Selbst nur 10 % Marktanteil gegen Microsoft wären enorm
      Mit so wenigen Ressourcen ist man auf Tausenden Open-Source-Paketen bis hierher gekommen. Dieses Geld könnte dafür verwendet werden, solche Projekte am Leben zu halten und während der Entwicklung zu fördern. Red-Hat-Mitarbeitende sind bereits an vielen davon beteiligt
    • Mir gefällt die ostree-Idee, aber nach einem kurzen Überfliegen wirkte es für normale oder fortgeschrittene Nutzer nicht so zugänglich wie Docker. Docker kann ein Privatnutzer an einem Nachmittag lernen
      Mir war nicht klar, wie man an den Punkt kommt, „eine Debian-Distribution als ostree-Snapshot auszuliefern“
      Ich frage mich, ob das nur für professionelle Systemadministratoren oder System-Builder entworfen wurde
    • Wenn du Nix ausprobiert hast, würde mich interessieren, wie der Vergleich ausfällt
      Silverblue habe ich nicht genutzt, aber auch Nix fühlt sich wie die Zukunft an
    • Auf meinen Servern nutze ich derzeit Ubuntu, und ich habe gesehen, dass ostree im Repository liegt, habe es aber noch nicht ausprobiert
      Wenn möglich, würde ich gern mit meinem aktuellen System unverändert eine Versionsverwaltung beginnen. Wenn das zu schwierig oder unmöglich ist, werde ich den Server irgendwann auf Silverblue umziehen. Die Idee hinter ostree gefällt mir wirklich sehr

  • Diesen Sommer bin ich auf Tinycore gestoßen
    Es ergänzt gut die Sicherheitsphilosophie „ein OS, eine Funktion“, die hinter Qubes, Tails und Whonix steht und über die wir hier vor ein paar Tagen gesprochen haben
    Es ist so leichtgewichtig, dass man in wenigen Sekunden jeweils eine VM für den Mailserver, eine VM für die Datenbank und eine VM für Firewall/Router hochfahren kann
    Tinycore selbst ist unveränderlich, also legt man „Pakete“ und Konfiguration in eine vdisk und markiert sie als read-only, fertig. Ein Virsh-Skript kümmert sich um Start und Stopp des „Dienstes“, und jeder Dienst ist eine Tinycore-Instanz
    Es macht Spaß und war bisher robust, aber ich bin mir noch nicht sicher, ob ich es in die Produktion von irgendjemandem geben würde

    • TinyCore fehlt in solchen Einführungen zu immutable Linux immer. Es gibt es schon lange und das Design ist hervorragend
      Die Implementierung hat Schwächen, und vermutlich gibt es auch keinen Unternehmenssponsor, der erklären würde, warum es so wenig bekannt ist
      Anders als andere immutable Linux-Distributionen ist es robust und einfach

  • Ich nutze Fedora Sericea seit seinem Erscheinen durchgehend. Im Grunde ist es Fedora Silverblue, aber mit Sway-wm statt Gnome-wm
    In der Praxis ist es ziemlich brauchbar, und man muss auch nicht nach jedem rpm-ostree install-Befehl neu booten. rpm-ostree live-apply erledigt das über ein systemd-basiertes Overlay

    • Ich nutze seit den letzten zwei Wochen Fedora Workstation, und aus der Perspektive von jemandem, der Linux nach 20 Jahren wieder ausprobiert, kann ich sagen: Die Erfahrung ist enorm viel besser geworden
      Ich musste bisher noch nicht zurück nach Windows booten. Wenn das in den nächsten sechs Monaten so bleibt, steige ich vollständig auf Linux um und lösche die Windows-Partition
    • Aber um einen neuen Kernel tatsächlich anzuwenden, muss man doch trotzdem neu booten, oder? Oder wird der Kernel mit etwas wie kexec gewechselt?

  • Zu der Aussage „Unveränderlichkeit ist eine Lüge, und viele Teile des Systems sind veränderlich. Ich weiß nur nicht, wie man diese Kategorie sonst beschreiben sollte, irgendwas mit Transaktionen?“: Im Fall von Nix klingt es eher so, als liege der Fokus stärker auf Reproduzierbarkeit
    Das scheint zu bedeuten, dass man dieselbe Systemkonfiguration erhält, wenn man die Nix-Konfigurationsdatei auf einen anderen Computer legt, abgesehen etwa von /home
    Die anderen wirken eher so, als würden sie Snapshot- und Rollback-Funktionen, die bestehende Tools schon boten, mit einer anderen Implementierung bereitstellen

    • Der Begriff „unveränderlich“ passt hier seltsam
      Wenn es bedeutet, dass System-Upgrades nicht auf dem laufenden System erfolgen, Paketänderungen erst beim nächsten Boot angewendet werden und Änderungen zurückgerollt werden können, dann ist das eher wie atomare Transaktionen bei Datenbanken. Dass man zum Commit das System herunterfahren muss, ist allerdings etwas übertrieben
      Microsoft hat vor einigen Jahren atomare Transaktionen ins Dateisystem eingebaut, aber Dateisystem-Transaktionen wurden kaum genutzt
      Ein Installationssystem sollte alle Änderungen auf einmal committen können und, wenn während der Installation ein Problem auftritt, in den vorherigen Zustand zurückrollen, ohne irgendetwas zu committen. Theoretisch wäre das mit einem transaktionalen Dateisystem möglich, aber in der Praxis ist vermutlich zu viel anderer Zustand beteiligt, der nicht im Dateisystem liegt

  • Auf der Serverseite gibt es Amazons Bottlerocket OS
    Die Idee ist, für Upgrades A/B-Partitionen zu verwenden und alles, was nicht zum Basissystem gehört, in Containern laufen zu lassen
    Für benutzerdefinierte Einstellungen beim Booten nutzt man boot container, und für lang laufende Dienste entweder host-container oder in Kubernetes ein DaemonSet
    https://github.com/bottlerocket-os/bottlerocket