Nix Flakes dan Fitur Guix yang Menjawabnya

(coopi.neocities.org)

1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp

Nix Flakes menyatukan dependensi proyek, penguncian versi, skema output, dan lingkungan pengembangan dengan berpusat pada flake.nix dan flake.lock, sementara Guix menyediakan jenis fungsi yang sama melalui kombinasi alat ortogonal seperti channels, manifests, guix describe, guix shell, dan operating-system
Flakes menetapkan dependensi per proyek dengan inputs dan flake.lock yang dibuat otomatis, sedangkan Guix membangun lingkungan yang dapat direproduksi dengan guix describe per pengguna, channels.scm yang mencatat commit di proyek, dan guix time-machine
Kemurnian dipaksakan di Flakes melalui restricted evaluation, sedangkan di Guix hal itu dicapai secara desain melalui struktur modul Scheme, input yang eksplisit, dan kontainer build yang terisolasi
Struktur output di Flakes menyediakan attrset standar seperti packages, devShells, dan nixosConfigurations, sedangkan Guix menggunakan record dan file Scheme yang transparan seperti <package>, manifest, operating-system, dan service yang langsung dikonsumsi oleh tiap perintah
Kriteria pemilihan: jika Anda lebih menyukai satu titik masuk tunggal dan skema standar, Flakes cocok; jika Anda lebih menyukai pendekatan menggabungkan alat-alat kecil yang independen, Guix lebih sesuai

Perbandingan inti

Tidak ada satu fitur Guix tunggal yang setara dengan Nix flake; sementara Nix Flakes menyelesaikan banyak masalah dalam satu fitur besar, Guix menanggapinya dengan kombinasi alat yang lebih kecil dan ortogonal
Guix menggunakan kembali Nix daemon dan berbagi komponen C++ yang menangani build isolation serta store management
Guix mengimplementasikan ulang sebagian besar hal di atas Nix daemon, seperti bahasa, definisi paket, dan sistem service, menggunakan Guile Scheme
Guix dan Nix berbagi format derivation ATerm serta garis keturunan daemon, tetapi struktur di atas daemon dibangun dengan cara Guix sendiri
Guix memiliki kapabilitas yang disediakan Flakes, tetapi menyediakannya dalam bentuk yang berbeda

Struktur dasar Nix Flake

Nix flake adalah source tree yang memiliki file flake.nix di root, dan biasanya berbentuk Git repository
Keberadaan flake.nix menjadikan source tree tersebut sebuah flake, dan file itu memiliki struktur seperti description, inputs, dan outputs
description adalah string yang dapat dibaca manusia untuk menjelaskan apa yang disediakan oleh flake
inputs mendeklarasikan dependensi seperti flakes lain, Git repos, dan tarballs, yang kemudian di-fetch dan dievaluasi oleh Nix sebelum diteruskan ke fungsi outputs
outputs adalah fungsi yang menerima input yang sudah di-resolve beserta input khusus self, lalu mengembalikan attrset terstruktur berisi packages, dev shells, konfigurasi NixOS, overlays, dan lainnya
Contoh struktur dan target eksekusi
- nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; pada contoh inputs berarti mengambil branch nixos-unstable dari repositori GitHub NixOS/nixpkgs
- Contoh flake menggunakan supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; dan nixpkgs.lib.genAttrs untuk menghasilkan output bagi beberapa arsitektur CPU
- Flakes mengharuskan tingkat packages.<system>, dan dalam contoh package default di bawah packages didefinisikan dengan pkgs.buildGoModule
- src = ./.; berarti seluruh Git repository digunakan sebagai source
- devShells adalah definisi shell pengembangan yang dirujuk oleh nix develop, dan dalam contoh menggunakan pkgs.mkShell serta buildInputs = with pkgs; [ go gopls gotools ];
flake.lock dan evaluasi murni
- Saat menjalankan perintah Nix terhadap sebuah flake, Nix akan membuat file JSON flake.lock yang mengunci semua input dan input transitif ke revisi yang tepat
- flake.lock adalah lock file yang memungkinkan reproducibility build lintas mesin dan waktu
- Flakes memaksakan pure evaluation, sehingga $NIX_PATH, builtins.currentSystem, dan environment variables tidak bisa masuk secara implisit; semuanya harus eksplisit
- Fungsi yang dijalankan Flakes dapat diringkas sebagai deklarasi dependensi, pinning dependensi, pemaksaan kemurnian, penyediaan skema output standar, berbagi yang reproducible, dan pendefinisian lingkungan pengembangan

Pendekatan Guix

