Vor- und Nachteile von SNAP (News-Split)

[TomTOm83]

Ich verstehe den ganzen Aufruhr um SNAP nicht ganz. Bin jetzt aber auch nicht in der Materie ganz drinnen. Für mich ist snap so was wie ein Playstore wo sich Apps auf einem zentralen Ort installieren lassen. Klingt nach Ordnung. Solange man die anderen Möglichkeiten nicht weg nimmt kompatibel zu bleiben ist ja alles gut. Ich hätte mir natürlich einen sanfteren weg gewünscht das zu realisieren aber Ubuntu war in der Hinsicht immer schon ein Eigenbrötler. Lg Tom

 

[pseudopseudonym]

Ich verstehe den ganzen Aufruhr um SNAP nicht ganz. Bin jetzt aber auch nicht in der Materie ganz drinnen.

Das schlimmste sind technische Unzulänglichkeiten.
Z. B. funktionieren SNAP-Programme nicht, wenn das Homeverzeichnis über einen Softlink läuft.
Dann kommt dazu, dass SNAP nur von Cannonical kontrolliert wird, man kann nicht einfach andere Paketquellen hinzufügen, wie es mit Apt geht. Wollte ich ein Betriebssystem, das von einem Hersteller kontrolliert wird und wo ein Hersteller bestimmt, was installiert wird, würde ich mich bei Apple umgucken.

Ergänzung (11. Juli 2020)

Ich verstehe die Aufregung auch nicht. Niemand wird gezwungen es zu nutzen, man kann es aber nutzen wenn man möchte

Auch das stimmt leider nicht. So wird der Chromium unter Ubuntu bewusst nur noch bei Snap angeboten und Snap-Programme werden immer tiefer in Ubuntu vergraben. Wo ergibt Snap bei vorinstallierten Programmen Sinn? Das führt bei mir z. B. dazu, dass der grafische "Appstore" nicht startet, siehe technische Unzulänglichkeiten.

 

[kim88]

Snap bei vorinstallierten Programmen macht durchaus Sinn. Fedora arbeitet ja mit Fedora Silverblue an was ähnlichem. Im Grunde geht es darum Betriebsystem und Anwendungen sauber zu trennen. Auf der einen Seite hat du dein OS (Linux Kernel) die GNU Tools und die grafische Oberfläche.

Danach gibt es die Anwendungen Browser, Office Paket, E-Mail Client, etc. In der Linux Welt wird unendlich viel Man-Power damit verschwendet diese Anwendungen für Distributionen zu bauen. Firefox als Beispiel, das wird gefühlt 1'000 mal gebaut. Einmal von einem openSUSE (für die diversen SUSE Versionen) Mitarbeiter, mal von einem Canonical Mitarbeiter, Debian Mitarbeiter, Red Hat Mitarbeiter, usw

Das kostet Zeit und Arbeitsstunden - beides ist teuer. Und eigentlich auch zu schade dafür nur ein neues Firefox Paket zu bauen. Flatpak/Snap umgehen das Problem. Ein Snap oder ein Flatpak wird genau einmal gebaut - und das läuft nachher auf jedem Linux - egal ob es ein Ubuntu 16.04, 18.04, 20.04, eine openSUSE, ein SLED, ein Feodra oder sonst was ist - da läuft immer das gleiche Paket - daher ja Anwendungen als Snap/Flatpak ob vorinstalliert oder nicht machen durchaus Sinn.

Der Weg geht sowohl bei Ubuntu aber auch bei Fedora (Silverblue soll irgendwann die normale Workstation Ausgabe ablösen) genau in die Richtung. Gezwungen wirst du nicht - wenn du über CLI dein Chromium per APT in Ubuntu installieren willst - wirst du ja gefragt ob du Snap haben willst. Wenn du es über die GUI installierst passiert es einfach (macht aber nichts ^^ Menschen die das über die GUI machen kennen den Unterschied eh nicht).

Alternativ kannst du jederzeit das Chromium Paket selber kompilieren, ein PPA suchen oder eine Distro nehmen die es anders handhabt.

 

[pseudopseudonym]

Snap bei vorinstallierten Programmen macht durchaus Sinn. Fedora arbeitet ja mit Fedora Silverblue an was ähnlichem. Im Grunde geht es darum Betriebsystem und Anwendungen sauber zu trennen.

