Unterschiede AppImage und Snap
-
Mintbonbon -
September 30, 2025 at 10:06 PM -
Thread is Resolved
-
-
Hier ein Auszug aus meinem appimage-Repertoire. Vorteil, du hast ein kompletten "Container" wo für die Programme alles drin ist. Eben ein Image. Da sind alle benötigten libs und dlls vorhanden. Die Apps liegen bei mir auf eine anderes Laufwerk. Somit wird das "C-Verzeichnis" nicht mit Snap oder Flatpacks voll geschrieben.
Starten kann man die direkt im Terminal oder aus einem Datei-Manager.
Es gibt auch zip-Dateien, entpacken und direkt das Programm starten. Ich habe scripte oder Verknüpfungen angelegt.
Das beste Programm ist Stellarium-25.3-qt5-x86_64.AppImage
-
Somit wird das C-Verzeichnis nicht mit Snap oder Flatpacks voll geschrieben.
Aha, Windows....

-
Aha, Windows....

Wär bestimmt ganz lustig, auf der Systempartition ein Verzeichnis C: anzulegen und zu chrooten. Umsteiger müssten sich nur daran gewöhnen, noch einen / vor das C: zu schreiben. Könnte man bestimmt in GuideOS einbauen

-
Stephan: Dankeschön, das ist eine gute Möglichkeit. Kannst Du evtl. einen oder auch mehrere "Store" dafür empfehlen, wo man diese Images bekommen kann?
-
@ all
Ich bemerke das ab Beitrag #39 am eigentlichen Thema vorbei geplaudert wird. Bitte beachten das der TE seine Anfrage bereits als "gelöst" markiert hat. Danke
-
Ich bemerke das ab Beitrag #39 am eigentlichen Thema vorbei geplaudert wird. Bitte beachten das der TE seine Anfrage bereits als "gelöst" markiert hat. Danke
Habe die Beiträge in ein neues Thema verschoben.
-
Nachteil ist natürlich, dass sich Appimages nicht automatisch aktualisieren. Sprich, man darf sich die Binärdateien selber zusammensuchen.
-
Stephan: Dankeschön, das ist eine gute Möglichkeit. Kannst Du evtl. einen oder auch mehrere "Store" dafür empfehlen, wo man diese Images bekommen kann?
www.appimagehub.comA community where developers and artists share applications, themes and other contentwww.appimagehub.com -
Danke Bleys.

-
Der vielleicht wichtigste Unterschied zwischen den Formaten AppImage und Snap (sowie in dem Fall auch Flatpak) ist, dass die Nutzung von AppImages ganz ohne übergeordnetes Management von seiten des Betriebssystems auskommt. Ein AppImage ist auch nicht im eigentlichen Sinne installiert, sondern nur kopiert. Im Windows-Jargon würde man von einem portablen Programm sprechen. Ansonsten haben AppImages aber die Gemeinsamkeit mit Snap- und Flatpak-Apps, dass sie ihre abhängigen Komponenten selber schon mitbringen und deshalb deutlich speicherhungriger sind als klassische Anwendungen aus der Paketverwaltung.
-
Nachteil ist natürlich, dass sich Appimages nicht automatisch aktualisieren. Sprich, man darf sich die Binärdateien selber zusammensuchen.
Hierfür (Aktualisierung der Anwendungen) eignen sich Anwendungen wie Gear Lever, wobei das auch oft Gefrickel ist zumindest sind das meine Erfahrungen. Ich nutze Appimages gern für Anwendungen die nicht regelmäßig aktualisiert werden müssen, einen Browser z.B würde ich darüber jetzt nicht nutzen.
-
Neumann und Hammer20l: Danke euch für eure Beiträge, das ist mir neu gewesen. Anfürsich eine gute Sache, was ich aber bisher so gefunden habe, war teils älteres Zeug. Auch Apps, die es im normalen LM-Paketmanager gibt. Hatte gehofft, hier noch ein paar Leckerlies zu finden. Schade.
Hammer20l: Mittlerweile gibt es wohl noch eine andere App, die die Updatefrage lösen soll. Ich glaube sie hört auf den Namen "AppimageUpdater", oder so ähnlich.
-
Wahrscheinlich ist es das.
GitHub - AppImageCommunity/AppImageUpdate: AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself.AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. - AppImageCommunity/AppImageUpdategithub.com -
Es gibt hier mehrere Wege. z.B.
appimagepool-5.1.0-x86_64.AppImage. Da ist eine Sammlung von Appimages, eher so ein Verwaltungsprogramm.
Sonst schaue ich direkt mal bei den Softwareentwicklern.
https://download.gimp.org/gimp/v3.0/linux/GIMP-3.0.4-x86_64.AppImage
https://github.com/rustdesk/rustdesk/releases/download/1.4.2/rustdesk-1.4.2-x86_64.AppImage
https://appimages.libreitalia.org/LibreOffice-fresh.standard-x86_64.AppImage
-
Hallo Stephan,
DANKE, für die Tipps, LibreOffice habe ich mir gleich mal gezogen. Was noch schön wäre, wenn es CrystalDiskInfo als Linuxversion geben würde. Obwohl auch die App "GSmartcontrol" einen guten Dienst verrichtet. Leider unterstützt die offizielle Version in LM noch keine Nvme's. Dazu muss man sich erst auf der Webseite des Herstellers die neueste Version holen, schade.
Super finde ich auch, dass es vom Tool "Ventoy" eine Linuxversion gibt, die auch nicht installiert werden muss. Da wäre es noch besser, wenn es das von "Rufus" auch gäbe. Aber "Ventoy" ist wichtiger.
-
Man sollte auch immer im Hinterkopf behalten, dass diese Image-Formate (Flatpak, Snap, AppImage) Erleichterungen für die Entwickler bringen sollen, aber nicht unbedingt Verbesserungen für die Nutzer. (Natürlich abgesehen davon, dass die ein oder andere App in der Form gar nicht (mehr) existieren würde, wenn die Programmierer nicht auf diese für sie komfortabler zu handhabende Darreichungsform ausweichen könnten.) Daher nutze ich diese Formate nur, wenn ein Programm nicht in der Paketverwaltung angeboten wird oder die dortige Version nicht richtig funktioniert.
Das Image-Format, das mir persönlich am besten gefällt, ist AppImage. Einfach weil es so einfach und unkompliziert daherkommt.
Was mir auch gleich auffiel, war dessen kozeptionelle Ähnlichkeit mit Anwendungen wie sie unter RISC OS organisiert sind (RISC OS (siehe auch DistroWatch) lief in den 90ern auf Nischensystemen (ACORN), die mit ARM-Prozessoren betrieben wurden und mit einem für die damalige Zeit avantgardistischen Desktop-Konzept daherkamen.)
AppImages sind im Grunde genommen ausführbare Ordner. Wenn man auf einen normalen Ordner doppelklickt, öffnet sich bekanntlich dessen Inhalt. Bei einem ausführbaren Ordner wird bei Doppelklick stattdessen nach einer Startdatei gesucht, die die Programmausführung in Gang setzt. Unter RISC OS konnte man im Gegensatz zu AppImages unter Linux aus der Nutzerebene heraus den Programmordner aber auch einfach nur öffnen, indem man beim Doppelklick die Shift-Taste gedrückt hielt. Dann ließen sich auch alle im Ordner enthaltenen Konfigurationsobjekte inspizieren (z.B. Icons für das Programm, geclaimte Dateitypen, Speicherreservierungen, verknüpfte Hintergrund-Module, Fenster-Definitionen, Preboot-Aktionen usw.).
Anwendungen unter RISC OS, die am vorangestellten '!'-Zeichen im Namen erkennbar sind, waren generell nicht im heutigen Sinne 'installiert'. Sie waren wie AppImages heute sozusagen portabel.
-
Neumann: Das hast Du wieder mal verständlich und ausführlich geschrieben. Danke dafür.
Das mit den "portablen Apps" hat mir schon unter Windows sehr gefallen. Der Grund war bei mir vor allem, dass Windows "sauber" blieb. Unter Windows war es ja weit verbreitet, dass die Deinstaller etlichen Müll zurück liessen, was mit der Zeit die Windowsinstallation immer weiter aufgebläht hat. Generell ist mir auch eine App aus der Paketverwaltung am liebsten.
Ich möchte dazu gerne noch eine Frage in die Runde stellen: Wie läuft das bei Linux (Mint) mit den Deinstallationen? Wird von Haus aus "ordentlich", sprich restlos deinstalliert? Oder bläht sich Linux auch immer weiter auf, je öfter man Apps in- und deinstalliert? Und wie steht es mit den Dateileichen, die tagtäglich angesammelt werden? Im Sinne von "temporären Dateien"?
Gibt es eine ANFÄNGERFREUNDLICHE App zum Löschen der temporären Dateien? Ich bin da schon übel eingegangen!!! Ich hatte einen "Supercleaner" der versprach, ordentlich Platz zu schaffen. Letztlich hat er so gut "aufgeräumt", dass mein System kaputt war. Gut, dass noch ein zeitnahes Vollbackup da war

. -
Mintbonbon
October 3, 2025 at 1:37 PM Selected a post as the best answer. -
Moderationshinweis:
Ich habe eure Beiträge, bezüglich temporäre Dateien löschen usw,, hierhin ausgekoppelt.
unameOctober 3, 2025 at 12:09 PM
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!