Guix sudah memiliki solusi untuk sebagian besar fitur Flakes bahkan sebelum Flakes diperkenalkan di Nix 2.4 pada 1 November 2021
Mekanisme channels Guix diperkenalkan sekitar 2018–2019
Solusi Guix bersifat ortogonal, dan setiap alat dapat digunakan secara independen tanpa mengadopsi satu abstraksi monolitik tunggal
Channels dan deklarasi dependensi
- Di Flake, dependensi dideklarasikan langsung di dalam flake.nix, dan dalam contoh digunakan nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11"; serta home-manager.url = "github:nix-community/home-manager";
- inputs.nixpkgs.follows = "nixpkgs"; pada input Flake membuat home-manager menggunakan nixpkgs milik flake saat ini alih-alih mengambil input nixpkgs miliknya sendiri, sehingga menghindari situasi munculnya dua salinan nixpkgs yang berbeda
- Channels di Guix adalah repository Git yang berisi modul Guile; biasanya memuat definisi paket, tetapi juga dapat memuat services, konfigurasi sistem, dan kode Scheme arbitrer
- Channels Guix dideklarasikan di ~/.config/guix/channels.scm, dan file Scheme ini mengembalikan list record channel
- guix pull akan mengambil dan mengompilasi semua channels, lalu membuat modul-modul tersebut tersedia untuk semua perintah guix
- Channels dapat mendeklarasikan dependensi pada channel lain menggunakan file .guix-channel di root repository
- Dependensi channel di Guix secara kasar mirip dengan inputs pada flake, dan saat guix pull dijalankan, dependensi channel transitif juga ikut diambil
Dependensi per proyek dan dependensi per pengguna
- Flakes memakai pendekatan per proyek, di mana tiap repository memiliki flake.nix dan input-nya sendiri, sedangkan channels bekerja secara system-wide atau per-user, dengan channels.scm yang berlaku untuk semua invocation guix
- Flakes secara alami mendukung proyek yang berbeda untuk memiliki set dependensi yang berbeda, sementara di Guix efek yang sama biasanya dicapai dengan guix time-machine atau profile terpisah
- Flakes menggunakan sintaks mirip URL seperti github:NixOS/nixpkgs, git+https://..., sedangkan channels memakai URL Git biasa
- Sintaks Flake lebih ergonomis untuk referensi cepat, sementara channels lebih sederhana dan eksplisit
- Flakes mendukung repository non-flake yang tidak memiliki flake.nix melalui flake = false;
- Di Guix, karena channel adalah repository Git yang berisi file Scheme, tidak diperlukan opt-in khusus; repository apa pun yang memiliki modul Guile dapat menjadi channel

Pinning, reproduktibilitas, dan perjalanan waktu

flake.lock
- flake.lock adalah graph JSON, semua input di-pin ke commit hash yang presisi, dan Nix memverifikasi narHash, yaitu hash dari seluruh source tree yang diambil
- flake.lock di-commit ke repository, sehingga orang yang melakukan clone akan mendapatkan versi dependensi yang sama
- original pada flake.lock adalah target yang diminta, sedangkan locked adalah target yang benar-benar diperoleh
- Sistem dua lapis pada flake.lock memungkinkan selective update, misalnya hanya memperbarui input tertentu dengan nix flake lock --update-input nixpkgs sambil mempertahankan yang lain
guix describe dan guix time-machine
- Guix mencatat commit yang tepat dari semua channel saat guix pull dijalankan, dan guix describe menampilkan informasi ini
- Output guix describe mencakup nomor generation, tanggal, penanda current, nama channel, URL repository, branch, dan commit
- Commit channel yang dicatat Guix setara dengan lock file, tetapi keberadaannya bukan sebagai file di direktori proyek melainkan sebagai profile Guile di ~/.config/guix/current
- Untuk berbagi environment yang dapat direproduksi, Guix dapat menggunakan guix time-machine
- guix time-machine --commit=8a1ab328 -- shell -m manifest.scm akan me-pin Guix sendiri ke revisi tertentu, lalu menjalankan guix shell menggunakan definisi paket dari revisi tersebut
- guix time-machine akan mengunduh dan mengompilasi revisi itu bila perlu, lalu membuat environment terisolasi dengan definisi paket yang persis sesuai keadaan commit tersebut
- Ada juga pola di Guix untuk me-check-in channels.scm dengan commit yang sudah di-pin ke dalam repository proyek
- guix time-machine -C channels.scm -- shell -m manifest.scm mereproduksi environment yang sama persis menggunakan channels.scm yang disertakan dalam repository
Perbedaan antara kedua pendekatan
- flake.lock bersifat per proyek dan otomatis, sedangkan guix describe bersifat per pengguna dan otomatis
- channels.scm yang berisi commit yang di-pin menyediakan pinning per proyek di Guix, tetapi dilakukan secara manual
- Guix sedang meningkatkan ergonomi pinning per proyek, tetapi alur kerja saat ini masih memerlukan setup yang lebih eksplisit
- flake.lock adalah graph JSON yang machine-readable, sedangkan padanannya di Guix adalah file Scheme yang mencantumkan channel dengan commit hash
- Keduanya sama-sama mencapai tujuan pinning dependensi, tetapi flake lock lebih terstruktur karena berupa full dependency graph dengan entri original dan locked untuk semua input transitif
- guix time-machine adalah fitur yang tidak memiliki padanan langsung di flake; ia memungkinkan perpindahan bukan hanya ke versi dependensi yang di-pin, tetapi juga ke keadaan historis koleksi paket yang sepenuhnya berbeda

