Quel est le rapport entre Snappy et Nix et Guix?

J'ai cherché une comparaison mais j'ai trouvé non et je ne suis pas assez bien informé pour le faire moi-même en ce moment.

Tous fournissent des mises à jour transactionnelles, mais différents niveaux de confinement.

• Snappy compile statiquement dans les bibliothèques pour fournir plusieurs versions des dépendances binaires. Il déclare les services fournis (et nécessaires?) En tant que métadonnées. Le package est fourni en une seule image?
• Nix traite de la liaison dynamique pour fournir plusieurs versions de dépendances binaires? Il déclare les services fournis et nécessaires en tant que métadonnées. Le package est fourni via un référentiel traitant des dépendances.
• Guix est comme Nix, mais dispose d'une intégration GNU.

Une comparaison plus approfondie entre Nix et Guix est donnée par Sander van der Burg , que je n'ai pas étudié en détail. Je suppose que quelqu'un chez Canonical a fait une analyse des solutions existantes. Il existe d'autres systèmes de déploiement basés sur des images, comme CoreOS m'a-t-on dit.

Alors, comment Snappy Ubuntu est-il lié à Nix et Guix? Quelles sont les principales différences?

Récemment, j'ai moi-même fait une évaluation. Je suis en fait un contributeur Nix / NixOS et ancien chercheur intéressé par la technologie de déploiement.

J'ai essayé de m'en tenir aux faits autant que possible, mais il est probablement impossible de rester totalement impartial. Pour résumer mes conclusions:

• Les deux approches stockent les packages de manière isolée . Snappy stocke les applications et les cadres dans des dossiers en utilisant la convention de nom suivante /app/name/version.vendor:, tandis que Nix utilise /nix/store/hash-name-version.

  La convention de dénomination de Nix est plus puissante, car elle utilise des préfixes de hachage dérivés de toutes les dépendances de génération . Avec Nix, vous pouvez facilement faire des distinctions entre n'importe quelle variante d'un package et les stocker côte à côte. Tout changement (par exemple, procédure de construction différente, mise à niveau de la bibliothèque, mise à niveau du compilateur) génère un nouveau hachage permettant de stocker n'importe quelle variante possible les unes à côté des autres.

• Pour permettre à un paquet pour trouver ses dépendances, Nix les lie statiquement à un exécutable (par exemple en modifiant le RPATHd'un binaire ELF) ou en les enveloppant dans des scripts qui définissent les variables d'environnement appropriées (par exemple CLASSPATH, PYTHONPATH, PERL5LIB, etc.).

  Snappy compose des conteneurs dans lesquels les exécutables peuvent trouver leurs dépendances dans leurs emplacements FHS communs, tels que /libet/bin

  Cependant, Nix prend également en charge l'approche de conteneur de Snappy, mais celle-ci n'est utilisée que dans de très rares cas. Le package Nix le plus important utilisant une approche conteneurisée est Steam dans NixOS, car Steam est un outil de déploiement lui-même avec des propriétés conflictuelles.

• Le Snappy Ubuntu Core utilise un schéma de partitionnement dit "A / B" pour mettre à niveau (et restaurer) le système de base. Il ne prend en charge qu'un nombre limité de versions (généralement deux) à la fois.

  En revanche, NixOS (la distribution Linux basée sur Nix) compose également le système de base à partir des packages Nix dans le magasin Nix et est beaucoup plus puissant. Vous pouvez revenir à n'importe quelle configuration précédente qui n'a pas encore été récupérée. De plus, des packages système similaires entre générations peuvent être partagés.

• Les deux outils prennent en charge les installations utilisateur non privilégiées . Cependant, Snappy stocke tous les fichiers dans le répertoire personnel de l'utilisateur. Si deux utilisateurs arrivent à installer le même package, ils sont installés deux fois sur le système.

  En revanche, les packages Nix permettent également aux utilisateurs ordinaires d'installer des packages dans le magasin Nix central afin que des packages identiques puissent être partagés entre les utilisateurs. En partie à cause de la convention de dénomination (à l'aide du hachage), cela peut être fait de manière sécurisée.

• Snappy limite le comportement d'exécution des packages prêts à l'emploi alors que Nix ne le fait pas

• Snappy ne semble pas aider les utilisateurs à construire des packages à partir du code source. Nix a cependant un DSL permettant aux gens de le faire assez facilement et d'installer automatiquement toutes les dépendances de compilation (compilateurs, outils de compilation, bibliothèques, etc.) en cas de besoin

• Snappy ne prend guère en charge la modularisation et la réutilisation . Dans les packages d'exemple, toutes les dépendances de bibliothèque sont regroupées statiquement et consomment beaucoup plus d'espace disque et de RAM. De plus, la documentation ne semble pas fournir de fonctionnalités autres que des frameworks. Cependant, les cadres ne sont pas destinés à être réutilisés selon la documentation

  Avec les packages de modularisation Nix et la gestion sécurisée des dépendances sont quelques-unes de ses principales caractéristiques.

Le billet de blog complet peut être trouvé ici: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

J'espère que vous le trouverez intéressant à lire et qu'il y a peut-être des choses auxquelles vous devriez réfléchir.