Nix Flakes और Guix में उनके समकक्ष फीचर

(coopi.neocities.org)

1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Nix Flakes प्रोजेक्ट dependencies, locking, output schema और development environment को flake.nix और flake.lock के केंद्र में बाँधते हैं, जबकि Guix channels, manifests, guix describe, guix shell, operating-system जैसे orthogonal tools के संयोजन से उसी तरह की सुविधाएँ देता है
Flakes प्रोजेक्ट-स्तर के inputs और अपने-आप बनने वाली flake.lock के ज़रिए dependencies को pin करते हैं, जबकि Guix user-स्तर के guix describe, प्रोजेक्ट में commit लिखी हुई channels.scm, और guix time-machine के माध्यम से reproducible environment बनाता है
शुद्धता Flakes में restricted evaluation से लागू की जाती है, जबकि Guix में इसे Scheme module structure, explicit inputs, और isolated build containers के ज़रिए design के स्तर पर हासिल किया जाता है
Output structure में Flakes packages, devShells, nixosConfigurations जैसे standard attrset देते हैं, जबकि Guix में <package>, manifest, operating-system, service जैसी पारदर्शी Scheme records और files को हर command सीधे consume करती है
चयन का मानदंड यह है कि अगर आप single entry point और standard schema पसंद करते हैं तो Flakes उपयुक्त हैं, और अगर आप छोटे, स्वतंत्र tools को जोड़कर काम करने का तरीका पसंद करते हैं तो Guix अधिक उपयुक्त है

मुख्य तुलना

Nix flake के ठीक बराबर कोई एकल Guix feature नहीं है; Nix Flakes कई समस्याओं को एक बड़े feature से हल करते हैं, जबकि Guix छोटे और orthogonal tools के संयोजन से उसका समकक्ष देता है
Guix ने Nix daemon का पुन: उपयोग किया है और build isolation तथा store management संभालने वाले C++ components को साझा करता है
Guix ने Nix daemon के ऊपर की अधिकांश चीज़ें, जैसे language, package definitions, और service system, Guile Scheme में नए सिरे से लागू की हैं
Guix और Nix derivation format ATerm और daemon lineage साझा करते हैं, लेकिन daemon के ऊपर की संरचना Guix के अपने तरीके से बनी है
Guix के पास Flakes जैसी capabilities हैं, लेकिन वह उन्हें अलग रूप में उपलब्ध कराता है

Nix Flake की बुनियादी संरचना

Nix flake वह source tree है जिसके root में flake.nix फ़ाइल होती है, और यह आमतौर पर Git repository के रूप में होता है
flake.nix की मौजूदगी source tree को flake बनाती है, और इस फ़ाइल में description, inputs, outputs जैसी संरचना होती है
description एक human-readable string है जो बताती है कि flake क्या प्रदान करता है
inputs दूसरे flakes, Git repos, tarballs जैसी dependencies घोषित करता है, जिन्हें Nix fetch और evaluate करके outputs function को देता है
outputs एक function है जो resolved inputs और विशेष self input लेकर packages, dev shells, NixOS configurations, overlays आदि वाले structured attrset को लौटाता है
उदाहरण संरचना और execution targets
- उदाहरण inputs में nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; का मतलब है कि GitHub के NixOS/nixpkgs repository से nixos-unstable branch लाई जाएगी
- उदाहरण flake supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; और nixpkgs.lib.genAttrs का उपयोग करके कई CPU architectures के लिए outputs बनाता है
- Flakes को packages.<system> स्तर चाहिए होता है, और उदाहरण में packages के नीचे default package को pkgs.buildGoModule से परिभाषित किया गया है
- src = ./.; पूरे Git repository को source के रूप में उपयोग करता है
- devShells वह development shell definition है जिसे nix develop संदर्भित करता है, और उदाहरण में pkgs.mkShell तथा buildInputs = with pkgs; [ go gopls gotools ]; का उपयोग किया गया है
flake.lock और pure evaluation
- जब flake पर Nix command चलाई जाती है, तो Nix JSON फ़ाइल flake.lock बनाता है, जो सभी inputs और transitive inputs को सटीक revision पर pin करती है
- flake.lock एक lock file है जो machines और समय के पार build reproducibility संभव बनाती है
- Flakes pure evaluation को लागू करते हैं, इसलिए $NIX_PATH, builtins.currentSystem, और environment variables को implicit रूप से आने नहीं दिया जाता; हर चीज़ explicit होनी चाहिए
- Flakes द्वारा दी जाने वाली सुविधाओं को dependencies declaration, dependencies pinning, purity enforcement, standard output schema, reproducible sharing, और development environments definition के रूप में समेटा जा सकता है

Guix का समकक्ष तरीका

