ubuntuusers.de

Hallo Ubuntuusers,

zunächst: Ich habe kein passendes Unterforum gefunden, also poste ich die Frage einfach mal hier:

Mit 17.10 hält ja jetzt snap Einzug, als "neues Paketformat", welches auch einen neuen "Appstore" mit sich bringt.

Nur ist die Frage: Was bringt das, bzw. ist das wirklich so toll?

Versteht mich nicht falsch, wenn es sowas unter Linux bzw. Ubuntu noch nicht gäbe, dann könnte ich es ja verstehen, aber wir haben doch bereits apt und unser App-Store heißt Synaptic/apt-get/aptitude.

OK, es gibt den neuen Ansatz, alles was das jeweilige Programm braucht mit in das jeweilige Installationspaket zu packen. Abgesehen davon, dass dies ein Vielfaches an Speicherplatz braucht, und ich mit 20GB für meine /-Partition für OS und Programme (bei <50% Belegung) vermutlich nicht mehr hinkommen dürfte, wo ist da der Vorteil?

OK, es muss keinen Paketverwalter mehr geben, der eine neue Version distributionsweise paketiert, wenn der Herausgeber eines Programms eine Sicherheitslücke entdeckt und behebt. Dafür muss der Herausgeber des Programms jetzt jede lib, die er mit in das Paket packt, weil es ja ein "Komplettpaket" sein soll, auf Änderungen und Sicherheitslücken überwachen, und jedes mal, wenn eine neue Version einer solchen lib rauskommt, das komplette Programm neu paketieren, denn er möchte ja nicht, dass sein Programm über die lib weiterhin angreifbar ist.

Also ich weiß nicht, ich bin deutlich gespaltener Meinung dazu. Ja, OK, ich könnte deutlich neuere Software auf meinem 14.04-basierten System haben, aber dafür gibt es doch auch schon lange die Lösung mit Backports. Jagut, es mag einfacher für den Endanwender zu sein, als in den Paketquellen backports zu aktivieren und damit umzugehen, aber wirklich: Warum will ich das?

Und was, wenn die ersten Programme aufhören als .debs für apt zu existieren und nur noch als snap bzw. flatpak auf dem System landen? Muss ich dann 2 Update-Befehle eingeben, und dauern die Updates dann länger, weil anstatt einer lib mit 200kB zu aktualisieren, zig Programmpakete zu jeweils zig MB aktualisiert werden müssen, wegen dieser einen gefixten lib?

Also, ich möchte letztendlich von Euch wissen: Überwiegen die Vorteile wirklich die Nachteile?

Oder, anders formuliert: Bitte überzeugt mich doch mal jemand davon, dass snap (oder meinetwegen auch flatpak) so toll ist, dass ich jetzt von apt nix mehr wissen wollen sollte!?

Danke,

P.

Mit 17.10 hält ja jetzt snap Einzug, als "neues Paketformat", welches auch einen neuen "Appstore" mit sich bringt.

ist schon mal falsch, das gibt es schon länger. Du hast wenig dazu bisher gelesen, oder? snap ist keine komplette Alternative für apt, denn die beiden sind teilweise grundverschieden. Ersteres (wie auch AppImages oder Flatpaks) erlaubt z.B. die Installation mehrerer Versionen eines Programms im System, letzteres nicht.

Das sind alles "Alles-Inklusive-Pakete", mit dem Nachteil eines höheren Speicherbedarfs und dem Mangel an automatischen Updates, um eine weitere Frage zu beantworten. Zu all dem gibt es aber genug Infos im Netz, einfach mal lesen!

voxxell99

Du hast wenig dazu bisher gelesen, oder?

Stimmt, ich hab mich erst von der letzten "#heiseshow" dazu motivieren lassen, mich dafür zu interessieren.

snap ist keine komplette Alternative für apt, denn die beiden sind teilweise grundverschieden.

Und doch heißt es, dass wohl Anwendungen dorthin portiert werden sollen (nur, ob sie dann aus apt ganz verschwinden oder darin nicht mehr gepflegt werden ist mir nicht ganz klar).

Ersteres (wie auch AppImages oder Flatpaks) erlaubt z.B. die Installation mehrerer Versionen eines Programms im System, letzteres nicht.

Oh, OK. Diese Anforderung hatte ich ein einziges mal bei Firefox (die normale Version + ESR), habe ich aber dann halt manuell gemacht...

Das sind alles "Alles-Inklusive-Pakete", mit dem Nachteil eines höheren Speicherbedarfs und dem Mangel an automatischen Updates, um eine weitere Frage zu beantworten.