Was soll denn der Schmarn? Das schöne an Linux-Distros ist doch gerade, dass sich alles als eine Einheit präsentiert, auch bei Updates, sodass man nicht die Feuerwerksstimmung bei Updates hat, die man von Microsoft kennt.

Gezwungen wirst du nicht - wenn du über CLI dein Chromium per APT in Ubuntu installieren willst - wirst du ja gefragt ob du Snap haben willst.

Ja eben nicht, es gibt den Chromium nicht mehr in den Paketquellen, nur noch ein Dummy-Paket.
Jetzt darf man sich die Debian-Paketquellen ins System frickeln, wenn man den Chromium noch normal nutzen möchte.

[...] oder eine Distro nehmen die es anders handhabt.

Und genau dafür liebe ich Linux. Die Desktop-PCs in meinem Umfeld wandern jetzt alle zu Linux Mint. Macht aus Nutzer-Sicht keinen großen Unterschied und schont meinen Kreislauf, weil ich mich so gar nicht erst über Snap aufregen musst. Wie gut, dass man in der Linux-Welt immer eine Wahl hat.

Die Server, die nicht auf Debian, sondern auf Ubuntu laufen, lasse ich einfach auf Ubuntu, weil Snap da zum Glück noch keine wirkliche Rolle spielt (meine VDR wäre ein Beispiel).

Ergänzung (11. Juli 2020)

Das, was mich an snap am meisten aufregt, ist allerdings, dass es bei mir schlicht und einfach nicht funktioniert, weil ich um Verzeichnisse teilweise über Softlinks einbinde.
Die Snap-Programme starten dann gar nicht erst.

 

[new Account()]

Was soll denn der Schmarn? Das schöne an Linux-Distros ist doch gerade, dass sich alles als eine Einheit präsentiert, auch bei Updates, sodass man nicht die Feuerwerksstimmung bei Updates hat, die man von Microsoft kennt.

Es ist auch ein Nachteil, den man vielleicht nicht in Kauf nehmen möchte.
sh. seine Ausführungen und:
https://www.reddit.com/r/Ubuntu/comments/a364ii/proscons_of_snap_vs_apt/
https://snapcraft.io/blog/a-technical-comparison-between-snaps-and-debs
Die Vorteile des Ansatzes zu ignorieren sollte man imho auch nicht.

Ich find gut, dass die Updates dort weniger fehleranfällig sind (es geht nichts kaputt) und man nicht vom Repo abhängig ist (wo man dann ggf. selber rumfrickeln muss oder unbequemere Lösungen hat -> Faulheit siegt heutzutage). Speicherplatz etc. interessiert da weniger.
Ich glaube man kanns auch gut mit Docker Container vergleichen

Wüsste nicht wie man dadurch typische Windows Updateprobleme bekommt (reboots?).

 

[pseudopseudonym]

Die Vorteile des Ansatzes zu ignorieren sollte man imho auch nicht.

Flatpak z. B. ist eine wunderbare Sache. Es ist optional, nicht auf einen zentralen Server beschränkt und natürlich super für "kleinere" Software, die man nicht mal eben für mehrere Distros ausrollen kann.
Nur wird Snap ja sogar für vorinstallierte Eigenentwicklungen genutzt, was für ein Irrsinn!

Wüsste nicht wie man dadurch typische Windows Updateprobleme bekommt (reboots?).

Dass eine Software nicht mehr mit dem neusten Updatestand arbeiten möchte. Das schöne an Paketsystemen wie Apt ist doch gerade, dass alles gleichzeitig aktuell gehalten wird.

 

[new Account()]

Dass eine Software nicht mehr mit dem neusten Updatestand arbeiten möchte.

Wie meinst du das? Bringen snaps nicht die deps mit, wodurch sie egal unter welchem Updatestand funktionieren sollten?

 

[pseudopseudonym]

@new Account()
Ich sehe ehrlich gesagt nicht, wie das langfristig gut gehen kann, wenn Canonical das vielleicht irgendwann sogar für Software macht, die relativ tief im System sitzt (Samba, Apache, SQL, ...). Die Befürchtung habe ich, wenn jetzt schon grafische Appstores darüber laufen.
Als kleines Extra finde ich den Ansatz super, aber nicht um Apt teilweise zu verdrängen. Dass bei mir Snap-Programme nicht funktionieren, weil das Home-Verzeichnis über einen Softlink läuft, zeigt doch, dass an der Umsetzung etwas ganz gewaltig schiefläuft.

