Nix Flakes ve buna karşılık gelen Guix özellikleri

• Nix Flakes, proje bağımlılıklarını, kilitlemeyi, çıktı şemasını ve geliştirme ortamlarını flake.nix ile flake.lock etrafında bir araya getirirken, Guix aynı tür işlevleri channels, manifests, guix describe, guix shell, operating-system gibi birbirine dik araçların birleşimiyle sunar
• Flakes, proje bazlı inputs ve otomatik flake.lock ile bağımlılıkları sabitler; Guix ise kullanıcı bazlı guix describe, projede commit’lerin yazılı olduğu channels.scm ve guix time-machine ile yeniden üretilebilir ortamlar kurar
• Saflık, Flakes’te restricted evaluation ile zorunlu kılınırken, Guix’te Scheme modül yapısı, açık girdiler ve yalıtılmış build container’ları üzerinden tasarım gereği sağlanır
• Çıktı yapısı bakımından Flakes packages, devShells, nixosConfigurations gibi standart attrset’ler sunarken, Guix’te <package>, manifest, operating-system, service gibi şeffaf Scheme kayıtları ve dosyaları doğrudan ilgili komutlar tüketir
• Seçim ölçütü olarak tek bir giriş noktası ve standart bir şema tercih ediliyorsa Flakes uygundur; küçük ve bağımsız araçları birleştiren bir yaklaşım tercih ediliyorsa Guix daha iyi uyar

---

Temel karşılaştırma

• Nix flake’e karşılık gelen tek bir Guix özelliği yoktur; Nix Flakes birden çok sorunu tek büyük bir özellikle çözerken Guix buna daha küçük ve birbirine dik araçların birleşimiyle karşılık verir
• Guix, Nix daemon’ını yeniden kullanır ve build isolation ile store management’tan sorumlu C++ bileşenlerini paylaşır
• Guix, Nix daemon’ın üzerindeki dil, paket tanımları, service sistemi gibi katmanların çoğunu Guile Scheme ile baştan uygular
• Guix ile Nix, ATerm olan derivation formatını ve daemon soyunu paylaşsa da daemon üzerindeki yapı Guix’in kendi yaklaşımıyla kuruludur
• Guix, Flakes’in sunduğu yeteneklere sahiptir, ancak bunları farklı bir biçimde sunar

Nix Flake’in temel yapısı

• Nix flake, kök dizininde flake.nix dosyası bulunan bir source tree’dir ve genellikle bir Git repository biçimindedir
• flake.nix dosyasının varlığı source tree’yi bir flake yapar; bu dosya description, inputs, outputs gibi bir yapıya sahiptir
• description, flake’in ne sunduğunu anlatan, insanlar tarafından okunabilir bir metindir
• inputs, diğer flakes, Git repos, tarballs gibi dependencies’i tanımlar; Nix bunları fetch edip evaluate ettikten sonra outputs fonksiyonuna iletir
• outputs, çözümlenmiş girdileri ve özel self girdisini alıp packages, dev shells, NixOS configurations, overlays ve benzerlerini içeren yapılandırılmış bir attrset döndüren bir fonksiyondur

• Örnek yapı ve yürütme hedefleri

  • Örnek inputs içindeki nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";, GitHub’daki NixOS/nixpkgs deposundan nixos-unstable branch’inin alınacağı anlamına gelir
  • Örnek flake, supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; ve nixpkgs.lib.genAttrs kullanarak birden fazla CPU architecture için outputs üretir
  • Flakes, packages.<system> düzeyini zorunlu kılar; örnekte packages altındaki default package, pkgs.buildGoModule ile tanımlanır
  • src = ./.;, tüm Git repository’yi source olarak kullanır
  • devShells, nix develop komutunun başvurduğu geliştirme shell tanımıdır; örnekte pkgs.mkShell ve buildInputs = with pkgs; [ go gopls gotools ]; kullanılır

• flake.lock ve saf değerlendirme

  • Bir flake üzerinde Nix komutları çalıştırıldığında Nix, tüm input’ları ve geçişli input’ları tam revision’lara sabitleyen JSON dosyası flake.locku oluşturur
  • flake.lock, makineler ve zaman boyunca build reproducibility sağlayan bir lock file’dır
  • Flakes, pure evaluation’ı zorunlu kılar; $NIX_PATH, builtins.currentSystem, environment variables örtük olarak içeri giremez ve her şeyin açıkça belirtilmesi gerekir
  • Flakes’in sunduğu işlevler; dependencies tanımlama, dependencies sabitleme, saflığı zorlama, standart bir output schema sağlama, yeniden üretilebilir paylaşım ve development environment tanımlama olarak özetlenebilir

Guix'in karşılık gelen yaklaşımı

