Was haben alle gegen Snap und Flatpack?

[andy_m4]

Da man bei chroot Environments etc. auch Zugriff auf die Hardware hat, sind sowas wie GPU Ressourcen auch kein Problem.

Snap macht aber nicht einfach nur ein chroot. Hab ich doch erklärt.

Kernel und Dev holt man sich ja üblicherweise per bind mount in den Container.

Idealerweise holt man sich nur in den Container, was man wirklich braucht.

Dem gegenüber steht der Wartungsaufwand, der halt kleiner wird. Da muss man entscheiden, was wichtiger ist.

Ich hab nicht gegen Container argumentiert. Ich hab nur versucht darzulegen, wo Probleme liegen können. Ich hab auch nicht behauptet das nicht nicht behebbar wären und letztlich vielleicht sogar nur Konfigurationsfehler sind.
Aber einfach zu sagen es kann prinzipiell kein solches Problem geben ist halt nicht zutreffend.

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.

Tatsächlich nutze ich auch exzessiv Container aber baue mir die dann immer selbst. Ich muss aber einräumen, das es hier und da Leute gibt die wären damit überfordert. Und die sind dann vielleicht mit Snappy und einem offiziellen Repository mit vorgefertigten Snaps nicht schlecht bedient. :-)

Zum Glück besteht ja kein Benutzungszwang. :-)

Es ist zwar mehr Kram auf dem System, allerdings gibt es weniger "bewegliche" Teile.

Ich sehe diesen Punkt. Ich hab auch so ziemlich von Anfang an gesagt, das es halt auch immer ein bisschen drauf ankommt und das jede Vorgehensweise seine Vor- und Nachteile hat und man eben bei sich selbst gucken muss, wie man möglichst viel Vorteile rauszieht und möglichst viel Nachteile weg kriegt.

Für das System selbst ist es weniger komplex.
Für den Entwickler ist es weniger komplex.
Obwohl insgesamt mehr da ist.

Allerdings steigt auch der Wartungsaufwand und man hat mehr Mühe den Überblick zu behalten.
Ohne Container brauchtest Du halt nur das ganze System zu aktualisieren um auf den neusten Stand zu sein. Jetzt musst Du ggf. noch die Container nachziehen und auch ggf. gucken das die nicht irgendeine löchrige uralt Bibliothek mit herumschleppen.

Wie gesagt. Alles hat seine Vor- und Nachteile. Das merkt man auch daran, das man ja nicht jedes Programm in einen Container packt. Ich nehme mal an selbst Du hast sowas wie /bin/ls noch einfach so auf dem System und nicht als Flatpak oder Snap. :-)

 

[foo_1337]

Für das System selbst ist es weniger komplex.
Für den Entwickler ist es weniger komplex.
Obwohl insgesamt mehr da ist.

Serverseitig hat man die Vorteile längst erkannt und nutzt docker/containerd. Auf dem Desktop dauert's halt wieder mal mit der Akzeptanz bzw. man führt lieber Grabenkämpfe mit fragwürdigen Argumenten

Ergänzung (3. März 2022)

Wie gesagt. Alles hat seine Vor- und Nachteile. Das merkt man auch daran, das man ja nicht jedes Programm in einen Container packt. Ich nehme mal an selbst Du hast sowas wie /bin/ls noch einfach so auf dem System und nicht als Flatpak oder Snap. :-)

Bei uns z.B. wird selbst Kleinkram wie ansible oder Terraform als Container geliefert. Hat den Vorteil, dass man einfach spezifische Versionen parallel nutzen kann und Linux und macOS User das selbe nutzen können. Und das ist trotz Linux Hilfs-VM auf dem Mac peformant genug

 

[andy_m4]

Serverseitig hat man die Vorteile längst erkannt und nutzt docker/containerd.

Container ja. Docker im Speziellen eher nicht. :-)

Bei uns z.B. wird selbst Kleinkram wie ansible oder Terraform als Container geliefert.

Also ls nicht. Dann hab ich keine weiteren Fragen. :-)

 

[andy_m4]

