Was haben alle gegen Snap und Flatpack?

[Phrasendreher]

@foo_1337 @ModellbahnerTT
Glaubt mir, naiv bin ich nicht, 30 Jahre Erfahrungen mit Unix, 28 mit Linux, davon 16 mit Ubuntu (und auf nem anderen Rechner habe ich Docker laufen - unter Windows).
Könnt Ihr beweisen, dass ein Fehler im Gnome-CPU-Load-Monitor-Snap-App-Paket zu finden ist?
Ansonsten sind Eure Einwände gegenstandslos.
Nochmal: Der gleiche Monitor nativ installiert verursacht keine nennenswerte Last.

 

[foo_1337]

"Der gleiche Monitor" ist potentiell ein Binary was mit völlig anderen Flags compiliert wurde. Und nein, beweisen muss ich hier nichts. Ich weiß, wie Snap, chroot() etc funktioniert. Und das reicht um zu wissen, dass daraus prinzipiell kein CPU Last Problem resultiert.

 

[andy_m4]

Es wird um Speicherplatz diskutiert im Jahre 2022 wo man mit Handys mit teilweise 1TB Speicherplatz rumläuft oder weil eine Technologie von einer Firma abhängig ist... eine Firma die oh Wunder Umsatz generiert.

Naja. Massenspeicher hast Du zwar im Überfluss aber RAM ist immer noch relativ "knapp". Und dann kommst Du halt plötzlich in die Situation das Dein Programm was unter normalen Umständen moderaten RAM-Bedarf hat, weil die Hälfte der benötigten Bibliotheken eh schon geladen ist dann plötzlich das x-fache braucht.

Außerdem gibts eine Reihe an praktischen Erwägungen wo Speicherbedarf eine Rolle spielt. Zum Beispiel bei Vollbackups. Die dauern länger, Du braucht mehr Speicher um sie zu sichern. usw.

Hinzu kommt noch das Komplexitätsproblem. Umso mehr Kram im System ist, umso höher ist die Chance das Du da irgendwelche Bugs drin hast.

Das sind alles so Dinge die sich nicht mit einem "Wir haben doch genügend große Festplatten/SSDs" erschlagen lassen.

Wir benutzen tag täglich vieles was von nur einer Firma abhängig ist und nicht alles muss OpenSource sein oder nicht alles ist schlecht weil es Geld kostet. Arbeitet ihr umsonst?

Glaub mir, viele Open-Source-Entwickler sind gut bezahlte Leute.
Open-Source benutzt man (außer vielleicht im Privatbereich) in der Regel auch nicht, weil die Software ansich kein Geld kostet, sondern weil man sich unabhängig macht, weil man selbst Modifikationen vornehmen kann, weil man flexibler ist.

Ist ja kein Wunder das sich Linux im Desktopbereich nie durchsetzen wird, einfach alles zu verbissen, zu ideologisch,

Über all woanders hat sich Linux durchgesetzt. Das kann also schlecht der Grund sein (falls er überhaupt zutrifft).

 

[Garmor]

Nochmal: Der gleiche Monitor nativ installiert verursacht keine nennenswerte Last.

Du versuchst von einer einzigen Anwendung aus zu generalisieren. Könnte es sein, dass das insgesamt kein sonderlich tragfähiges Denkmuster ist?

 

[Phrasendreher]

@Garmor Ich halte es für ein starkes Indiz.

 

[foo_1337]

Ist ungefähr wie "Chrome performed unter Windows besser als unter GNU/Linux, also muss Windows das effizientere OS sein"

 

[Phrasendreher]

Topic ist ja auch "Was haben alle gegen Snap und Flatpack" - und meine 2 cents sind eine katastrophale Experience mit dem ersten Snap, das mir über den Weg gelaufen ist. Warum alle anderen Snaps besser performen sollten?
Auch mir ist bekannt, wie Containersysteme arbeiten (und manchmal chroot()e ich einfach nur zum Spass - wenn meine Freundin nicht guckt), und es erschliesst sich auch mir nicht intuitiv, warum Snap auf einem 2014er PC-Design so mies laufen sollte, aber ich habe diese Erfahrung gemacht und hier meinen Beitrag geschrieben - ob es Euch gefällt oder nicht.

 

[fixedwater]

"Gtk-Message: 08:37:06.406: Failed to load module "xapp-gtk3-module"

Läuft deezer denn problemlos? Wenn ja: ignorieren.

 

[andy_m4]

IMHO demonstriert dies, wie übel ineffizient Snaps sind.