Guix के पास Nix 2.4 में 1 नवंबर 2021 को Flakes आने से पहले ही Flakes की कई सुविधाओं के लिए समाधान मौजूद थे
Guix channels mechanism लगभग 2018~2019 के दौरान पेश किया गया था
Guix का समाधान orthogonal है, और एक single monolithic abstraction अपनाने के बजाय हर टूल को स्वतंत्र रूप से इस्तेमाल किया जा सकता है
Channels और dependency declaration
- Flake में dependencies सीधे flake.nix के अंदर घोषित की जाती हैं, और उदाहरण में nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11"; तथा home-manager.url = "github:nix-community/home-manager"; का उपयोग किया गया है
- Flake input का inputs.nixpkgs.follows = "nixpkgs"; यह सुनिश्चित करता है कि home-manager अपना अलग nixpkgs input न लाए और मौजूदा flake का nixpkgs इस्तेमाल करे, जिससे nixpkgs की दो अलग copies बनने की स्थिति से बचा जा सके
- Guix के channels वे Git repository होते हैं जिनमें Guile modules शामिल होते हैं; इनमें आम तौर पर package definitions होती हैं, लेकिन services, system configurations, और मनमाना Scheme code भी शामिल हो सकता है
- Guix channels को ~/.config/guix/channels.scm में घोषित किया जाता है, और यह Scheme file channel records की list लौटाती है
- guix pull सभी channels को fetch और compile करता है, और उन modules को हर guix command में उपयोग के लिए उपलब्ध कराता है
- Channels repository root में मौजूद .guix-channel file के जरिए दूसरे channels पर dependencies घोषित कर सकते हैं
- Guix channels में channel dependency मोटे तौर पर flake के inputs जैसी है, और guix pull चलने पर transitive channel dependencies भी साथ में fetch हो जाती हैं
प्रोजेक्ट-स्तर dependencies और user-स्तर dependencies
- Flakes per-project तरीके से काम करते हैं, जहाँ हर repository का अपना flake.nix और inputs होता है, जबकि channels system-wide या per-user तरीके से काम करते हैं, जहाँ channels.scm सभी guix invocations पर लागू होता है
- Flakes स्वाभाविक रूप से अलग-अलग projects को अलग dependency set रखने देते हैं, जबकि Guix में यही प्रभाव पाने के लिए आम तौर पर guix time-machine या separate profiles का उपयोग किया जाता है
- Flakes github:NixOS/nixpkgs, git+https://... जैसी URL-like syntax का उपयोग करते हैं, जबकि channels plain Git URLs का उपयोग करते हैं
- Flake syntax quick references के लिए अधिक ergonomic है, जबकि channels अधिक सरल और explicit हैं
- Flakes flake = false; के जरिए flake.nix न रखने वाली repositories को non-flake inputs के रूप में समर्थन देते हैं
- Guix में channel एक Git repository है जिसमें Scheme files होती हैं, इसलिए किसी विशेष opt-in की जरूरत नहीं होती; Guile modules वाली कोई भी repository channel बन सकती है

Pinning, reproducibility, और time travel

flake.lock
- flake.lock एक JSON graph है, जिसमें हर input को सटीक commit hash पर pin किया जाता है और Nix fetch किए गए पूरे source tree के hash, यानी narHash, को verify करता है
- flake.lock repository में commit किया जाता है, इसलिए clone करने वाले लोगों को वही dependency versions मिलती हैं
- flake.lock में original वह target है जो मांगा गया था, और locked वह target है जो वास्तव में प्राप्त हुआ
- flake.lock का two-layer system nix flake lock --update-input nixpkgs की तरह selective update को संभव बनाता है, जिसमें सिर्फ किसी खास input को अपडेट किया जाता है और बाकी को जस का तस रखा जाता है
guix describe और guix time-machine
- Guix, guix pull चलने पर सभी channels के सटीक commits रिकॉर्ड करता है, और guix describe यह जानकारी दिखाता है
- guix describe के output में generation नंबर, तारीख, current का संकेत, channel नाम, repository URL, branch, और commit शामिल होते हैं
- Guix के recorded channel commits lock file के समकक्ष हैं, लेकिन वे project directory की file में नहीं बल्कि ~/.config/guix/current में Guile profile के रूप में मौजूद होते हैं
- reproducible environment साझा करने के लिए Guix में guix time-machine का उपयोग किया जा सकता है
- guix time-machine --commit=8a1ab328 -- shell -m manifest.scm पहले Guix को एक खास revision पर pin करता है, फिर उसी revision की package definitions का उपयोग करके guix shell चलाता है
- guix time-machine जरूरत पड़ने पर उस revision को download और compile करता है, और ऐसा isolated environment बनाता है जिसमें package definitions ठीक उसी commit state की होती हैं
- Guix में एक पैटर्न यह भी है कि pinned commits वाला channels.scm project repository में check in किया जाए
- guix time-machine -C channels.scm -- shell -m manifest.scm repository में शामिल channels.scm का उपयोग करके exact environment को reproduce करता है
दोनों तरीकों के बीच अंतर
- flake.lock per-project और automatic है, जबकि guix describe per-user और automatic है
- Pinned commits वाला channels.scm, Guix में per-project pinning देता है, लेकिन यह manual तरीका है
- Guix per-project pinning की ergonomics को बेहतर बना रहा है, लेकिन मौजूदा workflow में अभी भी अधिक explicit setup की जरूरत है
- flake.lock एक machine-readable JSON graph है, जबकि Guix का समकक्ष commit hashes वाले channels को सूचीबद्ध करने वाली Scheme file है
- दोनों तरीके dependency pinning के लक्ष्य को हासिल करते हैं, लेकिन flake lock अधिक structured है क्योंकि इसमें सभी transitive inputs के लिए original और locked entries के साथ full dependency graph होता है
- guix time-machine ऐसी सुविधा है जिसका सीधा flake equivalent नहीं है; यह सिर्फ pinned dependency versions ही नहीं, बल्कि package collection की पूरी तरह अलग historical state तक जाने की भी सुविधा देता है