Also früher war es öfter mal üblich statisch zu linken. Dann hat man uns gesagt: Nehmt shared libraries. Dann können sich mehrere Programme Code teilen. Und wenn in der Bibliothek mal ein Bug drin ist wird der da gefixt und alle Programme die die shared library verwenden profitieren von dem Bugfix.

Heute erzählt man, das es ja voll doof ist wenn Bibliotheken geteilt werden. Da sind dann möglicherweise nicht die richtigen da oder es gibt in den Versionen inkompatible Änderungen. Lasst uns mal lieber zur Anwendung die passenden Bibliotheken mitliefern.

Das macht man aber nicht mit altbewährten Methoden.
Nene. Das wäre ja zu einfach. Stattdessen etabliert man mit Container eine neue Technologie und statt statisch zu linken wirft man die Bibliotheken als shared libraries in den Container mit rein. Das ist so ein wenig dieser von-hinten-durch-die-Brust-ins-Auge-Ansatz. :-)

 

[foo_1337]

In Zeiten von composer, npm usw. wird's halt schwierig mit dem statischen Linken Das sind ja die prädestinierten Apps für die man gerne container nimmt.

 

[Untertan]

Mal ein kleines Beispiel von heute. Ich installiere Vorta (eine GUI für Borgbackup) aus dem AUR was dann 1,6 MB herunterlädt. Als Flat sind es dann 55MB. Mit der Flat Version kann ich nicht auf externe Laufwerke sichern was ich dann für meine Anwendung als sinnlos erachte. Dann doch lieber AUR also klassisch.

 

[Linuxfreakgraz]

Mit der Flat Version kann ich nicht auf externe Laufwerke sichern was ich dann für meine Anwendung als sinnlos erachte. Dann doch lieber AUR also klassisch.

Ähnliche Probleme kenne ich mit Snap, womit ich nicht sagen will, dass die Idee an sich nicht schlecht ist.
Nur gibt es Anwendungsszenarien, die Flat und Snap eben ausschließen.

 

[andy_m4]

In Zeiten von composer, npm usw. wird's halt schwierig mit dem statischen Linken

node.js, Python und Co bieten doch für sowas extra Virtual-Environments.

 

[foo_1337]

Und sobald du mehrere verschiedene Versionen der Runtime selbst brauchst, wirds eben spaßig.

 

[andy_m4]

Auch das Problem lässt sich lösen. Indem man einfach ne user-based-Installation macht.
Wie gesagt. Ich benutze auch Container und möchte deren Nutzen auch gar nicht in Abrede stellen. Aber viele Dinge, die man mit Containern macht lassen sich auch ohne Container lösen.

Aber selbst dann kann es sich lohnen solche Sachen in Container zu packen. Aber nicht mit der Begründung das es ohne Container nicht ginge, sondern weil man dann einheitlich diese Container verwalten kann. Gerade für Docker und Co gibts ja da inzwischen eine Menge Tools. Inzwischen ist und wird das alles auch zunehmend standardisiert (OCI-Container).

Inwieweit es Sinn macht sowas wie den Firefox in Container zu packen bleibt aber trotzallem fraglich. Selbst wenn man den unabhängig vom installierten Kram haben will, kann man das gut mit statischem Linken einkriegen. Und da, wo das vielleicht nicht geht kann man auch sowas wie AppImage einsetzen, was dann auch einfach so funktioniert ohne das man Infrastruktur auf dem Rechner braucht wie bei Snappy oder Flatpak.

 

[foo_1337]

