Ich habe mit Flatpak und AppImage (Snap habe ich bisher nicht benutzt) gute Erfahrungen gemacht. Nämlich dann, wenn ich eine spezielle Version einer Software benötige, die mir der hauseigene Paketmanager nicht anbietet. Zum Beispiel, wenn die neue Programmversion instabil ist, oder mir in der alten Version wichtige Features fehlen. Beides kam schon vor...
Da diese Probleme im allgemeinen nur temporär bestehen, kann das Flatpak/AppImage nachher wieder gelöscht werden. So gesehen, sollte es auch kein "security nightmare" geben.
Ich könnte mir den Einsatz dieser Werkzeuge auch für Programme vorstellen, die mir in der Manjaro-Paketverwaltung unter "AUR - Arch User Repository" angeboten werden. Diese funktionieren oft nicht richtig, weil sie für eine andere Arch-Version entwickelt wurden. Das ist schade, da im AUR so manche Software-Perle verborgen ist.
Leider gibt es Anbieter, welche die aktuellen Versionen Ihrer Anwendungen nur noch als AppImage oder Flatpak veröffentlichen.
z.B: Scribus: neueste Version in den Repos (auch testing): 1.48, aktuellste Version: 1.55 (läuft sehr stabil)
wobei einem auch ein AppImage nichts nützt, wenn die Anwendung gegen Libraries gebaut ist, welche z.B. in Devuan Ascii noch nicht vorhanden sind... (z.B. Okuna)
Ich stimme Dir und ProLan insofern zu, dass es wünschenswert ist alle grundlegenden Anwendungen über den Paketmanager verfügbar zu haben. Dazu gehören sicherlich Browser und Email, sowie alle anderen Programme mit Internetzugang -- schon aus Sicherheitsgründen.
Bei Scribus weiß ich nicht, wie stabil die Macher (und der Maintainer) ihre aktuelle Version bewerten. Möglicherweise ist das der Grund warum sie einen ältere Version als DEB-Paket ausliefern. Aber ich halte diese Politik für gar nicht so schlecht.
Bei dem von mir genutzen Manjaro kann es vorkommen, dass eine neue Programmversion noch Fehler hat. Dann bin ich froh, wenn ich auf eine stabilere Vorgängerversion ausweichen kann. Bei Mint ist es umgekehrt: Dort werden meist ältere Versionen angeboten und die neuesten Releases gibt es als Flatpak. Mit beiden Varianten kann ich gut leben.
Von simonsaysthis am Fr, 8. November 2019 um 07:05 #
Alptraum warum und für wen ganau? Für dich, weil du Veräderung scheust? Wirkliche Probleme haben damit kaum Leute und werden sie auch nicht haben im Vergleich zu DEB's oder RPM's
Veränderungen sind gut, deswegen nutze ich rolling release und keine 2 Jahre alte Software wie die fanatischen Debianer. Problematik bei Flatpak und Co ist, das Gnu Linux Distros jahrelang so sicher waren weil die Programme aus dem Paketmanager bezogen wurden. Jetzt geht man den Weg wie Microsoft. Wo du dir die Sachen zusammen suchen musst. Und dem Entwickler vertrauen musst.
Flatpak & Snap sind "Paket"manager. Die Software wird i.d.R. aus einem Repository installiert. Und alles, was in der Hinsicht an Flatpak & Snap bemängelt wird, trifft auch auf sie klassischen Paketmanager zu: man kann und es werden auch fette Pakete veröffentlicht, welche alle Abhängigkeiten mitliefern. Das ist ja schon notwendig, wenn die Distribution eine Veröffentlichung in den Repositories verhindert (wie bei Debian oder Fedora) oder ein Paket für viele Distributionen gebaut wird.
Dem Entwickler würde ich immer vertrauen... wem sonst?
Ja, es gibt bei Flatpak und Snap zentrale Repositorys. Es besteht nur das Problem, dass diese Pakete selten von den Entwicklern selbst betreut werden. Dadurch hängen die Anwendungen oft deutlich hinter dem Upstream hinterher. Erkennen kann ich das i.d.R. auch nicht auf den ersten Blick.
Das ist für mich das größte Sicherheitsrisiko!
Ich hoffe das ändert sich noch in Zukunft. Dann lieber AppImage die vom Upstream direkt auf der Entwicklerplattform bereitgestellt werden.
Ja, es gibt bei Flatpak und Snap zentrale Repositorys. Es besteht nur das Problem, dass diese Pakete selten von den Entwicklern selbst betreut werden.
Das gilt, ohne Ausnahme, für alle Distributionen. In der Regel werden die Anwendungen von Betreuern der Distribution und nicht direkt von den Entwicklern gepflegt. Einige Snaps werden dagegen direkt von den Entwicklern gepflegt (IntelliJ, Spotify, kdenlive, VLC & Slack, wenn ich die Store-Startseite besuche).
Dadurch hängen die Anwendungen oft deutlich hinter dem Upstream hinterher.
Welche Anwendungen hängen oft deutlich hinterher? Man kann mit Sicherheit noch so einiges verbessern und es gibt bestimmt Anwendungen, die schlechter gepflegt werden, aber bei meinen installierten Flatpaks erhalte ich häufig Aktualisierungen und bin in der Regel auf der neusten Version.
Erkennen kann ich das i.d.R. auch nicht auf den ersten Blick.
Das stimmt und trifft auf jeden Verteilungsweg zu (Archiv, Paketmanager, AppImage, etc.). Wenn etwas nicht aktualisiert wird, dann sieht man es meistens auch nicht. Und?
Dann lieber AppImage die vom Upstream direkt auf der Entwicklerplattform bereitgestellt werden.
Weil du unbedingt Updates erhalten möchtest, setzt du auf das Format, dass in der Hinsicht am schlechtesten aufgestellt ist? Wenn das AppImage-Verzeichnis stimmt (https://appimage.github.io/apps/), dann sind ein Großteil der AppImages nicht AutoUpdate-fähig (ob die AppImages überhaupt aktuell gehalten werden erkennt man natürlich auch nicht).
Bei den Distris hat der Paketbetreuer die Aufgabe Sicherheitslücken zu fixen (CVE-Lücken werden kenntlich gemacht) und Updates einzuspielen. Sofern er dieser Aufgabe nicht nachkommt wird er ggf. ausgetauscht.
Bei Snap, Flatpak, AppImage kann jeder beliebige ein Paket einstellen. Ob das dann weiter gepflegt wird interessiert dann erst mal nicht. Eigentlich sollte das aber m.E. der Sinn der neuen Paketformate sein, dass Upstream direkt die Pakete pflegt und verteilt (ein paar Pakete bei denen es gut läuft hast du ja schon genannt). Das ist aber auf den ersten Blick nicht immer erkennbar und danach filtern kannst du auch nicht.
Hab jetzt nur mal ein schnelles Beispiel rausgesucht:
https://flathub.org/apps/details/org.munadi.Munadi Version 17.02 vom 01.02.2017
https://gitlab.com/munadi/munadi/-/releases Version 19.04 vom 06.04.2019 (das ganz aktuelle habe ich mal rausgelassen weil noch zu frisch).
Die aktuellen Hub’s (auch AppImage) sind einfach schlecht. Daher besser direkt auf die Entwicklerplattform schauen (i.d.R. GitHub oder GitLab).
Bei den Distris hat der Paketbetreuer die Aufgabe Sicherheitslücken zu fixen (CVE-Lücken werden kenntlich gemacht) und Updates einzuspielen. Sofern er dieser Aufgabe nicht nachkommt wird er ggf. ausgetauscht.
Bei Snap, Flatpak, AppImage kann jeder beliebige ein Paket einstellen. Ob das dann weiter gepflegt wird interessiert dann erst mal nicht. Eigentlich sollte das aber m.E. der Sinn der neuen Paketformate sein, dass Upstream direkt die Pakete pflegt und verteilt (ein paar Pakete bei denen es gut läuft hast du ja schon genannt). Das ist aber auf den ersten Blick nicht immer erkennbar und danach filtern kannst du auch nicht..
Flathub hat ebenfalls Maintainer, welche sich um die Updates kümmern sollen. Der Prozess bei Flathub kann mit Sicherheit noch verbessert werden, aber es ist auch kein Projekt, dass schon seit Jahrzehnten existiert. Eine bessere Sichtbarkeit von offiziellen Flatpaks kannst man ja vorschlagen, bei Snap gibt es das ja auch (https://github.com/flathub/flathub/issues).
Hab jetzt nur mal ein schnelles Beispiel rausgesucht:
https://flathub.org/apps/details/org.munadi.Munadi Version 17.02 vom 01.02.2017
https://gitlab.com/munadi/munadi/-/releases Version 19.04 vom 06.04.2019 (das ganz aktuelle habe ich mal rausgelassen weil noch zu frisch).
Die AppStream-Metadaten sind falsch und deshalb wird eine alte Version angezeigt. Die Anwendung wird vermutlich sogar vom Entwickler gepflegt (der Entwickler nutzt eine @hak.pw E-Mail Adresse und der GitHub Maintainer heißt hakpw), wobei es dennoch eine Verzögerung gibt: https://github.com/flathub/org.munadi.Munadi/commits/master
Die aktuellen Hub’s (auch AppImage) sind einfach schlecht. Daher besser direkt auf die Entwicklerplattform schauen (i.d.R. GitHub oder GitLab).
Eben, und dies ist ein "security nightmare". Irgendwo, irgendwelche Dateien herunterladen und hoffen, dass die Quelle vertrauenswürdig ist, keine Informationen zu Updates erhalten (es sei denn, jede Anwendung liefert einen eigenen Updater mit…). Es gibt zwar die Funktionen bei AppImage (z.B. Validating the signature), aber Windows hat schon Eindrucksvoll bewiesen: Für den Otto-Normalbenutzer ist dies auch schon viel zu kompliziert.
Wir reden hier ja nicht von irgendwelchen Dateien von irgendwo, sondern direkt beim Entwickler. Wenn wir bei Windows angekommen sind, wo Apps dann auf Seiten wie chip.de oder noch schlimmer russland-warez-woauchimmer.net gezogen werden, dann sehe ich auch das absolute "security nightmare".
Das mit den Updates ist auch kein großes Problem. Einfach auf der Plattform anmelden und man bekommt automatisch Informationen über aktuelle Releases. Aber stimmt schon, für Otto-Normalbenutzer zu kompliziert.
Daher sehe ich die Apps generell lieber weiterhin in den offiziellen Paketquellen der Distributionen und nur als Ergänzung dann die neuen Paketquellen. Und hier hoffe ich auf einen gemeinsamen Standard und dann noch mehr Beteiligung vom Upstream.
Mal beobachten wie sich das ganze entwickelt. Man darf gespannt sein...
Von GebackenesBrot am Di, 12. November 2019 um 00:15 #
Ja Linux ist ein Alptraum. Jede Distribution hat verschiedene Softwarepakete in zig verschiedenen Versionen mit jeweils zig Kompatibilitätsmöglichkeiten. Und ich bin froh dass man dieses Hauptproblem von Linux endlich angeht, so dass bekannte Softwareschmieden nicht immer einen riesigen Kreis um Linux drehen müssen.
Snaps und Flatpak sind ein Alptraum. Verstehe nicht warum man seine Paketmanager nicht fördert. Stattdessen das security nightmare.
Ich habe mit Flatpak und AppImage (Snap habe ich bisher nicht benutzt) gute Erfahrungen gemacht. Nämlich dann, wenn ich eine spezielle Version einer Software benötige, die mir der hauseigene Paketmanager nicht anbietet. Zum Beispiel, wenn die neue Programmversion instabil ist, oder mir in der alten Version wichtige Features fehlen. Beides kam schon vor...
Da diese Probleme im allgemeinen nur temporär bestehen, kann das Flatpak/AppImage nachher wieder gelöscht werden. So gesehen, sollte es auch kein "security nightmare" geben.
Ich könnte mir den Einsatz dieser Werkzeuge auch für Programme vorstellen, die mir in der Manjaro-Paketverwaltung unter "AUR - Arch User Repository" angeboten werden. Diese funktionieren oft nicht richtig, weil sie für eine andere Arch-Version entwickelt wurden. Das ist schade, da im AUR so manche Software-Perle verborgen ist.
Leider gibt es Anbieter, welche die aktuellen Versionen Ihrer Anwendungen nur noch als AppImage oder Flatpak veröffentlichen.
z.B: Scribus:
neueste Version in den Repos (auch testing): 1.48,
aktuellste Version: 1.55 (läuft sehr stabil)
wobei einem auch ein AppImage nichts nützt, wenn die Anwendung gegen Libraries gebaut ist, welche z.B. in Devuan Ascii noch nicht vorhanden sind...
(z.B. Okuna)
Es grüsst
Roland
Ich stimme Dir und ProLan insofern zu, dass es wünschenswert ist alle grundlegenden Anwendungen über den Paketmanager verfügbar zu haben. Dazu gehören sicherlich Browser und Email, sowie alle anderen Programme mit Internetzugang -- schon aus Sicherheitsgründen.
Bei Scribus weiß ich nicht, wie stabil die Macher (und der Maintainer) ihre aktuelle Version bewerten. Möglicherweise ist das der Grund warum sie einen ältere Version als DEB-Paket ausliefern. Aber ich halte diese Politik für gar nicht so schlecht.
Bei dem von mir genutzen Manjaro kann es vorkommen, dass eine neue Programmversion noch Fehler hat. Dann bin ich froh, wenn ich auf eine stabilere Vorgängerversion ausweichen kann. Bei Mint ist es umgekehrt: Dort werden meist ältere Versionen angeboten und die neuesten Releases gibt es als Flatpak. Mit beiden Varianten kann ich gut leben.
Bei Devuan ASCII liegen die Prioritäten bei der Ideologie und nicht bei möglichst aktuellen, modernen Anwendungen (wozu auch systemd gehört).
Alptraum warum und für wen ganau? Für dich, weil du Veräderung scheust? Wirkliche Probleme haben damit kaum Leute und werden sie auch nicht haben im Vergleich zu DEB's oder RPM's
Veränderungen sind gut, deswegen nutze ich rolling release und keine 2 Jahre alte Software wie die fanatischen Debianer.
Problematik bei Flatpak und Co ist, das Gnu Linux Distros jahrelang so sicher waren weil die Programme aus dem Paketmanager bezogen wurden. Jetzt geht man den Weg wie Microsoft. Wo du dir die Sachen zusammen suchen musst. Und dem Entwickler vertrauen musst.
Flatpak und Co lassen die Programme in einer Sandbox laufen.
Flatpak & Snap sind "Paket"manager. Die Software wird i.d.R. aus einem Repository installiert. Und alles, was in der Hinsicht an Flatpak & Snap bemängelt wird, trifft auch auf sie klassischen Paketmanager zu: man kann und es werden auch fette Pakete veröffentlicht, welche alle Abhängigkeiten mitliefern. Das ist ja schon notwendig, wenn die Distribution eine Veröffentlichung in den Repositories verhindert (wie bei Debian oder Fedora) oder ein Paket für viele Distributionen gebaut wird.
Dem Entwickler würde ich immer vertrauen... wem sonst?
Ja, es gibt bei Flatpak und Snap zentrale Repositorys. Es besteht nur das Problem, dass diese Pakete selten von den Entwicklern selbst betreut werden. Dadurch hängen die Anwendungen oft deutlich hinter dem Upstream hinterher. Erkennen kann ich das i.d.R. auch nicht auf den ersten Blick.
Das ist für mich das größte Sicherheitsrisiko!
Ich hoffe das ändert sich noch in Zukunft. Dann lieber AppImage die vom Upstream direkt auf der Entwicklerplattform bereitgestellt werden.
Bei den Distris hat der Paketbetreuer die Aufgabe Sicherheitslücken zu fixen (CVE-Lücken werden kenntlich gemacht) und Updates einzuspielen. Sofern er dieser Aufgabe nicht nachkommt wird er ggf. ausgetauscht.
Bei Snap, Flatpak, AppImage kann jeder beliebige ein Paket einstellen. Ob das dann weiter gepflegt wird interessiert dann erst mal nicht. Eigentlich sollte das aber m.E. der Sinn der neuen Paketformate sein, dass Upstream direkt die Pakete pflegt und verteilt (ein paar Pakete bei denen es gut läuft hast du ja schon genannt). Das ist aber auf den ersten Blick nicht immer erkennbar und danach filtern kannst du auch nicht.
Hab jetzt nur mal ein schnelles Beispiel rausgesucht:
https://flathub.org/apps/details/org.munadi.Munadi
Version 17.02 vom 01.02.2017
https://gitlab.com/munadi/munadi/-/releases
Version 19.04 vom 06.04.2019 (das ganz aktuelle habe ich mal rausgelassen weil noch zu frisch).
Die aktuellen Hub’s (auch AppImage) sind einfach schlecht. Daher besser direkt auf die Entwicklerplattform schauen (i.d.R. GitHub oder GitLab).
Flathub hat ebenfalls Maintainer, welche sich um die Updates kümmern sollen. Der Prozess bei Flathub kann mit Sicherheit noch verbessert werden, aber es ist auch kein Projekt, dass schon seit Jahrzehnten existiert. Eine bessere Sichtbarkeit von offiziellen Flatpaks kannst man ja vorschlagen, bei Snap gibt es das ja auch (https://github.com/flathub/flathub/issues).
Die AppStream-Metadaten sind falsch und deshalb wird eine alte Version angezeigt. Die Anwendung wird vermutlich sogar vom Entwickler gepflegt (der Entwickler nutzt eine @hak.pw E-Mail Adresse und der GitHub Maintainer heißt hakpw), wobei es dennoch eine Verzögerung gibt: https://github.com/flathub/org.munadi.Munadi/commits/master
Eben, und dies ist ein "security nightmare". Irgendwo, irgendwelche Dateien herunterladen und hoffen, dass die Quelle vertrauenswürdig ist, keine Informationen zu Updates erhalten (es sei denn, jede Anwendung liefert einen eigenen Updater mit…). Es gibt zwar die Funktionen bei AppImage (z.B. Validating the signature), aber Windows hat schon Eindrucksvoll bewiesen: Für den Otto-Normalbenutzer ist dies auch schon viel zu kompliziert.Wir reden hier ja nicht von irgendwelchen Dateien von irgendwo, sondern direkt beim Entwickler. Wenn wir bei Windows angekommen sind, wo Apps dann auf Seiten wie chip.de oder noch schlimmer russland-warez-woauchimmer.net gezogen werden, dann sehe ich auch das absolute "security nightmare".
Das mit den Updates ist auch kein großes Problem. Einfach auf der Plattform anmelden und man bekommt automatisch Informationen über aktuelle Releases. Aber stimmt schon, für Otto-Normalbenutzer zu kompliziert.
Daher sehe ich die Apps generell lieber weiterhin in den offiziellen Paketquellen der Distributionen und nur als Ergänzung dann die neuen Paketquellen. Und hier hoffe ich auf einen gemeinsamen Standard und dann noch mehr Beteiligung vom Upstream.
Mal beobachten wie sich das ganze entwickelt. Man darf gespannt sein...
Ja Linux ist ein Alptraum. Jede Distribution hat verschiedene Softwarepakete in zig verschiedenen Versionen mit jeweils zig Kompatibilitätsmöglichkeiten. Und ich bin froh dass man dieses Hauptproblem von Linux endlich angeht, so dass bekannte Softwareschmieden nicht immer einen riesigen Kreis um Linux drehen müssen.