In che modo Snappy si collega a Nix e Guix?

Ho cercato un confronto, ma ho trovato non e non sono abbastanza ben informato per farlo da solo.

Tutti forniscono aggiornamenti transazionali, ma diversi livelli di contenimento.

• Snappy si compila staticamente in librerie per fornire più versioni di dipendenze binarie. Dichiara i servizi forniti (e necessari?) Come metadati. Il pacchetto è fornito come una 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 viene fornito tramite 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. Immagino che qualcuno di Canonical abbia fatto un'analisi delle soluzioni esistenti. Esistono altri sistemi di distribuzione basati su immagini, come mi è stato detto CoreOS.

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

Di recente ho fatto una valutazione da solo. In realtà sono un collaboratore di Nix / NixOS ed ex ricercatore interessato alla tecnologia di implementazione.

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

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

  La convenzione di denominazione di Nix è più potente, perché utilizza prefissi hash derivati ​​da tutte le dipendenze di buildtime . Con Nix puoi facilmente fare distinzioni tra qualsiasi variante di un pacchetto e conservarle una accanto all'altra. Qualsiasi modifica (ad es. Diversa procedura di compilazione, aggiornamento della libreria, aggiornamento del compilatore) produce un nuovo hash rendendo possibile l'archiviazione di ogni possibile variante una accanto all'altra.

• Per consentire un pacchetto per trovare le dipendenze, Nix li lega staticamente ad un eseguibile (ad esempio modificando la RPATHdi un binario ELF) o avvolgendoli in script che impostano le variabili di ambiente appropriate (ad esempio CLASSPATH, PYTHONPATH, PERL5LIB, ecc).

  Snappy compone contenitori in cui gli eseguibili possono trovare le loro dipendenze nelle loro posizioni FHS comuni, come /libe/bin

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

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

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

• Entrambi gli strumenti supportano installazioni utente senza privilegi . Tuttavia, Snappy archivia 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 nel negozio Nix centrale in modo che pacchetti identici possano essere condivisi tra gli utenti. In parte a causa della convenzione di denominazione (usando l'hash) questo può essere fatto in modo sicuro.

• Snappy limita il comportamento runtime dei pacchetti immediatamente, mentre Nix no

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

• Snappy difficilmente supporta la modularizzazione e il riutilizzo . Nei pacchetti di esempio, tutte le dipendenze delle librerie sono raggruppate staticamente consumando molto più spazio su disco e RAM. Inoltre, la documentazione non sembra fornire alcuna struttura ad eccezione dei framework. Tuttavia, i quadri non sono pensati per il riutilizzo secondo la documentazione

  Con Nix i pacchetti di modularizzazione e la gestione sicura delle dipendenze sono alcune delle sue caratteristiche principali.

Il post completo del blog è disponibile qui: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

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