AppImages in den Desktop integrieren

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.

Kommentare

25 Antworten zu „AppImages in den Desktop integrieren“

  1. Avatar von Hermann Salber
    Hermann Salber

    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 😀

    1. Avatar von kamome
      kamome

      Naja, die meisten Updates (auf einer LTS-Distri) dienen aber nicht den neuen Funktionen!

      1. Avatar von no one
        no one

        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.

      2. Avatar von Hermann Salber
        Hermann Salber

        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!

        1. Avatar von Atalanttore
          Atalanttore

          Du verwendest wohl kein Joplin.

    2. Avatar von Dominic
      Dominic

      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 😉

  2. Avatar von kamome
    kamome

    Interessant. Ein weiterer Nachteil von AppImages ist (glaube ich), dass sie sich keine Bibliotheken teilen _können_, selbst wo das sinnvoll wäre.

    1. Avatar von Sebastian
      Sebastian

      Ist das nicht deren Vorteil?
      😉

      1. Avatar von kamome
        kamome

        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!

        1. Avatar von juchtel
          juchtel

          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…

          1. Avatar von kamome
            kamome

            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.

          2. Avatar von kamome
            kamome

            wenn man mehrere Versionen eines Programmes parallel nutzen kann

            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).

    2. Avatar von Sebastian
      Sebastian

      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.

      1. Avatar von no one
        no one

        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.

        1. Avatar von tuxnix
          tuxnix

          Denke, es kommt immer auch auf den Verwendungszweck an.

          1. Snap ist keine freie Software hat aber Vorteile bei den vielen IoT- Geräten die ansonsten nie ein update bekommen würden. Für proprietäre Software auf Linux ideal weil es den Support in einer heterogene Linuxlandschaft ermöglicht.
          2. Flatpak ist frei, kann viel und kann auch recht schmal sein. Es erleichtert die Verteilung von Software und vor allem auch den Support.
          3. Beim Appimage ist der Entwickler wohl am unabhängigsten und kann seine Software frei von der Unterstützung von Distributionen und auch frei von den obigen Plackereien verteilen. Gut das es das gibt.

          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.

          1. Avatar von juchtel
            juchtel

            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!

          2. Avatar von kamome
            kamome

            Da ist es völlig egal; ob die nun als AppImage, als Distri-spezifisches Paket oder als Snap vorliegt!

            Gerade bei nicht einsehbarer Software ist das keineswegs egal, ob die wenigstens in einer Sandbox läuft oder direkt!

            wo man exakt nur aus dem Applestore Apps installieren kann!

            Das könnte bei Snap ja nie passieren 😉

          3. Avatar von tuxnix
            tuxnix

            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.

          4. Avatar von no one
            no one

            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.

  3. Avatar von Ratatösk
    Ratatösk

    Wird appimage so wie flatpack von redhat und snaps von ubuntu von einer Firma forciert?
    Hat SUSE etwas ähnliches wie flatpack?

    1. Avatar von Ferdinand

      Nein, hinter AppImage steht kein Unternehmen sondern Simon Peter, der im Netz als probono unterwegs ist. Und nein, openSUSE hat nichts dergleichen.

  4. Avatar von Hubert
    Hubert

    Schön, wenn´s funktionieren würde!
    AppImageLauncher-Appimage läßt sich nich starten.
    RPM-Installer bringt nur eine Fehlermeldung.
    Schade.

    1. Avatar von Ferdinand

      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.AppImage

      1. Avatar von Hubert
        Hubert

        Das ist nicht das Problem.
        Manche Appimages starten einfach nicht(dies Problem ist verbreitet und bekannt).
        Aber trotdem Danke für den Rat!

        1. Avatar von Hubert
          Hubert

          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)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert