Wenn der VLC das einzige Flatpak auf deinem System ist, ist es normal dass es so groß ist. Flatpak läd alle Abhängigkeiten mit, kann diese aber für andere Pakete dann teilen.
Appimage sind Zeitaufnahmen des Programmes und meines Wissens nach, nicht updatefähig. Du müsstet also für jede Version ein neues Appimage laden.
Dafür sind sie im einzellnen etwas kleiner.
Hier ist auch die Frage, wie viel Programme du jeweils in der Art nutzen willst. Über die Masse gesehen, werden Flats am Ende wohl insgesamt weniger Speicher benötigen, als die gleiche Anzahl an Appimages.
Sie aktualisieren sich in der Regel (es gibt vereinzelte AppImages die sich selber aktualisieren können) nicht automatisch. Und man muss wenn eine neue Version von z.b. VLC rauskommt, halt das AppImage von Hand neu herunterladen.
Ausserdem wenn man mehrere AppImages benutzt brauchen die mehr Speicherplatz als mehrere Flatpaks oder Snaps. Da Flatpak und Snap ja Abhängigkeiten haben. Also da wird bei VLC z.b. die komplette QT Bibliothek als extra Flatpak installiert -> wenn du dann ein zweites Flatpak das QT brauchst installierst nutzt es diese Abhängigkeit mit - während ein zweites QT-AppImage die Abhängigkeiten wieder selber mitbringt.
Zudem musst du bei AppImages wenn du sie sauber in den Desktop integrieren willst (also im "Startmenü" deines Desktops angezeigt werden) jeweils eigene *.desktop Dateien erstellen und hinterlegen.
Wenn du die AppImages per Terminal Befehl oder über Alt+F2 öffnen willst, musst du sie in einem Ordner schieben der in deinem $PATH ist, etc. Ist halt einfach mehr Handarbeit, die dir sonst ein Paketmanager (egal ob apt, dnf, zypper, pacman, flatpak, snap, etc) abnimmt.
Vom Prinzip her sind die nicht anders als die Flatpaks oder Snaps. Genau wie bei Flatpak oder Snap bringen die Appimages die kompilierten Ressourcen zum Laufen mit. Daher sind sie theoretisch auch nicht viel kleiner als z.B. ein Flatpak. Ein Flatpak, das mit z.B. einem GB Größe angegeben ist, wird in der Realität so gut wie soviel Platz belegen. Wenn Du viele Flatpaks oder Snaps hast, dann werden sich diese Images sogar einige Libs teilen. Bei einem Appimage hingegen würdest Du jedes mal die volle Größe herunterladen müssen und hättest am Ende sogar mehr Platz verbraten. Ein weiterer Vorteil der Flatpaks oder Snaps: die Aktualisierungsverwaltung Deiner Distro wird wahrscheinlich diese Apps aktuell halten.
Bein den Appimages musste Du selber dafür sorgen, dass die Updates eingespielt werden. Von der Funktionioalität her nehmen sich die verschiedenen Formate meiner Erfahrung nach nichts.
kim88 war schneller als ich 
Ich hau der Vollständigkeit halber noch den AppImage-Launcher hinterher. Der integriert die Files gleich ins Startmenü. Nur falls du den noch nicht kennst.
appimagelauncher_2.2.0-travis995.0f91801.bionic_amd64.deb läuft gut auf Mint
Wouw, was ein geiles Forum. Ich könnt grad heulen, wäre ich nur sensibel genug. Solche Antworten sucht man in anderen Forum mit der Lupe.
Ich hab da tatsächlich alles kapiert. Würde ich nun Flatpack nutzen, wäre mein DatenDingsda aufgebraucht, denn ich mach das ja grad über Android. Also AppImages, und das juckt mich herzlich wenig, die ab und an zu aktualisieren.
Habt ganz vielen DANK!!!!!
Schau auf github mal nach appman: https://github.com/ivan-hc/AppMan
Nutze ich auch. Musste aber im Terminal bedienen. Weiß nicht, ob dir das was ausmacht. Aber damit kannst du Appimages installieren, updaten, entfernen, etc. pp. Und es legt dir auch .desktop-Einträge an, sprich, du hast es auch im Menü.
Ich nutze schon länger den Bauh Appmanager für Appimage, und auch für Flatpak. Man kann so suchen, welche Paketart zu Verfügung steht, und entweder Flatpak oder Appimage installieren. Wird auch gleich ins Menü integriert und zeigt auch Updates an, die alle auf einmal eingespielt werden können. Appimages können auch manuell installiert und ins Menü integriert werden. Nutze ich regelmäßig. Kann auch Snap, WebApps, Debian und Arch Pakete verwalten. Integriert sich in den System-Tray und meldet sich automatisch bei verfügbaren Updates. (Kommt ursprüglich von Arch-Linux). Läuft unter Mint und Debian prima. Siehe auch: https://gnulinux.ch/pakete-mit-bauh-verwalten
Bei dem Appimages werden allerdings nicht immer alle verfügbaren gefunden, sondern nur die die bei Github Pakete zur Verfügung stellen. Z.B. beim Nextloud Appimage klemmt es öfters mal.
Supported sources: AppImageHub (applications with no releases published to GitHub are not available)
All available application names can be found at apps.txt
Für Debian-basierte Systeme kann ich auch noch deb-get empfehlen, um einige neuere Programmversionen automatisch aus einem Ubuntu-PPA oder Github etc. zu installieren. Das nimmt einem die Suche und Repositiy-Konfiguration ab. Nutze ich z.B. für Librewolf Browser, Bitwarden Passwort Manager, Copy Clipboard Manager. Bei PPAs werden die Updates automatisch über den Aktualisierungsmanager (der Distribution) oder
apt upgrade geupdated, bei Github etc. muß man allerdings deb-get upgrade selber von Zeit zu Zeit aufrufen.
Ich hoffe, es ist ok, wenn ich den alten Thread hier wieder ausgrabe.
Die verwirrung zwischen Snap, Appimage, Flatpak und .deb ist schon groß.
Das, was ich dazu gelesen und durch diesen Thread herausgefunden habe, ist:
Snap => Böse.
Appimage => gut, aber großer Speicherverbrauch
Flatpak => gut, erste Installation groß, dann geteilte Bibliotheken
.deb => native Pakete
In dieser Reihenfolge wäre es auch zu bevorzugen:
1. deb
2. Flat
3. AppImage
Das Problem ist, dass es manche Applicationen nur als Appimage gibt, z.B. Remnote.
Was ich nicht verstanden habe: Warum sind manche Apps bei Flatpak aktueller als über die "normale" Paketverwaltung?
Z.B. Rednote. Aktuell als Flat, älter (mit Bugs) im Repository.
Also, bei diesem Thema scheiden sich die Geister.
Snap -> ist meiner Meinung nach nicht böse (warum denn auch?) wird halt nur von einer Firma betreut. Ist ähnlich zu betrachten wie Flatpak
Flatpak -> hier werden das Programm als "ganzes - mit allen Abhängigkeiten" angeboten. Der Vorteil ist, dass man Plattform-Unabhängig Programme anbieten kann. Dadurch sind die Programme meist immer topaktuell. Nachteil: Sehr große Datenmengen, da ja alles in ein Paket gepackt werden muss.
Appimage -> beginnt sich erst jetzt wirklich in Linux durchzusetzen. Ist ähnlich wie Flatpak zu sehen, auch hier wird alles in eine Paket gepackt.
Deb Pakete -> sind für Debian basierte Linux Systeme (Linux Mint, Ubuntu, .......) Diese Pakte sind natürlich zu bevorzugen. Hier wird das entsprechende Programm von den Machern an das System "angepasst". Dadurch ergibt sich auch eine gewisse Verzögerung mit der Aktualität der Programmversionen.
Mein Fazit:
Wenn du genug Speicherplatz hast spricht rein gar nichts gegen Flatpak und Co.
Lediglich beim Programmstart musst du in Sachen Geschwindigkeit ein wenig Zeitverzögerung in Kauf nehmen, da ja alle Bibliotheken auch erst mitgeladen werden müssen.
Aber über die Verwendung muss natürlich jeder selbst für sich entscheiden was in Betracht kommt.
Wer die Wahl hat, hat auch die Qual 
Fedorer Sorry aber das ist Unsinn warum soll "Snap" böse sein? Weil das jemand im Internet geschrieben hat? 🙄
Was ich nicht verstanden habe: Warum sind manche Apps bei Flatpak aktueller als über die "normale" Paketverwaltung?
Hier kommt eben die grosse Frage für was für ein Distirbutionsmodell du dich entschieden hast.
Ubuntu, LinuxMint, Debian, etc sind klassische "Point-Release-Distributionen"
Als Beispiel Ubuntu:
Ubuntu baut ein komplettes Release z.b. 24.04. Alle Pakete die dort drin sind (LibreOffice, Kernel, Audioplayer, etc) haben eine fixe Versionsnummer und bleiben dann auch auf dieser Version. Das bedeutet wenn bei Ubuntu 24.04 z.b. ein Audiplayer in der Version 1 vorhanden ist wird der innerhalb von 24.04 nie ein Update auf Version 2 erhalten. Sonder er erhält nur Sicherheitsupdates.
Die Version 2 kommt dann erst mit einer komplett neuen Ubuntu Version (z.b. 24.10). Also kurz gesagt Ubuntu 24.04 bekommt maximal 12 Jahre Sicherheitsupdates - bedeutet wenn man im Jahr 2035 noch 24.04 benutzt hat man immer noch Version 1 von diesem Audioplayer selbst wenn es bereits Version 8 geben sollte.
Das ist das was man bei Linux unter "stabil" versteht. Das Wort "stabil" in der Linux Welt bedeutet nicht das eine Software nie abstürzt sondern, dass eine Version von einem Programm für einen fest definierten Zeitraum (z.b. 12 Jahre) nicht verändert wird - aber dennoch Sicherheitsupdates bekommt.
Als Gegensatz dazu gibt es das RollingRelease Modell wie z.B. von ArchLinux - das ständig Versionen ihrer Programme aktualisiert und keine eigenen Releases hat. Es gibt im Grunde kein ArchLinux Version 5 oder ArchLinux Version 6 oder sowas - sondern einfach ArchLinux das immer aktuell ist. Deswegen auch "Rolling Release" das Release ist ständig in Bewegung.
Das Point-Release Modell ist das am verbreiteste Modell von klassischen Linux Distributionen, da diese Distributionen auch oft auf Server eingesetzt werden - und auf einem Server willst du in der Regel kein Rolling Release. Als Beispiel, ich bin Software Entwickler. Wenn wir z.b. ein Web-Service für einen Kunden entwickelt haben ist der genau abgesteckt und gestestet mit definierten Software Versionen. Z.b. wissen wir er funktioniert perfekt mit PHP 7.4, und Apache 2.4 als Webserver.
Wir wollen nun keine Distribution, die bei einem Update plötzlich PHP 8 installiert und wir dann feststellen müssen dass der Service nicht mehr läuft. Du möchtest eine Distribution die möglichst lange (10-15 Jahre) Sicherheitsupdates gibt ohne die Version zu verändern. Bei jeder Versionsänderung musst du das Produkt nochmal anfassen (ausführlich testen, evtl Änderungen programmieren, wieder testen, usw) das kostet halt Zeit und dem Kunden wiederum viel Geld - und genau das versucht man zu vermeiden.
Und das ist der Grund - warum Flatpaks oft aktueller sind. Das Point-Release hat halt einen eingefrorenen Software-Stand und flatpaks werden (wie auch Snaps) in der Regel laufend aktualisiert.
kim88 Da haben wir wohl zeitgleich geschreibselt 
Zudem sind sowohl Flatpaks als auch AppImages schlussendlich graphische Anwendungsprogramme. Im Gegensatz dazu kann Snap auch unterhalb dieser "graphischen Anwendungsebene" zum Einsatz kommen (z.B. kann ein Daemon wie CUPS als Snap ausgeliefert werden) und ist daher wesentlich vielseitiger einsetzbar.
Wow.... ihr seid einfach zu gut hier, vielen Dank.
Ich glaube, jetzt habe ich einiges verstanden, besser hätte man es nicht erklären können.
Naja, ich lese viel im Internet und Snap wird von Cannonical verwaltet und die sammeln Telemetriedaten, drum böse
Das ist aber Nachgeplapper ohne eigene Erfahrungen.
Wenn man sich die Mühe macht, auf Linux (LMDE6) umzusteigen, möchte man ja möglichst wenig Daten hergeben, sonst kann man auch bei MacOS bleiben. Aber das ist ein anderes Thema, aber die Begründung, warum Snap böse sein soll
Das, was ich jetzt verstanden habe mal in meinen Worten:
Mein LMDE 6 ist dann ein Point-On-Release? D.h. ich habe ein "stabiles" (danke für die Erklärung) System und habe einige Jahre Sicherheitsupdates.
Ich kann auf der aktuellen Version viele Jahre leiben, muss aber nicht.
Update ich auf ein aktuelles System, ( beispielhaft LMDE 6.5), ist mein Release aktueller, aber es kann sein, dass einige "native" Software nicht mehr funktioniert, weil Abhängigkeiten aktualisiert wurden.
Entwickler entwickeln gezielt auf LMDE 6.
Daher ist mein Rednote auch auf einer älteren Version.
Da Flatpak alle Libraries mitbringt, ist es dem Entwickler möglich darüber schneller aktualisierte Versionen herauszubringen.
Habe ich mehrere Flatpaks, werden Bibliotheken geteilt.
Appimages ist ähnlich, teilen aber keine Bibliotheken. Daher sind die auch so riesig. Es gibt aber tatsächlich einiges an Software (Ja, ausschließlich grafische Software), die für Linux nur als AppImage bereitgestellt werden.
Da muss man halt damit leben.
Kann es bei Flatpaks nicht auch zu Abhängigkeitsfehlern kommen oder werden verschiedene Versionen von geteilten Bibliotheken erkannt?
Update ich auf ein aktuelles System, ( beispielhaft LMDE 6.5), ist mein Release aktueller, aber es kann sein, dass einige "native" Software nicht mehr funktioniert, weil Abhängigkeiten aktualisiert wurden.
Jein wahrscheinlich erst mit LMDE7. Aber ja im Grundsatz hast du das richtig verstanden.
Kann es bei Flatpaks nicht auch zu Abhängigkeitsfehlern kommen oder werden verschiedene Versionen von geteilten Bibliotheken erkannt?
Nein. Flatpaks haben wie du richtig erkannt hast eigene Abhängigkeiten - die gibt es aber in diversen Versionen. Daher der Flatpak ersteller definiert von abhängigkeit XY brauche ich Version 4 und bekommt die dann auch. Und alle Flatpaks die du hast die Abhängigkeit XY in Version 4 benötigen können darauf zugreifen - wenn du nun ein Flatpak hast die das in Version 3 braucht wird das eben zusätzlich installiert.
Naja, ich lese viel im Internet und Snap wird von Cannonical verwaltet und die sammeln Telemetriedaten, drum böse
Das ist aber Nachgeplapper ohne eigene Erfahrungen.
Ein gewisses Mass an Telemetrie hat auch Flathub. Alleine um zu zählen wie oft etwas installiert wurde. Ich spreche hier aus Software-Entwickler und sage auch klar, dass Telemetrie etwas nützliches ist. Dank Telemetrie weiss ich wie ich Software optimieren muss. Z.B. mit welchem Desktop wird sie hauptsächlich verwendet - wenn z.b. nur 0.5% der Nutzer die Software mit KDE verwenden, hat eine gute KDE Integration nur eine tiefe Priorität.
Mit welchen Bildschirmauflösungen wird meine App verwendet? So kann ich die Optik der App optimieren. In welchen Sprachen wird die App verwendet? So kann ich feststellen welche Übersetzungen ich priorisieren muss. Wie viel Arbeitsspeicher haben die Nutzer durchschnittlich, usw -> alle diese Informationen helfen Entwickler die App zu optimieren und besser zu machen.
Und ob die Telemtrie nun sendet "Ein Nutzer nutzt die App auf Fedora mit Gnome, am Notebook, mit 8 GB RAM, mit Systemsprache Finnisch" nutzt finde ich nicht tragisch. Es sind keine persönliche Daten, es verletzt die Privatspähre von niemanden. Oft haben aber Leute in der OpenSource Welt das Gefühl das Telemetrie grundsätzlich "böse" ist also wenn Daten meinen Computer verlassen ist es grundsätzlich der Teufel wie erwähnt ich persönlich sehe das differenzierter.
Die Kritik an Snap ist eher, dass der Store halt von einem Unternehmen (Canonical) kontrolliert wird. Bei Flatpak kannst du theoretisch unterschiedliche Repositorys haben in der Praxis nutzen 99% eh alle Flathub 🤷♂️. Bei Snap gibt es halt nur den Snap-Store.
Dann gab es noch viel Kritik das Snap-Anwendungen sehr langsam gestartet sind - das war vor 3 Jahren oder so wahr wurde aber längst behoben. Auf einem Durchschnittsrechner mit SSD wirst du da keine Unterschiede mehr feststellen.
Und dann gibt es noch die Kritik, dass das Backend also die Serverseite vom Snap-Store nicht OpenSource ist. Und ja das stimmt und ich denke Canonical wird da irgendwann die Sourcen veröffentlichen - hat das aber weit unten in der Prio-Liste - da das halt mehr so eine proforma Kritik ist.
Bei Flatpak ist noch zu beachten, das es in einer Sandbox läuft und wenn das Flatpak klemmt z.B. der Zugriff auf einen USB Stick oder das ganze Dateisystem etc. meistens erst mit einem (weiteren) Flatpak: "Flatseal" freigeschaltet werden muß, ebenso wenn weitere Hilfsprogramme oder externe Abspielprogramme mit eingebunden werden, z.B. bei Blender oder Gpodder. Dann versuche ich auf Appimage auszuweichen oder das .deb Paket direkt von der Entwicklerseite, z.B. Github zu laden, wenns denn aktuell sein soll. Jean hat zum den verschiedenen Linuxpaketformaten und nochmal zu Flatpak 2 hilfreiche Videos gemacht: https://www.youtube.com/watch?v=35cgN_dPgGw&t=554s und https://www.youtube.com/watch?v=QfIjA88ZMjg&t=838s.
Ich verwende für Flatpaks und Appimages gerne den Bauh-Appmanager: https://github.com/vinifmor/bauh, da kann man gleich sehen, ob es Appimages und/oder Flatpaks gibt und mit einem Klick installieren. Selber heruntergeladene Appimages kann Bauh auch gleich installieren, d.h. ausführbar machen und ins Anwendungsmenü integrieren.
Daneben nutze ich noch deb-get: https://github.com/wimpysworld/deb-get, besonders unter LMDE (Linux Mint Debian Edition), unter Mint (da Ubuntu basierend) nutze ich für aktuelle oder manche nötige .deb Pakete auch gerne PPAs: https://wiki.ubuntuusers.de/Paketquellen_freischalten/PPA, z.B. den Nextcloud Desktop Client. PPAs werden über das Updatesystem auch mit aktualisiert. Bei Bauh (Appimages) muß man es selber machen, aber es gibt eine Trayinfo bei Updates. Flatpaks werden auch über Mint selber aktualisiert. Deb-get muß man selber aufrufen, aber es startet auch gleich: "apt upgrade" mit.
Für Github .deb Pakete, die man selber herunterladen und installieren muß, habe ich mir selber ein Script gebaut: "self-update.sh", das installiert und updatet dann die Programme, z.B. fastfetch und den linux-assistant: https://www.linux-assistant.org/. Man kann revativ einfach das aktuelle Release bei Github über einen bestimmten Link downloaden. Ich hab das Script mal angehängt, ihr müßt es eventuell an eure Bedürfnisse anpassen. Auspacken, mit chmod +x self-update.sh ausführbar machen und z.B. in ~/.local/bin kopieren. Default wird bei Eingabe von "Enter" der jeweilige Eintrag übersprungen. Benutzung auf eigene Gefahr!
PS: Viele Flatpaks laufen aber auch bei mir problemlos, also auch ohne "Flatseal" Nacharbeit.
Vielleicht eine blöde Frage, aber mal angenommen ich deinstalliere/lösche ein Flatpak, das Abhängigkeiten installiert hat, die nur dieses Flatpak brauchte, werden die dann automatisch mit gecancelt oder sammelt sich da Datenmüll an ?
Und wenn sich Datenmüll ansammelt, wie find ich das raus und kann dann mal "aufräumen"
mfG
Schau dir mal "Warehouse" an, gibt es hier: https://flathub.org/apps/io.github.flattool.Warehouse
Im Terminal geht es so:
flatpak uninstall --unused -y
hier wird nur nach ungenutzten Dateien gesucht und mit "y" kannst du dann bestätigen ob diese gelöscht werden sollen.
Mein Fazit:
Warehouse findet eher und auch mehr ungenutzte Dateien als der Terminal Befehl.
Don’t have an account yet? Register yourself now and be a part of our community!
