Zunächst skizziert der Autor die Probleme der Entwickler, die er beim derzeitigen Zustand mit relativ strikter Trennung zwischen Upstream und den Maintainern in den Distributionen sieht. Dabei seien die Entwickler stark von den Maintainern der jeweiligen Distributionen abhängig, was die Art und den Zeitpunkt der Veröffentlichung angeht. Zudem seien für den Entwickler zuverlässige Tests seiner Software bei der Vielfalt an Distributionen und den vielfältigen Kombinationsmöglichkeiten mit unterschiedlichen Bibliotheken, Runtimes und Frameworks kaum möglich. Das Entwickeln einer Software für mehrere Distributionen sei zudem zu zeitaufwendig.
Aber nicht nur den Entwicklern ist der Veröffentlichungszyklus der gängigen Distributionen oft zu behäbig, auch der Endanwender möchte neue Software möglichst zeitnah nutzen können und trotzdem darauf bauen können, dass sie sowohl sicher als auch funktional ausgereift ist. Poettering sieht verschiedene Ansätze, die versuchen, diese Probleme anzugehen, dies seien allerdings jeweils nur Teillösungen. Er erwähnt in diesem Zusammenhang Ubuntu Apps, Docker, Software Collections, ChromeOS und CoreOS. Sie nähmen sich jeweils nur eines Teilaspekts entweder der Anwenderseite oder der Entwicklerseite an. Keines dieser Projekte versuche allerdings, den gesamten Problemkomplex in den Kernkomponenten des Betriebssystems zu beheben.
Das Systemd-Team möchte diese Probleme im Rahmen von Systemd lösen. Dies soll in einer generischen Weise geschehen, die durch ein langsames Ausrollen den Distributionen genug Zeit lässt, die Änderungen adäquat zu integrieren. Im Endeffekt geht es Poettering und seinen Mitstreitern dabei um Systeme, die sich weitgehend selbst installieren und administrieren können. Beispielsweise verfolgt CoreOS einen solchen Ansatz auf Serverebene, bei dem zwei Root-Dateisysteme auf zwei Partitionen nebeneinander existieren, von denen jeweils nur eine schreibbar eingehängt ist. So sind automatische Upgrades über viele Server möglich. Im Fall eines Fehlers wird das zweite Dateisystem mit dem alten Stand der Software eingehängt.
Dabei soll die angestrebte Lösung für das gesamte System, für Betriebssystem-Container, einzelne Applikationen, für ABIs und mehr funktionieren. Die daraus resultierenden Images sollen von der Firmware über den Bootloader, den Kernel und die Initrd bis zu den Applikationen voll vertrauenwürdig sein. Es folgt die geplante technische Umsetzung für die vorgeschlagenen Änderungen. Dabei spielt das Name-Spacing des Kernels ebenso eine Hauptrolle wie Btrfs mit seinen vielfältigen Optionen, von denen noch in Entwicklung seien. Dabei spielen Sub-Volumes, auch als Snapshots bezeichnet, eine gewichtige Rolle. Verschiedene Sub-Volumes, die vordefiniert und mit festen Bezeichnungen versehen werden, erfüllen unterschiedliche Aufgaben.
So könnte, wie bei der Idee der »Stateless Systems« bereits angerissen, ein Sub-Volume mit der Bezeichnung root beispielsweise /etc und /var, aber nicht usr, das ein eigenes Sub-Volume erhält, aufnehmen. Auch das Heimatverzeichnis eines Anwenders würde nach erfolgter Legitimierung durch den Anmeldemanager aus einem Snapshot eingehängt. Für Applikationen wird zur Laufzeit im Dateisystem ein Name-Space erstellt und ein generisches Sub-Volume für Apps in /opt eingehängt und mit /usr und /home/user verknüpft. Auch Entwickler sollen profitieren, indem sie ihre Software in unterschiedlichen Name-Spaces unter unterschiedlichen Bedingungen, die über eingehängte Sub-Volumes definiert sind, bauen.
Als Anwendungsfall beschreibt Poettering die Möglichkeit, mehrere Betriebssysteme oder mehrere Instanzen eines Systems sowie multiple Runtimes und Frameworks in einem Btrfs-Volume gleichzeitig vorzuhalten. Als Beispiel dient ein Fall, wo Fedora, Mandriva und Arch Linux diesem Schema folgen und entsprechende Images bereitstellen. Desktop-Umgebungen stellen in diesem Szenario den Entwicklern entsprechende Runtimes und Frameworks zur Verfügung. Zudem sei vorausgesetzt, LibreOffice und Firefox bedienen dieses Schema. Poettering zeigt auf, wie all dies mittels Sub-Volumes in verschiedenen Architekturen in einem einzigen Btrfs-Volume installierbar ist. Ob nun die verschiedenen Versionen von Apps wie Firefox mit Mandriva oder Arch Linux gestartet werden spielt keine Rolle, da ihnen jeweils beim Start die passende Runtime zugeordnet wird.
Um die Sub-Volumes auf die Hardware zu bekommen und sie zu aktualisieren kommt eine Btrfs-Funktion namens send-and-receive ins Spiel, die den Vergleich zweier Systemversionen erlaubt und die Unterschiede in ein eine binäre Delta-Datei schreibt. Entwickler können diese Deltas auf Endanwendersysteme schieben, um diese zu installieren oder aktuell zu halten. Dieses Vorgehen soll exakt gleich für das gesamte System, für Apps, Frameworks oder Runtimes funktionieren. Auch für Serverlandschaften sieht Poettering Vorteile dieses generischen Distributionsmodells, indem etwa /usr-Bäume auf dem Server erstellt und an Clients verteilt werden. Durch Erstellen eines neuen Sub-Volumes könnten sie dort etwa in Container verpackt werden. Auch für eingebettete Systeme in TV-Geräten, Set-Top-Boxen oder Telefonen sollen Entwickler das gleiche Schema umsetzen können.
Poettering nimmt die Frage nach der Reife von Btrfs vorweg, indem er klarstellt, alle Sub-Volumes außer dem für das Heimverzeichnis seien strikt nur lesbar. Derzeit sei man dabei die grundlegenden Bausteine für solch ein System zu erstellen, die Umsetzung insgesamt werde einiges an Zeit brauchen. Einige benötigte Funktionen in Btrfs seien zwar in Arbeit, aber noch nicht fertiggestellt. Dazu zählen etwa das Signieren und Verschlüsseln, um eine Kette des Vertrauens über das gesamte System zu gewährleisten. Einige Schritte auf dem Weg zum fertigen Schema sollen vorab bereits in neuen Systemd-Versionen verfügbar sein. Abschließend stellt Poettering klar, dass die angedachten Funktionen nicht in Stein gemeißelt sind, sondern sich im Lauf der Entwicklung bestimmt einiges ändern wird. Zudem stellt er klar, dass dieses System zwar in Systemd integriert sein soll, aber das das Team dies nur mit Hilfe aus den Distributionen wird umsetzen können
Poettering wird seine Ideen im Oktober auf der LinuxCon in Düsseldorf in einem Vortrag illustrieren.
Quelle: Poetterings Vision von der Linux-Distribution der Zukunft - Pro-Linux