• Guix, Nix 2.4'te Flakes'in 1 Kasım 2021'de sunulmasından önce, Flakes özelliklerinin önemli bir kısmı için zaten çözümler sunuyordu
• Guix channels mekanizması yaklaşık 2018~2019 döneminde tanıtıldı
• Guix'in çözümü orthogonal yapıdadır; tek bir monolitik soyutlama benimsemek yerine her araç bağımsız olarak kullanılabilir

• Channels ve bağımlılık bildirimi

  • Flake'te bağımlılıklar doğrudan flake.nix içinde tanımlanır; örnekte nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11"; ve home-manager.url = "github:nix-community/home-manager"; kullanılır
  • Flake input'taki inputs.nixpkgs.follows = "nixpkgs";, home-managerın kendi nixpkgs input'unu almaması ve mevcut flake'in nixpkgsini kullanması için ayarlanır; böylece iki farklı nixpkgs kopyasının oluşması önlenir
  • Guix'in channels yapısı, Guile modülleri içeren Git repository'leridir; genellikle paket tanımları içerir ama services, system configurations ve rastgele Scheme code da barındırabilir
  • Guix channels, ~/.config/guix/channels.scm içinde tanımlanır ve bu Scheme dosyası channel kayıtlarından oluşan bir liste döndürür
  • guix pull, tüm channels'ı fetch edip compile eder ve ilgili modülleri tüm guix komutlarında kullanılabilir hale getirir
  • Channels, repository kök dizinindeki .guix-channel dosyasını kullanarak diğer channels'a bağımlılık bildirebilir
  • Guix channels içindeki channel bağımlılıkları, flake'in inputs yapısına kabaca benzer; guix pull çalıştırıldığında transitive channel dependencies de birlikte fetch edilir

• Proje bazlı bağımlılıklar ve kullanıcı bazlı bağımlılıklar

  • Flakes proje başına çalışır; her repository kendi flake.nix dosyasına ve input'larına sahiptir. Channels ise system-wide ya da per-user şekilde çalışır ve channels.scm, tüm guix çağrılarına uygulanır
  • Flakes, farklı projelerin doğal biçimde farklı bağımlılık setlerine sahip olmasını destekler; Guix'te aynı etki için genellikle guix time-machine veya ayrı profiller kullanılır
  • Flakes, github:NixOS/nixpkgs, git+https://... gibi URL benzeri bir sözdizimi kullanırken channels düz Git URL'leri kullanır
  • Flake sözdizimi hızlı referanslar için daha ergonomiktir; channels ise daha basit ve explicit'tir
  • Flakes, flake = false; ile flake.nix içermeyen repository'leri non-flake input olarak destekler
  • Guix'te channel, içinde Scheme dosyaları bulunan bir Git repository olduğundan özel bir opt-in gerekmez; Guile modülleri içeren herhangi bir repository channel olabilir

Sabitleme, yeniden üretilebilirlik ve zamanda geri gitme

• flake.lock

  • flake.lock bir JSON graph'tır; tüm input'lar tam commit hash'leriyle pin edilir ve Nix, fetch edilen source tree'nin tamamının hash'i olan narHash değerini doğrular
  • flake.lock repository'ye commit edildiği için, repository'yi clone eden herkes aynı dependency versions'larını alır
  • flake.lock içindeki original, istenen hedefi; locked ise gerçekten elde edilen hedefi gösterir
  • flake.lock içindeki two-layer system, nix flake lock --update-input nixpkgs örneğinde olduğu gibi yalnızca belirli bir input'u güncelleyip diğerlerini koruyan selective update olanağı sağlar

• guix describe ve guix time-machine

  • Guix, guix pull çalıştırıldığında tüm channels'ın tam commit'lerini kaydeder ve guix describe bu bilgiyi gösterir
  • guix describe çıktısı generation numarası, tarih, current işareti, channel adı, repository URL'si, branch ve commit bilgilerini içerir
  • Guix'in kaydedilmiş channel commit'leri bir lock file karşılığıdır, ancak proje dizinindeki bir dosya olarak değil, ~/.config/guix/current altında bir Guile profile olarak bulunur
  • Yeniden üretilebilir ortamları paylaşmak için Guix'te guix time-machine kullanılabilir
  • guix time-machine --commit=8a1ab328 -- shell -m manifest.scm, önce Guix'in kendisini belirli bir revision'a pin eder, ardından o revision'daki paket tanımlarını kullanarak guix shell çalıştırır
  • guix time-machine, gerekirse ilgili revision'ı download edip compile eder ve paket tanımları tam olarak o commit durumunda olan izole bir ortam oluşturur
  • Proje repository'sine pin edilmiş commit'ler içeren channels.scm dosyasını check in etme şeklinde bir Guix deseni de vardır
  • guix time-machine -C channels.scm -- shell -m manifest.scm, repository içinde yer alan channels.scm dosyasını kullanarak exact environment'ı yeniden üretir