Model kemurnian

Flakes berjalan dalam konteks evaluasi terbatas, sehingga penggunaan builtins.currentSystem, builtins.getEnv, dan $NIX_PATH dilarang atau diabaikan
Di Flakes, semua hal harus berasal dari input yang dideklarasikan, sehingga sulit terjadi dependensi tak disengaja pada state implisit
Trade-off evaluasi murni di Flakes adalah parameter system yang eksplisit diperlukan di banyak tempat untuk deteksi sistem, dan variabel lingkungan tidak bisa dibaca
Saat membutuhkan escape hatch impure di Flakes, --impure harus diberikan secara eksplisit
Guix tidak memerlukan mode evaluasi murni terpisah, karena evaluasinya secara konvensi sudah murni
Modul Guile tidak mengakses variabel lingkungan kecuali secara eksplisit diteruskan kepadanya
Guix tidak memiliki padanan untuk $NIX_PATH, dan menyelesaikan package melalui sistem modul, bukan search path
Guix tidak memiliki konsep yang setara dengan builtins.currentSystem, dan sistem ditentukan secara eksplisit melalui metadata package serta flag --system
Build di Guix juga murni, dan build dijalankan dalam container terisolasi yang hanya dapat melihat input yang dideklarasikan secara eksplisit
Dalam build Guix, tidak ada akses ke /usr/bin, /etc, maupun jaringan, dan pengecualian akses jaringan dibatasi pada fixed-output derivations
Metode sandboxing build pada dasarnya menggunakan pendekatan yang sama di Nix dan Guix
Guix mencapai kemurnian secara arsitektural melalui struktur modul Scheme, sedangkan Flakes menegakkan kemurnian dengan menambahkan mode evaluasi terbatas di atas sistem yang pada dasarnya impure

Skema output dan model data

Skema output Flake
- Flakes mendefinisikan skema standar untuk outputs, dan packages.<system>.<name> digunakan oleh nix build, devShells.<system>.<name> oleh nix develop, serta apps.<system>.<name> oleh nix run
- Skema output Flake juga mencakup nixosConfigurations.<name>, overlays.<name>, nixosModules.<name>, formatter.<system>, templates.<name>, dan checks.<system>.<name>
- Standardisasi skema output Flake membuat nix build ., nix run, dan nix flake show merujuk ke lokasi yang konsisten sehingga meningkatkan kemudahan penemuan
- Kelemahan skema output Flake adalah sifatnya yang kaku; menambahkan tipe output arbitrer memerlukan modifikasi pada Nix itu sendiri, meski tersedia mekanisme ekstensi kecil
- Karena parameter <system> pada Flake, dukungan multi-platform harus ditangani secara eksplisit, sehingga helper function atau library seperti forAllSystems, flake-utils, atau flake-parts digunakan
Tipe data first-class di Guix
- Guix tidak memiliki satu skema output tunggal seperti Flakes, melainkan tipe data first-class yang dapat dikonsumsi oleh berbagai command
- Di Guix, package didefinisikan sebagai record <package> dan digunakan oleh guix install serta guix build
- Di Guix, manifest didefinisikan sebagai file Scheme dan digunakan oleh guix shell -m serta guix package
- Di Guix, konfigurasi sistem didefinisikan sebagai operating-system dan digunakan oleh guix system reconfigure
- Di Guix, konfigurasi home didefinisikan sebagai home-environment dan digunakan oleh guix home reconfigure
- Di Guix, service didefinisikan sebagai record <service> dan digunakan oleh field services pada operating-system
- Di Guix, channel adalah repo Git dan digunakan oleh guix pull
- Di Guix, varian package adalah prosedur Scheme dan digunakan oleh --with-input serta --transform
File dan definisi package
- Proyek Guix dapat menyediakan kombinasi channel yang berisi definisi package, manifest.scm untuk pengembangan, system.scm untuk deployment, serta deklarasi operating-system atau home-environment
- Di Guix, file-file ini tidak memerlukan file entry point khusus, melainkan hanya file Scheme yang mendefinisikan nilai Scheme
- Di Guix, command memproses file tersebut saat file diberikan ke subcommand guix yang relevan, tanpa memerlukan ceremony terpisah atau validasi skema
- Contoh manifest.scm mendeklarasikan lingkungan pengembangan dengan meneruskan daftar nama package "guile", "guile-git", "guile-json" ke specifications->manifest
- Contoh mylib.scm mendefinisikan record <package>, padanan Guix untuk Nix derivation, dan field package dapat di-query secara terprogram
- Contoh definisi package memiliki (name "mylib"), (version "0.1.0"), (source (local-file ".")), (build-system gnu-build-system), (inputs (list guile guile-git)), (home-page "https://example.com";), dan (license gpl3+)
- local-file di Guix mengambil file dari direktori saat ini pada waktu build, mirip dengan src = ./.; di Nix
- gnu-build-system di Guix menggunakan pendekatan ./configure && make && make install, dan Guix juga memiliki build system lain seperti cmake-build-system dan python-build-system
- Berbeda dengan Nix, di mana stdenv secara implisit menyediakan gcc dan coreutils, Guix membuat semua dependensi bersifat eksplisit