शुद्धता मॉडल

Flakes restricted evaluation context में चलते हैं, और builtins.currentSystem, builtins.getEnv, $NIX_PATH का उपयोग प्रतिबंधित होता है या अनदेखा किया जाता है
Flakes में सब कुछ declared inputs से आना चाहिए, जिससे implicit state पर accidental dependency बनना कठिन हो जाता है
Flakes की pure evaluation trade-off यह है कि system detection के लिए जगह-जगह explicit system parameters की ज़रूरत पड़ती है, और environment variables पढ़ना संभव नहीं होता
Flakes में जब impure escape hatch की ज़रूरत हो, तो --impure को स्पष्ट रूप से पास करना पड़ता है
Guix में अलग pure evaluation mode की ज़रूरत नहीं होती, क्योंकि convention के स्तर पर evaluation पहले से ही pure होती है
Guile modules environment variables तक तब तक पहुंच नहीं करते जब तक उन्हें explicit रूप से पास न किया जाए
Guix में $NIX_PATH के समकक्ष कुछ नहीं है, और packages को search path के बजाय module system के जरिए resolve किया जाता है
Guix में builtins.currentSystem जैसी कोई अवधारणा नहीं है, और systems को package metadata और --system flag से explicit किया जाता है
Guix की builds भी pure होती हैं, और builds isolated containers में चलती हैं जहां सिर्फ explicitly declared inputs ही दिखाई देते हैं
Guix builds में /usr/bin, /etc, और network access नहीं होता; network access के अपवाद सिर्फ fixed-output derivations तक सीमित होते हैं
Build sandboxing के मामले में Nix और Guix मूलतः एक ही approach साझा करते हैं
Guix Scheme modules की संरचना के जरिए architecture स्तर पर purity हासिल करता है, जबकि Flakes मूल रूप से impure system के ऊपर restricted evaluation mode लगाकर purity लागू करते हैं

आउटपुट स्कीमा और डेटा मॉडल

Flake output schema
- Flakes outputs के लिए standard schema परिभाषित करते हैं, और packages.<system>.<name> का उपयोग nix build में, devShells.<system>.<name> का उपयोग nix develop में, और apps.<system>.<name> का उपयोग nix run में होता है
- Flake output schema में nixosConfigurations.<name>, overlays.<name>, nixosModules.<name>, formatter.<system>, templates.<name>, checks.<system>.<name> भी शामिल हैं
- Flake output schema की standardization से nix build ., nix run, और nix flake show लगातार एकसमान locations को refer करते हैं, जिससे discoverability बेहतर होती है
- Flake output schema की कमी यह है कि यह rigid है; arbitrary output types जोड़ने के लिए Nix खुद में बदलाव करना पड़ता है, हालांकि एक छोटा extension mechanism मौजूद है
- Flake के <system> parameter की वजह से multi-platform support को explicit रूप से संभालना पड़ता है, और forAllSystems, flake-utils, flake-parts जैसी helper functions या libraries इस्तेमाल की जाती हैं
Guix के first-class data types
- Guix में Flakes जैसा कोई एकल output schema नहीं है, बल्कि first-class data types हैं जिन्हें कई commands consume कर सकते हैं
- Guix में packages को <package> records के रूप में परिभाषित किया जाता है, और guix install, guix build उनका उपयोग करते हैं
- Guix में manifests को Scheme files के रूप में परिभाषित किया जाता है, और guix shell -m, guix package उनका उपयोग करते हैं
- Guix में system configs को operating-system के रूप में परिभाषित किया जाता है, और guix system reconfigure उनका उपयोग करता है
- Guix में home configs को home-environment के रूप में परिभाषित किया जाता है, और guix home reconfigure उनका उपयोग करता है
- Guix में services को <service> records के रूप में परिभाषित किया जाता है, और operating-system का services field इस्तेमाल होता है
- Guix में channels Git repos होते हैं, और guix pull उनका उपयोग करता है
- Guix में package variants Scheme procedures होते हैं, और --with-input, --transform का उपयोग किया जाता है
फ़ाइलें और package definitions
- Guix project package definitions वाले channel, development के लिए manifest.scm, deployment के लिए system.scm, और operating-system या home-environment declarations जैसी चीज़ों का संयोजन दे सकता है
- Guix में इन फ़ाइलों के लिए किसी special entry point file की ज़रूरत नहीं होती; ये सिर्फ Scheme values परिभाषित करने वाली Scheme files होती हैं
- Guix में command संबंधित guix subcommand को फ़ाइल देकर उसे process करता है, और अलग ceremony या schema validation की ज़रूरत नहीं होती
- उदाहरण manifest.scm development environment घोषित करने के लिए specifications->manifest को "guile", "guile-git", "guile-json" package names की list देता है
- उदाहरण mylib.scm Guix में Nix derivation के समकक्ष <package> record परिभाषित करता है, और package fields को programmatically query किया जा सकता है
- उदाहरण package definition में (name "mylib"), (version "0.1.0"), (source (local-file ".")), (build-system gnu-build-system), (inputs (list guile guile-git)), (home-page "https://example.com";), (license gpl3+) शामिल हैं
- Guix का local-file build time पर current directory की files लाता है, और यह Nix के src = ./.; जैसा है
- Guix का gnu-build-system ./configure && make && make install तरीका अपनाता है, और Guix में cmake-build-system, python-build-system जैसे दूसरे build systems भी हैं
- Guix, Nix से अलग, जहां stdenv implicit रूप से gcc और coreutils देता है, dependencies को पूरी तरह explicit रखता है