Es geht ja vor allem darum, ob wirklich Updates kommen, wenn eine lib, die in so einem "Alles-Inklusiv-Paket", eine Sicherheitslücke hat. z.B. eine SSL-Lib in einem Browser-Paket, wenn die Lib gefixt wird, kommt dann auch das Browserpaket in einer neuen Version heraus, mit der man die alte (natürlich!) überschreiben möchte? Automatische Updates bzw. die Prüfung darauf werden sich ja sicherlich irgendwie scripten lassen, bzw. wird dafür schon eine Lösung existieren - oder spätestens halt für 18.04LTS (da ich eh nur die LTS Versionen einsetze).

Zu all dem gibt es aber genug Infos im Netz, einfach mal lesen!

Naja, ich hatte halt ein paar konkrete Fragen, bzw. eine generelle Skepsis, also wenn Du einen Artikel kennst (ob englisch oder deutsch ist mir egal), der da lautet "warum snap besser ist als apt" oder was in der Art, darfst Du ihn mir gerne empfehlen! ☺

Es geht ja vor allem darum, ob wirklich Updates kommen, wenn eine lib, die in so einem "Alles-Inklusiv-Paket", eine Sicherheitslücke hat.

Keine Updates einzelner Teile, du müsstest ein neues komplettes Paket runterladen. Wie schon gesagt: apt und snap/AppImage/Flatpak sind 2 völlig verschiedene Sachen. Letztere sind mE eher als Ergänzung zu sehen als als Ersatz.

Perceptron schrieb:

Hallo Ubuntuusers,

Hallo!

Mit 17.10 hält ja jetzt snap Einzug, als "neues Paketformat", welches auch einen neuen "Appstore" mit sich bringt.

gabs wie gesagt schon länger

Nur ist die Frage: Was bringt das, bzw. ist das wirklich so toll?

Hier gibt es einige verschiedene Punkte:
1. (Achtung, überspitzt) Du sitzt da gemütlich auf der Couch und erwartest, dass dir jemand vorher erst mal alles für "dein" apt parat gemacht hat. Jetzt sitzt nicht nur du da mit deinem ubuntu, sondern auch noch einer mit .rpm auf Fedora uns ein weiterer mit Archlinux etc.
Global betrachtet muss also ein Entwickler von einem Programm (nicht lib) für die 2-5% Marketshare von Linux die 3-10fache Arbeit machen, damit sein Programm auf dem jeweiligen Linux läuft. Aber es reicht ja nicht ein Paket für alle Ubuntu Versionen. Dank der Abhängigkeitshölle muss man noch für jede Version ein extra Paket machen. Diese Arbeit wird oft von anderen Freiwilligen aus der Community übernommen (Paket Maintainer); aber auch hier ist das Engagement oft Rückläufig und es gibt einen Haufen verwaiste Pakete, die dann oft auch mal rausgeschmissen werden.

2. In Zeiten von Android, iOS und co sind die Leute gewohnt einen App-Store zu benutzen. Das diese Apps auch alles an Board haben was sie brauchen ist auf Windows eh normal, und in heutigen Zeiten von HDDs und SSDs im TB Bereich und schnellem Internet sind einige Webseiten beim Aufruf größer als das was du beim Update ziehst. Aber noch mal: gerade die Abhängigkeitshölle fällt mit diesem Ansatz weg. Flatpak versucht da einen "halben" Ansatz, aber ubuntu/canonical hatte den Ansatz beim ubuntu-touch schon ausprobiert mit den "Click"-Paketen. Aber da hat man gemerkt, dass eine halbe Abhängigkeitshölle immer noch eine Abhängigkeitshölle ist.
Jetzt kann man natürlich sagen: Aber jetzt kümmert sich ja nicht mehr der vertraute Maintainer und die Community um die Sicherheit der Pakete, sondern ein dahergelaufener Typ, der das Paket in den Appstore gepackt hat. Das ist richtig. Aber es interessiert jetzt schon ohne Snap Pakete keine Sau, wenn man sich anguckt mit wie vielen PPAs die Leute ihr System zuballern. PPAs kann auch jeder Typ aufmachen wie er lustig ist.

Versteht mich nicht falsch, wenn es sowas unter Linux bzw. Ubuntu noch nicht gäbe, dann könnte ich es ja verstehen, aber wir haben doch bereits apt und unser App-Store heißt Synaptic/apt-get/aptitude.

Der Trend geht wohl dahin, dass das Gundsystem apt basiert ist und eine Menge Programme (gerade der Kram in Universe) dann eher per snap kommt.

Also ich weiß nicht, ich bin deutlich gespaltener Meinung dazu. Ja, OK, ich könnte deutlich neuere Software auf meinem 14.04-basierten System haben, aber dafür gibt es doch auch schon lange die Lösung mit Backports. Jagut, es mag einfacher für den Endanwender zu sein, als in den Paketquellen backports zu aktivieren und damit umzugehen, aber wirklich: Warum will ich das?

