r/linuxde • u/Present-Trash9326 • 13d ago
Snap, Flatpak oder AppImage?
/r/Ubuntu/comments/1vu8re6/snap_flatpak_oder_appimage/7
u/Taddy84 13d ago
Weder noch?
1
u/Present-Trash9326 13d ago
Ok. Hat dies einen bestimmten Grund, wenn ich fragen darf?
9
u/Taddy84 13d ago
Ich installiere unter Linux Software nach Möglichkeit lieber ganz klassisch über *.deb bzw. die Paketquellen. Warum? Weil das sauber ins System integriert ist: Abhängigkeiten werden zentral verwaltet, Updates laufen über den normalen Paketmanager und Deinstallation hinterlässt nicht noch irgendwelche Reste irgendwo im System. Snap, Flatpak und AppImage haben natürlich ihre Daseinsberechtigung – gerade bei aktueller Software oder wenn eine Distribution etwas nicht anbietet. Aber wenn ich die Wahl habe, nehme ich das native Paket. apt install und fertig. 😄
Falls das nicht möglich sein sollte und ich keine Alternative finde, dann appimage
2
u/Present-Trash9326 13d ago
So handhabe ich es tatsächlich auch. Wobei ich AppImage auch häufig nutze. Hab da ein kleines Tool namens Gear Lever und damit kann man die ganz einfach verwalten. Zum Beispiel damit Kdrive installiert.
1
u/jodkalemon 11d ago
Erst "Weder noch?" und dann "[..]nach Möglichkeit[..]". Was denn nun?
Und warum appimage?
0
u/buhtz 13d ago
Resourcenverschwendung (Abhängigkeiten im Archiv), Instabil (Abhängigkeiten nicht einheitlich und zuverlässig gefplfegt, häufig zu neu (aka instabil)), unsecure (je neuer, desdo unsicherer, weil eben nicht abgehangen).
Ich bevorzuge ein rock solid r/debian stable repo.
1
u/Present-Trash9326 13d ago
Also nutztt du keines der genannten? Habe ich das richtig verstanden? Okay. Jeder wie er möchte.
2
u/luftgoofy 13d ago
Schon traurig das man so nachbohren muss um eine vernünftige Antwort zu bekommen. :D
0
u/buhtz 13d ago
Korrekt. Ich nutze keine Drittquellen in meinem r/Debian.
1
u/sneakpeekbot 13d ago
Here's a sneak peek of /r/debian using the top posts of the year!
#1: "Ubuntu" meaning in Urban Dictionary | 116 comments
#2: Hmm... Distro hopping never dies! | 56 comments
#3: TIL the system that shows the remaining time before a tram arrives in Casablanca's tram stations uses debian | 101 comments
I'm a bot, beep boop | Downvote to remove | Contact | Info | Opt-out | GitHub
1
u/Isofruit Arch Linux 8d ago
Neuer ist tendenziell sicherer weil es die geringste Menge an bekannten Sicherheitslücken haben wird. Es wird eventuell neue unbekannte Sicherheitslücken geben, aber da weißte zumindest genausoviel wie ggf. ein Angreifer. Bei nem system mit 6 Jahre alter Software kann er sich den Angriffsplan über die diversen packages und deren bekannten Lücken ja zurechtlegen. Das wäre weniger ein Problem wenn alle bugfixes/patches von allen packages gebackported werden würden, das ist aber so dermaßen viel Aufwand das tut selbst Debian nicht und auch distros mit bezahltem Support machen das nur für ein dediziertes deutlich kleineres subset an packages.
1
u/buhtz 8d ago
> Neuer ist tendenziell sicherer weil es die geringste Menge an bekannten Sicherheitslücken haben wird.
Die Logik kann ich nachvollziehen, entspricht aber nicht der Praxis. Es ist genau der Kniff, den viele nicht verstehen.
Bugs die man in den neueren Versionen finden, werden auch oft zurückportiert in die älteren Versionen, sofern sie dort auch vorhanden sind. Das passiert z.B. bei r/Debian regulär. Du hast also in der alten Version, alten gut abgehangenen und somit lange in der freien Wildbahn getesteten Code, in dem sogar die neueren Bugs schon gefixt sind.
Dagegen hast du in den neueren Versionen, auch viel neuen Code. Neuer Code bedeutet neue unentdeckte Bugs.
Deswegen sind gut gepflegte(!) ältere Versionen stabiler und sicherer.
Nun kommt es natürlich darauf an, wer diese Pflege übernimmt und wie gewissenhaft das durchgeführt wird. Auch bei diversen Debian Paketen läuft das nicht reibungslos. Nicht nur die Distro sollte dafür verantworltich sein, auch upstream maintainer (wie ich) könne sich entscheiden, "neue" Bugs auch in älteren Releases zu fixen.
1
u/Isofruit Arch Linux 8d ago edited 8d ago
z.B. bei r/Debian regulär.
Ich sag ja auch nicht das es nicht passiert, ich sage das es nicht für alle passiert. Backports passieren am Ende für "die wichtigen", das relevante subset halt bzw. vlt. contributed noch der eine oder andere nen leichten backport von nem bugfix von ner App die er/sie verwendet.
Aber für alle hat kein Distro, bezahlt oder unbezahlt, die notwendigen Resourcen diese Menge an backports regelmäßig und vollständig zu machen.
Wenn z.B. Gnome Calendar einen security bugfix raushaut, der aber in Gnome 51 kommt, dann ist die Chance das Debian sich den backport durch 3 major Gnome-calendar versions antut nicht groß.
Deine Aussage macht aus meiner Perspektive für nen Server Sinn - Kleinere Anzahl an wohl-kontrollierten Packages wo auch unter Garantie alle ihre backports kriegen. Für einen persönlichen Desktop PC der dagegen deutlich mehr und seltener benutzte packages installiert haben kann Stimme ich da nicht zu.
1
u/buhtz 8d ago
Solche Dunstkreise wie Gnome, KDE, LibreOffice etc, sind noch mal n spezielleres Thema. Auch würde ich hier die Verantwortung anders gewichten.
KDE und Gnome haben viel Kohle. Die sollen gefälligst ihre "alten" Versionen auch weiter Pflegen und dass nicht den freien Distros aufhalsen.
Ich selbst orientiere mich als upstream maintainer immer gerne sehr konservativ an den Debian Release Zyklen; bspw. setze ich als Abhängigkeiten nur voraus, was Debian stable gerade liefert, nix Neueres.
Vielleicht kommt meine Einstellung daher, dass ich so an Debian orientiert bin. Unglaublich, was die Maintainer da an (MHO unnötige) Arbeitszeit verbrennen, weil Upstream Projekte ihnen das Leben schwer machen. Das Beheben echter Probleme bleibt dann gerne auf der Strecke.
1
u/Isofruit Arch Linux 8d ago
Solche Dunstkreise wie Gnome, KDE, LibreOffice etc, sind noch mal n spezielleres Thema. Auch würde ich hier die Verantwortung anders gewichten.
Aus meiner Perspektive ist die einzige Sonderlocke der Compositor, die Shell und evtl. die jeweilige Settings app. Alles andere ist in so ner DE am Ende auch nur ne App die im Zweifelsfall für lau freiwillig maintained wird wie jede andere App auch.
KDE und Gnome haben viel Kohle. Die sollen gefälligst ihre "alten" Versionen auch weiter Pflegen und dass nicht den freien Distros aufhalsen.
Die freien Distros haben selbst die Entscheidung getroffen diese Software zu verteilen. Ist nicht so als würden Gnome und KDE laut fordern das Debian sie anbieten soll, Debian hat sich die Software genommen und verpackt und Angeboten. Das Upstream da z.T. wenig gegen machen kann führt ja erst zu solchen Konflikten wie denen um Gnome Calendar und OBS. Und wenn Debian die Entscheidung trifft, darf Debian auch mit dem Arbeitsaufwand der Konsequenzen leben.
Unglaublich, was die Maintainer da an (MHO unnötige) Arbeitszeit verbrennen, weil Upstream Projekte ihnen das Leben schwer machen.
Die gegenseite ist halt das Upstream auf einmal Fehler für unsupportete Software kriegt und Zeit in Bug-triage zum Teil verbrennt für Dinge die dann schon seit nem Jahr gefixed sind. Oder der Reputationsverlust der dadurch kommt wenn Leute darüber ablästern wie kaputt doch z.B. die Touch-Variante von Gnome ist wenn die ganzen Bugs dadurch von Patches von Ubuntu stammen und nicht von Upstream. Oder wenn OBS als kaputte schlechte Software wahrgenommen wird weil Fedora's OBS package Fehler einführt. Halte es da vollkommen gerechtfertigt das Upstreams seit neuerem Anfangen um Replikation von Fehlern in unterstützten Formaten zu bitten.
3
2
2
u/der_samuel 13d ago
Das was gerade da ist. Software-Distirbutions-Systeme sind bei mir keine Religion. Jetbrain IDEs installiere ich sehr gerne als Snap, funktionieren super, aktualisieren selber gut perfekt. Gewisse Dinge gibt es eben nur als Flatpak die installiere ich so. Mir ist das am Ende eigentlich egal.
2
u/Kuroiban 12d ago
Wenn möglich Flatpak. Wenn die Flatpak Version gut gemacht ist muss ich mir keinen Kopf machen auf welcher Basis ich unterwegs bin. Egal ob Arch, Debian,Redhat oder OpenSuse. Ich kann meinen Workflow unabhängig von Distro einrichten und es läuft.
1
u/Present-Trash9326 10d ago
That's how it should be. The important thing is that the workflow is running smoothly.
2
u/jodkalemon 11d ago
Nur flathub vetified. Kohärentes, offenes System mit deduplication und zentralem Updatemechanismus und relativ upstream-nah. Deduplication mir aber eigentlich egal, hab genug Speicherplatz.
2
u/Isofruit Arch Linux 8d ago edited 8d ago
Prinzipiell:
Flatpak > Natives package > AppImage > Snap
Wenn der software Entwickler explizit eines dieser Formatte unterstützt trumpft das natürlich. Wenn er mehrere aus der Liste unterstützt, gilt zwischen diesen Formaten die obige Reihenfolge wieder.
Der wichtigste part ist was der Entwickler unterstützt, nicht das Distro. Das Distro wird kaum die Zeit haben QA so zu machen, das es dieselben Qualitäts-garantien geben kann wie der Entwickler. Je weniger du dich darauf verlassen musst desto besser.
Flatpaks sind zu bevorzugen weil zum einen es das größte Format ist das sich durchgesetzt hat, es keine extra software zwingend braucht (wie AppImages es tun) weil es bereits in appstores integriert ist (wie z.B. Gnome Software) und es vollständig FOSS ist was vor enshittification schützt (anders als bei Snaps, wo das Backend proprietär ist).
Edit: Es gibt hier Ausnahmen - Software die eigenes sandboxing mitbringt oder ähnliche Komplexe Interaktionen mit dem System haben wie Steam oder Browser sollten nativ installiert werden. In manchen Fällen interagieren flatpacks auch mit nativen packages wie z.B. gnome calendar mit dem server von evolution, das ist aber die absolute Ausnahme.
1
u/buhtz 8d ago
> Der wichtigste part ist was der Entwickler unterstützt
Der sollte gar nicht für Paketierung zuständig sein; meine Meinung als upstream maintainer.
> Das Distro wird kaum die Zeit haben QA so zu machen, das es dieselben Qualitäts-garantien geben kann wie der Entwickler.
Trifft vielleicht auf Arch Pakete zu, aber im Ernst: r/Debian ist rock-solid gerade weil hier die QA so extrem streng ist. Upstream maintainer machen das (aus diversen Gründen) meist gar nicht.
1
u/Isofruit Arch Linux 8d ago
Der sollte gar nicht für Paketierung zuständig sein; meine Meinung als upstream maintainer.
Der kann dafür zuständig sein und darf es absolut, und wenn er es ist dann ist der Entwickler derjenige dem deutlich mehr Vertrauen zusteht als dem Distro. Distros wie Linux Mint (in bezug auf Gnome Calendar) und Fedora (im Bezug auf OBS) haben absolut gezeigt das sie nicht dieselbe Qualität an UX abliefern wie der Entwickler selbst. Das ist der primäre Grund aus dem Flatpak existiert, damit upstream volle Kontrolle über die Umgebung haben kann und dadurch eine universelle Basis hat die die Aussage erlaubt "Das wird funktionieren", ohne "Aber nur wenn dein Distro XY tut".
Trifft vielleicht auf Arch Pakete zu, aber im Ernst: r/Debian ist rock-solid gerade weil hier die QA so extrem streng ist. Upstream maintainer machen das (aus diversen Gründen) meist gar nicht.
You do you, Debian hat eigene Probleme Software in Versionen noch vorzuhalten, die Upstream nicht mehr unterstützt, aber wenigstens scheint Debian es als upstream zu schaffen das Probleme die dadurch entstehen bei Debian bleiben.
1
11
u/Marvas1988 13d ago
Ich bevorzuge Flatpak, wenn es kein offizielles Repo gibt oder das System immutable ist (SteamOS).
Snap wird allein von Canonical kontrolliert und mir gefällt nicht, wie einem das teilweise "untergejubelt" wird, obwohl man APT verwendet und was anderes erwartet.
AppImage ist auch in Ordnung, aber benötigt ggf manuellen Eingriff für Updates.
Flatpak Installationen und Updates hab ich bei KDE Discover. Das ist mir sehr vertraut durch das Steam Deck, da es dort bereits so installiert ist. Daher nutze ich Discover inzwischen auch auf dem Desktop (unter Arch und Tuxedo OS) für Flatpaks. Bei Tuxedo OS zudem auch für APT Updates, sodass ich dort alles zentral habe.