Es lässt sich ganz sicher darüber streiten, wie sinnvoll es ist, wenn die Distros plötzlich anfangen, ihre Pakete als Snap etc. auszuliefern. Das befürworte ich definitiv auch nicht. Wenn ich aber aus Entwicklersicht möchte, dass so viele User wie möglich ohne großen Aufwand in den Genuss meiner Applikation kommen, dann stelle ich den kram via Container (wenns Serverseitig ist) oder als Flatpak (Desktop) zur Verfügung. Denn bei den großen Distros kann ich oft lange bis unendlich lange warten bis meine Applikation aufgenommen wird.
Und die Maintenance von verschiedenen Distros ist sehr aufwendig. Wir bekommen das oft mit unseren eigenen Paketen zu spüren, obwohl wir nur ubuntu und rhel/centos/oel in jeweils 3 Versionen supporten. Daher läuft auch hier das meiste via Docker. Da gibt es ein (meist alpine basiertes) image und es ist egal, ob der host auf coreos, centos oder ubuntu läuft. Gebaut wird der Kram via gitlab ci, vulnerability scanning via clair auf der registry.

 

[andy_m4]

Ja. Es macht das Deployment einfacher.

Flatpak (Desktop) zur Verfügung.

Wie gesagt: AppImage geht auch und funktioniert auch da, wo kein Flatpak installiert ist. Also wenn Du viele User erreichen willst, dann nimmst Du eher das. :-)

via Container (wenns Serverseitig ist)

Als Server-Admin kennt man sich idealerweise mit der Materie aus und ist da auf Fertig-Container eher weniger angewiesen. Das ist tatsächlich sehr verbreitet aber ich bin da kein übermäßiger Fan von und baue mir dann lieber meine Container selbst.

 

[foo_1337]

Wie gesagt: AppImage geht auch und funktioniert auch da, wo kein Flatpak installiert ist. Also wenn Du viele User erreichen willst, dann nimmst Du eher das. :-)

Fair point. Man sieht leider, dass ich nicht im Desktop Bereich unterwegs bin

Als Server-Admin kennt man sich idealerweise mit der Materie aus und ist da auf Fertig-Container eher weniger angewiesen.

Naja, wenn man sich das ganze IoT Gelumpe anschaut und wer das so nutzt, wäre ich mir da nicht so sicher
Und auch ein "Profi" freut sich, wenn er "mal schnell" was ausprobieren kann. Produktiv kann er es ja dann immer noch selbst machen.

Hier meine Homekiste:

root@srv:~# docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
root@srv:~#
root@srv:~# netstat -anp
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      757/sshd: /usr/sbin
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      634280/cupsd
tcp        0      0 127.0.0.1:8088          0.0.0.0:*               LISTEN      656/influxd
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      2001/master
tcp        0      0 192.168.2.5:443         0.0.0.0:*               LISTEN      634287/apache2
tcp        0      0 192.168.2.7:443         0.0.0.0:*               LISTEN      634287/apache2
tcp        0      0 0.0.0.0:3100            0.0.0.0:*               LISTEN      1251376/ntopng
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN      9361/gravo
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      932/mariadbd
tcp        0      0 127.0.0.1:43691         0.0.0.0:*               LISTEN      1253261/containerd
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      1248985/redis-serve
tcp        0      0 127.0.0.1:8461          0.0.0.0:*               LISTEN      1259499/python3
tcp        0      0 0.0.0.0:40557           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/init
tcp        0      0 192.168.2.5:80          0.0.0.0:*               LISTEN      634287/apache2
tcp        0      0 192.168.2.7:80          0.0.0.0:*               LISTEN      634287/apache2

Es läuft nix im Container, sondern alles nativ. Aber wenn ich mal schnell $software ausprobieren möchte, kann ich schnell ein image laden, testen und wenns gefällt entscheiden, ob ich beim Container bleibe oder nicht.
https://github.com/andig/gravo ist so ein Beispiel. Es gibt keine Startscripte, nichts. Nur nen fertigen Container. Den hab ich einfach mal ausprobiert, entschlossen dass es passt und mir den Kram selbst paketiert. Warum ich hier keinen Container verwendet habe? Weil der Maintainer nix pflegt.

 

[Photon]

Snap basiert auf zwei Konzepten: Distributionsunabhängigkeit und Sandboxing.