• İki yaklaşım arasındaki fark

  • flake.lock proje bazlı ve automatic iken, guix describe kullanıcı bazlı ve automatic'tir
  • İçinde pinned commit'ler bulunan channels.scm, Guix'te proje bazlı pinning sağlar ama manual bir yaklaşımdır
  • Guix, proje bazlı pinning ergonomics'ini iyileştiriyor ancak mevcut workflow hâlâ daha explicit bir kurulum gerektiriyor
  • flake.lock machine-readable bir JSON graph iken, Guix'teki karşılığı commit hash'leri içeren channel'ları listeleyen bir Scheme dosyasıdır
  • Her iki yaklaşım da dependency pinning hedefini gerçekleştirir, ancak flake lock tüm transitive input'lar için original ve locked girdileri içeren tam bir dependency graph sunduğundan daha structured'dır
  • guix time-machine, birebir bir flake karşılığı olmayan bir özelliktir; yalnızca sabitlenmiş bağımlılık sürümlerine değil, paket koleksiyonunun tamamen farklı tarihsel durumlarına da geçiş yapabilir

Saflık modeli

• Flakes, restricted evaluation context içinde çalışır; builtins.currentSystem, builtins.getEnv, $NIX_PATH kullanımı yasaktır ya da yok sayılır
• Flakes'te her şey declared inputs içinden gelmelidir; bu da implicit state'e accidental dependency oluşmasını zorlaştırır
• Flakes'in pure evaluation açısından trade-off'u, system detection için her yerde açık system parametrelerinin gerekmesi ve environment variables okunamamasıdır
• Flakes'te impure bir escape hatch gerektiğinde --impure açıkça verilmelidir
• Guix'te ayrı bir pure evaluation mode gerekmez; evaluation, teamül gereği zaten saftır
• Guile modülleri, açıkça environment variables olarak aktarılmadıkça bunlara erişmez
• Guix'te $NIX_PATH karşılığı bir yapı yoktur; paketler bir search path yerine module system üzerinden çözümlenir
• Guix'te builtins.currentSystem karşılığı bir kavram yoktur; sistemler package metadata ve --system bayrağıyla açıkça belirtilir
• Guix'in build süreci de saftır; build'ler yalnızca açıkça tanımlanmış girdileri görebilen isolated container'larda çalışır
• Guix build'lerinde /usr/bin, /etc ve network access yoktur; network access istisnası fixed-output derivations ile sınırlıdır
• Build sandboxing yaklaşımı bakımından Nix ve Guix özünde aynı yaklaşımı paylaşır
• Guix, Scheme modül yapısı üzerinden mimari düzeyde saflık sağlar; Flakes ise aslında impure olan bir sistemin üzerine restricted evaluation mode ekleyerek saflığı zorunlu kılar

Çıktı şeması ve veri modeli

• Flake output schema

  • Flakes, outputs için standard bir şema tanımlar ve packages.<system>.<name> nix build, devShells.<system>.<name> nix develop, apps.<system>.<name> ise nix run tarafından kullanılır
  • Flake output schema içinde nixosConfigurations.<name>, overlays.<name>, nixosModules.<name>, formatter.<system>, templates.<name>, checks.<system>.<name> de bulunur
  • Flake output schema'nın standardizasyonu, nix build ., nix run, nix flake show komutlarının tutarlı konumlara bakmasını sağlayarak discoverability'yi artırır
  • Flake output schema'nın dezavantajı rigid olmasıdır; keyfi output types eklemek için Nix'in kendisini değiştirmek gerekir, ancak küçük bir extension mechanism mevcuttur
  • Flake'teki <system> parametresi nedeniyle multi-platform support açık biçimde ele alınmalıdır; bunun için forAllSystems, flake-utils, flake-parts gibi helper functions veya libraries kullanılır

• Guix'in first-class data types yapısı

  • Guix'te Flakes'teki gibi tek bir output schema yoktur; bunun yerine çeşitli komutların tüketebildiği first-class data types bulunur
  • Guix'te paketler <package> records olarak tanımlanır ve guix install, guix build bunları kullanır
  • Guix'te manifest'ler Scheme dosyaları olarak tanımlanır ve guix shell -m, guix package tarafından kullanılır
  • Guix'te sistem yapılandırmaları operating-system olarak tanımlanır ve guix system reconfigure tarafından kullanılır
  • Guix'te home yapılandırmaları home-environment olarak tanımlanır ve guix home reconfigure tarafından kullanılır
  • Guix'te servisler <service> records olarak tanımlanır ve operating-system içindeki services alanı tarafından kullanılır
  • Guix'te channel'lar Git depolarıdır ve guix pull tarafından kullanılır
  • Guix'te package variants Scheme procedures şeklindedir ve --with-input, --transform tarafından kullanılır