Backports fallen auch nicht vom Himmel.

Und was, wenn die ersten Programme aufhören als .debs für apt zu existieren und nur noch als snap bzw. flatpak auf dem System landen? Muss ich dann 2 Update-Befehle eingeben,

Der grafische Store hat schon länger Snaps und .deb zusammen. Für die Konsole wird es sicher auch einen wrapper geben, der beides gleichzeitig kann. Snaps aktualisieren sich heute schon selber, ganz ohne dein zutun.

Also, ich möchte letztendlich von Euch wissen: Überwiegen die Vorteile wirklich die Nachteile?

Die Vorteile sind gerade für die Entwickler und Distributionen. Du als Endanwender hast den Vorteil, das bei wegfallendem Engagement der Community du das Programm direkt vom Entwickler bekommst und nicht gar nichts mehr, weil es keiner mehr für die ubuntu Repos maintained.

Oder, anders formuliert: Bitte überzeugt mich doch mal jemand davon, dass snap (oder meinetwegen auch flatpak) so toll ist, dass ich jetzt von apt nix mehr wissen wollen sollte!?

Es ist kein Ersatz für apt.

Snaps aktualisieren sich heute schon selber, ganz ohne dein zutun.

Okay, da habe ich was Falsches gesagt, zumindest bez. der snaps. Aber bei AppImages ist es mE nicht so.

voxxell99 schrieb:

Snaps aktualisieren sich heute schon selber, ganz ohne dein zutun.

Okay, da habe ich was Falsches gesagt, zumindest bez. der snaps...

Oder doch?

...and they update automatically and transactionally so your app is always fresh and never broken.

Quelle: https://www.ubuntu.com/desktop/snappy

Selbst wenn nicht, ein

sudo snap refresh

an

sudo apt update && sudo apt full-upgrade

angehängt, ist ja kein Problem.

k1l schrieb:

Global betrachtet muss also ein Entwickler von einem Programm (nicht lib) für die 2-5% Marketshare von Linux die 3-10fache Arbeit machen, damit sein Programm auf dem jeweiligen Linux läuft.

Eigentlich kann dem Entwickler das relativ am Gesäß vorbeigehen, denn das ist die Arbeit der Maintainer. Der Entwickler sollte an der Upstream-Software arbeiten.

Hallo,

Oder, anders formuliert: Bitte überzeugt mich doch mal jemand davon, dass snap (oder meinetwegen auch flatpak) so toll ist, dass ich jetzt von apt nix mehr wissen wollen sollte!?

Allerspätestens dann, wenn es das Programm, dass du gaaaaaaanz dringend brauchst, nur als snap verfügbar ist, installierst du es per snap, Bedenken / Vorurteile hin oder her. Genauso war es doch bei PPAs: kann man so doof finden, wie man will - wenn es das Programm, dass man gaaaaaaanz dringend braucht, nur über ein PPA gibt, aktiviert man halt das PPA. Selber kompilieren ist zwar immer eine Option, kann aber je nach Voraussetzung sehr aufwendig sein.

Ich hatte in den letzten Tage 2x den Fall im Wiki, dass eine neue Version eines Progs "nur" als snap verfügbar war - haben wir dann auch im Artikel so eingebaut. In einem Fall hatte der Entwickler sogar sein PPA zugunsten von snap eingestellt. Immerhin ist IMHO ein Vorteil von snap vs. PPA, dass man bei snap wirklich nur das bekommt, was das Prog braucht und nicht, wie bei PPAs, die Seiteneffekt-Gefahr hat, dass man aus dem PPA z.B. Pakete installiert (bzw. installiert werden), die man gar nicht wollte.

Gruß, noisefloor

@noisefloor - Also gibt es tatsächlich schon Programme, die von apt zu snap wechseln? Inklusive der Notwendigkeit des Programm-Entwicklers, seine Snap-Version immer dann zu updaten, wenn irgendwelche Abhängigkeiten,die das Programm beinhaltet, ein Update erfahren (aus Sicherheitsgründen). Die "Seiteneffekt-Gefahr" sehe ich jedenfalls bei PPAs nicht als eine solche, denn normalerweise werden die dependencies dann ja aus dem normalen Ubuntu-Repository installiert, wenn der Entwickler, der das PPA betreibt, nicht auch die Wartung für die jeweiligen .debs in seinem PPA übernehmen will. Andererseits ist er mit snaps dazu gezwungen, denn sonst hat das Programm womöglich ganz schnell Sicherheitslücken. Und die Windows-Herangehensweise des "wird schon nicht so schlimm sein, lassen wir trotzdem auf der alten Version, weil die dauernden Updates zu aufwändig sind" ist definitiv keine gute Alternative.

