In einem Beitrag für TechRepublic schreibt der Enwickler Jack Wallen: "Ich verstehe, warum es AppImages gibt. Sie waren die Vorläufer von Flatpak und Snaps und ermöglichten es Entwicklern, portable, universelle Anwendungen zu erstellen, die auf jeder Linux-Distribution laufen konnten. Während Flatpaks und Snaps sowohl Isolation, Integration und Update-Fähigkiet mit sich bringen, werden AppImages nicht tatsächlich installiert. Stattdessen sind sie so etwas wie die Container von Desktop-Anwendungen, ohne dass sie auf eine installierte Engine wie Docker angewiesen sind. Man lädt ein AppImage herunter, erteilt ihm die Erlaubnis zur Ausführung und führt es aus. Es gibt jedoch Probleme mit AppImages; Probleme, die bei Flatpak- oder Snap-Anwendungen nicht auftreten. Diese Probleme führen dazu, dass man sich dreimal überlegen sollte, AppImages zu verwenden.
Wer den aktuellen Nextcloud-Desktop-Client (Version 3) entweder unter MacOS oder Windows verwenden, erhält ein natives Installationsprogramm. Nach der Installation funktioniert alles genau wie erwartet. Linux-Anwenderinnen haben nur eine einzige Option, ein AppImage. Von der Version 3 existieren weder native Pakete (deb, rpm, etc.) noch aktuelle Flatpaks (letzte Version ist 2.6.5) oder Snaps (gar keine Version). Zwar funktioniert das Appimage einwandfrei, solange es lediglich um seine eigentliche Funktionalität geht. Das Problem liegt jedoch darin, dass es nicht möglich ist, das Nextcloud AppImage beim Login automatisch zu starten und in das Desktop-Menü zu integrieren. Auf dem GNOME-Desktop funktioniert dies nicht. Soll der Nextcloud-Desktop-Client gestartet werden, muss man den Dateimanager öffnen, das AppImage finden und es von dort aus starten. Es nützt auch nichts bei den Einstellungen 'beim Systemstart starten' zu aktivieren; es startet nicht. Der Grad der Integration hängt jedoch von der Desktop-Umgebung ab:
- GNOME: Die Anwendung läuft ohne Desktop-Integration und wird beim Login nicht automatisch gestartet.
- KDE: Anwendung läuft mit Desktop-Integration und startet automatisch beim Login
- Deepin: Anwendung läuft ohne Desktop-Integration und ohne automatischen Start bei der Anmeldung
- Pantheon (elementares OS): Die Anwendung läuft ohne Desktop-Integration (nicht einmal eine Möglichkeit, auf die Anwendung über das Panel zuzugreifen) und ohne Autostart bei der Anmeldung.
Die Idee der AppImages ist verständlich: Sie machen es den Entwicklern viel einfacher. Anstatt ein Build für jede mögliche Kombination aus Distribution und Desktop erstellen zu müssen, müssen sie nur ein einziges paketiertes AppImage erstellen. Die Sache ist die, dass diese AppImages selten durchgängig konsistent sind. Was passiert, wenn jemand weniger Erfahrung mit einer Anwendung auf der Desktop/Distribution-Kombination seiner Wahl hat als erwartet? Wahrscheinlich hört er auf, diese Anwendung zu verwenden und geht zu einer anderen Lösung über. Oder schlimmer noch, es vermittelt einem neuen Benutzer einen schlechten Eindruck von Linux als Ganzem.
Hier ist ein weiteres Problem mit AppImages: Jeder kann ein AppImage erstellen, es zu einem "must-have" der Software erklären, schadhafte Bestandteile einbauen und es zum Herunterladen zur Verfügung stellen. Benutzer laden dann dieses AppImage herunter, erteilen ihm die Erlaubnis zur Ausführung und starten es. Angesichts der steigenden Popularität von Linux werden wir immer mehr Angriffe auf die Plattform erleben." Soweit die Meinung von Jack Wallen.
Die Probleme mit nicht funktionierendem Autostart, kann ich für diverse Appimages bestätigen. Auch Anwendungsstarter werden von Appimages nicht erstellt. Gerade bei Einsteigern führt dies zu einem schlechten Eindruck, da die wenigsten in der Lage sind, selbst eine Menüintegration und einen Starter mit passendem Anwendungs-Icon zu erstellen. Bezüglich der Sicherheit, sehe ich hingegen keinen Unterschied zu Flatpak- und Snap-Paketen, da diese ebenfalls das klassische Maintainer-Prinzip nicht kennen. Der ArchLinux-Paketbetreuer Kyle Keen kritisierte das Konzept von Snaps und wandte sich prinzipiell gegen eine Softwareverteilung durch die Applikationsentwickler (Upstream-Entwickler). Linus Torvalds sprach sich dagegen für Upstream Packaging aus und verwendet für seine Anwendung Subsurface AppImage-Pakete.
Von den Entwicklern der Linux-Distribution Mint wird kritisiert, dass Snaps exklusiv über einen einzigen App-Store von Canonical ausgeliefert werden, der unter der Kontrolle von Canonical steht und dessen Code proprietär ist. Dadurch habe Canonical die Möglichkeit Hintertüren in Ubuntu einzurichten. Seit der Version „Ulyana“ blockiert Linux Mint die Installation von Snap-Paketen.
Dies sind jedoch weitergehende Kritikpunkte, die auf alle neuen Container-Formate zutreffen. Zumindest bei der Systemintegration bieten Flatpaks und Snaps eindeutige Vorteile gegenüber Appimages.
Quelle: https://www.techrepublic.com/article/why-i-have-a-problem-with-appimages-on-linux/
keine Kommentare, unverdienterweise. Weil oberflächlich und mehr persönliche Meinung als Fakten Ich benutze Appimages seit Jahren, wenn ich die Wahl zwischen appimages und flatpaks habe, nehme ich Appimages (u.A. wegen des beträchtlichen Unterschiedes im Platzbedarf).
Systemintegration ist einfach, entweder eine *.Desktop Datei selber erstellen (echt jetzt, das ist wirklich kein Hexenwerk, das kann man nach 5 Minuten googlen rausfinden, wie das geht) oder für Faule ein Tool wie z.B. appimagelauncher, der nicht nur eine desktop Datei erstellt, sondern sie auch gleich in ~home/.local/share/applications/ unterbringt.
Wie, Autostart geht nicht? Das hätte man mir vor ein paar Jahren sagen sollen. Natürlich geht das, einfach (je nach Distribution) die desktopdatei in den Autostart Ordner werfen oder bei schlichteren System mit startup dateien, das Appimage dort aufrufen. Ja, das ist vielleicht nicht ganz so Deppensicher einfach wie eine Programminstallation über einen "Appstore" und man muss vielleicht auch mal ein paar Doks lesen (wie schreibt man Desktop Dateien, wie startet man Programme im Autostart ... wo ist bei meinem Auto der Scheibenwischer und wie fülle ich das Wasser nach ...jesses)