डेवलपमेंट एनवायरनमेंट

Flakes के devShells उदाहरण में devShells.x86_64-linux.default = pkgs.mkShell { buildInputs = with pkgs; [ go gopls gotools ]; shellHook = '' echo "Welcome to the devShell!" ''; }; का उपयोग किया गया है
mkShell build के समय shell environment बनाने वाला derivation जनरेट करता है, buildInputs shell के अंदर PATH में जुड़ते हैं, और shellHook shell में प्रवेश करते समय arbitrary bash चलाता है
Flake dev shell में nix develop या named shell के लिए nix develop .#my-shell से प्रवेश किया जाता है
Guix development environment को manifest.scm में specifications->manifest को package specification strings की list देकर परिभाषित किया जा सकता है
उदाहरण Guix manifest में "go", "gopls", "go-tools" घोषित हैं
Guix manifest-आधारित shell में guix shell -m manifest.scm से प्रवेश किया जाता है
Guix ad-hoc environment में बिना फ़ाइल के सिर्फ command line package names देकर guix shell go gopls go-tools की तरह काम कर सकता है
guix shell full isolation के लिए --container, standard Linux filesystem layout की अपेक्षा करने वाले प्रोग्राम चलाने के लिए --emulate-fhs, और Guix container के भीतर Guix चलाने के लिए --nesting को सपोर्ट करता है
Guix manifests बड़े flake.nix स्ट्रक्चर में embedded नहीं होते, बल्कि standalone Scheme files होते हैं
guix shell बिना फ़ाइल के भी काम कर सकता है, लेकिन nix develop को flake या legacy interface के shell.nix की ज़रूरत होती है
Flakes devShells.x86_64-linux.test, devShells.x86_64-linux.default जैसे named dev shells प्रदान करते हैं
Guix manifests named dev shells की जगह manifest.scm, test-manifest.scm जैसी अलग-अलग फ़ाइलें साथ रखकर काम करते हैं
Nix Flakes और Guix दोनों containerized development को सपोर्ट करते हैं

सिस्टम कॉन्फ़िगरेशन

NixOS और Flakes
- Flakes के nixosConfigurations उदाहरण में nixpkgs.lib.nixosSystem NixOS modules की list लेकर kernel, services, config files आदि सहित full system derivation जनरेट करता है
- Flake-आधारित NixOS deployment का उदाहरण command nixos-rebuild switch --flake .#myhost है
- उदाहरण nixosConfigurations.myhost में system = "x86_64-linux"; और modules = [ ./configuration.nix home-manager.nixosModules.home-manager ]; शामिल हैं
- NixOS modules एक module system है जो options, config, mkIf, mkDefault, mkForce के जरिए priority-based merging का उपयोग करता है
- NixOS module system में कई modules एक ही option सेट करें तब भी सिस्टम priority resolve कर लेता है, इसलिए दर्जनों modules एक ही configuration में योगदान दें तब भी conflict से बचना आसान होता है
Guix operating-system
- Guix का operating-system function नहीं बल्कि एक Scheme record है, और हर field एक named typed value होती है जिसे Guix validate करता है
- Guix system deployment का उदाहरण command guix system reconfigure config.scm है
- उदाहरण operating-system record में (host-name "myhost"), (timezone "Etc/UTC"), bootloader configuration, file systems, और services शामिल हैं
- Guix bootloader configuration के उदाहरण में grub-efi-bootloader और target "/boot/efi" का उपयोग होता है, और Guix GRUB, U-Boot आदि को सपोर्ट करता है
- Guix file systems list के रूप में घोषित किए जाते हैं, और %base-file-systems /dev, /proc, /sys आदि के लिए defaults देता है
- Guix services directed acyclic graph(DAG) बनाती हैं, और हर service दूसरी services को extend कर सकती है
- %base-services Shepherd init system, syslog, networking जैसी आवश्यक services प्रदान करता है
- Guix system configuration में किसी special output type की ज़रूरत नहीं होती; operating-system record लौटाने वाली फ़ाइल को guix system में देना पर्याप्त है
- Guix की service composition नई services लिखना आसान बनाती है जिन्हें मौजूदा सिस्टम में मनचाहे तरीके से जोड़ा जा सके

