¿Cómo se relaciona Snappy con Nix y Guix?

Busqué una comparación pero encontré que no y no estoy lo suficientemente bien informado como para hacerlo yo mismo ahora.

Todos ellos proporcionan actualizaciones transaccionales, pero diferentes niveles de contención.

• Snappy compila estáticamente en bibliotecas para proporcionar múltiples versiones de dependencias binarias. Declara los servicios proporcionados (¿y necesarios?) Como metadatos. El paquete se proporciona como una sola imagen?
• ¿Nix trata con enlaces dinámicos para proporcionar múltiples versiones de dependencias binarias? Declara los servicios prestados y necesarios como metadatos. El paquete se proporciona a través de un repositorio que se ocupa de las dependencias.
• Guix es como Nix, pero presenta integración con GNU.

Sander van der Burg ofrece una comparación más profunda entre Nix y Guix , que no estudié en detalle. Supongo que alguien en Canonical ha hecho un análisis de las soluciones existentes. Hay otros sistemas de implementación basados ​​en imágenes, como CoreOS, me dijeron.

Entonces, ¿cómo se relaciona Snappy Ubuntu con Nix y Guix? ¿Cuáles son las principales diferencias?

Recientemente, hice una evaluación yo mismo. En realidad, soy un colaborador de Nix / NixOS, y ex investigador interesado en la tecnología de implementación.

He tratado de apegarme a los hechos tanto como sea posible, pero probablemente sea imposible permanecer completamente imparcial. Para resumir mis hallazgos:

• Ambos enfoques almacenan paquetes de forma aislada . Snappy almacena aplicaciones y marcos en carpetas usando la siguiente convención de nombres: /app/name/version.vendormientras que Nix usa /nix/store/hash-name-version.

  La convención de nomenclatura de Nix es más poderosa porque usa prefijos hash que se derivan de todas las dependencias de tiempo de compilación . Con Nix, puede distinguir fácilmente cualquier variante de un paquete y almacenarlas una al lado de la otra. Cualquier cambio (por ejemplo, procedimiento de compilación diferente, actualización de la biblioteca, actualización del compilador) produce un nuevo hash que hace posible almacenar cualquier variante posible una al lado de la otra.

• Para permitir que un paquete para encontrar sus dependencias, Nix los une estáticamente a un archivo ejecutable (por ejemplo, mediante la modificación de la RPATHde un binario ELF) o envolviéndolos en scripts que definen las variables de entorno apropiadas (por ejemplo CLASSPATH, PYTHONPATH, PERL5LIB, etc.).

  Snappy compone contenedores en los que los ejecutables pueden encontrar sus dependencias en sus ubicaciones comunes de FHS, como /liby/bin

  Sin embargo, Nix también admite el enfoque de contenedor de Snappy, pero esto solo se usa en casos muy raros. El paquete Nix más destacado que utiliza un enfoque en contenedores es Steam en NixOS, porque Steam es una herramienta de implementación en sí misma con propiedades en conflicto.

• Snappy Ubuntu Core utiliza un esquema de partición llamado "A / B" para actualizar (y revertir) el sistema base. Solo admite un número limitado de versiones (generalmente dos) en ese momento.

  Por el contrario, NixOS (la distribución de Linux basada en Nix) compone el sistema base a partir de paquetes de Nix en la tienda de Nix también y es mucho más poderoso. Puede revertir a cualquier configuración anterior que aún no se haya recolectado como basura. Además, se pueden compartir paquetes de sistemas similares entre generaciones.

• Ambas herramientas admiten instalaciones de usuarios sin privilegios . Sin embargo, Snappy almacena todos los archivos en el directorio de inicio del usuario. Si dos usuarios instalan el mismo paquete, se instalan dos veces en el sistema.

  Por el contrario, los paquetes de Nix también permiten a los usuarios comunes instalar paquetes en la tienda central de Nix para poder compartir paquetes idénticos entre los usuarios. En parte debido a la convención de nomenclatura (usando hashing), esto se puede hacer de manera segura.

• Snappy restringe el comportamiento en tiempo de ejecución de los paquetes listos para usar, mientras que Nix no

• Snappy no parece ayudar a los usuarios a construir paquetes a partir del código fuente. Sin embargo, Nix tiene un DSL que permite a las personas hacer esto con bastante facilidad e instalar automáticamente todas las dependencias de compilación (compiladores, herramientas de compilación, bibliotecas, etc.) cuando sea necesario

• Snappy apenas admite modularización y reutilización . En los paquetes de ejemplo, todas las dependencias de la biblioteca están agrupadas estáticamente y consumen mucho más espacio en disco y RAM. Además, la documentación no parece proporcionar ninguna instalación, excepto los marcos. Sin embargo, los marcos no están destinados a ser reutilizados de acuerdo con la documentación

  Con los paquetes de modularización de Nix y la gestión segura de las dependencias, algunas de sus características clave.

La publicación completa del blog se puede encontrar aquí: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Espero que le resulte interesante leer y tal vez haya algunas cosas en las que valga la pena pensar.