Lingkungan pengembangan

Dalam contoh devShells milik Flakes, digunakan devShells.x86_64-linux.default = pkgs.mkShell { buildInputs = with pkgs; [ go gopls gotools ]; shellHook = '' echo "Welcome to the devShell!" ''; };
mkShell membuat derivation yang membentuk shell environment saat di-build, buildInputs dimasukkan ke PATH di dalam shell, dan shellHook menjalankan bash arbitrer saat masuk ke shell
Masuk ke dev shell Flake dilakukan dengan nix develop atau nix develop .#my-shell untuk shell bernama
Development environment Guix dapat didefinisikan di manifest.scm dengan meneruskan daftar package specification strings ke specifications->manifest
Contoh manifest Guix mendeklarasikan "go", "gopls", "go-tools"
Masuk ke shell berbasis manifest Guix dilakukan dengan guix shell -m manifest.scm
Guix pada environment ad-hoc juga bisa hanya menerima nama paket lewat command line seperti guix shell go gopls go-tools tanpa file
guix shell mendukung --container untuk isolasi penuh, --emulate-fhs untuk menjalankan program yang mengharapkan standard Linux filesystem layout, dan --nesting untuk menjalankan Guix di dalam container Guix
Manifest Guix adalah file Scheme mandiri yang tidak di-embed ke dalam struktur flake.nix yang lebih besar
guix shell dapat berjalan tanpa file, tetapi nix develop membutuhkan flake atau shell.nix dari interface lama
Flakes menyediakan named dev shells seperti devShells.x86_64-linux.test, devShells.x86_64-linux.default
Alih-alih named dev shells, manifest Guix menggunakan pendekatan menempatkan file terpisah seperti manifest.scm, test-manifest.scm secara berdampingan
Baik Nix Flakes maupun Guix sama-sama mendukung containerized development

Konfigurasi sistem

NixOS dan Flakes
- Dalam contoh nixosConfigurations milik Flakes, nixpkgs.lib.nixosSystem menerima daftar modul NixOS dan menghasilkan full system derivation yang mencakup kernel, service, file config, dan lain-lain
- Contoh perintah deployment NixOS berbasis Flake adalah nixos-rebuild switch --flake .#myhost
- Contoh nixosConfigurations.myhost mencakup system = "x86_64-linux"; dan modules = [ ./configuration.nix home-manager.nixosModules.home-manager ];
- Modul NixOS adalah sistem modul yang menggunakan options, config, mkIf, mkDefault, mkForce serta penggabungan berbasis prioritas
- Sistem modul NixOS menyelesaikan prioritas meskipun beberapa modul mengatur opsi yang sama, sehingga lebih mudah menghindari konflik walaupun puluhan modul berkontribusi pada konfigurasi yang sama
Guix operating-system
- operating-system di Guix bukan function melainkan record Scheme, dan setiap field adalah nilai bertipe bernama yang divalidasi oleh Guix
- Contoh perintah deployment sistem Guix adalah guix system reconfigure config.scm
- Contoh record operating-system mencakup (host-name "myhost"), (timezone "Etc/UTC"), konfigurasi bootloader, file system, dan service
- Contoh konfigurasi bootloader Guix menggunakan grub-efi-bootloader dengan target "/boot/efi", dan Guix mendukung GRUB, U-Boot, dan lainnya
- File system Guix dideklarasikan sebagai list, dan %base-file-systems menyediakan default untuk /dev, /proc, /sys, dan lainnya
- Service Guix membentuk directed acyclic graph (DAG), dan setiap service dapat meng-extend service lain
- %base-services menyediakan service esensial seperti Shepherd init system, syslog, networking, dan lain-lain
- Konfigurasi sistem Guix tidak memerlukan special output type, cukup tentukan file yang mengembalikan record operating-system ke guix system
- Komposisi service di Guix memudahkan penulisan service baru yang terhubung ke sistem yang ada dengan cara yang arbitrer