खोजयोग्यता और रजिस्ट्री

Flakes में flake.nix एक standard entry point है, जिसमें project dependencies, outputs, और discoverable schema एक ही फ़ाइल में घोषित किए जाते हैं
Guix projects manifest.scm, channels.scm, guix.scm, package.scm जैसी convention-based फ़ाइलों का उपयोग कर सकते हैं
guix shell द्वारा अपने-आप पहचानी जाने वाली project file के रूप में guix.scm को standardize करने की कोशिशें हैं, लेकिन यह flake.nix जितना स्थापित नहीं हुआ है
Flakes में छोटा नाम URL से map करने वाली global registry flake-registry है, उदाहरण के लिए nix run nixpkgs#hello, nix build github:NixOS/nixpkgs#firefox
Guix समान सुविधा के लिए package specifications का उपयोग करता है, उदाहरण के लिए guix shell hello, guix install firefox
Guix में किसी arbitrary Git repository को छोटे नाम से संदर्भित करने वाली registry-जैसी समकक्ष व्यवस्था नहीं है, इसलिए URL सीधे इस्तेमाल किए जाते हैं
Nix registry कभी-कभी भ्रम का स्रोत रही है क्योंकि हमेशा यह स्पष्ट नहीं होता कि nixpkgs registry entry है, local path है, या कोई और target
nix flake show वह command है जो flake द्वारा प्रदान की गई सभी चीज़ों को tree view में दिखाता है
Guix में packages के लिए guix search और services के लिए guix system search हैं, लेकिन किसी खास project या repository द्वारा दी गई सभी चीज़ें दिखाने वाला समकक्ष command नहीं है; इसके लिए Scheme files सीधे देखनी पड़ती हैं
Flakes की discoverability इस मायने में मज़बूत है कि nix flake show project द्वारा प्रदान की गई चीज़ों का consistent view दिखाता है
Guix projects अधिक ad-hoc होते हैं; आपको पता होना चाहिए कि कौन-सी फ़ाइल देखनी है, और कोई standard single-entry-point file नहीं होती
Guix में सब कुछ Scheme होने के कारण बिना schema के भी मनचाही चीज़ें परिभाषित और संयोजित की जा सकती हैं, इसलिए flexibility मज़बूत है

पैकेज मॉडल और ग्राफ री-राइटिंग

Nix में पैकेज stdenv.mkDerivation { ... } कॉल के ज़रिए derivation लौटाने वाले functions होते हैं, और उनका परिणाम एक opaque attribute set होता है
Guix में पैकेज <package> record होता है, जो नामित fields वाला एक transparent data structure है, इसलिए इसे standard Scheme procedures से inspect, transform और combine किया जा सकता है
Guix package definitions opaque functions नहीं बल्कि transparent records हैं, इसलिए special tooling के बिना inspect और transform को programmatically किया जा सकता है
Guix में packages data होते हैं, इसलिए graph rewrites आसानी से किए जा सकते हैं
Guix में package-input-rewriting के ज़रिए पूरे dependency graph को traverse करके perl को perl-minimal से बदलने का काम व्यक्त किया जा सकता है
Guix का inherit keyword coreutils के सभी fields को inherit करके केवल बताए गए fields को override करने के तरीके से पैकेज को redefine करता है
Nix में इसी तरह के उद्देश्य के लिए overlays हैं, लेकिन opaque function interface की वजह से inspect और transform करना ज़्यादा कठिन है, इसलिए usability कम हो जाती है

सुरक्षा अपडेट, बूटस्ट्रैप, प्रमाणन

Guix का grafting सभी dependency packages को फिर से build किए बिना dependency tree में सुरक्षा अपडेट लागू करने देता है
जब glibc जैसी low-level libraries में vulnerability होती है, तब Guix store paths को rewrite करके उन्हें patched version से बदल सकता है
Nix सुरक्षा अपडेट की स्थिति में सब कुछ फिर से build करता है, और बड़े dependency tree में build time में कई घंटों का अंतर हो सकता है
Guix source-based bootstrapping पर बहुत ज़ोर देता है, और पूरे system को एक छोटे trust base से build किया जा सकता है
Guix की bootstrap chain लगभग 500-byte hex assembler से शुरू होकर, Scheme में लिखे गए mes C compiler, tcc, और पूरे GNU toolchain तक जाती है
bootstrappable builds प्रोजेक्ट full-source bootstrap के पूरे विवरण को कवर करता है
Nix, Guix की तुलना में, ज़्यादा binary seeds पर निर्भर करता है
अगर bootstrap chain का audit नहीं किया जा सकता, तो यह पूरी तरह verify नहीं किया जा सकता कि system वास्तव में इच्छित source से build हुआ है या नहीं, इसलिए full-source bootstrapping trust और verifiability के लिए महत्वपूर्ण है
Guix channels में डिफ़ॉल्ट रूप से cryptographic authentication का समर्थन होता है
Guix channel एक “introduction” निर्दिष्ट करता है, जो किसी खास commit और उसके Ed25519 signature से बना होता है, और Guix उस introduction से current commit तक पूरी signature chain को verify करता है
Flakes trust model के रूप में HTTPS और GitHub infrastructure का उपयोग करते हैं, जो Guix के Ed25519 channel authentication से अलग security model है

