Ubuntu hat mit Snap ein neues Paketformat vorgestellt, das sich nicht nur für den Einsatz auf Servern eignet. Worum geht es bei Snap und warum ist das neue Ubuntu-Format nützlich? Wir geben einen Überblick.
Eine Sache lernt man bei Linux ganz schnell: Die Installation von Software funktioniert fundamental anders, als man es von Windows oder OS X her gewohnt ist. Wenn Sie etwa mit den Betriebssystemen von Microsoft Erfahrung haben, sind Sie es gewohnt, eine Datei von der Programm-Website herunterzuladen und dann doppelt auf diese zu klicken – schon startet ein Installationsprogramm, das die Software auf Ihr System bringt. So ähnlich läuft die Installation neuer Programme auch unter OS X: Hier laden Sie eine Datei herunter, deren Name auf .dmg endet – und kopieren dann meistens bloß noch die Programmdatei aus diesem komprimierten Archiv in den Programme-Ordner.
Linux funktioniert anders: Hier steht zuerst der Hersteller der genutzten Distribution in der Pflicht, möglichst viele Programme in Form von Paketen anzubieten. Alle großen Distributionen, darunter auch OpenSuse und Ubuntu, setzen auf eine Paketverwaltung: Bei Ubuntu kommen dabei Pakete im .deb-Format zum Einsatz, bei OpenSuse .rpm-Pakete. Die Paketmanager dpkg und APT für .deb-Pakete (Abbildung 1) und die Programme rpm und zypper für .rpm-Pakete bieten diverse Vorteile: Sie ermöglichen es den Distributoren und auch Autoren von Programmen, ihre Software so vorzubereiten, dass sie sich – kompiliert – als Paket auf den Nutzersystemen installieren lässt.
Abbildung 1: Auf Ubuntu-Systemen ist “dpkg” der angestammte Paketmanager, doch der bekommt nun genauso wie “rpm” Konkurrenz von “snap”.
Ohne Pakete: Viel Handarbeit
Paketsysteme lösen für Anwender ein großes Problem: Entwickler stellen von ihren Programmen meist nur den Quelltext zur Verfügung; die Aufgabe, daraus ein ausführbares Programm zu erstellen (also den Quelltext zu kompilieren), fällt dem Benutzer zu. In der Realität ist das aber nicht praktikabel, denn die meisten Nutzer wissen nicht, wie das Kompilieren funktioniert – und haben im Zweifelsfall auch nicht die nötige Zeit. Das Kompilieren von OpenOffice dauert selbst auf modernen Rechnern mit Multi-Kern-Prozessoren viele Stunden, in denen der Rechner für andere Aufgaben praktisch nicht zu gebrauchen ist.
Der Anbieter stellt den Benutzern als Alternative gängige Programme bereits fertig kompiliert zur Verfügung. Anwender installieren bloß noch ein Paket über die Paketverwaltung oder auf der Kommandozeile und können die Software danach nutzen: Das Kompilieren entfällt.
Auch bei Paketsystemen ist aber nicht alles Gold, was glänzt. Ein großes Thema sind etwa Abhängigkeiten: Die meisten Programme greifen im Hintergrund auf Programmbibliotheken zu – und oft auf dieselben. Die C-Bibliothek libc etwa nutzt praktisch jedes in C geschriebene Programm. Im Paketsystem lässt sich das als Abhängigkeit ausdrücken: Jedes Programm, das explizit die C-Bibliothek braucht, um zu funktionieren, hat eine Abhängigkeit auf diese – legt also fest: “Das jeweilige Paket kann nur installiert werden, wenn die C-Bibliothek libc bereits installiert ist oder gleichzeitig mit dem Programm installiert wird.”
Arbeit bei Updates
Gerade das System der Abhängigkeiten verursacht viel Mehraufwand für die Anbieter externer Software, die gern an das Paketsystem der Distribution anknüpfen möchten. Denn weil sich zwischen den Releases der Distributionen oft Kernkomponenten entscheidend verändern oder diese auf neue Major-Versionen aktualisiert werden, müssen auch externe Anbieter ihre Pakete ständig an die veränderten Bedingungen der Distributionen anpassen. Hinzu kommt, dass die Paketverwaltung von Systemen mit der Zeit langsam und schwerfällig wird, wenn auf dem System sehr viele Pakete installiert sind.
Snap schneidet alte Zöpfe ab
Hier kommt das Snap-Format von Ubuntu ins Spiel. Canonical wirbt auf der Snap-Projektseite damit, dass es sich um eine völlig neue Art von Paketsystem handle. Tatsächlich unterscheidet sich Snap von seinen “klassischen” Kollegen Dpkg und RPM. Der erste und auch wichtigste Unterschied ist, dass Snap kein klassischer Paketverwalter ist, sondern viel mehr Funktionalität liefert, ohne dass Nutzer das bemerken. Snap basiert auf Containervirtualisierung. An dieser Stelle ist ein kleiner Exkurs in die Welt der Virtualisierung notwendig.
Den Begriff “Virtualisierung” haben Sie sicher schon gehört: Es geht darum, einen zweiten, virtuellen Computer als eigenständiges System innerhalb Ihres echten Computers zu betreiben. Die Gründe, Virtualisierung einzusetzen, sind vielfältig: Vorhandene Ressourcen lassen sich damit oft besser nutzen als direkt auf dem System, und außerdem sorgt sie für eine strikte Trennung zwischen dem physischen System und dem virtuellen Rechner. Anders formuliert: Selbst wenn Ihnen in einer virtuellen Maschine (VM) ein grober Fehler unterläuft, genügt es, diese anschließend neu aufzusetzen. Reguläre Daten, die sich auf Ihrem physischen Rechner (und außerhalb der VM) befinden, sind davon nicht betroffen. Gerade für Experimente und Basteleien eignet sich die Technik also perfekt.
Container im Fokus
Diese Art der Virtualisierung, bei der auf dem virtuellen PC ein reguläres Betriebssystem installiert wird, das dann Anwendungen ausführt, heoßt Vollvirtualisierung. Daneben gibt es noch eine Variante, bei der zwar ein kompletter, virtueller Computer simuliert wird, dabei erhalten allerdings die Software-Komponenten des virtuellen Systems direkten Zugriff auf Hardware des physischen Computers (Paravirtualisierung). Beide Varianten sind ressourcenintensiv: Alleine dafür, dass ein kompletter Computer mit eigenem Betriebssystem nachgeahmt wird, verwendet das Virtualisierungsprogramm Ressourcen – also Prozessorleistung, Arbeitsspeicher und Festplattenplatz. Im Fachjargon ist vom “Overhead” die Rede: Die so benutzten Ressourcen lassen sich nicht für tatsächliche Nutzprogramme verwenden, die im physischen oder im virtuellen System laufen.
Hier kommt Containervirtualisierung ins Spiel: Sie hat sich in den letzten Jahren zunehmend etabliert und verfolgt einen anderen Ansatz. Dort läuft kein eigener, virtueller Computer mehr, mit dem sich ein eigenständiges virtuelles System erreichen ließe. Stattdessen nutzt auch das Gastsystem das Betriebssystem des physischen PCs. Über diverse technische Mittel, die zum Teil tief im Kern des Linux-Betriebssystems – also dem Kernel – verankert sind, erreicht Containervirtualisierung trotzdem eine strikte Trennung zwischen dem Host- und dem Gastsystem. Mehraufwand in Sachen Prozessor oder Arbeitsspeicher entsteht allerdings kaum. Nur eine Sache ist bei Container- und Vollvirtualisierung gleich: Das virtuelle System hat ein eigenes Dateisystem, teilt sich also nicht die Dateien mit dem Host.
Snap-Pakete sind Container
Hier schließt sich der Kreis zum Ubuntu-Format Snap: Bei Snap kommen die Programme als Container daher, die strikt vom Hostsystem getrennt sind. Dieses hat nur die Aufgabe, den Betrieb des Containers sicherzustellen. So enthält also Snap-Applikation ein eigenes, wenn auch sehr kleines und absolut reduziertes Linux-System: Alle Abhängigkeiten der im Snap-Programm laufenden Applikation werden zusammen mit dieser geliefert.
In Sachen Flexibilität setzt das Maßstäbe, weil sich ein Snap-Programm sogar auf unterschiedlichen Distributionen in völlig identischer Weise nutzen lässt, wenn der PC grundsätzlich Snap-Programme ausführen kann. Vor allem erleichtert das Snap-Format also das Verteilen von Anwendungen, weil sich ein Programmautor um distributionsspezifische Details keine Gedanken mehr machen muss. Er kann stattdessen voraussetzen, dass sein Tool auf jedem Snap-fähigen System laufen wird, wenn es auf seinem eigenen System mit Snap funktioniert.
Komplizierter technischer Unterbau
Was in der Theorie so schön und elegant klingt, geht in der Praxis mit manchem praktischen Problem einher. Die meisten Programme, die Sie im Alltag unter Linux nutzen, benötigen zum Beispiel Zugriff auf die Dateien in Ihrem Home-Verzeichnis. Viele Anwendungen legen dort ihre Konfigurationsdateien ab. Auch Sie selbst haben den allergrößten Teil dieser Dateien vermutlich an dieser Stelle abgelegt, etwa Ihre Internet-Downloads, die Dokumente oder die Musikdateien.
Snap basiert wie beschrieben auf dem Prinzip der strikten Trennung zwischen dem zu Snap gehörenden Container und dem Host-System. Trotzdem müssen Snap-Programme in der Lage sein, auf die persönlichen Dateien eines Nutzers zuzugreifen. Die Lösung liefert Canonical, das federführend an Snap beteiligt ist, in Form der internen Snap-Schnittstellen (“Interfaces”). Die bestehen aus zwei Teilen:
- Der Host, der Snap-Programme starten kann, betreibt dabei eine Art Übersetzungsdienst zwischen den Snap-Containern und den Dateien des Hosts.
- Der Snap-Container selbst dockt an diesen Dienst an und erhält so Zugriff auf die benötigten Dateien.
Ab Werk liefert Snap mehrere Interfaces, neben jenem für die persönlichen Dateien gibt es z. B. auch eine Snap-Schnittstelle für den Zugriff auf bestimmte Hardware-Komponenten über das /dev-Verzeichnis.
Snap in der Praxis
Auf der Snap-Website [1] weist Canonical darauf hin, dass Snap mit praktisch jeder aktuellen Linux-Distribution funktioniert. Auch kommt es den dortigen Paketverwaltungen nicht in die Quere, denn es verwaltet seine eigenen Dateien im Verzeichnis /snap. Selbst auf älteren Linux-Installationen lässt Snap sich also einigermaßen leicht nachrüsten, falls der dort laufende Linux-Kernel aktuell genug ist.
Das Snap-eigene Verwaltungswerkzeug snap steht für mehrere Distributionen bereit. Und so unscheinbar es wirkt: Diesem Kommandozeilentool kommt eine sehr große Bedeutung zu.
Das wird schnell klar, wenn man sich die Frage stellt, welches Ziel Snap verfolgt. Die Entwickler hatten den Anspruch, ein universelles Werkzeug für die Verwaltung von Anwendungen zu schaffen, das sämtliche Linux-Distributionen im Sturm erorbern soll. Damit das klappt, muss es für Anwender allerdings möglich sein, Snap-Applikationen so komfortabel wie Pakete der eigenen Distribution einzurichten. Diese Aufgabe übernimmt snap im Gespann mit der Website “uApp Explorer” [2], die Snaps auflistet und zum Download bereitstellt. Bei Redaktionsschluss standen dort bereits 430 Snaps bereit, darunter auch der beliebte Medienspieler VLC (Abbildung 3) und der BitTorrent-Client Vuze. Auf snap-fähigen Systemen genügt ein simples snap install mit der gewünschten Snap-App, die sich per snap find suchen lässt (Abbildung 2), und wenige Sekunden später ist das Programm bereit für den Einsatz. Es dürfte nur eine Frage der Zeit sein, bis für snap auch eine grafische Variante existiert.
Abbildung 2: Snap ist eine auf Containervirtualisierung basierende Softwareverwaltung, die Canonical entwickelt hat.
Abbildung 3: Auf der Snap-Website finden sich bereits diverse Snaps, die sich mit “snap install” installieren lassen – darunter der Medienspieler VLC.
Kritische Fragen
So clever das Snap-Format auf den ersten Blick zu sein scheint, hat das Prinzip auch handfeste Probleme, die für den Erfolg oder das Scheitern von Snap von Bedeutung sein werden: Zwar verkürzt sich dank Snap der Weg zwischen den Entwicklern von Programmen und den Herstellern der gängigen Linux-Distributionen. Aber so fällt auch eine Instanz der Kontrolle weg: Red Hat, Suse, Canonical, das Debian-Projekt und die vielen weiteren Linux-Distributoren investieren viel Zeit, um die Qualität ihrer Distributionen sicherzustellen. Dazu gehören auch Sicherheitsupdates, die kritische Fehler in Programmen beseitigen. Beim Snap-Szenario fällt genau diese Kontrollinstanz weg. Die Anbieter von Programmen zeichnen alleine dafür verantwortlich, Nutzern aktuelle Snaps zu liefern, die frei von Fehlern sind – so läuft es auch bei Software für Windows und OS X.
Aus Nutzersicht ist das keine schöne Vorstellung. Denn bei Entwicklern stehen meist neue Funktionen im Vordergrund, während viele Anwender stabile Software bevorzugen, die vielleicht nicht alle aktuellen Features hat. Dieses Problem muss unbedingt gelöst werden, wenn Snap sich durchsetzen soll.
Auch aus Sicht der Linux-Anbieter wirft Snap Fragen auf: Wenn jede Distribution nur noch Snap-Container ausführen soll, haben die Distributoren kaum noch Möglichkeiten, spezifische Eigenheiten ihrer Produkte als besondere Funktion zu vermarkten. Im Grunde wäre der Bedarf auf der Distributionsebene auf minimale Kern-Linuxe beschränkt, die lediglich an ein vorhandenes Netzwerk angeschlossen werden und dann Snap-Container starten.
Viele Fragen
So sehr Canonical Snap bei dessen Veröffentlichung mit PR-Rummel bedacht hat, so unklar ist aktuell, ob die Lösung sich am Markt durchsetzen kann. Aus technischer Sicht sprechen manche Punkte klar für Snap: Wer bei früheren Software-Installationen Probleme mit unlösbaren Abhängigkeiten hatte, findet den Snap-Ansatz sicher sehr reizvoll. Damit Snap jedoch zur ernst zu nehmenden Alternative zu den gängigen Paketsystemen wird, muss es mehr Snap-Apps geben. Und die anderen Firmen im Linux-Markt, allen voran Red Hat und Suse, müssen sich klar werden, wie sie mit Snap umgehen wollen. Vorerst bleibt Nutzern ihre gewohnte Paketverwaltung aber sicher erhalten.
