Quel est le rapport entre Snappy et Nix et Guix?

22

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?

charge utile
la source
1
Vous nous demandez donc de lire ce que vous ne voulez pas lire ??? "Une comparaison plus approfondie entre Nix et Guix est donnée par Sander van der Burg, que je n'ai pas lu" ... "comment Snappy Ubuntu se rapporte-t-il à Nix et Guix? Quelles sont les différences majeures?"
don.joey
Je posais la question ici, car je pense qu'une de ces communautés y a déjà pensé ou connaît un article que je n'ai pas trouvé. Je suis juste tombé sur Snappy aujourd'hui, j'ai lu à ce sujet, mais je ne me considère pas suffisamment informé sur Snappy pour décider comment il se positionne entre ces gestionnaires de packages matures. Les articles Snappy ne mentionnent pas du tout ces systèmes et je trouve triste de garder le silence sur d'autres logiciels libres traitant de problèmes similaires. De plus, l'article de blog lié ne nomme pas Snappy et n'est pas une personne impliquée dans Snappy.
charge utile
1
C'est suffisant. Le downvote est revenu.
don.joey
Snappy ne compile pas statiquement dans les bibliothèques. Il vous permet de stocker des bibliothèques dans le même dossier que votre binaire afin que vous n'ayez pas à dépendre des bibliothèques système, mais il vous permet également de compter sur les bibliothèques système si vous n'avez pas besoin d'un package indépendant de la version. Snappy ne supprime donc pas les avantages d'une version LTS stable. Cela rend tout simplement beaucoup plus simple.
Jo-Erlend Schinstad

Réponses:

29

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.

Sander van der Burg
la source
3
Bien que votre réponse soit correcte à 100%, elle peut également devenir inutile à 100% si ce lien est déplacé, modifié, fusionné dans un autre ou si le site principal disparaît simplement ... :-( Par conséquent, veuillez modifier votre réponse et copier les informations pertinentes. étapes du lien dans votre réponse, garantissant ainsi votre réponse pour 100% de la durée de vie de ce site! ;-) Vous pouvez toujours laisser le lien en bas de votre réponse comme source pour votre matériel ...
Fabby
3
Ok, je viens de réviser ma réponse. J'espère que cela aide!
Sander van der Burg