Distributionsunabhängigkeit ist super, es spart tatsächlich Aufwand, wenn es nur ein Paket geben muss statt x Pakete für die x Distributionen, die die Software anbieten wollen. Ich bin als Hobby an der Entwicklung von Shutter beteiligt, wobei ich mangels Perl-Kenntnissen nicht an der eigentlichen Entwicklung teilnehmen kann und so Dinge tu wie Nutzern im Bugtracker zu helfen und eben mich um den Kontakt mit Paketmaintainern diverser Distros zu kümmern. Und ich kann aus Erfahrung berichten, was für ein langwieriger Prozess es ist, die Software in die Quellen einer Distro zu bekommen, das will man nicht zehnmal machen müssen. Und da ist noch nicht mal das Schreiben von Paketen im Spiel, das tun ja die Paketmaintainer, sondern rein der organisatorische Aufwand. Wenn man sich dann noch überlegt, wie viel Manpower das Erstellen und Pflegen von Paketen bindet, den man auf einen Bruchteil reduzieren könnte, falls es ein einheitliches Paketformat gäbe...

Aber dann kommt natürlich das große Aber, das Sandboxing und die damit verbundenen Probleme mit Performance, Platzverbrauch und Integration ins System, die hier ja bereits diskutiert worden sind. Ich habe genau aus diesem Grund kein einziges Programm an der "nativen" Paketverwaltung vorbei installiert, meine Systeme sind alle Snap- und Flatpak-frei.

Mir stellt sich die grundsätzliche Frage: Alle Linux-Distros nutzen denselben Kernel, die allermeisten nutzen dieselben Systemtools wie systemd, D-Bus, Polkit usw. Geschichtlich hat sich ergeben, dass die Paketverwaltung distrospezifisch ist, aber gibt es dafür irgendeinen technischen Grund? Denn das wäre doch die ideale Lösung: Eine distroagnostische Paketverwaltung ohne die technischen Probleme des Sandboxings.

 

[foo_1337]

Alle Linux-Distros nutzen denselben Kernel

mööp. Nutzen sie nicht. Zum einen ist es nicht die selbe Version und zum anderen gibt es massiv custom patches, backports etc.
Es ist mittlerweile ein nicht zu unterschätzender Aufwand herauszufinden, ob dein system von einer Lücke im Kernel betroffen ist oder nicht. Jedenfalls so lange bis ein Statement von der Distro kommt.

 

[Photon]

mööp. Nutzen sie nicht. Zum einen ist es nicht die selbe Version und zum anderen gibt es massiv custom patches, backports etc.

Klar, du hast Recht, das war zu flapsig formuliert. Was ich rüberbringen wollte, ist: Alle Distros nutzen den Linux-Kernel, nicht den BSD-Kernel, nicht den Darwin-Kernel und nicht den NT-Kernel. Dass verschiedene Distros verschiedene Versionen anbieten und den Kernel gerne mal patchen, ist mir natürlich bekannt. Aber ich denke, was ich mit diesem Beispiel illustrieren wollte, gilt dennoch: Es gibt Systemkomponenten, die distributionsunabhängig sind, und ich frage mich, warum die Paketverwaltung nicht zu ihnen gehört.

 

[andy_m4]

Naja, wenn man sich das ganze IoT Gelumpe anschaut und wer das so nutzt, wäre ich mir da nicht so sicher

Ja. Da hast Du natürlich recht.
Aber ich wollte nicht gerade die untere Grenze als üblich annehmen. Ich versuche mir meinen Optimismus dadurch zu erhalten, das ich mir einrede das ein signifikanter Anteil der Leute da draußen so ungefähr weiß, was er tut. :-)

Und auch ein "Profi" freut sich, wenn er "mal schnell" was ausprobieren kann.

Ja. Das ist sicher ein valider Punkt.

Distributionsunabhängigkeit ist super, es spart tatsächlich Aufwand

Naja. So richtig unabhängig ist es dann doch nicht. Es ist zwar (inzwischen) in vielen Distributionen verfügbar. Aber es gibt quasi nur einen Snap-Store und das ist der von Canonical.

Da ist mir AppImage im Zweifel lieber. Das kann der Software-Autor selbst bereitstellen und muss es nicht in irgendein Repository einstellen. Und es funktioniert halt immer. Egal ob der Anwender nur Snappy hat oder nicht. DAS nenne ich dann eher distributionsunabhängig. :-)

