Wer sich in der Linux Welt schon eine Weile herumtreibe hat evtl. schon mal von AppImages gehört. Wem der Begriff neu ist oder für die diejenigen die gerne mehr darüber wissen wollen, sind hier genau richtig. Außerdem widmet sich dieser Beitrag der Frage, warum sich AppImages einer recht durchwachsenen Reputation in der Linuxgemeinschaft erfreuen.
Lange Zeit und auch noch heutzutage ist es Gang und Gebe, dass jede Linux Distribution oder Distributionsfamilie Softwarepakete selbst bereitstellt. Ist man Benutzer einer der großen Distributionen ist die Chance recht groß dass die meisten Anwendungen in den Softwarequellen verfügbar sind. Man kann also Problemlos die Software herunterladen und installieren.
Aber, nicht jede Software ist für jede Linux Distribution verfügbar. Oder zumindest nicht in einer bestimmten oder der neusten Version. Ist dies der Fall beginnt die Suche danach wie man Anwendung XYZ auf Linux Distribution ABC auf eine neuere Version aktualisiert. Und manchmal hat man Glück und es gibt eine Zusätzliche Softwarequelle die von der Gemeinschaft beriet gestellt wird und es erlaubt eben diese Software zu aktualisieren. Diese müsste man dann also nur zum eigenen System hinzufügen und fertig.
Aber Vorsicht! „Von der Gemeinschaft bereitgestellt“ klingt erst mal nicht bedrohlich. Doch tatsächlich verlässt sich der Endnutzer damit darauf, dass derjenige der diese Softwarequelle anbietet, nicht eine mit Malware infizierte Version der eigentlichen Software ausliefert. Oder aber, da es sich um eine Drittanbieter Softwarequelle handelt, stellt sich schnell die Frage, wie gut die Software getestet ist. Welche zusätzlichen Bibliotheken noch mit aktualisiert werden müssen und wie sich das ganze dann mit dem eigenen System an Ende verträgt.
Die schiere Menge an Problemen die das nach sich ziehen kann ist fast nicht zu überblicken. Was tun? Die Linux Distribution ganz wechseln, zu einer die einen neueren Softwarestand bietet? Was wenn dort andere Software fehlt?
AppImages versuchen diese Probleme zu lösen
Die Grundidee hinter AppImages ist, das eine Softwarehersteller seine Software genau ein einziges mal Paketieren muss und diese Software dann auf jeder beliebigen Linux Distribution lauffähig ist. Ohne dass besagter Entwickler sich mit den verschiedenen Paketeirungsmethoden diverser Linux Distributionen befassen muss. Oder was in welcher Distribution enthalten ist und was nicht.
Damit nicht genug, zudem sollen AppImages aus einer einzigen lauffähigen Datei bestehen, die alles mitbringt was benötigt würde, damit besagte Software läuft und zu dem das Zielsystem nicht modifiziert werden muss, da die Anwendung zusätzlich portabel sein soll.
Also einfach herunterladen, ausführen und fertig. Egal wo, egal wann und egal ob Online oder Offline.
Um einen Großteil dieser Anforderungen zu erfüllen, bedienen sich AppImages der Bibliothek FUSE (Filesystem in Userspace). Das bedeutet das die Anwendung in einem virtualisierten, und unabhängig vom restlichen System, Dateisystem ausgeführt wird. Sprich die Dateisystemhirachie wie sie unter Linux Gang und Gebe ist, wird in einem temporären und virtuellen Dateisystem abgebildet, ohne dass bestehende Systembibliotheken ersetzt oder „überschattet“ werden.
Das bedeutet aber auch, dass AppImages im allgemeinen größer sind, da eine Vielzahl an Abhängigkeiten neben der eigentlichen Software mit ausgeliefert werden müssen. Benutzt man viele AppImages parallel ergibt sich eine gewisse Redundanz. Da jedes AppImages gleiche oder gar die selben Bibliotheken immer und immer wieder ausliefern und diese untereinander auch nicht teilen. Das sollen sie ja auch nicht, da jedes AppImage autark lauffähig sein soll.
Wie zuvor erwähnt bringen AppImages eine Menge an extra Dateien mit. Allerdings längst nicht alles was für ein lauffähiges System notwendig wäre. Denn schauen wir uns diverse Live Images von diversen Linux Distributionen an, dann sind diese manchmal bis zu mehreren hundert oder gar einige Gigabytes groß. AppImages sind sehr viel kleiner.
Zugegeben, sie müssen keine vollständige Desktopumgebung mit bringen, eine Kopie des Linuxkernels ist auch nicht notwendig und vieles mehr. Dennoch setzt das AppImage Format gewisse Abhängigkeiten auf dem Zielsystem voraus, die es nicht selber mitbringt. Genau hier beginnt die Abhängigkeitshölle (engl. dependency hell).
Zum einen benötigt das Zielsystem die Bibliothek libfuse in der Version 2. Zum andern aber auch diverse Bibliotheken für Grafische Benutzeroberflächen, wie zum Beispiel dem X11 Server und etwaige Begleitkomponenten. Hinzu kommen noch etwaige Bibliotheken die der Softwarehersteller evtl. einfach nur vergessen hat mitzuliefern. Sei es weil die Distribution auf der das AppImage getestet wurde diese vorinstalliert hatte oder der Entwickler diese Bilbiotheken nachinstalliert hat und schlicht weg vergessen dass getan zu haben.
Das ganze summiert sich recht bald auf und wird zu einem waren Minenfeld. Denn AppImages haben noch ein Problem. Einmal paketiert, und im Internet unterwegs, wird es nie wieder aktualisiert. Sprich mit der Zeit sind AppImages im Umlauf, die auf Bibliotheken angewiesen sind, die es evtl nicht mehr gibt oder die bekannte Sicherheitslücken aufweisen. Und somit einen Endanwender dazu zwingen aus Kompatibilitätsgründen diverse alte Komponenten nach zu installieren. Zum Beispiel libfuse2 höchst selbst. Finaler Release 4. Januar 2019…
Für denjenigen die AppImages dennoch in einer relativ sicheren Umgebung ausführen wollen empfehle ich Distrobox. Hier könnt ihr dann in einem separaten System alle Abhängigkeiten für eure AppImages nach installieren, ohne euer Hauptsystem zu verunreinigen. Ich habe hier sogar einen Distrobox Assemble Skript geschrieben, der die meisten gängigen Abhängigkeiten in eine Distrobox installiert. Zudem bleibt so euer Hauptsystem frei von zusätzlichem Ballast.
Das Skript könnt ihr über distrobox-assemble create –file /pfad/zur/ini/datei/distrobox.ini ausführen und Distrobox legt euch die neue AppImage Box an.
Startet ihr den Container zum ersten mal kann es etwas dauern, bis Distrobox alles eingerichtet hat. Anschließend sollte es aber deutlich schneller von statten gehen.
Im Zusammenhang mit dem bereits erwähnten distrobox.ini Skript habe ich auch ein KDE Servicemenü entwickelt, welches es euch ermöglicht AppImages bequem von Dolphin aus im AppImage Container auszuführen.
Ladet die *.desktop Datei von hier herunter und platziert es unter ~/.local/share/kio/servicemenus/. Existiert dieser Ordner nicht legt ihn an. Anschließend markiert die Datei noch als ausführbar. Rechts-Klick -> Eigenschaften -> Berechtigungen -> Die Ausführung als Programm erlauben.
Nun solltet ihr, wenn ihr eine Datei rechts-klickt einen neuen Eintrag „AppImage -> AppImage ausführen“ in Dolphin haben.
Analog zum Servicemnü habe ich auch für Gnome Benutzer einen Skript geschrieben der mit Nautilus verwendet werden kann. Ladet die Datei von hier herunter und platziert sie unter ~/.local/share/nautilus/scripts/ existiert dieser Pfad nicht legt ihn einfach neu an. Abschließend markiert die Datei noch als Ausführbar. Rechts-Klick -> Eigenschaften -> Als Programm ausführbar.
Nach dem ihr Nautilus neugestartet habt, könnt ihr dann ein AppImage Rechts-klicken und via Skripte -> run_appimage ein AppImage im AppImage Container ausführen.
Wer schon etwas tiefer im Thema AppImages drin ist, kennt evtl. auch diverse AppImage Desktopintegratoren. Sprich das AppImages automatisch einen Starter im Anwendungsmenü bekommen und von dort gestartet werden können.
Diese Funktionalität bietet mein hier vorgeschlagener Ansatz nicht! Die existierenden Wege können auch nicht adaptiert werden, da diese voraussetzten dass das AppImage nativ und nicht in einem Distrobox Container ausgeführt werden.
Wenn ihr demnach ein Start- oder Anwendngsmenüeintrag wünscht, läuft es daraus hinaus, dass dieser Händisch angelegt werden muss. Mit einer Adaption der Dateimanagereinträge die ich oben bereits vorgestellt habe.
In der Theorie sind AppImages eine echt gute Sache. Allerdings halten sie nicht ganz das was sie versprechen. Neben der Tatsache das sie nicht alle Abhängigkeiten beinhalten und auf teils veraltete Bibliotheken aufbauen, stellen sie den Benutzer vor neue Herausforderungen.
Um die Echtheit eines AppImages zu dem zu überprüfen bedarf es einer Signatur, die der Originale Entwickler irgendwo beriet stellen müsste und dem Endnutzer, das er weiß wie man diese Überprüft. Etwas was bei den herkömmlichen Wegen Software unter Linux zu installieren bereits automatisch und transparent im Hintergrund passiert.
Demnach gilt bei AppImages besondere Vorsicht von wo und wem ihr diese bezieht.
