Pummeluff schrieb:
Wir nutzen bei uns Ubuntu-Server mit zentralen Homeverzeichnissen, die per NFS eingebunden werden. Die Verzeichnisse liegen dabei nicht in /home/$User sondern /home/subirgendwas/$User. Snap nutzt dabei das Sicherheitskonzept von Apparmor, selbst wenn man auf dem System kein Apparmor nutzt (wir machen alles über iptables). Und dann tritt
dieses Problem auf:
Dann passt Snap eben nicht in euren Use-Case. Ist ja kein Weltuntergang, ist ja nicht so das man Software über 100 andere Wege installieren könnte.
Es ging ja hier auch eher um den Use Case: Ein Rechner und Benutzer und Installation von Software -> ich bezweifle das in Unternehmen Spotify als Client an die User ausgerollt wird
Pummeluff schrieb:
Die Lösung bestand dann darin, Snap vom System zu verbannen und Firefox über das
Mozilla-PPA zu installieren. Seitdem läuft's. Bei Chromium haben wir kein offizielles PPA gefunden. Also stellen wir keinen Chromium zur Verfügung.
In einem Unternehmen könnte man ja auch die Software die man benötigt über ein eigenes Repository zur Verfügung stellen.
Pummeluff schrieb:
Dazu kommt noch bei Snap, dass beim Start einer über Snap installierten Anwendung ein Loopback-Device erzeugt wird. Nutzt man mehrere Snap-Anwendungen, dann wird die Dateisystemtabelle (df) arg unübersichtlich.
"df" hat wie so ziemlich jedes Tool Manpages mit -x kann man Dinge in der Option nicht anzeigen lassen:
Wenn man das permanent will baut man sich eben ein Alias:
Bash:
alias df='df -x"squashfs"'
Pummeluff schrieb:
Bisher hatten wir mit Snap nur Probleme. Vorteile konnte ich noch nicht erkennen.
Wie gesagt, vielleicht sind Snaps für euren Use Case völlig falsch. Deswegen zu behaupten das es keine Vorteile gibt ist halt schwierig.
Die Sandbox ist definitiv ein objektiver Vorteil.
Das man Software nun direkt vom Hersteller bekommt und die Distributionen die nicht kaputt patchen (man denke an Linux Mint, die die Google Suche aus Firefox rausgepatcht haben 🙄) ist je nach Betrachtungsweise ein Vor- oder Nachteil.
Das man jedes Update eines Snap Pakets easy zurück rollen kann - oder man z.b. ganz bewusst eine "alte" Version installieren kann, wenn man die braucht sind alles Vorteile die du mit klassischen Paket Managern nicht hast.
Kann sein, dass du das alles nicht brauchst - und das ist auch okay - aber Vorteile sind es definitiv.
Pummeluff schrieb:
Etwas positiver beurteile ich Flatpack. Das hat seine Berechtigung, wenn bestimmt Pakete noch nicht über den Paketmanager der Distribution bereitgestellt werden.
Soll ich jetzt aufzählen was mir alles an Flatpak missfällt?
Man kann nicht einfach "gimp" ausführen wenn es als Flatpak installiert ist, sondern muss immer dieses dämliche "flatpak run" eingeben und dann den kryptischen Programmnamen googeln gehen für Gimp wäre das:
Bash:
flatpak run org.gimp.GIMP
Flatpak wurde designt, das man zwingend eine Desktop Session laufen haben muss, damit die Anwendungen überhaupt laufen. Im Serverbetrieb ist es kaum nutzbar.
All diese und auch weitere Dinge werden aber 99% der Nutzer kaum interessieren, weil es für Sie eben kein Problem darstellt. Daher kann ich nun auch ich sehe in Flatpak wegen diesen Punkte keine Vorteile. Richtiger formuliert ist aber Flatpaks sind für meinen Use-Case nicht die richtige Wahl -> das bedeutet aber nicht, dass Flatpaks keine objektiven Vorteile (wie z.b. Snadbox, etc) haben.
Pummeluff schrieb:
Mehrere Paketmanager auf einem System birgt potentielle Konflikte.
Nicht bei Snaps und Flatpaks.
Sowohl Snaps wie Flatpaks sind im Grunde Container-Technologien. Alles was du brauchst liefern die mit. Sie laufen beide ausserhalb vom "bin" Verzeichnis.
Weder kenne ich Berichte darüber, das Snaps oder Flatpaks in irgendwelche Systeminternas eingegriffen und Probleme verursacht hätten.
Ganz generell kann man hier sagen, dass es absolut kein Problem darstellt sowohl Pakete vom Paketmanager seiner Distribution, Snaps und Flatpaks gleichzeitig und Parallel zu nutzen.
Im Gegensatz zu z.b. NPM, das Dinge wenn man sie global installiert, gerne mal ins "bin" Verzeichnis schreibt und bestehende Software die über APT oder DNF dort parkiert wurde überschreiben kann.
Krakadil schrieb:
Ich will Spotify herunterladen, gehe auf die Homepage von Spotify und finde dort was ich suche (.exe, APK, deb, Snap) aber eben kein Flatpak. Diese hat also irgendjemand bereitsgestellt und nicht Spotify selbst.
Die Frage ist warum genau das ein Problem ist. Snaps und Flatpaks sind noch relativ neu in der Linux Welt. Davor war es +/- 25 Jahre völlig normal Software zu installieren die nicht vom Hersteller selbst kommt. Wenn du in Fedora mit "sudo dnf install firefox" Firefox installierst, bekommst du kein Paket von Mozilla.
Du bekommst ein Paket von Fedora. Fedora nimmt den Quellcode von Firefox, macht sogar noch eigene Patches rein, baut dan ein eigenes Programm daraus und liefert dir das. Das gleiche gilt für Gimp, Libreoffice, Slype, etc.
Daher unter Linux war und ist es eigentlich immer völlig normal, dass du nicht Software direkt vom Hersteller sondern über einen dritten beziehst.
Mit Snaps und Flatpaks haben die Hersteller nun erstmals direkt die Möglichkeit Software unkompliziert für Linux anzubieten. Sie erscheinen sogar direkt in den Software Stores der Distributionen (Gnome-Software) das ist relativ neu -> und aus meiner Sicht auch ein Vorteil.
Wenn wir uns nunmal ansehen was Flathub beim Spotify Paket genau hinschriebt:
Dann sehen wir, das alles was hier steht stimmt.
Die Entwickler (Developer) vom Spotify Paket ist "Spotify". Du bekommst wenn du das Flatpak installierst 1:1 das Snap Paket, dass von Spotify bereitgestellt wurde.
Die Publisher (das sind die, die das Flatpak auf Flathub veröffentlich haben) bei denen steht "see Details" wenn wird dort drauf klicken. Kommst du auf eine GitHub Seite von Flathub aus der ersichtlich ist, dass es sich um ein Paket handelt deren Veröffentlichung von der Flathub Community gepflegt wird.
Daher das worüber du dich beklagst wird dir hier transparent mitgeteilt...
garfield121 schrieb:
Oder Irgendjemand anderes, sozusagen inoffiziell?
Jeder kann auf Flathub ein Paket veröffentlichen, oder eigene Flatpak Repositorys wie z.b. Flathub erstellen.