सारांश तालिका में मुख्य समकक्ष संबंध

dependency declaration के लिए Flakes flake.nix के inputs का उपयोग करते हैं, जबकि Guix channels.scm और .guix-channel का उपयोग करता है
dependency pinning के लिए Flakes automatic, project-specific flake.lock का उपयोग करते हैं, जबकि Guix user-specific automatic guix describe और project-specific manual commit specification channels.scm का उपयोग करता है
pure evaluation flake mode में enforce होती है, और Guix में यह design के स्तर पर अंतर्निहित गुण है
output schema में Flakes outputs का structured attrset इस्तेमाल करते हैं, जबकि Guix ad-hoc Scheme records का उपयोग करता है
development environment के लिए Flakes devShells और nix develop का उपयोग करते हैं, जबकि Guix manifest.scm और guix shell का उपयोग करता है
system configuration के लिए Flakes nixosConfigurations और module system का उपयोग करते हैं, जबकि Guix operating-system और service DAG का उपयोग करता है
one-command reproducibility के लिए Flakes nix build github:foo/bar का उपयोग करते हैं, जबकि Guix guix time-machine -C channels.scm -- build फ़ॉर्म का उपयोग करता है
project-specific pinning को Flakes flake.lock से अपने-आप संभालते हैं, जबकि Guix commit शामिल channels.scm से इसे manually संभालता है
discoverability के लिए Flakes nix flake show देते हैं, जबकि Guix Scheme module inspection पर निर्भर करता है
package model में Flakes/Nix opaque functions का उपयोग करते हैं, जबकि Guix transparent records का
init system के रूप में Nix systemd और Guix GNU Shepherd का उपयोग करता है
security updates में Nix full rebuild करता है, जबकि Guix तेज़ grafting का उपयोग करता है
bootstrap trust के लिए Nix binary seeds पर, और Guix full-source bootstrap पर आधारित है
authenticated updates में Flakes HTTPS/GitHub trust model, और Guix Ed25519 channel authentication का उपयोग करता है
FHS support के लिए Nix buildFHSUserEnv और Guix --emulate-fhs प्रदान करता है
non-Linux support में Nix macOS के लिए nix-darwin देता है, जबकि Guix GNU Hurd के साथ व्यवस्थित है
केवल free software के मामले में Nix अनिवार्य रूप से ऐसा नहीं है और configurable है, जबकि Guix FSDG का पालन करता है

निष्कर्ष

Flakes और Guix reproducibility, dependency management और system declaration जैसी एक ही तरह की समस्याओं को अलग-अलग architectural philosophies से हल करते हैं
Flakes एक single feature के काफ़ी करीब हैं, जिसमें एक file, एक schema, एक lock file और conventions का एक set होता है
Guix distribution के लिए channels, environments के लिए manifests, configuration के लिए operating-system, reproducibility के लिए guix time-machine, और अन्य संरचनाओं के लिए Scheme records जैसे orthogonal tools का संयोजन है
अगर आप एक standard तरीका, एक entry-point file, एक output schema और एक lock format को पसंद करते हैं, तो Flakes स्वाभाविक रूप से उपयुक्त लगेंगे
अगर आप छोटे, स्वतंत्र tools को जोड़कर इस Unix philosophy को package management पर लागू करना पसंद करते हैं कि हर tool एक काम बहुत अच्छी तरह करे, तो Guix बेहतर मेल खाएगा
दोनों ecosystems इस विचार के इर्द-गिर्द विकसित हुए हैं कि package management functional, declarative और reproducible होना चाहिए, और वे अलग implementations के साथ उसी विचार को आगे बढ़ा रहे हैं

1 टिप्पणियां

GN⁺ 5 시간 전

Lobste.rs की रायें