Ich weiß nicht, ob das an Snap als Solches liegt (was ungewöhnlich wäre). Allerdings macht ja die Snap eine Reihe an Sachen (inkl. Sandboxing). Möglicherweise löst das quasi als Nebeneffekt eine erhöhte Last durch den CPU-Load-Monitor aus. Möglicherweise sind es aber auch Paketkonfigurationen oder Probleme in den mitgelieferten Bibliotheken.

Das lässt sich aber abschließend nur dadurch aufklären, in dem man sich die Sache mal genauer ansieht (ggf. Debugging macht).

Ich bin auch kein Fan von Snappy, aber nur aufgrund einer einfachen Beobachtung solch weitreichende und allgemeingültige Schlüsse zu ziehen ist mir dann doch zu gewagt.

 

[ModellbahnerTT]

Könnt Ihr beweisen, dass ein Fehler im Gnome-CPU-Load-Monitor-Snap-App-Paket zu finden ist?

Leider derzeit nicht zum Gegencheck könntest du aber ein anderes Snap testen um zu sehen ob dort das gleiche Phänomen auftritt wenn ja dann liegt es doch an Snap ansonsten liegt es im Paket.

 

[Phrasendreher]

@ModellbahnerTT Kann ich leider nicht testen, einerseits hatte ich nach meiner Erfahrung (noch in 2020) Snap deaktiviert (und daraufhin lief der alte PC runder), andererseits ist die Maschine derzeit offline (und disassembliert).

Anders herum: Gibt es hier jemand mit nem (älteren?) Raspberry Pi mit Ubuntu, der mit Snaps Erfahrungen gesammelt hat? (insbesondere mit UI-Apps)? Wie ist da die Experience?

 

[riversource]

Ich hab seit Jahren Erfahrung mit Snaps und vergleichbaren Mechanismen (chroot etc.) und hab sie vor allem auf kleineren Embedded Systemen gern eingesetzt, eben weil sie mich vom Zwang befreiten, aufgrund eines spezifischen Anwendungsfalls ganze Bibliotheksbäume aktualisieren zu müssen und damit Kompatibilitätsprobleme an anderer Stelle zu erzeugen. Ich kann vor allem bestätigen, dass Container-Anwendungen wie Snap keinen zusätzlichen CPU Overhead erzeugen. Es ist eine Container-Technik, keine Virtualisierung. Wenn eine Snap Anwendung signifikant mehr CPU konsumiert, als eine native Anwendung, dann liegt da definitiv ein Fehler vor.

Vor allem auf Systemen mit sehr spezifischen HW Anforderungen ist es nicht so leicht, mal eben Treiber- oder Middleware Komponenten auszutauschen. Das sind häufig Kombinationen aus Kernel-Treibern und Userspace-Bibliotheken, und es wird die Hölle, wenn man denen die bekannten libs unter den Füßen wegzieht. Jeder, der schon mal in der Lage war, solche Systeme zu betreuen, wird auf Knie fallen und Gott (oder vergleichbaren Instanzen) danken, dass es sowas wie Snaps gibt.

 

[Phrasendreher]

Danke für die Aufklärung.
Mir war klar, dass Snap keine Virtualisierung macht, aber ich habe den Verdacht, dass das Sandboxing (und was weiss ich was Canonical da treibt) für Overhead sorgt.
Falls Du bei Embeddeds gute Erfahrungen gemacht hast, ist das natürlich interessant und spricht für die Leichtgewichtigkeit (wie zur Hölle hast Du darauf Ubuntu installiert?). Dass ein chroot() allein nix kostet, ist klar.

BTW: Hab gerade Svens Artikel zu Armbian gelesen (Ubuntu based), in der Doku nach Snap gesucht - anscheinend wird's nicht mitgeliefert; es findet sich nur ein Hinweis, dass ein Aufwand betrieben wird, ohne auszukommen. Vielleicht bin ich mit meinen Erfahrungen ja doch nicht allein auf der Welt!?

 

[ghecko]

und spricht für die Leichtgewichtigkeit

Tut es nicht, im Gegenteil. Alles was das Programm braucht, aber nicht teil des Programms ist, ist in snap integriert.
Und je größer und komplexer die Anwendung, desto abstruser wird es. Für kleine Embedded-geschichten ist das egal ob das Programm jetzt 2 oder 6MB hat, wenn aber so was wie Blender statt 600mb auf einmal 3GB groß ist wird es abstrus. Das ganze Ding muss von der SSD geholt, entpackt und im RAM gelagert werden.