Deshalb stelle ich hier in dem Thread mal eine neue Frage auf: Wie kann ich sicher gehen, dass snaps sicher sind? Wenn z.B. der Entwickler eines Programms dieses als snap bereitstellt, und da auch eine openssl lib mit reinpackt, aber diese erfährt in der Zwischenzeit ein Sicherheitsupdate, was passiert, wenn das dem Programmentwickler egal ist, und das snap dementsprechend nicht aktualisiert wird? Damit wird doch der ganze Vorteil einer zentralen Paketverwaltung zunichte gemacht? Irgendwie erschließt sich mit nicht, was daran gut sein soll...

(Davon abgesehen, dass Wiki-Artikel IMHO auch immer zumindest die letzte aktuelle LTS-Version abbilden sollten, und soweit ich weiß sind snaps in 16.04 noch nicht standardmäßig aktiviert?) Ich benutze nämlich z.B. nur die LTS-Versionen, und will auch gar nicht auf die Zwischenversionen updaten...

noisefloor schrieb:

Allerspätestens dann, wenn es das Programm, dass du gaaaaaaanz dringend brauchst, nur als snap verfügbar ist, installierst du es per snap,

Garantiert nicht. Diese snap-app-flatpack-Entwicklung läuft diametral ressourcenschonender Paketverwaltungsysteme, also eines grundlegenden Merkmals gegenüber aufgeblähten OS, namentlich denen aus Redmond. Lehne ich grundsätzlich ab.

Genauso war es doch bei PPAs

Andere Baustelle.

Selber kompilieren ist zwar immer eine Option

Genau das.

Ich hatte in den letzten Tage 2x den Fall im Wiki, dass eine neue Version eines Progs "nur" als snap verfügbar war - haben wir dann auch im Artikel so eingebaut.

"Wir". Und das bei QupZilla auch nicht ohne Gegenwind.

axt schrieb:

noisefloor schrieb:

Selber kompilieren ist zwar immer eine Option

Genau das.

Das bin ich nicht bereit zu akzeptieren, denn genauso, wie snap die Vorteile einer zentralen Paketverwaltung in die eine Richtung zunichte macht, macht "selbst kompilieren" ebendiese Vorteile in die entgegengesetzte Richtung zunichte.

Deshalb hatte ich ja gehofft, dass es nicht dazu kommt, dass Programme nur noch per snap (oder zum selbst kompilieren), aber nicht mehr über apt verfügbar sind. Das ist ein absoluter Killer für die usability: Bei snap weiß man nie, ob man tatsächlich ein sicheres Programm hat (mit der aktuellsten Version aller Abhängigkeiten, wo jede Sicherheitslücke behoben wurde), und selbst kompilieren ist einfach nur ein maximaler Nerv-Faktor, man muss selbst prüfen ob neue Versionen vorhanden sind, und dann die Programme auch noch so ins System einbinden, dass sie genauso sicher laufen wie per apt installierte (also z.B. nicht mit den vollen user-Rechten im $HOME usw.), das ist doch einfach nur Murks! Ich benutze Debian und Ubuntu seit 2006, aber habe in der ganzen Zeit vielleicht zweimal ein Programm manuell übersetzt, d.h. es war immer nur die Ausnahme. Jetzt muss man sich also, wenn man keine (potentiell unsicheren, weil die Abhängigkeiten nicht gefixt werden) snaps installieren will, grundsätzlich bei allen Programmen darum kümmern, manuell Updates aus dem Upstream zu kompilieren? Wo bleibt da die User-Freundlichkeit? Warum ist das besser, als Linux-From-Scratch?!?

Perceptron schrieb:

Das bin ich nicht bereit zu akzeptieren,

Du kennst die Bedeutung des Wortes "Option"?

denn genauso, wie snap die Vorteile einer zentralen Paketverwaltung in die eine Richtung zunichte macht, macht "selbst kompilieren" ebendiese Vorteile in die entgegengesetzte Richtung zunichte.

Wenn ich kompiliere und selbstredend Abhängigkeiten beachten muß (und da nicht irgendwas zusätzlich 'reinklatsche, was das System längst hat), erstelle ich .deb-Pakete. Die werden wie jedes andere von der Paketverwaltung verwaltet.

axt schrieb:

Wenn ich kompiliere und selbstredend Abhängigkeiten beachten muß (und da nicht irgendwas zusätzlich 'reinklatsche, was das System längst hat), erstelle ich .deb-Pakete. Die werden wie jedes andere von der Paketverwaltung verwaltet.

Und bei einem einfachen "apt update && apt upgrade" wird automatisch die neue Version kompiliert und installiert? Denn das ist die usability, die ich davon erwarte!

Ich weiß gerade nicht, ob Du besonders geistreich sein willst oder einfach nur naiv bist. Wenn ich für mich Pakete erstelle, bin ich auch für deren Aktualisierung verantwortlich.