Sechs Distributionen, sechs Arten, wie ein Programm scheitert

Ein Schreibtischprogramm unter Linux zu verteilen, stoesst jedes Mal auf dieselbe Wand: die Abhaengigkeiten. Dasselbe Programm, einmal gebaut, laesst sich auf einer anderen Distribution vielleicht nicht installieren, weil die erwarteten Fassungen der Bibliotheken fehlen oder weil die Pfade anders geordnet sind. Die Meldung ist selten aufschlussreich, meist eine Nummer und ein fehlender Name, und die Frage, welches der beiden Systeme schuld ist, bleibt beim Nutzer.

Die uebliche Antwort ist ein eigenes Paket je Distribution. Das vervielfacht die Arbeit mit der Zahl der Ziele und laesst die schiefen Kombinationen trotzdem offen. Flatpak geht einen anderen Weg.

Die Laufzeitumgebung mit der Anwendung zusammen packen

Der Ansatz ist, die Anwendung zusammen mit der Laufzeitumgebung zu packen, die sie braucht, und diese Umgebung unabhaengig vom System darunter zu halten. Die Anwendung leiht sich die Bibliotheken der Distribution nicht mehr, sie bringt eigene mit. Damit laesst sich dasselbe Paket auf Systemen, die sonst wenig gemeinsam haben, gleich installieren und gleich starten.

Diese Unabhaengigkeit ist der ganze Gedanke, und es lohnt, genau zu sagen, was sie einkauft. Sie macht eine Anwendung nicht im Abstrakten uebertragbar; sie macht die Laufzeitumgebung zu einer festen Groesse, sodass eine Sache stimmen muss statt einer ganzen Kette von Systempaketen. Der Preis liegt auf der anderen Seite: die Umgebung wird als eigenes Objekt ausgeliefert und aktualisiert, also mehr Platte und mehr Aktualisierungen, als ein einheimisches Paket braucht.

Eine Sandbox zwischen Anwendung und System

Zwischen Anwendung und System liegt eine Sandbox. Standardmaessig sieht die Anwendung nicht das ganze Dateisystem und hat keinen unmittelbaren Zugriff auf Geraete. Wenn sie ein bestimmtes Verzeichnis lesen oder schreiben will oder ein bestimmtes Geraet benutzen moechte, muss das in ihren Rechten ausdruecklich stehen.

Das Modell macht die Grenze des Verhaltens klarer, und es laesst den Nutzer vor der Installation ungefaehr sehen, welche Mittel ein Programm anfassen wird. In der Praxis ist das ein kleiner Gewinn, im Grundsatz ein echter: die Frage, wie weit ein Programm reicht, wird nicht mehr allein durch Vertrauen beantwortet.

Feinere Geraeterechte in 1.18

Fassung 1.18 hat feinere Bedingungen fuer Geraeterechte gebracht. Eine Anwendung kann die eine Klasse von Geraeten verlangen, die sie wirklich braucht, statt die Tuer fuer alle zu oeffnen. Die Aenderung klingt klein und ist es nicht: ein Rundumzugriff auf Geraete ist einer der Gruende, aus denen eine Sandbox leicht als Zierrat abgetan wird, und die Einengung macht aus der Erklaerung ein Argument statt einer Zeile auf dem Installationsbildschirm.

Darin steckt ein allgemeiner Satz. Ein Rechtemodell wird ernst genommen, wenn die einzelnen Bitten so genau sind, dass man sie beurteilen kann; wo alles auf einmal verlangt wird, lernt der Nutzer, ohne Hinsehen weiterzuklicken.

Woher die Anwendungen kommen

Die haeufigste Quelle ist Flathub, eine zentrale Sammlung mit sehr vielen Anwendungen. In der Befehlszeile genuegt ein Installationsbefehl, und die grafischen Softwarezentren bringen sie meist mit, sodass derselbe Katalog von beiden Seiten erreichbar ist.

Neben der offiziellen Sammlung lassen sich fremde Sammlungen hinzufuegen. Das verdient eine Warnung statt einer Anleitung: eine fremde Sammlung durchlaeuft nicht dieselbe Pruefung, ihre Herkunft sollte also feststehen, bevor sie eingetragen wird. Fassung 1.18 kann ausserdem unmittelbar aus OCI-Abbildern installieren und zeigt bessere Meldungen, wenn eine Aktualisierung scheitert. Die zweite Aenderung zaehlt erst, wenn schon etwas schiefgegangen ist, und genau dann zaehlt sie am meisten.

Die anderen Wege und was sie trennt

Mehrere Vorhaben arbeiten an derselben Klasse von Problem mit anderem Schwergewicht. Die eine Familie legt die Anwendung in einen zentralen Laden mit Pruefung dahinter und deckt viele Distributionen ab. Eine andere haengt eng an einer einzelnen Distribution, deren Konto und Aktualisierung sie mitbenutzt. Eine dritte ist die einfachste: eine Datei, die laeuft wie sie ist, aber ohne zentrale Aktualisierung und ohne gemeinsamen Katalog.

Keine davon ersetzt die Paketverwaltung des Systems, und den Vergleich als Wettkampf zu lesen ist ein Fehler. Der Unterschied liegt darin, wohin die Muehe geht: Abdeckung und Pruefung, Bindung an eine Plattform, oder moeglichst wenig Verpackung bei Wartung durch den Nutzer.

Eine vernuenftige Aufteilung

Fuer die meisten Schreibtischnutzer ist die stabile Kombination, das Ganze als zusaetzlichen Kanal zu behandeln und Werkzeuge auf Systemebene bei den einheimischen Paketen der Distribution zu lassen. Anwendungen, die die Distribution nicht fuehrt oder zu langsam nachzieht, kommen aus dem Paket; was das System selbst beruehrt, bleibt dort, wo das System es erwartet.

Drei Handgriffe decken den Alltag ab: installieren, aktualisieren und nachsehen, was einer Anwendung eingeraeumt wurde. Der dritte wird gern uebersprungen, und er ist der Grund, aus dem eine Sandbox ueberhaupt etwas wert ist.

Flatpaks Wert liegt darin, die Frage, auf welchen Maschinen eine Anwendung laeuft, von den Unterschieden der Distributionen zu loesen, und die Installation ueber Sandbox und Rechte pruefbar zu machen. Es ersetzt die Paketverwaltung nicht, es fuellt die Luecke, die sie liess.