यह साइट मोबाइल पर पढ़ने में बहुत परेशान करती है: टेक्स्ट थोड़ा छोटा है, और हर बार स्क्रॉल करने पर बाधा डालती रहती है
पहली तुलना के बाद मैं आगे पढ़ ही नहीं पाया, क्योंकि यह बार-बार विषय-सूची पर वापस उछाल देती थी
- बिल्कुल पढ़ा ही नहीं जा सकता। यो-यो की तरह हिलती रहती है। यह हाल के समय के उन लेखों में से एक था जिन्हें मैं सच में पढ़ना चाहता था, इसलिए इतनी हताशाजनक reading experience देखकर निराशा हुई
- डेस्कटॉप पर भी यही होता है। यह बेतुका है, और ऐसा लगता है जैसे जानबूझकर accessibility खराब की गई हो
लेख पढ़ने के बाद भी मुझे अब तक ठीक से समझ नहीं आया कि प्रोजेक्ट की dependencies को कैसे specify और pin करना है। Deploy और share करने के लिए ऐसा लगता है कि channels.scm में हर transitive dependency का commit hash हाथ से ढूँढकर डालना पड़ता है
time-machine शायद सिर्फ Guix package set पर काम करता है, out-of-tree dependencies पर नहीं
nix run github:nixos/nixpkgs/<commit hash>#<package> की तरह nixpkgs के पुराने point-in-time code को भी काफी आसानी से चलाया जा सकता है
Guix की एक अनोखी बात यह है कि यह package collection version और package manager version को अलग नहीं करता। पुराना package चलाने के लिए पुरानी Guix release भी साथ चलानी पड़ती है, और मुझे समझ नहीं आता कि कोई ऐसा क्यों चाहेगा
लेख में कहा गया है कि flakes में commits हाथ से ढूँढकर specify करने पड़ते हैं, और उसके तुरंत बाद ऐसे Guix command का उदाहरण दिया गया है जिसमें commits specify करने पड़ते हैं। Nix flake में भी --override-input से nixpkgs version override किया जा सकता है, लेकिन यह गंदा लगता है, और unflake जिन चीज़ों को बेहतर करना चाहता है उनमें यह भी एक है
- मेरा Guix अनुभव लेखक से कम है, लेकिन मैंने docs कुछ हद तक देखी हैं, तो कुछ जवाब देने की कोशिश करता हूँ
  आमतौर पर flow यह होता है कि पहले dedicated guix shell environment में development करो, फिर share करने के चरण पर guix describe -f channels > channels.scm चलाकर सभी commit hashes को channels.scm में लिख लो
  declaring channel dependencies docs देखने पर dependencies के commits specify किए जा सकते हैं, लेकिन अगर उन dependencies की भी dependencies हों, तो वे भी किसी specific commit पर pinned हैं या नहीं, इसे verify करने का कोई option नहीं दिखता
  time-machine का --commit= notation Guix channels के लिए है, लेकिन -C से file से अतिरिक्त channels भी लोड किए जा सकते हैं
  इससे यह फ़ायदा होता है कि package manager और package records में breaking changes होने पर भी history और reproducibility नहीं खोती
- इसके लिए nixpkgs का reverse index बनाया जा सकता है: जैसे nixpkgs के commit X से Y तक किसी खास package का version A शामिल है
  लेकिन हर commit के लिए nixpkgs checkout चाहिए होगा, इसलिए शुरुआत में इसे बनाना बहुत महँगा पड़ेगा। एक बार बन जाने के बाद index को maintain करना सस्ता होगा
मैंने साइट की समस्या और इस thread के बारे में coopi को बता दिया है, उम्मीद है जल्दी ठीक हो जाएगा
पूरी तरह Guix की तरफ झुक चुके नज़रिए से भी, जैसा coopi ने कहा, अच्छा होता अगर Guix में भी Nix की तरह कोई standard file/directory होती, जैसे एक flake.nix या एक nix directory, जिसमें सब कुछ समा जाए। हालाँकि Scheme modules import करने के लिए सही path specify करना पड़ता है, इसलिए शायद यह संभव न हो
इस Lobsters पोस्ट में वही बातें हैं जिनका लेखक ज़िक्र करता है, इसलिए nix और lisp टैग ही काफ़ी लगते हैं
- linux हटाने की बात मुझे convincing नहीं लगी। दोनों के बीच साझा एकमात्र kernel वही है :P हालाँकि जैसा कहा गया, unix शायद यहाँ फिट नहीं बैठता
- flakes की तरह, channels क्या provide करते हैं यह automatically infer करने में मदद करने वाला कोई structured channel data type भी अच्छा होगा
  उदाहरण के लिए कुछ ऐसा:
```
(channel  
  (operating-systems  
    (list my-vm))  
  (services  
    (list my-system-service)))  
```
  और नए channels बनाने और संभालने में मदद करने वाला guix channel command भी अच्छा होगा
