Como Snappy se relaciona com Nix e Guix?

Question

Eu procurei uma comparação, mas achei não e não estou bem informado o suficiente para fazer isso agora mesmo.

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

• O Snappy é compilado estaticamente em bibliotecas para fornecer várias versões de dependências binárias. Declara os serviços fornecidos (e necessários?) Como metadados. O pacote é fornecido como uma única imagem?
• O Nix lida com links dinâmicos para fornecer múltiplas versões de dependências binárias? Declara os serviços fornecidos e necessários como metadados. O pacote é fornecido por meio 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 aprofundada entre Nix e Guix é dada por Sander van der Burg , que eu 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 foi dito.

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

    

Answer 1

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

Eu tentei me ater aos fatos tanto quanto possível, mas é provavelmente impossível permanecer totalmente imparcial. Para resumir minhas descobertas:

• Ambas as abordagens armazenam pacotes no isolamento . O Snappy armazena aplicativos e estruturas em pastas usando a seguinte convenção de nomes: /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 hash derivados de todas as dependências do buildtime . Com o Nix você pode facilmente fazer distinções entre qualquer variante de um pacote e armazená-las uma ao lado da outra. Qualquer alteração (por exemplo, procedimento de criaçã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 encontre suas dependências, o Nix os vincula estaticamente a um executável (por exemplo, modificando o RPATH de um binário ELF) ou agrupando-os em scripts que definem o ambiente apropriado variáveis (por exemplo, CLASSPATH , PYTHONPATH , PERL5LIB , etc.).

  O Snappy compõe contêineres nos quais os executáveis podem encontrar suas dependências em seus locais comuns de FHS, como /lib e /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 de conteinerizada é o Steam no NixOS, porque o Steam é uma ferramenta de implantação com propriedades conflitantes.

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

  Por outro lado, o NixOS (a distribuição Linux baseada em Nix) compõe o sistema básico dos pacotes Nix no repositório 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 sistema semelhantes entre gerações podem ser compartilhados.

• Ambas as ferramentas suportam instalações de usuários sem privilégios . 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 Nix central, para que pacotes idênticos possam ser compartilhados entre usuários. Em parte por causa da convenção de nomenclatura (usando hashing) isso pode ser feito de maneira segura.

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

• O Snappy não parece ajudar os usuários a construir pacotes do código-fonte. No entanto, o Nix tem uma DSL que permite que as pessoas façam isso com facilidade e instalem automaticamente todas as dependências do buildtime (compiladores, ferramentas de construção, bibliotecas etc.) quando necessário

• O Snappy dificilmente suporta a modularização e a 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 facilidade, exceto estruturas. No entanto, os frameworks não são destinados a reutilização de acordo com a documentação

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

A postagem completa do blog pode ser encontrada aqui: link

Espero que você ache interessante ler e talvez haja algumas coisas em que você acha que vale a pena pensar.