Alles anzeigenKommt am Ende darauf an wie die Updates organisiert sind. Das Problem bei Updates bei klassischen DEB oder RPM Paketen ist das es ein Rollback kaum möglich ist. Ausser du nutzt ein spezielles Dateisystem wie Btrfs - was die dann aber in der Dateisystem-Auswahl einschränkt.
Oder du nutzt sowas wie Timeshift, das aber durch komplette "Clones" die angelegt werden Zeit und Ressourcenintensiv ist - und man manuell konfigurieren muss und mit den meisten Paketmanagern nicht direkt kompatibel ist - im Sinne von "sudo dnf update" (macht automatisch ein Timeshift Snapshot vorher).
Snaps kannst du aber jederzeit problemlos auf vorherige Versionen zurückrollen. Snap selbst behält immer die letzten 3 Versionen auf der Platte (ist eine Standardeinstellung, kann man in der Config aber erhöhen oder kleiner machen) - somit kannst du einzelne Snap Pakete problemlos zurückrollen.
Codesudo snap revert firefoxinstalliert dir automatisch die vorherige Version von Firefox. Mit
Codesnap list firefox --allwerden dir alle verfügbaren Snap Rollbacks angezeigt und du kannst direkt eines auswählen:
Anhand der Revisionsnummer kannst du ein gezieltes Rollback auf eine gewünschte Version machen (In meiner VM ist Snap so konfiguriert das nur eine vorheriger Version statt drei zwischengespeichert wird).
Codesudo snap revert firefox --revision 1540Daher mit dieser Rollback Funktion sind automatische Updates eigentlich kein Problem. Sollte da mal was schiefgehen kann man ja einfach zurückrollen.
Es gibt die unterschiedlichsten Gründe Linux zu verwenden. Und es gibt sicher ein Anwender-Teil die sich viel aus Anpassung und Customisierung machen. Es gibt aber auch ein sehr sehr grosser Teil an Menschen denen ist sowas völlig egal.
Ich denke ab dem Zeitpunkt wo Linux in beruflichem Umfeld eingesetzt wird - spielt Anpassbarkeit absolut keine Rolle mehr. Bei uns im Büro ändern unsere Mitarbeiter nicht mal das Hintergrundbild ihres Windows Rechners (Mein Mac hat übrigens auch das Default Hintergrundbild und keine Anpassungen).
Sind halt Arbeitsgeräte, man kommt am Morgen stellt die Dinger an, öffnet seine Programme arbeitet damit und stellt sie dann irgendwann wieder aus.
Und gerade in diesem Umfeld ist Anpassbarkeit von irgendwelchen Ordner-Icons oder zusätzlichen Leisten oder Themes einfach nicht relevant.
Und wenn man bedenkt welche 3 grossen Player an "Immutable Distributionen" arbeiten macht das ganze wieder Sinn. Es sind Red Hat (bei Fedora), Suse mit MicroOS und Ubuntu mit CoreOS (bzw einer bald vollwertigen Distribution). Das heisst im Bereich "Immutable" sind die Distributionen aktiv die ihr Produkt im "professionellen/beruflichen" Umfeld vermarkten und verkaufen - und dort macht das definitiv Sinn.
Dass der "Bastler" der sein Linux bis in die kleinste Stufe anpassen, konfigurieren und verändern will damit wenig anfangen kann ist klar. Die Person legt in der Regel aber auch nicht viel Wert auf Gnome (was bei Fedora (Red Hat), Suse und Ubuntu aber der absolute Kern Desktop ist und auch die weitreichendsten "Immutable" Tests gemacht werden.
Aber aus diesem Grund gibt es ja verschiedene Distributionen. Wenn das nichts für dich ist - ist das voll okay und es wird sicher auch in Zukunft noch Distributionen geben die nicht ummutable sind.
Zu den Vorteilen ansich:
Mit Immutable hast du halt eine saubere Trennung zwischen "System" und "Apps". Ähnlich wie auf Smartphones - wo du keinen Zugriff auf Systemdateien oder sowas hast. Android und iPhoneOS aktualisieren sich ja auch unabhängig von den Apps.
Die Apps laufen auf einer eigenen Ebene - bei Fedora/ RedHat als Flatpak bei Ubuntu als Snaps. Hat halt den Vorteil das du in Firmenumgebungen das Grundsystem einmal einrichten kannst (mit Mounting von Netzlaufwerken, etc) - Du dem User kein Admin Passwort geben musst. Er aber dennoch Software "frei" aus dem App Store installieren kann ohne das irgendwas am System kaputt gehen kann.
Das führt am Ende zu geringerer interner IT-Komplexität, weniger Ausfällen (z.b. bei fehlgeschlagenem Update da man nicht das Problem sofort lösen muss, sondern einfach zurückrollen und der Mitarbeiter dann direkt weiterarbeiten kann). Das ganze fördert wiederum die Effizienz in der Arbeitsleistung was immer was gutes ist.
Durch saubere Trennung von "System und User Ebene" und dem erzwungenen Sandboxing von Apps hast du auch eine höhere Sicherheit, vor z.b. Verschlüsselungstrojaner, etc.
Selbst wenn der Mitarbeiter in einer E-Mail auf einen komischen Link klickt - ist am Ende am schlimmsten Fall der Browser am Arsch (den man zurückrollen kann). Da der Browser Dank der Sandbox aber keinen Zugriff auf irgendwelche Dateien im Dateisystem oder Netzlaufwerken hat konnte keinen Schaden wie z.b. Verschlüsselung, etc angerichtet werden.
Jein der allergrösste Teil von Snap ist freie Software. Das betrifft den "Snap Store" (damit meine ich die Software Snap Store wo man seine Snaps suchen, installieren und verwalten kann).
Das Snap-Paketsystem an sich ist ebenfalls komplett offen.
Snapcraft (die Software zum erstellen von Snap-Paketen) ist ebenfalls GPL.
Snapd der Daemon auf deinem Gerät, dass die Snaps herunterlädt, zurückrollen, aktualisiert, etc ist ebenfalls OpenSource.
Das einzige was nicht OpenSource ist, ist der Snap Server. also der Server von wo aus die Pakete heruntergeladen werden. Ich verstehe auch das das bei Canonical eine extrem tiefe Priorität hat. Ich denke Canonical will verhindern das damit das Lunchpad Desaster von 2008/2009 wiederholt wird.
Das mit den zurückrollbaren Snaps wusste ich noch nicht...
Ein Pluspunkt für Snap