In che modo Snappy si relaziona con Nix e Guix?

20

Ho cercato un confronto ma ho trovato non e non sono abbastanza informato abbastanza da farlo da solo al momento.

Tutti forniscono aggiornamenti transazionali, ma diversi livelli di contenimento.

  • Snappy compila staticamente nelle librerie per fornire più versioni di dipendenze binarie. Dichiara i servizi forniti (e necessari?) Come metadati. Il pacchetto è fornito come singola immagine?
  • Nix si occupa del collegamento dinamico per fornire più versioni di dipendenze binarie? Dichiara i servizi forniti e necessari come metadati. Il pacchetto è fornito attraverso un repository che si occupa delle dipendenze.
  • Guix è come Nix, ma presenta l'integrazione GNU.

Un confronto più approfondito tra Nix e Guix è dato da Sander van der Burg , che non ho studiato in dettaglio. Direi che qualcuno di Canonical ha fatto un'analisi delle soluzioni esistenti. Esistono altri sistemi di distribuzione basati su immagini, come CoreOS mi è stato detto.

Quindi, come si collega Snappy Ubuntu a Nix e Guix? Quali sono le principali differenze?

    
posta payload 10.02.2015 - 17:42
fonte

1 risposta

27

Recentemente, ho fatto una valutazione da solo. Sono in realtà un contributore Nix / NixOS e un ex ricercatore interessato alla tecnologia di implementazione.

Ho cercato di attenermi ai fatti il ​​più possibile, ma è probabilmente impossibile rimanere completamente imparziali. Per riassumere i miei risultati:

  • Entrambi gli approcci memorizzano i pacchetti in isolation . Snappy archivia app e framework in cartelle usando la seguente convenzione del nome: /app/name/version.vendor , mentre Nix usa /nix/store/hash-name-version .

    La convenzione di denominazione di Nix è più potente, perché usa i prefissi hash derivati ​​da tutte le dipendenze del buildtime . Con Nix puoi facilmente fare distinzioni tra qualsiasi variante di un pacchetto e memorizzarle l'una accanto all'altra. Qualsiasi modifica (ad esempio, procedura di compilazione diversa, aggiornamento della libreria, aggiornamento del compilatore) produce un nuovo hash che rende possibile memorizzare qualsiasi variante possibile l'una accanto all'altra.

  • Per consentire a un pacchetto di trovare le sue dipendenze, Nix li lega staticamente a un eseguibile (ad esempio modificando RPATH di un binario ELF) o avvolgendoli in script che impostano l'ambiente appropriato variabili (ad es. CLASSPATH , PYTHONPATH , PERL5LIB , ecc.).

    Snappy compone contenitori in cui gli eseguibili possono trovare le loro dipendenze nei loro percorsi FHS comuni, come /lib e /bin

    Tuttavia, Nix supporta anche l'approccio contenitore di Snappy, ma questo è usato solo in casi molto rari. Il pacchetto Nix più importante che utilizza un approccio containerizzato è Steam in NixOS, perché Steam è uno strumento di distribuzione stesso con proprietà in conflitto.

  • Snappy Ubuntu Core utilizza un cosiddetto schema di partizionamento "A / B" per aggiornare (e ripristinare) il sistema di base. Al momento supporta solo un numero limitato di versioni (in genere due).

    Al contrario, NixOS (la distro Linux basata su Nix) compone il sistema di base dai pacchetti Nix nello store Nix ed è molto più potente. È possibile eseguire il rollback a qualsiasi configurazione precedente che non sia ancora stata raccolta. Inoltre, pacchetti di sistema simili tra generazioni possono essere condivisi.

  • Entrambi gli strumenti supportano installazioni utente non privilegiate . Tuttavia, Snappy memorizza tutti i file nella home directory dell'utente. Se due utenti installano lo stesso pacchetto, vengono installati due volte sul sistema.

    Al contrario, i pacchetti Nix consentono anche agli utenti ordinari di installare pacchetti nell'archivio centrale di Nix in modo che i pacchetti identici possano essere condivisi tra gli utenti. In parte a causa della convenzione di denominazione (usando l'hashing), questo può essere fatto in modo sicuro.

  • Snappy limita il comportamento di runtime dei pacchetti out-of-the-box mentre Nix non fa

  • Snappy non sembra aiutare gli utenti a costruire pacchetti dal codice sorgente. Tuttavia, Nix ha un DSL che consente alle persone di farlo abbastanza facilmente e installa automaticamente tutte le dipendenze del buildtime (compilatori, strumenti di compilazione, librerie ecc.) Quando necessario

  • Snappy supporta a malapena la modularizzazione e il riutilizzo . Nei pacchetti di esempio, tutte le dipendenze della libreria sono raggruppate in modo statico e richiedono molto più spazio su disco e RAM. Inoltre, la documentazione non sembra fornire alcuna infrastruttura eccetto framework. Tuttavia, i framework non sono pensati per il riutilizzo secondo la documentazione

    Con Nix modularizzare i pacchetti e gestire le dipendenze in sicurezza sono alcune delle sue caratteristiche principali.

Il post completo del blog può essere trovato qui: link

Spero che tu lo trovi interessante da leggere e forse ci sono alcune cose in cui trovi che vale la pena di pensare.

    
risposta data Sander van der Burg 30.04.2015 - 22:29
fonte

Leggi altre domande sui tag