falls es ein einheitliches Paketformat gäbe...

Mit dem einheitlichen Paketformat ist es ja nicht getan. Das ist quasi noch das Wenigste (auch wenn das natürlich ne Grundvoraussetzung wäre). Aber was in den Paketen drin ist und welche Versionsstände und Patches bestimmen die Distribution selbst. Deshalb ist es schwierig z.B. auf Debian ein Paket aus nem ubuntu-Repository zu installieren, obwohl die beide das gleiche Format haben (und beide Repositories sogar durch ihre Verwandschaft noch relativ ähnlich sind).

Geschichtlich hat sich ergeben, dass die Paketverwaltung distrospezifisch ist, aber gibt es dafür irgendeinen technischen Grund?

Eher historisch gewachsen. :-)
Wie gesagt. Man muss da differenzieren zwischen Paketsys (also DEB, RPM und was es da sonst noch so alles gibt) und der Organisation der Pakete ansich.
Das man sich auf ein Paketformat einigt, kriegt man vielleicht noch so eben hin. Aber den Rest, da wehe ich eher schwarz. Überhaupt tut man sich ja mit Standardisierungen gerne mal schwer. Sieht man ja sehr schön an der Linux-Standard-Base die heutzutage quasi tot ist.

Und jede Distriubtion hat nun mal ne andere Vorstellung davon, wie Pakete vorkonfiguriert sein sollen, was da drin sein soll. Welche Version man nehmen will usw.
Das ist völlig aussichtslos, das man sich da auf einen gemeinsamen Standard einigt.

Aber dann kommt natürlich das große Aber, das Sandboxing und die damit verbundenen Probleme mit Performance, Platzverbrauch und Integration ins System

Wobei sich zumindest die Integration noch bewerkstelligen ließe. Auch der Performance-Impact ist minimal, wenn man es richtig macht.

ohne die technischen Probleme des Sandboxings

Sandboxing ansich ist gar nicht so verkehrt (wenn man es richtig macht). Normal ist es so, das mein Videoplayer Zugriff auf meine Textdateien hat. Der braucht die nicht und kann auch gar nichts damit anfangen. Allerdings wenn der mal exploitet wird, kann der Schadcode eben nicht nur meine Videodateien killen, sondern auch meine Textdateien.
Hier einen Mechanismus zu haben der das verhindert ist also keinesfalls verkehrt.
Sandboxing ist auch praktisch, wenn man mal eben nur ein Programm ausprobieren will ohne das das Dateien vom System lesen kann oder seine Konfigs und sonstigen Dateien irgendwo verteilt.

Es gibt also durchaus sinnvolle Anwendungsfälle. Aber wie gesagt. Man muss es halbwegs vernünftig implementieren und konfigurieren.

 

[Donnerkind]

Das ist wieder ein gutes Beispiel wie es um die Linux-Community steht... bitte nicht falsch verstehen, ich bin großer Linux Fan aber da werden einem zwei geniale Technologien in die Hand gelegt und was wird gemacht? Es wird um Speicherplatz diskutiert im Jahre 2022 wo man mit Handys mit teilweise 1TB Speicherplatz rumläuft

Naja, es ist für uns Puritaner ein weiterer Backstein in der "Wir werfen noch mehr Komplexität auf die Hardware, denn Leistung ist ja da"-Mauer. Als SSDs noch nicht verbreitet waren, ist die Bootzeit von Windows & Co kaum gesunken, trotz immer stärkerer CPUs (und auch Festplatten). Eher im Gegenthum.

Das Argument ist natürlich etwas philosophisch, aber "leider" ist es heutzutage billiger, Software mit Framework-Baukästen zu bauen, die dann einen riesigen Ballast mitbringen als ordentlich Gehirnschmalz reinzuschmieren und zu optimieren, damit möglichst wenige Zyklen verbraucht werden. (Den einen oder anderen Nutzen streite ich natürlich nicht ab, klar sind 3D-Effekte im Desktop schön anzugucken.)