Ergänzung (11. Juli 2020)

Dass ich Snap gegenüber nicht sonderlich positiv eingestellt bin, wenn meine ersten Erfahrungen "funktioniert nicht" und "wir verschieben dir Software auf eine Plattform, die bei dir nicht funktioniert" sind, sollte klar sein.
Würde das für mich so funktionieren, dass ich von Snap so gut wie gar nichts mitbekomme, wäre meine Einstellung dazu sicherlich eine andere.

 

[new Account()]

Inwiefern sitzt SQL, oder Apache tief im System? Das sind doch normale Anwendungen, ein Webserver und ne Datenbank - nicht unbedingt tief im System, oder?

Ich sehe das Problem lediglich, falls die Datenbank oder der Webserver eine Abhängigkeit von einem anderen Programm ist, z.B. Synapse.
Aber dann würde ich auch erwarten, dass das Programm diese Abhängigkeit mitbringt, oder einen entsprechenden Prozess für die Integration für den User bereitstellt.

Natürlich sollte es nicht vorkommen, dass irgendwas im System abhängig von den Snaps ist. Das wär creepy (weil es die Integrität des Systems mehr oder weniger zwangsweise beschädigen würde).
Ist das der Fall bei Ubuntu? Bin da jetzt nicht sonderlich tief drin.

Als kleines Extra finde ich den Ansatz super, aber nicht um Apt teilweise zu verdrängen. Dass bei mir Snap-Programme nicht funktionieren, weil das Home-Verzeichnis über einen Softlink läuft, zeigt doch, dass an der Umsetzung etwas ganz gewaltig schiefläuft.

Von der Umsetzung - ja. Konzeptuell? nicht unbedingt.

Bei Anwendungen sehe ich, siehe oben, kein Problem, wenn apt da verdrängt wird. Das könnte durchaus für alle Anwendungen passieren.
Hat irgendwie etwas von Android.


Zwecks Flatpak: scheint ja ein neuerer Konkurrent zu snap zu sein. Wenn der keine zentralen Abhängigkeiten hat, top.
Aber Konzept trotzdem ähnlich?

 

[kim88]

Das, was mich an snap am meisten aufregt, ist allerdings, dass es bei mir schlicht und einfach nicht funktioniert, weil ich um Verzeichnisse teilweise über Softlinks einbinde.
Die Snap-Programme starten dann gar nicht erst.

Das ist dann tatsächlich ein Problem. Du musst zugeben, dass das aber auch kein "normales" Setup ist. Wurde das Canonical mal mitgeteilt? Also wissen die das es dieses Problem gibt?

Ich find gut, dass die Updates dort weniger fehleranfällig sind (es geht nichts kaputt) und man nicht vom Repo abhängig ist (wo man dann ggf. selber rumfrickeln muss oder unbequemere Lösungen hat -> Faulheit siegt heutzutage). Speicherplatz etc. interessiert da weniger.
Ich glaube man kanns auch gut mit Docker Container vergleichen

Vielleicht mag ich die Snaps/Flatpaks deswegen - weil ich sonst auch viel mit Docker arbeite. Speicherplatz ist nun wirklich kein Argument. Selbst mein "schwächstes" Notebook hat eine 1TB SSD über NVM.

Dass eine Software nicht mehr mit dem neusten Updatestand arbeiten möchte. Das schöne an Paketsystemen wie Apt ist doch gerade, dass alles gleichzeitig aktuell gehalten wird.

Snaps und Flatpaks aktualisieren sich doch auch. Für mich ist es einfach eine zusätzliche "Paketverwaltung" neben Apt, DNF, etc gibt noch flatpak und Snap. In der Regel hatte man ja vorher schon mehr als eine Paketverwaltung oft arbeitet man ja auch noch mit NPM oder Composer, etc - verlangt ja auch niemand dass diese Pakete als Deb vorliegen.

Ich sehe ehrlich gesagt nicht, wie das langfristig gut gehen kann, wenn Canonical das vielleicht irgendwann sogar für Software macht, die relativ tief im System sitzt (Samba, Apache, SQL, ...). Die Befürchtung habe ich, wenn jetzt schon grafische Appstores darüber laufen.