क्या Guix में भी Nix flake के .inputs.nixpkgs.follows जैसा कोई feature है जो transitive dependencies के pinned values को override कर सके?
और लेखक की Guix संबंधी व्याख्या का बड़ा हिस्सा flakes से पहले वाले Nix की याद दिलाता है: standard entrypoint नहीं, channels का इस्तेमाल वगैरह। लेकिन Guix में type system और एक असली language होने के कारण लगता है कि वही patterns वहाँ कम दर्दनाक हैं। यह किसी ऐसी alternate history जैसा लगता है जो Nix बेहतर होता या किसी और language में लिखा गया होता तो बन सकती थी
- उस feature का इस्तेमाल किस लिए होता है?
दूसरे comments में बताई गई usability problems की वजह से इसे recommend करने में हिचक हो रही है। मैं NoScript इस्तेमाल करता हूँ जिसमें JavaScript डिफ़ॉल्ट रूप से बंद रहता है, इसलिए मुझे यह दिखा ही नहीं
फिर भी यह लेख बिल्कुल सही समय पर आया। हमारी company Nix का काफी ज़्यादा इस्तेमाल करने की दिशा में जा रही है और flakes की वजह से थोड़ी मशक्कत हो रही है, लेकिन इस लेख की व्याख्या पहले पढ़ी चीज़ों की तुलना में कहीं अधिक स्पष्ट थी
- Coopi के मुताबिक, उन्होंने JavaScript या CSS के बिना भी पढ़े जा सकने लायक progressive enhancement अपनाने की कोशिश की थी, और JavaScript वाला हिस्सा बिगड़ गया, लेकिन कम-से-कम वह philosophy काम कर रही थी। अब तक JavaScript भी शायद ठीक हो चुका होगा
Coopi का जवाब: आज सुबह बदलाव किया था, लेकिन काम की वजह से test नहीं कर पाए, और बाद में पता चला कि JavaScript में समस्या थी
यह साइट iOS मोबाइल पर इस्तेमाल नहीं की जा सकती। लगता है पेज नीचे से लोड होने के बाद तुरंत ऊपर scroll हो जाता है, और मैं अगर एक screen से ज़्यादा नीचे जाता हूँ तो कुछ trigger होकर फिर से ऊपर भेज देता है
reading mode काम करता है, लेकिन highlighting और बाकी जो काफ़ी अच्छी detail styling थी, वह गायब हो जाती है
यह कहना सही है कि flakes जो करते हैं वह Guix के कई tools से भी किया जा सकता है, लेकिन यह भी कहना चाहिए कि Nix में भी यही समस्याएँ हल करने वाले छोटे और orthogonal tools पहले से थे और अब भी हैं
flakes जो देते हैं वह है standard project entrypoint और उससे संभव होने वाला ecosystem, जैसे registry। लेख में भी कहा गया है कि Guix में यह हिस्सा नहीं है
Guix उपयोगकर्ता मान सकते हैं कि standard entrypoint की ज़रूरत नहीं है, और बहुत से Nix उपयोगकर्ता भी अब तक ऐसा मानते आए हैं
लेकिन यह कहना कि orthogonal tools के सेट से flakes जैसी चीज़ की जा सकती है, कुछ वैसा लगता है जैसे कहना कि FreeBSD में jail से ज़रूरी सब हो जाता है इसलिए OCI support की ज़रूरत नहीं। यह इस बात को नज़रअंदाज़ करता है कि standardization ही ecosystem को संभव बनाती है
मुझे Guix में बहुत रुचि है और थोड़ा योगदान भी किया है, इसलिए मैं तुलना करना चाहूँगा कि channels.scm के साथ guix time-machine से build करना, flake pin बदलकर Nix evaluation करने की तुलना में इतना ज़्यादा समय क्यों लेता है। अगर यह लगभग 3 गुना धीमा हो, जैसे 5~10 सेकंड की जगह 15~30 सेकंड, तो मैं उसे स्वीकार कर सकता हूँ, लेकिन जब मैंने कोशिश की थी, तब मामला उससे कहीं ज़्यादा था

Nix Flakes और Guix में उनके समकक्ष फीचर

मुख्य तुलना

Nix Flake की बुनियादी संरचना

उदाहरण संरचना और execution targets

`flake.lock` और pure evaluation

Guix का समकक्ष तरीका

Channels और dependency declaration

प्रोजेक्ट-स्तर dependencies और user-स्तर dependencies

Pinning, reproducibility, और time travel

`flake.lock`

`guix describe` और `guix time-machine`

दोनों तरीकों के बीच अंतर

शुद्धता मॉडल

आउटपुट स्कीमा और डेटा मॉडल

Flake output schema

Guix के first-class data types

फ़ाइलें और package definitions

डेवलपमेंट एनवायरनमेंट

सिस्टम कॉन्फ़िगरेशन

NixOS और Flakes

Guix `operating-system`

खोजयोग्यता और रजिस्ट्री

पैकेज मॉडल और ग्राफ री-राइटिंग

सुरक्षा अपडेट, बूटस्ट्रैप, प्रमाणन

सारांश तालिका में मुख्य समकक्ष संबंध

निष्कर्ष

1 टिप्पणियां

Lobste.rs की रायें

Nix Flakes और Guix में उनके समकक्ष फीचर

मुख्य तुलना

Nix Flake की बुनियादी संरचना

उदाहरण संरचना और execution targets

flake.lock और pure evaluation

Guix का समकक्ष तरीका

Channels और dependency declaration

प्रोजेक्ट-स्तर dependencies और user-स्तर dependencies

Pinning, reproducibility, और time travel

flake.lock

guix describe और guix time-machine

दोनों तरीकों के बीच अंतर

शुद्धता मॉडल

आउटपुट स्कीमा और डेटा मॉडल

Flake output schema

Guix के first-class data types

फ़ाइलें और package definitions

डेवलपमेंट एनवायरनमेंट

सिस्टम कॉन्फ़िगरेशन

NixOS और Flakes

Guix operating-system

खोजयोग्यता और रजिस्ट्री

पैकेज मॉडल और ग्राफ री-राइटिंग

सुरक्षा अपडेट, बूटस्ट्रैप, प्रमाणन

सारांश तालिका में मुख्य समकक्ष संबंध

निष्कर्ष

संबंधित पढ़ाई

1 टिप्पणियां

Lobste.rs की रायें

`flake.lock` और pure evaluation

`flake.lock`

`guix describe` और `guix time-machine`

Guix `operating-system`