Kemudahan eksplorasi dan registry

Flakes memiliki flake.nix sebagai standard entry point yang mendeklarasikan dependensi proyek, output, dan schema yang dapat ditemukan dalam satu file
Proyek Guix dapat menggunakan file berbasis konvensi seperti manifest.scm, channels.scm, guix.scm, package.scm
Ada upaya untuk menstandarkan guix.scm sebagai file proyek yang otomatis dikenali oleh guix shell, tetapi ini belum semapan flake.nix
Flakes memiliki registry global flake-registry yang memetakan nama pendek ke URL, contohnya nix run nixpkgs#hello, nix build github:NixOS/nixpkgs#firefox
Guix menggunakan package specification untuk kemudahan serupa, contohnya guix shell hello, guix install firefox
Guix tidak memiliki padanan registry untuk menunjuk repositori Git arbitrer dengan nama pendek, sehingga URL digunakan secara langsung
Registry Nix pernah menjadi sumber kebingungan karena tidak selalu jelas apakah nixpkgs adalah entri registry, path lokal, atau target lain
nix flake show adalah perintah yang menampilkan semua item yang disediakan flake dalam tree view
Guix memiliki guix search untuk paket dan guix system search untuk service, tetapi tidak ada perintah padanan yang menampilkan semua item yang disediakan proyek atau repositori tertentu; file Scheme harus diperiksa langsung
Flakes unggul dalam discoverability karena nix flake show menampilkan apa saja yang disediakan project dalam consistent view
Proyek Guix lebih ad-hoc; Anda harus tahu file mana yang perlu dilihat dan tidak ada standard single-entry-point file
Guix memiliki fleksibilitas tinggi karena semuanya adalah Scheme, sehingga Anda bisa mendefinisikan dan menggabungkan apa pun tanpa schema

Model paket dan penulisan ulang graf

Di Nix, paket adalah fungsi yang mengembalikan derivation melalui pemanggilan stdenv.mkDerivation { ... }, dan hasilnya berupa attribute set yang opak
Di Guix, paket adalah record <package>, yaitu struktur data transparan dengan field bernama sehingga bisa diperiksa, diubah, dan dikombinasikan menggunakan prosedur Scheme standar
Karena definisi paket Guix adalah record transparan, bukan fungsi opak, inspect dan transform dapat dilakukan secara terprogram tanpa tooling khusus
Di Guix, karena packages adalah data, graph rewrites dapat dilakukan dengan mudah
Di Guix, package-input-rewriting dapat mengekspresikan pekerjaan menelusuri seluruh graf dependensi untuk mengganti perl dengan perl-minimal
Kata kunci inherit di Guix mendefinisikan ulang paket dengan mewarisi semua field dari coreutils lalu hanya menimpa field yang ditentukan
Nix memiliki overlays untuk tujuan serupa, tetapi karena antarmuka fungsinya opak, inspeksi dan transformasi lebih sulit sehingga kegunaannya menurun

Pembaruan keamanan, bootstrap, autentikasi

grafting di Guix memungkinkan penerapan pembaruan keamanan ke pohon dependensi tanpa membangun ulang semua paket dependennya
Saat ada kerentanan pada pustaka tingkat rendah seperti glibc, Guix dapat menulis ulang jalur store untuk menggantinya dengan versi yang sudah diperbaiki
Nix membangun ulang semuanya dalam situasi pembaruan keamanan, dan pada pohon dependensi besar waktu build bisa berbeda sampai hitungan jam
Guix sangat berfokus pada bootstrap berbasis source, sehingga seluruh sistem dapat dibangun dari basis kepercayaan yang kecil
Rantai bootstrap Guix dimulai dari hex assembler sekitar 500 byte, lalu berlanjut ke kompiler C mes yang ditulis dalam Scheme, tcc, dan GNU toolchain lengkap
Proyek bootstrappable builds membahas detail bootstrap source secara menyeluruh
Nix bergantung pada lebih banyak binary seed dibanding Guix
Jika rantai bootstrap tidak dapat diaudit, maka tidak mungkin sepenuhnya memverifikasi apakah sistem benar-benar dibangun dari source yang dimaksud, sehingga bootstrap source penuh penting untuk kepercayaan dan verifiabilitas
Guix channels mendukung autentikasi kriptografis secara bawaan
Channel Guix menentukan “introduction” yang terdiri dari commit tertentu beserta tanda tangan Ed25519-nya, dan Guix memverifikasi seluruh rantai tanda tangan dari introduction tersebut hingga commit saat ini
Flakes menggunakan HTTPS dan infrastruktur GitHub sebagai model kepercayaan, yang merupakan model keamanan berbeda dari autentikasi channel Ed25519 milik Guix