Apache, MariaDB, etc sind keine Systempakete. Der Linux Kernel ist ein Systempaket die GNU Tools ebenfalls, und auch die Hardwaretreiber (die nicht im Kernel integriert sind). Wer bitte installiert heute im professionellen Umfeld noch Apache & Co über die Distro-Paketverwaltungen, das sind doch längst schon Docker Container - was im Grunde nichts gross anderes ist als Snap oder Flatpak. Nur das die letzten beiden für grafische Oberflächen optimiert sind.

BTW: Ich habe diesen Beitrag selber gemeldet, da das ganze extrem Offtopic wird und vielleicht eher abgespalten werden sollte.

 

[pseudopseudonym]

@kim88
Dann lasse ich das Diskutieren hier besser, hab schon ne Verwarnung, weil ich mal ne Zeile aus einem Beitrag über mir zitiert habe.
Ich bin jedenfalls kein Fan davon, dass OS und Anwendungen auf die Art getrennt werden. Ich finde es gerade gut, dass sich auf Linux-Distros alles als eine Einheit darstellt.

 

[sh.]

Da sieht man mal wieder was der größte Vorteil von Linux ist - ist sogleich auch der größte Nachteil. Jedes Team macht sein eigenes Projekt und es wird unnötige Man-Power sinnlos verbraucht. Aber da die meisten Linux-Entwickler anscheinend von Luft und Liebe leben ist es ja egal.

 

[Jerry123]

Also ganz ehrlich, man muss sich vor snap nicht fürchten - weil es nämlich den gleichen Weg gehen wird wie Unity und all diese anderen Canonical-Eigenwege

Das zeichnet sich bereits ab: Schaut euch bloß die Snaps in Canonicals App Store an und die Versionsnummern. Sie sind teilweise deutlich älter als die apt-Versionen oder auch die als flatpak erhältlichen. Der Grund ist, dass praktisch ausschließlich Canonicals eigenes Team snaps erstellt. Beteiligung von Entwicklern außerhalb von Canonical scheint nicht gegeben zu sein. Dazu kommt, dass die Ubuntu-Derivate wie Mint nun auch abspringen.

Tja, wie soll das wohl ausgehen? Die gesamte Linux-Welt springt plötzlich auf snaps, weil sie auf veraltete und - vor allem - im Vergleich zu flatpak wesentlich langsamer startende Apps steht?

Mein Theorie ist ja, dass Canonical solche Vorstöße wie seinerzeit Unity und jetzt snap aus pädagogischen Gründen macht. Die wollen sich gar nicht durchsetzen, sondern sie wollen ein abschreckendes Beispiel liefern, sodass die anderen sich am Riemen reißen. Siehe Gnome, das ist seit Unity ganz ordentlich

 

[Iapetos]

Zwecks Flatpak: scheint ja ein neuerer Konkurrent zu snap zu sein. Wenn der keine zentralen Abhängigkeiten hat, top.
Aber Konzept trotzdem ähnlich?

Weder neuer noch Konkurrent. Der einzige Konkurrent ist Canonical mit mit Snappy. Der zentrale Server ist proprietär und unter der Kontrolle von Canonical. Die Idee dahinter ist wohl, eine Art App Store oder Play Store für das Linux-Ökosystem zu etablieren. Canonical hätte sich ebenso an der gemeinschaftlich gepflegten Lösung xdg-app bzw. Flatpak beteiligen können oder die ziemlich gut funktionierenden AppImages übernehmen können - beides bot offenbar nicht genügende Möglichkeiten der Kontrolle, so dass - wieder einmal - ein Sonderweg beschritten wurde. Mal sehen, wie lange das noch anhält.

Konzeptuell unterscheidet sich Flatpak durch seine Dezentralität von Snappy. Flatpak soll ein einheitliches Paketformat für alle Distributionen sein. Snaps sollen Canonical Einfluss auf und Kontrolle über Software-Verteilung ermöglichen.

 

[new Account()]

Weder neuer noch Konkurrent.

Zwei Dienste, die im Prinzip das selbe machen - mehr Konkurrent geht kaum.