• Dosyalar ve paket tanımları

  • Bir Guix projesi, package definitions içeren bir channel, geliştirme için manifest.scm, dağıtım için system.scm, operating-system veya home-environment declaration'ları gibi bileşenleri birlikte sunabilir
  • Guix'te bu dosyalar özel bir entry point file gerektirmez; bunlar yalnızca Scheme values tanımlayan Scheme dosyalarıdır
  • Guix'te ilgili guix alt komutuna dosya belirtilmesi yeterlidir; komut dosyayı işler ve ayrıca ceremony ya da schema validation gerekmez
  • Örnek manifest.scm, geliştirme ortamını tanımlamak için specifications->manifest fonksiyonuna "guile", "guile-git", "guile-json" paket adlarından oluşan bir liste verir
  • Örnek mylib.scm, Guix'in Nix derivation karşılığı olan <package> record'unu tanımlar ve package fields programatik olarak sorgulanabilir
  • Örnek package definition şu alanları içerir: (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'teki local-file, build time sırasında current directory içindeki dosyaları alır; bu, Nix'teki src = ./.; ile benzerdir
  • Guix'teki gnu-build-system, ./configure && make && make install yaklaşımını kullanır; ayrıca Guix'te cmake-build-system, python-build-system gibi başka build system'lar da vardır
  • Guix, Nix'te stdenv'nin gcc ve coreutils'i implicit olarak sağlamasının aksine tüm bağımlılıkları explicit tutar

Geliştirme ortamı

• Flakes'in devShells örneğinde devShells.x86_64-linux.default = pkgs.mkShell { buildInputs = with pkgs; [ go gopls gotools ]; shellHook = '' echo "Welcome to the devShell!" ''; }; kullanılır
• mkShell, build sırasında shell environment oluşturan bir derivation üretir; buildInputs, shell içindeki PATH'e eklenir ve shellHook, shell'e girildiğinde rastgele bir bash komutu çalıştırır
• Flake dev shell içine nix develop veya adlandırılmış bir shell için nix develop .#my-shell ile girilir
• Guix geliştirme ortamı, manifest.scm içinde specifications->manifest fonksiyonuna paket belirtim dizgelerinden oluşan bir liste verilerek tanımlanabilir
• Örnek Guix manifest'i "go", "gopls", "go-tools" bildirir
• Guix manifest tabanlı shell'e guix shell -m manifest.scm ile girilir
• Guix, ad-hoc environment için dosya olmadan guix shell go gopls go-tools gibi yalnızca komut satırı paket adlarının geçirilmesine izin verir
• guix shell, tam izolasyon için --container, standart Linux filesystem düzenini bekleyen programları çalıştırmak için --emulate-fhs, Guix container içinde Guix çalıştırmak için --nesting desteği sunar
• Guix manifest'leri, daha büyük flake.nix yapısına gömülü olmayan bağımsız Scheme dosyalarıdır
• guix shell dosya olmadan da çalışabilir, ancak nix develop için bir flake veya legacy arayüzündeki shell.nix gerekir
• Flakes, devShells.x86_64-linux.test, devShells.x86_64-linux.default gibi adlandırılmış dev shell'ler sunar
• Guix manifest'leri, adlandırılmış dev shell'ler yerine manifest.scm, test-manifest.scm gibi ayrı dosyaları yan yana bulundurur
• Hem Nix Flakes hem de Guix container tabanlı geliştirmeyi destekler

Sistem yapılandırması

• NixOS ve Flakes

  • Flakes'in nixosConfigurations örneğinde nixpkgs.lib.nixosSystem, NixOS modüllerinden oluşan bir liste alarak kernel, servisler, yapılandırma dosyaları ve daha fazlasını içeren tam bir sistem derivation'ı üretir
  • Flake tabanlı NixOS dağıtımı için örnek komut nixos-rebuild switch --flake .#myhost şeklindedir
  • Örnek nixosConfigurations.myhost, system = "x86_64-linux"; ve modules = [ ./configuration.nix home-manager.nixosModules.home-manager ]; içerir
  • NixOS modülleri, options, config, mkIf, mkDefault, mkForce üzerinden öncelik tabanlı birleştirme kullanan bir modül sistemidir
  • NixOS modül sistemi, birden fazla modül aynı seçeneği ayarlasa bile öncelikleri çözer; bu da onlarca modül aynı yapılandırmaya katkı sunduğunda bile çakışmalardan kaçınmayı kolaylaştırır

• Guix operating-system

  • Guix'in operating-system yapısı bir function değil, bir Scheme record'udur; her field, Guix tarafından doğrulanan adlandırılmış ve tiplenmiş bir değerdir
  • Guix sistem dağıtımı için örnek komut guix system reconfigure config.scm şeklindedir
  • Örnek operating-system record'u (host-name "myhost"), (timezone "Etc/UTC"), bootloader yapılandırması, file systems ve services içerir
  • Guix bootloader yapılandırması örneği grub-efi-bootloader ve "/boot/efi" hedefini kullanır; Guix, GRUB, U-Boot ve diğerlerini destekler
  • Guix file systems, bir liste olarak bildirilir ve %base-file-systems, /dev, /proc, /sys gibi yollar için varsayılanları sağlar
  • Guix services, yönlendirilmiş çevrimsiz grafik (DAG) oluşturur ve her service başka services'leri extend edebilir
  • %base-services, Shepherd init system, syslog, networking ve benzeri temel services'leri sağlar
  • Guix sistem yapılandırması için özel bir output type gerekmez; operating-system record'u döndüren bir dosyanın guix system komutuna verilmesi yeterlidir
  • Guix'teki service bileşimi, mevcut sisteme keyfi biçimde bağlanan yeni services yazmayı kolaylaştırır

Keşfedilebilirlik ve registry

• Flakes, proje bağımlılıklarını, çıktıları ve keşfedilebilir şemayı tek bir dosyada bildiren standart giriş noktası flake.nix dosyasına sahiptir
• Guix projeleri manifest.scm, channels.scm, guix.scm, package.scm gibi teamül tabanlı dosyalar kullanabilir
• guix shell tarafından otomatik algılanan proje dosyası olarak guix.scm'yi standartlaştırmaya yönelik bir hareket vardır, ancak bu yaklaşım flake.nix kadar yerleşmiş değildir
• Flakes'te kısa adları URL'lere eşleyen küresel bir registry flake-registry bulunur; örnekler arasında nix run nixpkgs#hello ve nix build github:NixOS/nixpkgs#firefox yer alır
• Guix, benzer kullanım kolaylığı için paket belirtimlerini kullanır; örnekler guix shell hello ve guix install firefox şeklindedir
• Guix'te herhangi bir Git deposunu kısa adla işaret eden bir registry karşılığı yoktur; URL'ler doğrudan kullanılır
• Nix registry'si, nixpkgs ifadesinin bir registry girdisi mi, yerel bir yol mu yoksa başka bir hedef mi olduğunun her zaman açık olmaması nedeniyle zaman zaman kafa karışıklığı kaynağı olmuştur
• nix flake show, bir flake'in sunduğu tüm öğeleri ağaç görünümünde gösteren bir komuttur
• Guix'te paketler için guix search, servisler için guix system search vardır, ancak belirli bir proje veya deponun sunduğu tüm öğeleri gösteren karşılık bir komut yoktur; Scheme dosyalarını doğrudan incelemek gerekir
• Flakes, nix flake show komutunun projenin sunduklarını tutarlı bir görünümle göstermesi sayesinde keşfedilebilirlik açısından güçlüdür
• Guix projeleri daha ad-hoc yapıdadır; hangi dosyaya bakılması gerektiğini bilmeniz gerekir ve standart bir tek giriş noktası dosyası yoktur
• Guix, her şeyin Scheme olması sayesinde şema olmadan istediğinizi tanımlayıp birleştirebilmeniz açısından güçlü bir esneklik sunar

Paket modeli ve grafik yeniden yazımı

• Nix'te paketler, stdenv.mkDerivation { ... } çağrısıyla derivation döndüren bir fonksiyondur; sonuç ise opak bir attribute set'tir
• Guix'te paketler <package> kaydıdır; adlandırılmış alanlara sahip şeffaf bir veri yapısı oldukları için standart Scheme prosedürleriyle incelenebilir, dönüştürülebilir ve birleştirilebilir
• Guix package definitions, opaque functions değil transparent records olduğundan, özel araçlara ihtiyaç duymadan inspect ve transform işlemleri programatik olarak yapılabilir
• Guix'te packages veri olduğu için graph rewrites kolayca gerçekleştirilebilir
• Guix'te package-input-rewriting, tüm bağımlılık grafiğini dolaşıp perl'ü perl-minimal ile değiştirme işlemini ifade edebilir
• Guix'in inherit anahtar sözcüğü, coreutils'in tüm alanlarını devralıp yalnızca belirtilen alanların üzerine yazarak paketi yeniden tanımlar
• Nix'te benzer amaç için overlays vardır, ancak opak fonksiyon arayüzü nedeniyle inceleme ve dönüşüm daha zordur; bu da kullanım kolaylığını düşürür

Güvenlik güncellemeleri, bootstrap ve kimlik doğrulama

• Guix'in grafting özelliği, tüm bağımlı paketleri yeniden derlemeden bağımlılık ağacına güvenlik güncellemeleri uygulanmasını sağlar
• glibc gibi düşük seviye kütüphanelerde bir zafiyet olduğunda Guix, depo yollarını yeniden yazarak bunları yamalanmış sürümle değiştirebilir
• Nix, güvenlik güncellemeleri durumunda her şeyi yeniden derler; büyük bağımlılık ağaçlarında derleme süresi saatlerce farklı olabilir
• Guix, kaynak tabanlı bootstrap konusuna güçlü biçimde odaklanır ve tüm sistemi küçük bir güven tabanından inşa edebilir
• Guix'in bootstrap zinciri, yaklaşık 500 baytlık bir hex assembler ile başlar; ardından Scheme ile yazılmış mes C derleyicisi, tcc ve tam GNU toolchain gelir
• bootstrappable builds projesi, tam kaynak bootstrap ayrıntılarını ele alır
• Nix, Guix'e kıyasla daha fazla binary seed'e dayanır
• Bootstrap zinciri denetlenemiyorsa sistemin gerçekten amaçlanan kaynaktan derlenip derlenmediği tam olarak doğrulanamaz; bu nedenle tam kaynak bootstrap, güven ve doğrulanabilirlik açısından önemlidir
• Guix channels, varsayılan olarak kriptografik kimlik doğrulama desteği sunar
• Bir Guix channel'ı, belirli bir commit ile onun Ed25519 imzasından oluşan bir “introduction” tanımlar; Guix de bu introduction noktasından mevcut commit'e kadar tüm imza zincirini doğrular
• Flakes, güven modeli olarak HTTPS ve GitHub altyapısını kullanır; bu, Guix'in Ed25519 channel authentication yaklaşımından farklı bir güvenlik modelidir

Özet tablodaki temel karşılıklar

• Bağımlılık bildirimi için Flakes flake.nix içindeki inputs'u, Guix ise channels.scm ve .guix-channel dosyalarını kullanır
• Bağımlılık sabitlemede Flakes otomatik ve proje bazlı flake.lock, Guix ise kullanıcı bazında otomatik guix describe ve proje bazında commit belirtilen elle yönetilen channels.scm kullanır
• Saf değerlendirme, flake mode'da zorunludur; Guix'te ise tasarım gereği içseldir
• Çıktı şeması olarak Flakes, outputs içinde yapılandırılmış bir attrset kullanırken Guix ad-hoc Scheme records kullanır
• Geliştirme ortamları için Flakes devShells ve nix develop, Guix ise manifest.scm ve guix shell kullanır
• Sistem yapılandırmasında Flakes nixosConfigurations ve modül sistemini, Guix ise operating-system ve service DAG'i kullanır
• Tek komutla yeniden üretilebilirlik için Flakes nix build github:foo/bar, Guix ise guix time-machine -C channels.scm -- build biçimini kullanır
• Proje bazlı sabitlemeyi Flakes flake.lock ile otomatik yaparken, Guix commit içeren channels.scm ile elle yapar
• Keşfedilebilirlikte Flakes nix flake show sunarken, Guix Scheme modüllerinin incelenmesine dayanır
• Paket modelinde Flakes/Nix opak fonksiyonlar, Guix ise şeffaf kayıtlardır
• init system olarak Nix systemd, Guix GNU Shepherd kullanır
• Güvenlik güncellemelerinde Nix tam yeniden derleme, Guix ise hızlı grafting kullanır
• Bootstrap güveninde Nix binary seed'lere, Guix ise tam kaynak bootstrap'e dayanır
• Kimliği doğrulanmış güncellemelerde Flakes HTTPS/GitHub güvenine, Guix ise Ed25519 channel authentication'a dayanır
• FHS desteği için Nix buildFHSUserEnv, Guix ise --emulate-fhs sunar
• Linux dışı destek tarafında Nix macOS için nix-darwin, Guix ise GNU Hurd ile öne çıkar
• Yalnızca özgür yazılım kullanımı konusunda Nix yalnızca bununla sınırlı değildir ve yapılandırılabilir; Guix ise FSDG'ye uygundur

Sonuç

• Flakes ve Guix; yeniden üretilebilirlik, bağımlılık yönetimi ve sistem bildirimi gibi aynı tür sorunları farklı mimari felsefelerle çözer
• Flakes; tek dosya, tek şema, tek kilit dosyası ve tek bir teamül seti sunan tekil bir özelliğe daha yakındır
• Guix ise dağıtım için channels, ortamlar için manifests, yapılandırma için operating-system, yeniden üretilebilirlik için guix time-machine ve diğer yapılar için Scheme records gibi ortogonal araçların birleşimidir
• Tek bir standart yöntem, tek bir giriş dosyası, tek bir çıktı şeması ve tek bir kilit biçimi tercih ediliyorsa Flakes doğal bir seçimdir
• Küçük ve bağımsız araçları birleştirip her aracın tek bir işi iyi yapmasını sağlayan Unix felsefesini paket yönetime uygulama yaklaşımı tercih ediliyorsa Guix daha uygundur
• Her iki ekosistem de paket yönetiminin fonksiyonel, bildirimsel ve yeniden üretilebilir olması gerektiği fikri etrafında gelişmiştir; aynı fikri farklı uygulamalarla ileri taşırlar

[GN⁺]

Lobste.rs yorumları

• Bu siteyi mobilde okumak aşırı sinir bozucu: yazılar biraz küçük ve her kaydırmada sürekli engel çıkarıyor.
  İlk karşılaştırmadan sonrasını okuyamadım, çünkü sürekli içindekilere geri zıplıyordu.

  • Hiç okunmuyor. Yoyo gibi hareket ediyor. Son zamanlarda gerçekten okumak istediğim yazılardan biriydi ama şimdiye kadarki en sinir bozucu okuma deneyimlerinden biri olduğu için hayal kırıklığı yarattı.
  • Aynı şey masaüstünde de oluyor. Saçmalık; sanki erişilebilirliği bilerek bozmuşlar gibi görünüyor.

• Yazıyı okuduktan sonra bile proje bağımlılıklarının nasıl belirtilip sabitleneceğini hâlâ tam anlayamadım. Dağıtmak ve paylaşmak için channels.scm içine her geçişli bağımlılığın commit hash'ini elle bulup koymak gerekiyormuş gibi görünüyor.
  time-machine yalnızca Guix paket kümesi üzerinde çalışıyor gibi, ağaç dışı bağımlılıklarda değil.
  nix run github:nixos/nixpkgs/<commit hash>#<package> gibi, nixpkgs'nin geçmişteki bir anındaki kodu da oldukça kolay çalıştırabiliyorsunuz.
  Guix'in alışılmadık tarafı, paket koleksiyonu sürümü ile paket yöneticisi sürümünü ayırmaması. Eski bir paketi çalıştırmak için eski bir Guix sürümünü de birlikte çalıştırmış oluyorsunuz; neden bunu isteyeyim pek anlayamıyorum.
  Yazı, flakes'te commit'in elle bulunup belirtilmesi gerektiğini söylüyor ama hemen ardından commit belirtmeniz gereken bir Guix komutunu örnek veriyor. Nix flake'de de --override-input ile nixpkgs sürümünü ezebilirsiniz ama bu da dağınık ve unflake'in iyileştirmeye çalıştığı konulardan biri.

  • Yazardan daha az Guix deneyimim var ama belgeleri biraz okudum, o yüzden birkaç şeye cevap vermeyi deneyebilirim.
    Genelde özel bir guix shell ortamında geliştirip, paylaşma aşamasına gelince guix describe -f channels > channels.scm ile tüm commit hash'lerini channels.scm içine kaydetmek akışın parçası oluyor.
    declaring channel dependencies belgesine bakınca bağımlılık commit'leri belirtilebiliyor ama o bağımlılığın da kendi bağımlılıkları olduğunda onların da belirli commit'lere sabitlenip sabitlenmediğini doğrulayan bir seçenek yok gibi görünüyor.
    time-machine içindeki --commit= gösterimi Guix kanalı için geçerli, ama -C ile dosyadan ek kanallar da yükleyebilirsiniz.
    Paket yöneticisi ile paket kayıtlarında geriye dönük uyumluluğu bozan değişiklikler olsa bile, geçmişi ve yeniden üretilebilirliği kaybetmemenizi sağlama avantajı var.
  • Bunun için nixpkgs'nin ters indeksi yapılabilir: örneğin nixpkgs'de X'ten Y'ye kadar olan commit'lerin belirli bir paketin A sürümünü içerdiği şeklinde.
    Ama bunun için her commit'te nixpkgs checkout'u gerektiğinden ilk kurulum maliyeti çok yüksek. Bir kez kurulduktan sonra indeksi güncel tutmanın maliyeti düşük olur.

• Site sorununu ve bu başlığı coopi'ye ilettim, umarım yakında düzelir.
  Tamamen Guix tarafına meyletmiş biri olarak, coopi'nin dediği gibi Guix'te de Nix'teki gibi her şeyi tek bir flake.nix ya da tek bir nix dizininde toplayan standart bir dosya/dizin olsa iyi olurdu. Ama Scheme modüllerini içe aktarmak için doğru yolların belirtilmesi gerektiğinden bu mümkün olmayabilir.
  Bu Lobsters gönderisinde yazarın bahsettiği şeyler var, o yüzden etiket olarak yalnızca nix ve lisp bile yeterli görünüyor.

  • linux etiketini çıkaralım fikri bana ikna edici gelmiyor. Ortak sahip oldukları tek çekirdek o sonuçta :P ama dediğin gibi unix pek uygun olmayabilir.
  • Flakes gibi bir kanalın ne sunduğunu otomatik olarak çıkarsamaya yardımcı olacak yapılandırılmış bir kanal veri tipi de güzel olurdu.
    Mesela şöyle bir şey:

    (channel  
      (operating-systems  
        (list my-vm))  
      (services  
        (list my-system-service)))  
    

    Ayrıca yeni kanal oluşturup yönetmeye yardımcı olacak bir guix channel komutu da iyi olurdu.

• Guix'te de Nix flake'teki .inputs.nixpkgs.follows gibi geçişli bağımlılıkların sabit değerlerini ezme özelliği var mı diye merak ediyorum.
  Ayrıca yazarın Guix açıklamasının önemli bir kısmı bana flakes öncesi Nix'i hatırlatıyor: standart giriş noktası yok, kanal yapısı var vs. Ama Guix'te biçim sistemi ve gerçek bir dil olduğu için aynı kalıpların yarattığı acı daha az gibi. Sanki Nix daha iyi ya da farklı bir dil olsaydı ortaya çıkacak bir alternatif tarih gibi.

  • Bu özellik ne için kullanılıyor?

• Diğer yorumlarda işaret edilen kullanılabilirlik sorunları yüzünden bunu tavsiye etmekte tereddüt ediyorum. Varsayılan olarak JavaScript'i kapatan NoScript kullandığım için ben fark etmemiştim.
  Yine de bu yazı tam gerektiği anda geldi. Şirkette Nix'i daha yoğun kullanma yönüne gidiyoruz ve flakes yüzünden biraz zorlanıyoruz; bu yazıdaki anlatım daha önce okuduklarımdan çok daha açıktı.

  • Coopi'nin dediğine göre JavaScript ya da CSS olmasa bile okunabilir olması için aşamalı geliştirme yaklaşımını izlemeye çalışmış; JavaScript tarafını bozmuş ama en azından o felsefe çalışıyormuş. Şimdi JavaScript'in de düzeltilmiş olması gerekir.

• Coopi'nin yanıtı: Bu sabah bir değişiklik yapmış ama iş yüzünden test edememiş, sonra da sorunun JavaScript'te olduğunu fark etmiş.

• Bu site iOS mobilde kullanılamıyor. Sayfa alttan yüklendikten hemen sonra yukarı kayıyor gibi görünüyor; ben ekranda bir sayfadan fazla aşağı iner inmez bir şey tetiklenip beni tekrar yukarı atıyor.
  Okuma modu çalışıyor ama vurgular ve aslında oldukça iyi olan özgün ayrıntılı stil kayboluyor.

• Flakes'in yaptıklarının Guix'teki farklı araçlarla da yapılabildiğini söylemek makul, ama Nix'te de aynı sorunları çözebilen küçük ve ortogonal araçların eskiden beri var olduğunu ve hâlâ var olduklarını belirtmek gerekir.
  Flakes'in sağladığı şey, standart proje giriş noktası ve bunun mümkün kıldığı ekosistem; örneğin kayıt defteri. Yazı da Guix'te bunun eksik olduğunu söylüyor.
  Guix kullanıcıları standart bir giriş noktasına ihtiyaç olmadığını düşünebilir ve birçok Nix kullanıcısı da uzun süre böyle düşündü.
  Ama ortogonal araç takımıyla flakes yapılabildiğini söylemek, FreeBSD'de ihtiyaç duyulan her şey jail ile yapılabildiği için OCI desteğine gerek olmadığını savunmaya benziyor. Standardizasyonun ekosistemi mümkün kıldığı kısmı ıskalıyor.
  Guix'e çok ilgim var ve biraz da katkı sundum; channels.scm ile birlikte guix time-machine kullanarak derleme yapmanın, flake sabitlerini değiştirip Nix değerlendirmesi yapmaktan neden bu kadar yavaş olduğunu karşılaştırmak istiyorum. Yaklaşık 3 kat yavaş olması, örneğin 5–10 saniyenin 15–30 saniyeye çıkması kabul edilebilir ama benim denediğimde durum bundan çok daha kötüydü.