Seit einigen Jahren machen neue distributionsunabhängige Paketformate wie Flatpak, Snap und AppImage den althergebrachten Paketmanagern Konkurrenz. Während Flatpak aus der Ecke von Red Hat kommt und Snap von Canonical entwickelt wurde, gibt es AppImage schon sehr viel länger. Es erhielt durch den Erfolg der beiden Konkurrenten Auftrieb und genießt dadurch in den letzten Jahren einen höheren Bekanntheitsgrad.
Vor- und Nachteile
Während Flatpak und Snap auf die Installation von unterstützender Software angewiesen sind, kommt AppImage völlig eigenständig daher. Neben den Vorteilen der Unabhängigkeit und der Portabilität bringt AppImage für den Anwender den Nachteil, dass sich die derart gepackten Apps sich nur manuell in das jeweilige Applikationsmenü der Distributionen einfügen lassen und ansonsten entweder von der Kommandozeile aus oder per Klick auf die Anwendung im Dateimanager gestartet werden müssen, nachdem sie ausführbar gemacht wurden. Ein weiterer Nachteil ist der fehlende Update-Mechanismus, der dem Anwender verfügbare Updates ankündigt oder ausführt.
Gestern entdeckte ich zufällig das kleine Tool AppImageLauncher, das angetreten ist, diese Nachteile auszubügeln. Das Tool wird auf GitHub entwickelt und wer viele AppImages nutzt, spart damit einiges an Zeit und gewinnt an Komfort. Außer der Installation per PPA bietet der Entwickler freundlicherweise neben dem Quellcode auch Pakete in den Formaten DEB und RPM für die Architekturen x86-64, i386 und armhf an. Zusätzlich gibt es die Anwendung auch – wer hätte es gedacht – als AppImage.
AppImageLauncher
Beim ersten Start von AppImageLauncher wird der Anwender gefragt, wo AppImages künftig zentral gespeichert werden sollen. Voreingestellt ist ~/Applications. Wird nun ein AppImage auf herkömmliche Weise gestartet, meldet sich AppImageLauncher und fragt, ob die App in den Desktop integriert werden soll. Stimmt der Anwender zu, wird das Image in den vorher festgelegten Ordner verschoben und samt Icon ins Applikationsmenü oder den genutzten Anwendungsstarter eingebunden. Dort bietet das Kontextmenü der Anwendung dann neue Einträge zum Löschen und Aktualisieren der Anwendung, letzteres nur, wenn das AppImage die Funktion AppImageUpdate unterstützt.
Mit AppImageLauncher lassen sich AppImages zentral verwalten und über das Menü der Desktop-Umgebung starten, entfernen und, falls unterstützt, auch aktualisieren. Damit können die Nachteile von AppImage gegenüber Flatpak und Snap egalisiert werden und die Vorteile überwiegen.
Schön, wenn´s funktionieren würde!
AppImageLauncher-Appimage läßt sich nich starten.
RPM-Installer bringt nur eine Fehlermeldung.
Schade.
Läuft hier schon länger als der Artikel alt ist. Evtl. musst du die Datei zunächst ausführbar machen:
chmod a+x NAME_DER_DATEI.AppImageDas ist nicht das Problem.
Manche Appimages starten einfach nicht(dies Problem ist verbreitet und bekannt).
Aber trotdem Danke für den Rat!
Hab den Fehler (scheinbar) gefunden!
In manchen Appimages scheinen die Entwickler nicht alle Zugehörigkeiten integriert zu haben…deshalb Fehlstart(bzw. kein Start/Ausführung)!
Lösung: Enwickler kontaktieren! (als DAU)
Wird appimage so wie flatpack von redhat und snaps von ubuntu von einer Firma forciert?
Hat SUSE etwas ähnliches wie flatpack?
Nein, hinter AppImage steht kein Unternehmen sondern Simon Peter, der im Netz als probono unterwegs ist. Und nein, openSUSE hat nichts dergleichen.
Interessant. Ein weiterer Nachteil von AppImages ist (glaube ich), dass sie sich keine Bibliotheken teilen _können_, selbst wo das sinnvoll wäre.
Ist das nicht deren Vorteil?
😉
Der Vorteil ist, dass man nicht auf geteilte Bibliotheken zugreifen _muss_ – dass man aber nicht anders _kann_ als alles selbst mitzubringen (selbst wenn x AppImages dieselbe Version einer Bibliothek verwenden), empfinde ich klar als Nachteil!
Es ist ganz klar von Vorteil, wenn man mehrere Versionen eines Programmes parallel nutzen kann; z.B. wenn sich das Format der gespeicherten Daten ändert…
Und dieses Mimimi-Argument mit der Platzverschwendung in Zeiten von Terrabyte-SSDs ist einfach nur zum totlachen – nein, es ist tot-traurig, dass es immernoch hinter dem Sofa hergeholt wird…
Es hat zwar nicht jeder TB-SSDs (und dann können ein paar zusätzliche GB für in paar kleine Anwendungen schon entscheidend sein – traurig ist, dass Du Dir das nicht vorstellen kannst), aber um den Platz ging es mir nicht (sondern um Wartbarkeit/Sicherheit) – wenn eine Anwendung nicht auf eine uralte Version einer Bibliothek angewiesen ist (und dann stellt sich die Frage, ob man der Anwendung vertrauen sollte), wäre es besser, die Bibliothek zentral für alle Anwendungen aktualisieren zu können, statt darauf hoffen zu müssen, dass das jede Anwendung selbst tut.
Das ist/wäre ja auch bei klassischen Distri-Paketen der Fall (wenn sie denn mehrere Versionen paketieren (würden)).
Mich stört speziell aber das „Beiwerk“ (Bibliotheken), das man (bei „Standardversionen“) eben nicht immer selbst mitbringen müsste – so wie es bei Flatpak gelößt ist (wenn es denn sinnvoll verwendet wird).
Lange Version: so kann jede “App” eigene (modifizierte, neue oder zu alte) Bibliotheken verwenden, ohne dass es Einfluss auf andere Programme hat. (Erinnert ein wenig an Windows, wo man öfters mal gefragt wurde, ob man xyz.dll überschreiben möchte, sodass das neue Programm dann lief, aber andere Programme dann plötzlich nicht mehr). Der Preis ist, dass dann eine Bibliothek (in drölfzig Versionen/Varianten) zig mal im Speicher liegt und zig mal auf der Festplatte.
Flatpak nutzt Runtimes, von denen man mehrere haben kann, die allen auf diesen Runtimes basierenden Anwedungen bestimmte Bibliotheken zur Verfügung stellen. Nutzen mehrere Apps die gleiche Runtime, braucht man nicht alles doppelt und dreifach. Nutzt allerdings jede Anwendung eine andere Runtime, geht das nach hinten los.
Denke, es kommt immer auch auf den Verwendungszweck an.
Paket-Maintainte Distributionen sind für mich aber immer noch das Beste überhaupt weil die gegenseitige Kontrolle in einer Community und die Nachvollziehbarkeit jedes einzelnen Codeschnipsels dafür sorgt, dass wir vor “praktischer” Addware verschont bleiben.
Nicht nur wegen Microsoft bin ich damals von Windows geflüchtet. Auch die ganzen Werbe- und Spyadds, die man sich fasst überall eingefangen konnte haben mich damals angewidert. Und alle drei Techniken öffnen eine Tür, die das Gleiche bei Linux möglich macht.
Einspruch!
Es gibt leider immer noch ausreichend Software, die keine OpenSource ist; die man aber trotzdem haben möchte.
Da ist es völlig egal; ob die nun als AppImage, als Distri-spezifisches Paket oder als Snap vorliegt!
Andersherum bedeutet eine Software als Snap, AppImage oder Faltpack zu verteilen auch nicht, das sie nicht doch OpenSource ist und deshalb für jeden nachvollziehbar ist!
Ansonsten müsstest Du die Distri total verrammeln, a’ la Apple, wo man exakt nur aus dem Applestore Apps installieren kann! – Allerdings wäre solch eine Distri nicht sonderlich erfolgreich, weil man eben nicht mehr das Programm installieren kann, was man braucht!
Gerade bei nicht einsehbarer Software ist das keineswegs egal, ob die wenigstens in einer Sandbox läuft oder direkt!
Das könnte bei Snap ja nie passieren 😉
Wieso formulierst du das als Einspruch?
Snap ist zielgerichtet dafür entwickelt worden ein distributionsübergreifender Marktplatz für proprietäre Software auf Linux zu sein. Ich sehe das erst einmal ganz neutral.
Flatpack kann das auch, ist aber nicht so lizesiert, dass ausschließlich ein Unternehmen diesen Marktplatz inne hat.
Zusätzlich, und das war wohl das naheliegendste Motiv für RedHat flatpack zu entwickeln, sind die Formate dafür ausgelegt auf einem oft älteren stabilen Kernpaketstand aktuelle Anwendungen laufen zu lassen. Das pushed Linux ungemein. Firmen die Linux einsetzen müssen nicht mehr auf neue Versionen von Anwendungssoftware warten oder automatisch die Version der Anwendungen updaten wenn die Distribution updatet.
Dies hat aber langfristig auch große Auswirkungen auf die gesamte Distributionslandschaft.
Bisher waren die Distributionen ein vertikales Nebeneinander verschiedener Software Aktualitäten, wobei jede Distribution auf einen möglichst kompletten Paketbestand achten musste. Mit den Formaten snap und flätpack kommt eine horizontale Ebene hinzu, die es erlaubt nur noch ein Kernangebot bereit zu stellen.
Bei all dem recht positiven Fortschritt, gehe ich halt nur zu bedenken, dass das Selbstverständnis das man als Linuxnutzer hatte von Addware verschont zu bleiben damit bald ein Ende haben wird.
Privat werde ich darauf weiterhin wert legen, eine ausschließlich von der Community betriebene Distribution zu nutzen, die weiterhin ein Maintainment aller wichtigen Softwarepakete garantiert. Und wenn ich dann auch gelegentlich auch mal flatpack nutzen werde dann werde ich darauf achten aus welcher Quelle dies Pack stammt.
Ein Statment für das bisherige Maintainment heißt nicht, dass man die neuen Formate ablehnt. Aber ein mehr an Möglichkeiten sollte auch immer davon begleitet werden sich mehr Orientierung dabei zu verschaffen was diese Veränderungen bedeuten.
Wobei sich das nicht ausschließt. Distributionen wie Fedora oder elementaryOS bieteten eigene Flatpak-Repos an.
(rpm-)ostree basierte Distributionen (Fedora Silverblue, Endless OS) sind auf Flatpaks angewiesen, weil klassisches Paketmanagement nicht oder nur noch eingeschränkt funktioniert und elementry OS kann so unabhängig von der Ubuntu Basis die eigenen Anwendungen verteilen/verkaufen.
Appimages sind der Hammer!
Erinnert mich etwas an die Zeit von Windows mit den Exe-Dateien, nur dass man Appimages sogar nicht mal installieren braucht.
Da ich eh nicht soo updateverliebt bin, brauch ich nicht dauernd Auto-Updates. Wenn doch mal ein großes Update mit vielen nützlichen Neuerungen rauskommt, dann kann mans auch manuell runterladen. Das ist aber meist so selten, dass es verschmerzbar ist.
Und keine Abhängigkeit von Snap und Co, Snaps sind direkt bei der Linuxinstallation runtergeflogen 😀
Naja, die meisten Updates (auf einer LTS-Distri) dienen aber nicht den neuen Funktionen!
Wobei es diesen Automatismus mit Flatpak/AppImage so eben nicht gibt. Da kann man ein altes vergammeltes Debian nutzen, aber trotzdem die neuesten Anwendungen haben, eben weil sie unabhängig von der Distribution installiert werden.
Zu Auto-Updates würde ich aber trotzdem raten, sonst sammelt man am Ende noch Sicherheitslücken.
Nein, bei gewissen Produkten ist es sinnvoll, neuste Sicherheitsupdates zu haben. Gerade alles was übers Internet läuft. Das ist bei Appimages häufig oder fast meistens gar nicht der Fall, wie sie auch schreiben bei einer LTS-Distro (hier geht es ja um Appimages). Wenn mein Inkscape stabil läuft, warum brauche ich also Updates? Alle 1-2 Jahre von mir aus, aber dauernd jede kleine Veröffentlichung mitmachen? Ne!
Du verwendest wohl kein Joplin.
Bei einigen Anwendungen, die ich nur gelegentlich nutze, greife ich auch – u.a. aus Komfortgründen – auf das Appimage zurück. Es ist schön einfach, zügig das Helferlein zu finden und immer wieder unkompliziert starten zu können. Vor allem dann, wenn das Tool nicht über “Mainstream-Quellen” verfügbar ist. Ist nicht das alleinige Format der Wahl mit unbegrenzten Vorzügen, aber es hat eben seine Vorteile, die ich sehr schätze 😉