Und Snap scheint auch vor Flatpak schon dagewesen zu sein:
Linux: Snap-Konkurrent Flatpak jetzt offiziell freigegeben
https://www.heise.de/newsticker/mel...tpak-jetzt-offiziell-freigegeben-3246482.html

Von daher finde ich deine Aussagen irgendwie daneben.

 

[Iapetos]

Das Konzept von Flatpak/xdg-app ist das ältere. Es konkurriert nicht mit Snappy, da es grundsätzlich nicht-kommerziell ist. Monetarisierung ist zwar möglich, aber kein Konzept der Plattform. Im Gegensatz zu Snappy.

Erinnert an Wayland und Mir: Ein neues Konzept wird vorgestellt und kurz darauf "kreiert" Canonical seine eigene Variante, die nicht besser ist, aber unter Canonicals Kontrolle steht.

 

[new Account()]

Es konkurriert nicht mit Snappy, da es grundsätzlich nicht-kommerziell ist.

Das eine hat doch mit dem anderen nichts zu tun. Auch nicht kommerzielle Produkte können konkurrieren.

Das Konzept von Flatpak/xdg-app ist das ältere.

Und snap war immer noch vor flatpak da.

 

[Iapetos]

Die offizielle Vorstellung des einen spricht dem anderen nicht das Alter ab. Der von dir verlinkte Heise-Artikel spricht eindeutig von jahrelanger Entwicklung. Entwicklung, die öffentlich stattgefunden hat.

Und nein, Flatpak konkurriert nicht, auch wenn unsere Vorstellungen von Marktmechanismen das suggerieren. Es koexistiert und wird noch lange nach Snappy (wenn Canonical dessen zentrales Repo außer Dienst stellt) weiter existieren.

 

[new Account()]

Und nein, Flatpak konkurriert nicht, auch wenn unsere Vorstellungen von Marktmechanismen das suggerieren.

Koexistenz und lange weitere Existenz bedeutet auch nicht, dass etwas nicht konkurriert.
Beispielsweise sind XMPP und ICQ Konkurrenten gewesen, obwohl ersteres föderiert war/ist.
XMPP war sogar für die Inkorporation mit ICQ ausgelegt (explizite Koexistenz) und ist auch heute noch in Benutzung. Selbes Spiel mit Matrix und allen anderen Chatdiensten in der heutigen Zeit.

Der von dir verlinkte Heise-Artikel spricht eindeutig von jahrelanger Entwicklung. Entwicklung, die öffentlich stattgefunden hat.

Und dann kam Ubuntu und stellt kurzerhand eine Lösung zur Verfügung, während an flatpak immer noch gearbeitet worden ist.

 

[Iapetos]

Flatpak hat im Gegensatz zu Snappy keinen Alleinigkeitsanspruch. Diesen benötigt letzteres für eine erfolgreiche Marktdurchdringung und Monetarisierung. Der Vergleich mit XMPP und ICQ ist nicht verkehrt, ich interpretiere ihn aber anders: Ersteres hat Portale zur Kommunikation mit anderen Protokollen, während letzteres solche Funktionen nicht bietet. Inkorporation ist das freilich nicht. Aufseiten von XMPP bleibt es Koexistenz, da es (als offenes Protokoll) nicht darauf angewiesen ist sich durchzusetzen; für ICQ als kommerzielles Produkt war es grundsätzlich Konkurrenz.

Kannst du dir vorstellen, dass Canonical im Angesicht von Ubuntu Touch und hochtrabenden Smartphone-Plänen dringend eine plattformgebundene, kommerzialisierbare Lösung brauchte, weil absehbar war, dass xdg-app bzw. Flatpak eine brauchbare Lösung für das Problem distributionsübergreifendes Paketformat wird? Canonical wollte sich (nicht zum ersten Mal) einen Plattformvorteil verschaffen und ist damit (nicht zum ersten Mal) gescheitert.

Die Historie von Flatpak zeigt deutlich, dass dieser offene Ansatz der ältere ist. Nur, weil es seinen endgültigen (aussprechbaren) Namen nach Snappy erhalten hat, ist es kein "Nachahmer-Produkt". Deine Vermutung

Und Snap scheint auch vor Flatpak schon dagewesen zu sein:

ist also widerlegt. Ist doch nicht schlimm, oder? Ich jedenfalls habe keine Canonical-Aktien und werde mich hüten, solche zu kaufen.