Hubungan padanan inti dalam tabel ringkasan

Deklarasi dependensi: Flakes memakai inputs di flake.nix, sedangkan Guix memakai channels.scm dan .guix-channel
Penguncian dependensi: Flakes memakai flake.lock otomatis per proyek, sedangkan Guix memakai guix describe otomatis per pengguna dan channels.scm dengan penetapan commit manual per proyek
Evaluasi murni dipaksakan dalam flake mode, sedangkan di Guix itu merupakan sifat bawaan desainnya
Skema output: Flakes memakai attrset terstruktur di outputs, sedangkan Guix memakai Scheme records ad-hoc
Lingkungan pengembangan: Flakes memakai devShells dan nix develop, Guix memakai manifest.scm dan guix shell
Konfigurasi sistem: Flakes memakai nixosConfigurations dan sistem modul, Guix memakai operating-system dan service DAG
Reproducibility satu perintah: Flakes berbentuk nix build github:foo/bar, Guix berbentuk guix time-machine -C channels.scm -- build
Penguncian per proyek: Flakes ditangani otomatis dengan flake.lock, sedangkan Guix ditangani manual dengan channels.scm yang berisi commit
Kemudahan eksplorasi: Flakes memakai nix flake show, Guix bergantung pada inspeksi modul Scheme
Model paket: Flakes/Nix memakai fungsi opak, Guix memakai record transparan
Init system: Nix memakai systemd, Guix memakai GNU Shepherd
Pembaruan keamanan: Nix membangun ulang total, Guix memakai grafting cepat
Kepercayaan bootstrap: Nix berbasis binary seed, Guix berbasis bootstrap source penuh
Pembaruan terautentikasi: Flakes memakai kepercayaan HTTPS/GitHub, Guix memakai autentikasi channel Ed25519
Dukungan FHS: Nix menyediakan buildFHSUserEnv, Guix menyediakan --emulate-fhs
Dukungan non-Linux: Nix dirapikan dengan nix-darwin untuk macOS, Guix dirapikan dengan GNU Hurd
Khusus perangkat lunak bebas atau tidak: Nix tidak eksklusif dan bisa dikonfigurasi, sedangkan Guix mematuhi FSDG

Kesimpulan

Flakes dan Guix menyelesaikan jenis masalah yang sama—reproducibility, manajemen dependensi, dan deklarasi sistem—dengan filosofi arsitektur yang berbeda
Flakes mendekati satu fitur terpadu dengan satu file, satu skema, satu lock file, dan satu himpunan konvensi
Guix adalah kombinasi alat-alat ortogonal seperti channels untuk distribusi, manifests untuk environment, operating-system untuk konfigurasi, guix time-machine untuk reproducibility, serta Scheme records untuk struktur lainnya
Jika Anda lebih menyukai satu cara standar, satu file titik masuk, satu skema output, dan satu format lock, maka Flakes terasa paling alami
Jika Anda lebih menyukai cara menerapkan filosofi Unix pada manajemen paket—menggabungkan alat-alat kecil dan independen agar masing-masing melakukan satu hal dengan baik—maka Guix lebih cocok
Kedua ekosistem berkembang di sekitar gagasan bahwa manajemen paket harus bersifat fungsional, deklaratif, dan dapat direproduksi, dan keduanya mendorong gagasan yang sama dengan implementasi yang berbeda

1 komentar

GN⁺ 5 jam lalu

Opini Lobste.rs

