Bagaimana Snappy berhubungan dengan Nix dan Guix?

Saya mencari perbandingan tetapi tidak menemukan dan tidak cukup informasi untuk melakukannya sendiri sekarang.

Semuanya menyediakan pembaruan transaksional, tetapi berbagai tingkat penahanan.

• Snappy mengkompilasi secara statis di perpustakaan untuk menyediakan beberapa versi dependensi biner. Ini menyatakan layanan yang disediakan (dan dibutuhkan?) Sebagai metadata. Paket ini disediakan sebagai gambar tunggal?
• Nix berurusan dengan tautan dinamis untuk menyediakan beberapa versi dependensi biner? Ini menyatakan layanan yang disediakan dan dibutuhkan sebagai metadata. Paket ini disediakan melalui repositori yang berhubungan dengan dependensi.
• Guix seperti Nix, tetapi fitur integrasi GNU.

Perbandingan yang lebih mendalam antara Nix dan Guix diberikan oleh Sander van der Burg , yang tidak saya pelajari secara terperinci. Saya kira seseorang di Canonical telah membuat analisis solusi yang ada. Ada sistem penyebaran lain berdasarkan gambar, seperti CoreOS saya diberitahu.

Jadi, bagaimana kaitan Snappy Ubuntu dengan Nix dan Guix? Apa perbedaan utama?

Baru-baru ini, saya melakukan evaluasi sendiri. Saya sebenarnya adalah kontributor Nix / NixOS, dan mantan peneliti yang tertarik pada teknologi penempatan.

Saya telah berusaha untuk menempel fakta sebanyak mungkin, tetapi mungkin mustahil untuk tetap tidak bias sepenuhnya. Untuk merangkum temuan saya:

• Kedua pendekatan menyimpan paket secara terpisah . Snappy menyimpan aplikasi dan kerangka kerja di folder menggunakan konvensi nama berikut /app/name/version.vendor:, sedangkan Nix menggunakan /nix/store/hash-name-version.

  Konvensi penamaan Nix lebih kuat, karena menggunakan awalan hash yang diturunkan dari semua dependensi buildtime . Dengan Nix Anda dapat dengan mudah membuat perbedaan antara varian paket dan menyimpannya di samping satu sama lain. Setiap perubahan (mis. Prosedur build yang berbeda, pemutakhiran perpustakaan, pemutakhiran kompiler) menghasilkan hash baru yang memungkinkan untuk menyimpan varian yang mungkin bersebelahan

• Untuk memungkinkan paket untuk menemukan dependensinya, Nix mengikat mereka statis untuk dapat dieksekusi (misalnya dengan memodifikasi RPATHsebuah biner ELF) atau dengan membungkus mereka dalam skrip yang mengatur variabel lingkungan yang sesuai (misalnya CLASSPATH, PYTHONPATH, PERL5LIB, dll).

  Snappy menyusun wadah tempat executable dapat menemukan dependensinya di lokasi FHS umum mereka, seperti /libdan/bin

  Namun, Nix juga mendukung pendekatan wadah Snappy tetapi ini hanya digunakan dalam kasus yang sangat jarang. Paket Nix yang paling menonjol dengan menggunakan pendekatan kemas adalah Steam di NixOS, karena Steam adalah alat penyebaran itu sendiri dengan sifat yang saling bertentangan.

• Snappy Ubuntu Core menggunakan apa yang disebut skema partisi "A / B" untuk memutakhirkan (dan memutar kembali) sistem basis. Itu hanya mendukung sejumlah versi (biasanya dua) pada saat itu.

  Sebaliknya, NixOS (distro Linux berbasis Nix) menyusun sistem dasar dari paket Nix di toko Nix juga dan jauh lebih kuat. Anda dapat memutar kembali ke konfigurasi sebelumnya yang belum mengumpulkan sampah. Selain itu, paket sistem serupa antar generasi dapat dibagikan.

• Kedua alat mendukung instalasi pengguna yang tidak memiliki hak . Namun, Snappy menyimpan semua file di direktori home pengguna. Jika dua pengguna kebetulan menginstal paket yang sama maka mereka diinstal dua kali pada sistem.

  Sebaliknya, paket Nix juga memungkinkan pengguna biasa untuk menginstal paket di pusat toko Nix sehingga paket yang sama dapat dibagi di antara pengguna. Sebagian karena konvensi penamaan (menggunakan hashing) ini dapat dilakukan dengan cara yang aman.

• Snappy membatasi perilaku runtime dari paket out-of-the-box sedangkan Nix tidak

• Snappy tampaknya tidak membantu pengguna untuk membuat paket dari kode sumber. Namun Nix memiliki DSL yang memungkinkan orang untuk melakukan ini dengan cukup mudah dan secara otomatis menginstal semua dependensi buildtime (kompiler, peralatan build, perpustakaan dll.) Ketika diperlukan

• Snappy hampir tidak mendukung modularisasi dan penggunaan kembali . Dalam paket contoh, semua dependensi perpustakaan dibundel secara statis memakan lebih banyak ruang disk dan RAM. Selain itu, dokumentasi tampaknya tidak menyediakan fasilitas apa pun kecuali kerangka kerja. Namun, kerangka kerja tidak dimaksudkan untuk digunakan kembali sesuai dengan dokumentasi

  Dengan paket modularisasi Nix dan pengelolaan dependensi yang aman adalah beberapa fitur utamanya.

Posting blog lengkap dapat ditemukan di sini: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Semoga Anda menemukan itu menarik untuk dibaca dan mungkin ada beberapa hal di dalamnya yang menurut Anda layak untuk dipikirkan.