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

21

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

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 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 servicios proporcionados y necesarios como metadatos. El paquete se proporciona a través de un repositorio que trata con dependencias.
  • Guix es como Nix, pero cuenta con integración de GNU.

Una comparación más en profundidad entre Nix y Guix viene dada por Sander van der Burg , 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?

    
pregunta payload 10.02.2015 - 16:42

1 respuesta

28

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

He intentado concentrarme en los hechos tanto como sea posible, pero probablemente sea imposible permanecer completamente imparcial. Para resumir mis hallazgos:

  • Ambos enfoques almacenan paquetes en aislamiento . Snappy almacena aplicaciones y marcos en carpetas utilizando la siguiente convención de nombres: /app/name/version.vendor , mientras que Nix usa /nix/store/hash-name-version .

    La convención de nomenclatura de Nix es más poderosa, porque usa prefijos de hash que se derivan de todas las dependencias de compilación . Con Nix puede hacer distinciones entre cualquier variante de un paquete y almacenarlas una al lado de la otra. Cualquier cambio (por ejemplo, un procedimiento de creación diferente, una actualización de la biblioteca o una 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 encuentre sus dependencias, Nix los vincula estáticamente a un ejecutable (por ejemplo, modificando el RPATH de un binario ELF) o envolviéndolos en scripts que establecen el entorno apropiado variables (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 /lib y /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 prominente que utiliza un enfoque contenedor es Steam en NixOS, porque Steam es una herramienta de despliegue en sí misma con propiedades contradictorias.

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

    En contraste, NixOS (la distribución Linux basada en Nix) compone el sistema base de los paquetes Nix en la tienda Nix y es mucho más poderoso. Puede retroceder a cualquier configuración previa que aún no haya sido recolectada. Además, se pueden compartir paquetes de sistema similares entre generaciones.

  • Ambas herramientas admiten instalaciones de usuario 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.

    En contraste, los paquetes Nix también permiten a los usuarios normales instalar paquetes en la tienda Nix central para que los paquetes idénticos puedan compartir entre los usuarios. En parte debido a la convención de nomenclatura (usando hash) esto se puede hacer de una manera segura.

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

  • Snappy no parece ayudar a los usuarios a construir paquetes desde el código fuente. Sin embargo, Nix tiene una 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 se agrupan de forma estática y consumen mucho más espacio de disco y RAM. Además, la documentación no parece proporcionar ninguna infraestructura, excepto marcos. Sin embargo, los marcos no están diseñados para su reutilización según la documentación

    Con Nix, la modularización de paquetes y la administración segura de dependencias son algunas de sus características clave.

La publicación completa del blog se puede encontrar aquí: enlace

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

    
respondido por el Sander van der Burg 30.04.2015 - 20:29

Lea otras preguntas en las etiquetas