Situs ini sangat menyebalkan dibaca di ponsel: hurufnya agak kecil, dan terus mengganggu setiap kali menggulir
Setelah perbandingan pertama, saya sudah tidak bisa membacanya lagi karena terus meloncat naik ke daftar isi
- Benar-benar tidak bisa dibaca. Bergeraknya seperti yoyo. Ini salah satu tulisan yang belakangan ini benar-benar ingin saya baca, jadi saya kecewa karena ini adalah pengalaman membaca paling membuat frustrasi yang pernah saya alami
- Hal yang sama terjadi di desktop. Tidak masuk akal, dan terlihat seperti sengaja merusak aksesibilitas
Bahkan setelah membaca artikelnya, saya masih tidak begitu paham bagaimana cara menentukan dan mengunci dependensi proyek. Untuk mendistribusikan dan membagikannya, sepertinya kita harus mencari hash commit tiap dependensi transitif secara manual lalu memasukkannya ke channels.scm
time-machine tampaknya hanya bekerja untuk kumpulan paket Guix, dan tidak untuk dependensi di luar tree
Kode nixpkgs dari titik waktu lama juga bisa dijalankan dengan cukup mudah seperti nix run github:nixos/nixpkgs/<commit hash>#<package>
Hal unik dari Guix adalah ia tidak memisahkan versi koleksi paket dan versi manajer paket. Untuk menjalankan paket lama, kita juga jadi menjalankan rilis Guix lama, dan saya kurang paham kenapa itu diinginkan
Tulisan itu mengatakan flakes mengharuskan kita mencari dan menentukan commit secara manual, lalu tepat setelah itu memberi contoh perintah Guix yang juga mengharuskan penentuan commit. Di Nix flake, versi nixpkgs juga bisa dioverride dengan --override-input, tetapi memang berantakan, dan itu salah satu hal yang ingin diperbaiki oleh unflake
- Pengalaman saya memakai Guix memang lebih sedikit daripada penulisnya, tetapi saya sudah cukup membaca dokumentasinya, jadi saya coba jawab beberapa hal
  Biasanya alurnya adalah mengembangkan di lingkungan guix shell khusus, lalu saat siap dibagikan menjalankan guix describe -f channels > channels.scm untuk mencatat semua hash commit ke channels.scm
  Jika melihat dokumentasi declaring channel dependencies, commit dependensi memang bisa ditentukan, tetapi tampaknya tidak ada opsi untuk memverifikasi apakah dependensi itu, jika punya dependensi lagi, juga terkunci ke commit tertentu
  Notasi --commit= milik time-machine berlaku untuk channel Guix, tetapi dengan -C kita juga bisa memuat channel tambahan dari file
  Ini punya keuntungan bahwa meskipun ada perubahan yang mematahkan kompatibilitas pada manajer paket dan record paket, riwayat dan reproduksibilitas tetap tidak hilang
- Ini bisa dilakukan dengan membuat indeks balik untuk nixpkgs: misalnya dari commit X sampai Y di nixpkgs memuat versi A dari paket tertentu
  Namun itu memerlukan checkout nixpkgs untuk tiap commit, jadi biaya awal pembuatannya sangat besar. Setelah jadi, biaya untuk memelihara indeksnya akan rendah
Saya sudah memberi tahu coopi tentang masalah situs ini dan thread ini, jadi semoga segera diperbaiki
Dari sudut pandang yang sudah sepenuhnya condong ke Guix, saya setuju dengan yang dikatakan coopi bahwa Guix juga akan bagus jika punya file/direktori standar seperti satu flake.nix atau satu direktori nix yang memuat semuanya. Tetapi mungkin itu tidak memungkinkan karena untuk mengimpor modul Scheme harus menentukan path yang benar
Karena postingan Lobsters ini memuat hal-hal yang dibicarakan penulis, tag nix dan lisp saja tampaknya sudah cukup
- Saya kurang yakin dengan usulan menghapus linux. Itu satu-satunya kernel yang sama-sama dimiliki keduanya :P tetapi seperti yang kamu bilang, unix mungkin memang kurang cocok
- Akan bagus juga jika ada tipe data channel terstruktur yang membantu menginferensi secara otomatis apa yang disediakan sebuah channel, seperti flakes
  Misalnya seperti ini:
```
(channel  
  (operating-systems  
    (list my-vm))  
  (services  
    (list my-system-service)))  
```
  Dan akan bagus juga jika ada perintah guix channel yang membantu membuat dan mengelola channel baru