Deshalb sind viele so vehement dagegen, alles als snap auszuliefern. Es macht auf einem Desktop einfach viel weniger Sinn und schafft mehr Probleme als es löst.

 

[foo_1337]

Naja, wir treiben auf der Arbeit auch nen gewissen Aufwand, snapd von unseren Systemen fern zu halten. Aber dafür gibt's eben viele Gründe.

 

[andy_m4]

Ich kann vor allem bestätigen, dass Container-Anwendungen wie Snap keinen zusätzlichen CPU Overhead erzeugen.

Dennoch kann es natürlich mittelbare Effekte geben. Zum Beispiel wenn eine Anwendung von GPU-Beschleunigung Gebrauch macht und dann aber aus dem Container nicht mehr auf die entsprechenden Funktionen zurückgreifen kann und aufgrund dessen auf die Emulation via CPU zurückgreift.
Das wäre jetzt so ein exemplarischer Fall wo durch eine Verkettung von Umständen es doch zu einer höheren Last kommt. Und solche Effekte sind natürlich nicht auszuschließen.

Abgesehen davon hast Du natürlich durch Lösungen wie Snap Overhead. Der mag minimal sein, aber er ist größer als Null. Schon allein deshalb weil z.B. im Falle von Snap fürs Sandboxing AppArmor genutzt wird und wenn man das einschaltet kostet das eben Zeit.
Auch der Overhead den Du durch die containisierte Anwendung kriegst ist nicht unbedingt zu vernachlässigen. Du hast ein höheren RAM-Bedarf (RAM der Dir dann an anderer Stelle fehlt und sei es nur das Dein Disk-Cache kleiner ist).

 

[Garmor]

Vielleicht bin ich mit meinen Erfahrungen ja doch nicht allein auf der Welt!?

Die Leute wehren sich in der Regel gegen den nächsten Alleingang von Canonical und nicht, weil bei ihnen ein einzelnes Programm nicht so lief, wie sie es sich erhofft haben.

 

[riversource]

Das ganze Ding muss von der SSD geholt, entpackt und im RAM gelagert werden.

Im RAM ist am Ende nur das, was die Prozesse benötigen. Die snaps an sich sind ja üblicherweise squashfs Dateien. Das wird nicht alles gecached.

Ja klar, am Ende ist es ein Abwägen. Vor allem Massenspeicher braucht man deutlich mehr. RAM ist es überschaubar und CPU vernachlässigbar. Da man bei chroot Environments etc. auch Zugriff auf die Hardware hat, sind sowas wie GPU Ressourcen auch kein Problem. Kernel und Dev holt man sich ja üblicherweise per bind mount in den Container. Dem gegenüber steht der Wartungsaufwand, der halt kleiner wird. Da muss man entscheiden, was wichtiger ist.

 

[ghecko]

Ja klar, am Ende ist es ein Abwägen. Vor allem Massenspeicher braucht man deutlich mehr. RAM ist es überschaubar und CPU vernachlässigbar.

Beispiel mpv:
Benutze ich zum schnellen durchhören von Musikdateien. Doppelklick auf die Datei und schon wird sie abgespielt. Dann auf einem System aus versehen die Snap-Version eingespielt und ich hab geschlagene 5 Sekunden warten dürfen, bis nach dem Doppelklick mal Musik aus den Lautsprechern kam.
So was mag nicht bei allen Anwendungen relevant sein, es nervt mich aber, weil unter Linux seit SSDs existieren eigentlich so was wie Startzeit von Programmen nicht mehr existiert.

Ich finde es legitim für Spezialfälle, wo man eben auf ein "stabiles" System aktuelle Software aufspielen will die man einfach warten kann oder um Schuppen wie Adobe die Ausreden zu nehmen, warum sie ihre Software nicht für Linux bereitstellen.
Aber ich will nicht das bald jedes Programm nur noch als Snap ausgeliefert wird, da fange ich lieber an alles selbst von Git zu ziehen und zu bauen. Damit vergeude ich weniger Zeit.

 

[KitKat::new()]

Hinzu kommt noch das Komplexitätsproblem. Umso mehr Kram im System ist, umso höher ist die Chance das Du da irgendwelche Bugs drin hast.

Es ist zwar mehr Kram auf dem System, allerdings gibt es weniger "bewegliche" Teile. Man hat viele Pakete, die für sich selbst abgeschlossen sind, statt indirekt miteinander verwoben sind.
Für das System selbst ist es weniger komplex.
Für den Entwickler ist es weniger komplex.
Obwohl insgesamt mehr da ist.