Quel est le lien 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 pour le moment.
Tous fournissent des mises à jour transactionnelles, mais différents niveaux de confinement.
- Snappy compile statiquement dans les bibliothèques pour fournir plusieurs versions de dépendances binaires. Il déclare les services fournis (et nécessaires?) Sous forme de métadonnées. Le paquet est fourni comme une seule image?
- Nix traite de la liaison dynamique pour fournir plusieurs versions de dépendances binaires? Il déclare que les services fournis et nécessaires sont des métadonnées. Le package est fourni via un référentiel traitant des dépendances.
- Guix est comme Nix, mais comporte GNU intégration.
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 analysé les solutions existantes. Il existe d'autres systèmes de déploiement basés sur des images, comme CoreOS, m'a-t-on dit.
Alors, quel est le lien entre Snappy Ubuntu et Nix et Guix? Quelles sont les principales différences?
Récemment, j'ai fait une évaluation moi-même. Je suis en fait un contributeur Nix/NixOS et un ancien chercheur intéressé par la technologie de déploiement.
J'ai essayé de m'en tenir le plus possible aux faits, mais il est probablement impossible de rester totalement impartial. Pour résumer mes conclusions:
Les deux approches stockent les paquets dans isolement . Snappy stocke les applications et les frameworks dans des dossiers en utilisant la convention de nom suivante:
/app/name/version.vendor, alors que Nix utilise/nix/store/hash-name-version.La convention de nommage de Nix est plus puissante, car elle utilise des préfixes de hachage dérivés de toutes les dépendances de la compilation . Avec Nix, vous pouvez facilement distinguer toutes les variantes d’un package et les stocker les unes à côté des autres. Toute modification (procédure de construction différente, mise à niveau de bibliothèque, mise à niveau de compilateur, par exemple) génère un nouveau hachage permettant de stocker toutes les variantes possibles les unes à côté des autres.
Pour permettre à un paquet de trouver ses dépendances, Nix les lie statiquement à un exécutable (par exemple, en modifiant le
RPATHd'un binaire ELF) ou en les encapsulant. les scripts qui définissent les variables d'environnement appropriées (par exemple,CLASSPATHname__,PYTHONPATHname__,Perl5LIB, etc.).Snappy compose des conteneurs dans lesquels les exécutables peuvent trouver leurs dépendances dans leurs emplacements FHS communs, tels que
/libet/binCependant, Nix prend également en charge l’approche conteneur de Snappy, mais elle n’est utilisée que dans de très rares cas. Le package Nix le plus répandu utilisant une approche conteneurisée est Steam dans NixOS, car Steam est un outil de déploiement doté de propriétés en conflit.
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 le système de base à partir des packages Nix du magasin Nix et est beaucoup plus puissant. Vous pouvez revenir à toute configuration précédente qui n'a pas encore été nettoyée. De plus, des packages système similaires entre générations peuvent être partagés.
Les deux outils prennent en charge les installations d'utilisateurs non privilégiés . Cependant, Snappy stocke tous les fichiers dans le répertoire de base de l'utilisateur. S'il arrive que deux utilisateurs installent 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 central Nix afin que des packages identiques puissent être partagés entre les utilisateurs. En partie à cause de la convention de dénomination (utilisant le hachage), cela peut être fait de manière sécurisée.
Snappy restreint le comportement à l'exécution des packages prêts à l'emploi, alors que Nix ne le fait pas.
Snappy ne semble pas aider les utilisateurs à construire des paquets à partir du code source. Cependant, Nix dispose d’une DSL permettant aux utilisateurs de le faire assez facilement et installe automatiquement toutes les dépendances de compilation (compilateurs, outils de compilation, bibliothèques, etc.) en cas de besoin.
Snappy supporte difficilement la modularisation et la réutilisation . Dans les exemples de packages, toutes les dépendances de bibliothèque sont regroupées de manière statique, consommant beaucoup plus d'espace disque et de RAM. De plus, la documentation ne semble pas fournir d’installations autres que des cadres. Cependant, les frameworks ne sont pas destinés à être réutilisés selon la documentation
La modularisation des packages et la gestion sécurisée des dépendances sont quelques-unes de ses principales caractéristiques.
Le blog complet peut être trouvé ici: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html
J'espère que vous trouverez cela intéressant à lire et peut-être y a-t-il des éléments qui méritent que vous y réfléchissiez.