In welcher Beziehung steht Snappy zu Nix und Guix?

Ich suchte nach einem Vergleich, fand ihn aber nicht und bin nicht gut genug informiert, um ihn jetzt selbst zu machen.

Alle bieten Transaktionsaktualisierungen, aber unterschiedliche Sicherheitsstufen.

• Snappy wird statisch in Bibliotheken kompiliert, um mehrere Versionen von binären Abhängigkeiten bereitzustellen. Sie deklariert bereitgestellte (und benötigte?) Dienste als Metadaten. Das Paket wird als Einzelbild geliefert?
• Nix befasst sich mit dynamischer Verknüpfung, um mehrere Versionen von binären Abhängigkeiten bereitzustellen? Es deklariert bereitgestellte und benötigte Dienste als Metadaten. Das Paket wird über ein Repository bereitgestellt, das sich mit Abhängigkeiten befasst.
• Guix ist wie Nix, bietet jedoch eine GNU-Integration.

Einen tieferen Vergleich zwischen Nix und Guix gibt Sander van der Burg , den ich nicht im Detail studiert habe. Ich würde vermuten, dass jemand bei Canonical eine Analyse der vorhandenen Lösungen durchgeführt hat. Es gibt andere Bereitstellungssysteme, die auf Images basieren, wie CoreOS, wurde mir gesagt.

Wie verhält sich Snappy Ubuntu zu Nix und Guix? Was sind die Hauptunterschiede?

Kürzlich habe ich selbst eine Bewertung vorgenommen. Eigentlich bin ich ein Nix / NixOS-Mitarbeiter und ehemaliger Forscher, der sich für Bereitstellungstechnologie interessiert.

Ich habe versucht, mich so weit wie möglich an die Fakten zu halten, aber es ist wahrscheinlich unmöglich, völlig unvoreingenommen zu bleiben. Um meine Ergebnisse zusammenzufassen:

• Beide Ansätze speichern Pakete isoliert . Snappy speichert Apps und Frameworks in Ordnern mit der folgenden Namenskonvention:, /app/name/version.vendorwährend Nix verwendet /nix/store/hash-name-version.

  Die Namenskonvention von Nix ist leistungsfähiger, da Hash-Präfixe verwendet werden, die von allen Abhängigkeiten bei der Erstellung abgeleitet sind . Mit Nix können Sie leicht zwischen verschiedenen Varianten eines Pakets unterscheiden und diese nebeneinander aufbewahren. Jede Änderung (z. B. unterschiedliche Erstellungsprozeduren, Bibliotheks-Upgrades, Compiler-Upgrades) führt zu einem neuen Hash, der es ermöglicht, alle möglichen Varianten nebeneinander zu speichern.

• Damit ein Paket seine Abhängigkeiten zu finden, bindet Nichts sie statisch auf eine ausführbare Datei (zB durch die Modifizierung RPATHvon ELF - Binaries) oder indem man sie in Skripten Verpackung, die die entsprechenden Umgebungsvariablen (zB CLASSPATH, PYTHONPATH, PERL5LIB, etc.).

  Snappy erstellt Container, in denen ausführbare Dateien ihre Abhängigkeiten an ihren gemeinsamen FHS-Speicherorten finden können, z. B. /libund/bin

  Nix unterstützt jedoch auch den Container-Ansatz von Snappy, der jedoch nur in sehr seltenen Fällen verwendet wird. Das bekannteste Nix-Paket, das einen containerisierten Ansatz verwendet, ist Steam in NixOS, da Steam selbst ein Bereitstellungstool mit widersprüchlichen Eigenschaften ist.

• Der Snappy Ubuntu Core verwendet ein sogenanntes "A / B" -Partitionsschema, um das Basissystem zu aktualisieren (und zurückzusetzen). Derzeit wird nur eine begrenzte Anzahl von Versionen (normalerweise zwei) unterstützt.

  Im Gegensatz dazu NixOS (die-Nix - basierte Linux - Distribution) komponiert das Basissystem aus Nix Paketen im Nichts Speicher auch und ist viel mächtiger. Sie können zu jeder vorherigen Konfiguration zurückkehren, bei der noch kein Datenmüll gesammelt wurde. Darüber hinaus können ähnliche Systempakete zwischen Generationen geteilt werden.

• Beide Tools unterstützen nicht privilegierte Benutzerinstallationen . Snappy speichert jedoch alle Dateien im Home-Verzeichnis des Benutzers. Wenn zwei Benutzer das gleiche Paket installieren, werden sie zweimal auf dem System installiert.

  Im Gegensatz dazu können mit Nix-Paketen auch normale Benutzer Pakete im zentralen Nix-Speicher installieren, sodass Benutzer identische Pakete gemeinsam nutzen können. Teilweise aufgrund der Namenskonvention (unter Verwendung von Hashing) kann dies auf sichere Weise erfolgen.

• Snappy schränkt das Laufzeitverhalten von Paketen ab Werk ein, Nix hingegen nicht

• Snappy scheint nicht zu helfen Benutzer zu konstruieren Pakete aus dem Quellcode. Nix hat jedoch ein DSL, mit dem die Leute dies ganz einfach tun und bei Bedarf automatisch alle Abhängigkeiten zur Build-Zeit (Compiler, Build-Tools, Bibliotheken usw.) installieren können

• Snappy unterstützt kaum Modularisierung und Wiederverwendung . In den Beispielpaketen werden alle Bibliotheksabhängigkeiten statisch gebündelt, wodurch viel mehr Speicherplatz und RAM verbraucht werden. Darüber hinaus scheint die Dokumentation keine anderen Möglichkeiten als Frameworks zu bieten. Frameworks sind jedoch nicht für die Wiederverwendung gemäß der Dokumentation vorgesehen

  Mit Nix sind die Modularisierung von Paketen und das sichere Verwalten von Abhängigkeiten einige der Hauptmerkmale.

Den vollständigen Blog-Beitrag finden Sie hier: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Hoffentlich finden Sie es interessant zu lesen und vielleicht gibt es einige Dinge, über die Sie nachdenken sollten.