Saya penasaran apakah Guix juga punya fitur untuk menimpa nilai pin dependensi transitif seperti .inputs.nixpkgs.follows di Nix flake
Selain itu, banyak bagian penjelasan Guix dari penulis mengingatkan saya pada Nix sebelum flakes: tidak ada titik masuk standar, struktur yang memakai channel, dan sebagainya. Bedanya, di Guix ada sistem bentuk dan bahasa sungguhan, jadi pola yang sama terasa lebih tidak menyakitkan. Rasanya seperti sejarah alternatif yang akan muncul jika Nix lebih baik atau memakai bahasa lain
- Fitur itu dipakai untuk apa?
Saya jadi ragu merekomendasikannya karena masalah usability yang disebut di komentar lain. Saya tidak menyadarinya karena memakai NoScript yang mematikan JavaScript secara default
Meski begitu, tulisan ini datang tepat pada waktunya. Di kantor kami sedang bergerak ke arah penggunaan Nix yang lebih banyak dan agak kesulitan dengan flakes, dan penjelasan dalam tulisan ini jauh lebih jelas daripada yang pernah saya baca sebelumnya
- Kata Coopi, mereka berusaha mengikuti progressive enhancement agar tetap bisa dibaca tanpa JavaScript atau CSS, dan walaupun bagian JavaScript rusak, setidaknya filosofi itu sempat berjalan. Sekarang JavaScript-nya seharusnya juga sudah diperbaiki
Ini balasan dari Coopi: dia membuat perubahan pagi ini tetapi belum sempat mengujinya karena pekerjaan, lalu ternyata ada masalah pada JavaScript
Situs ini tidak bisa dipakai di iOS mobile. Halamannya tampaknya dimuat di bagian bawah lalu langsung menggulir ke atas, dan jika saya menggulir turun lebih dari satu layar, sesuatu terpicu dan mendorongnya naik lagi
Mode baca memang berfungsi, tetapi penyorotan dan detail styling asli yang sebenarnya cukup bagus jadi hilang
Mengatakan bahwa apa yang dilakukan flakes juga bisa dilakukan dengan berbagai alat Guix memang masuk akal, tetapi perlu dicatat bahwa di Nix juga sejak dulu sudah ada, dan sekarang pun masih ada, alat-alat kecil yang ortogonal untuk menyelesaikan masalah yang sama
Yang diberikan flakes adalah titik masuk proyek standar dan ekosistem yang dimungkinkannya, misalnya registry. Tulisan itu juga mengatakan bagian ini tidak ada di Guix
Pengguna Guix mungkin bisa menilai bahwa titik masuk standar tidak dibutuhkan, dan banyak pengguna Nix juga sudah lama menilai begitu
Tetapi mengatakan bahwa kumpulan alat ortogonal bisa melakukan apa yang dilakukan flakes terdengar mirip dengan mengatakan bahwa FreeBSD tidak perlu dukungan OCI karena semua yang dibutuhkan bisa dilakukan dengan jail. Itu melewatkan fakta bahwa standardisasi memungkinkan ekosistem
Saya sangat tertarik pada Guix dan juga pernah sedikit berkontribusi, jadi saya ingin membandingkan kenapa build dengan guix time-machine bersama channels.scm memakan waktu jauh lebih lama dibanding mengubah pin flake dan mengevaluasi Nix. Jika hanya sekitar 3 kali lebih lambat, misalnya 5–10 detik menjadi 15–30 detik, saya masih bisa menerimanya, tetapi saat saya mencobanya, hasilnya jauh dari kisaran itu

Nix Flakes dan Fitur Guix yang Menjawabnya

Perbandingan inti

Struktur dasar Nix Flake

Contoh struktur dan target eksekusi

`flake.lock` dan evaluasi murni

Pendekatan Guix

Channels dan deklarasi dependensi

Dependensi per proyek dan dependensi per pengguna

Pinning, reproduktibilitas, dan perjalanan waktu

`flake.lock`

`guix describe` dan `guix time-machine`

Perbedaan antara kedua pendekatan

Model kemurnian

Skema output dan model data

Skema output Flake

Tipe data first-class di Guix

File dan definisi package

Lingkungan pengembangan

Konfigurasi sistem

NixOS dan Flakes

Guix `operating-system`

Kemudahan eksplorasi dan registry

Model paket dan penulisan ulang graf

Pembaruan keamanan, bootstrap, autentikasi

Hubungan padanan inti dalam tabel ringkasan

Kesimpulan

1 komentar

Opini Lobste.rs

Nix Flakes dan Fitur Guix yang Menjawabnya

Perbandingan inti

Struktur dasar Nix Flake

Contoh struktur dan target eksekusi

flake.lock dan evaluasi murni

Pendekatan Guix

Channels dan deklarasi dependensi

Dependensi per proyek dan dependensi per pengguna

Pinning, reproduktibilitas, dan perjalanan waktu

flake.lock

guix describe dan guix time-machine

Perbedaan antara kedua pendekatan

Model kemurnian

Skema output dan model data

Skema output Flake

Tipe data first-class di Guix

File dan definisi package

Lingkungan pengembangan

Konfigurasi sistem

NixOS dan Flakes

Guix operating-system

Kemudahan eksplorasi dan registry

Model paket dan penulisan ulang graf

Pembaruan keamanan, bootstrap, autentikasi

Hubungan padanan inti dalam tabel ringkasan

Kesimpulan

Bacaan terkait

1 komentar

Opini Lobste.rs

`flake.lock` dan evaluasi murni

`flake.lock`

`guix describe` dan `guix time-machine`

Guix `operating-system`