Como o Snappy se relaciona com o Nix e o Guix?

Procurei uma comparação, mas não achei e não estou suficientemente bem informado para fazê-lo agora.

Todos eles fornecem atualizações transacionais, mas diferentes níveis de contenção.

• O Snappy compila estaticamente nas bibliotecas para fornecer várias versões de dependências binárias. Declara serviços fornecidos (e necessários?) Como metadados. O pacote é fornecido como uma imagem única?
• O Nix lida com o vínculo dinâmico para fornecer várias versões de dependências binárias? Ele declara serviços fornecidos e necessários como metadados. O pacote é fornecido através de um repositório que lida com dependências.
• O Guix é como o Nix, mas possui integração com o GNU.

Uma comparação mais profunda entre Nix e Guix é feita por Sander van der Burg , que não estudei em detalhes. Eu acho que alguém da Canonical fez uma análise das soluções existentes. Existem outros sistemas de implantação baseados em imagens, como o CoreOS me disseram.

Então, como o Snappy Ubuntu se relaciona com o Nix e o Guix? Quais são as principais diferenças?

Recentemente, eu mesmo fiz uma avaliação. Na verdade, sou colaborador do Nix / NixOS e ex-pesquisador interessado em tecnologia de implantação.

Tentei me apegar aos fatos o máximo possível, mas é provavelmente impossível permanecer totalmente imparcial. Para resumir minhas descobertas:

• Ambas as abordagens armazenam pacotes isoladamente . O Snappy armazena aplicativos e estruturas em pastas usando a seguinte convenção de nome /app/name/version.vendor:, enquanto o Nix usa /nix/store/hash-name-version.

  A convenção de nomenclatura do Nix é mais poderosa, porque usa prefixos de hash derivados de todas as dependências de tempo de construção . Com o Nix, você pode facilmente fazer distinções entre qualquer variante de um pacote e armazená-las próximas umas das outras. Qualquer alteração (por exemplo, procedimento de compilação diferente, atualização da biblioteca, atualização do compilador) gera um novo hash, possibilitando o armazenamento de qualquer variante possível próxima uma da outra.

• Para permitir que um pacote para encontrar as suas dependências, Nix se liga-los estaticamente a um executável (por exemplo, modificando a RPATHde um binário ELF) ou enrolando-os em scripts que definem as variáveis ambiente apropriadas (por exemplo CLASSPATH, PYTHONPATH, PERL5LIB, etc.).

  O Snappy compõe contêineres nos quais os executáveis ​​podem encontrar suas dependências nos locais comuns da ESF, como /libe/bin

  No entanto, o Nix também suporta a abordagem de contêiner do Snappy, mas isso é usado apenas em casos muito raros. O pacote Nix mais proeminente usando uma abordagem em contêiner é o Steam no NixOS, porque o Steam é uma ferramenta de implantação em si com propriedades conflitantes.

• O Snappy Ubuntu Core usa o chamado esquema de particionamento "A / B" para atualizar (e reverter) o sistema base. Ele suporta apenas um número limitado de versões (normalmente duas) no momento.

  Por outro lado, o NixOS (a distribuição Linux baseada no Nix) também compõe o sistema básico dos pacotes Nix na loja Nix e é muito mais poderoso. Você pode reverter para qualquer configuração anterior que ainda não tenha sido coletada como lixo. Além disso, pacotes de sistemas similares entre gerações podem ser compartilhados.

• Ambas as ferramentas suportam instalações de usuário não privilegiadas . No entanto, o Snappy armazena todos os arquivos no diretório inicial do usuário. Se dois usuários instalarem o mesmo pacote, eles serão instalados duas vezes no sistema.

  Por outro lado, os pacotes Nix também permitem que usuários comuns instalem pacotes no repositório central do Nix, para que pacotes idênticos possam ser compartilhados entre os usuários. Em parte devido à convenção de nomenclatura (usando o hash), isso pode ser feito de maneira segura.

• O Snappy restringe o comportamento do tempo de execução dos pacotes prontos para uso, enquanto o Nix não

• O Snappy parece não ajudar os usuários a construir pacotes a partir do código fonte. No entanto, o Nix possui uma DSL, permitindo que as pessoas façam isso com facilidade e facilidade de instalação automática de todas as dependências de tempo de compilação (compiladores, ferramentas de compilação, bibliotecas etc.) quando necessário

• O Snappy dificilmente suporta modularização e reutilização . Nos pacotes de exemplo, todas as dependências da biblioteca são empacotadas estaticamente, consumindo muito mais espaço em disco e RAM. Além disso, a documentação não parece fornecer nenhuma instalação, exceto estruturas. No entanto, as estruturas não devem ser reutilizadas de acordo com a documentação

  Com os pacotes de modularização do Nix e o gerenciamento seguro de dependências, alguns dos principais recursos.

A postagem completa do blog pode ser encontrada aqui: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Espero que você ache interessante ler e talvez haja algumas coisas nas quais você pense que vale a pena pensar.