antiX-26 — zase o niečo lepší #5 (+ GNU Guix)

Máme nainštalovanú „core“ verziu antiX-u, XFCE4. Dalšie balíky možno samozrejme inštalovať pomocou APT. Ale čo takto skúsiť manažér balíkov GUIX? V tejto prvej časti si povieme jeho vlastnosti a systém fungovania.

APT a repozitáre Debian-u sú dobré, ale…

… niektoré programy v nich nie sú, alebo sú — a to je častejšia situácia — v starších verziách. Iste — dá sa používať aj vetva testing či experimental, ale ako som sa sám v minulosti presvedčil, neradno to veľmi kombinovať so stable. Potom človek rieši zbytočné konflikty knižníc a pod.

Spočítané to nemám, ale určite mi 90% balíkov zo stable vyhovuje. Najčastejšie si zo zdrojákov kompilujem GNU Emacs, pcb2gcode, tree-sitter,… a možno je toho viac, ale toto robím pravidelne.

Má vôbec zmysel inštalovať si kvôli pár balíkom nový balíčkovací systém a učiť sa ho používať? Podľa mňa áno, jednak samozrejme kvôli samotnej radosti zo skúšania a učenia sa novej veci, a tiež kvôli tomu, že samotný nový balíčkovací systém je zaujímavý, a tiež preto, že je úplne autonómny a izolovaný od zvyšku programov. Takže nám, vulgárne povedané, nič „nepototo“ 😈.

Tak si o ňom povedzme viac. Verím, že informácie o ňom budú vzrušujúce. Mňa to nadchlo dostatočne.

GNU Guix

Vyslovuje sa „gnu giks“. Pekný názov.

Hneď upozornenie na úvod: existuje Guix OS, čo je operačný systém (s libre jadrom), ktorý používa balíčkovací systém Guix. A existuje balíčkovací systém Guix — a tento mám na mysli. Je použiteľný aj mimo svojho „domovského“ operačného systému.

Oficiálna dokumentácia ho opisuje ako pokročilého správcu balíkov, ale skôr ide o univerzálny systém nasadzovania softvéru. Proste sada nástrojov definovaných v Guile — funkcionálnom programovacom jazyku založenom na Scheme.

Guile a Lisp sa „držia za ruky“ v obklopení symbolmi a zátvorkami. Jedna gramatika — zoznamy, rekurzie, makrá, lambda funkcie. Ich spoločným génom je homoikonické kódovanie, kde programy sú zároveň dátami. Tvoria ich jednoduché základné konštrukcie, ktoré umožňujú konať zložité abstrakcie. To by sa dalo oceniť, nie?

Môžeme si ho (Guix) predstaviť ako správcu balíkov kombinovaného s funkciami ako má Ansible, s čisto funkcionálnym prístupu k správe balíkov.

Inštrukciami na zostavenie balíka sú funkcie, nazývané derivácie. Samotné výsledné balíky sú hodnotami týchto funkcií. Derivácie prijímajú závislosti (napríklad knižnice, iné programy) ako vstupy. Použitie tej istej derivácie s tými istými vstupmi vytvorí vždy ten istý balík (však logicky 😀). Ak sa vstupy zmenia (napr. nová verzia knižnice), derivácie vytvoria inú výstupnú hodnotu, čo znamená nový balík.

Možno to znie zbytočne zložito, ale má to zásadnú výhodu: kedže každý balík v Guix-e je definovaný týmto spôsobom, tak každá zmena v systéme je zaznamenaná a všetko, čo závisí od tejto zmeny, „preklopí“ túto zmenu do nového balíka. Každá zmena systému je vlastne jedinečná konfigurácia systému.

Uplatnenie toho princípu vedie k príjemným vlastnostiam: deterministické a reprodukovateľné derivácie a sandboxované prostredie. Lebo každá derivácia má jedinečný hash, ktorý ju identifikuje nezávisle od názvu balíka. Ďalšou vlastnosťou je vytvorenie stroja času. Nie doslovne.

Guix takto implementuje izolované prostredia pre každý program/balík, asi podobne ako virtualenv v Python-e (tu som na tenkom ľade, nie som pythonista, ale pre pochopenie sa mi táto analógia zdá dostatočná).

Takže (hurá):

• Žiadne konflikty, pretože každý balík má svoje vlastné prostredie (závislosti, cesty atď.).
• Netreba sudo, pretože balíky sa inštalujú do používateľského profilu.
• A už viackrát spomínaná reprodukovateľnosť, t.j. každá inštalácia je definovaná hashom derivácie.

Dá sa to pripodobniť aj k flatpak-u, ale flatpak je skôr orientovaný na GUI prostredie a jeho používanie v príkazovom riadku je značne kostrbaté, kdežto v prípade Guix je to práve také, ako to poznáme z používania CLI nástrojov z /usr/bin/ a podobných. Flatpak je však menej transparentný ako Guix.

Bočná úvaha

Zvedavý čitateľ (ten jeden!) sa pýta: „Ale ak má Guix svoje derivácie, nie je to to isté ako manifesty pre flatpak?“

Takmer, ale je tu pár rozdielov. Najmä v úrovni abstrakcie. Derivácia je teda funkcia, ktorá definuje vstup → zostavenie → výstup. Výsledok je vždy jednoznačne identifikovateľný (hashom, ktorý je tvorený deterministicky serializovaným popisom receptu vrátane všetkých závislostí (ich hashov), zdrojových súborov, skriptov zostavenia, relevantných premenných prostredia a konfiguračných parametrov — prosto všetko, čo ovplyvní výsledný spustiteľný súbor).

Manifest je skôr recept, ktorý hovorí ako zostaviť sandboxovanú aplikáciu a môže obsahovať odkazy na predvytvorené SDK/runtime (ľudovo povedané, SDK je balík „všetkého možného potrebného“ na zostavenie aplikácie, runtime je samotné prostredie s knižnicami a službami potrebnými na spustenie, napr. Gnome). Tento prístup znižuje garantovanú reprodukovateľnosť a tiež SDK či runtime môžu byť binárne distribuované a teda neauditovateľné.

Takže derivácia v Guix je formálnejšia, na nižšej úrovni a navrhnutá na reprodukovateľnosť.

Ako vyzerá taká derivácia?

Tak napríklad pre spomínaný program pcb2gcode (používam ho na generovanie G-kódov pre CNC stroj z gerber výstupov z KiCAD-u):

(define-public pcb2gcode
  (let ((commit "8c084afd00c6653dfa9cbf24a1dbeeb24f592aa9")
        (revision "0"))
    (package
      (name "pcb2gcode")
      (version (git-version "2.5.0" revision commit))
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/pcb2gcode/pcb2gcode")
               (commit commit)))
         (file-name (git-file-name name version))
         (sha256
          (base32 "19hyzd1601l51bwlv43j8l602nfacbjwqf54m5xsmj50718bcks2"))))
      (build-system gnu-build-system)
      (native-inputs
       (list autoconf
             automake
             libtool
             pkg-config))
      (inputs
       (list boost
             geos
             gerbv
             glibmm
             gtkmm-2
             (librsvg-for-system)))
      (home-page "https://github.com/pcb2gcode/pcb2gcode")
      (synopsis "Generate G-code for milling PCBs")
      (description
       "pcb2gcode is a command-line program for isolation routing and drilling
of PCBs.  It takes Gerber files as input and outputs G-code files for the
milling of PCBs.  It also includes an autoleveller for the automatic dynamic
calibration of the milling depth.")
      (license license:gpl3+))))

Vidíme, že v jednom riadku je (url "https://github.com/pcb2gcode/pcb2gcode"). Aha: takže Guix si sťahuje zdrojáky priamo z githubu… super, nie? Vždy aktuálna verzia.

Ďalej tam máme (native-inputs (list autoconf …)). To sú nástroje a knižnice potrebné iba počas zostavovania (konfiguračné skripty, kompilátory, autoconf/automake atď.), ktoré zvyčajne nie sú súčasťou výsledného balíka.

(inputs (list boost geos…)) sú závislosti, ktoré sú potrebné počas zostavenia a pri spustení výsledného programu.

Zase ten jeden zvedavý čitateľ sa pýta: „A to Guix stále prekladá programy počas inštalácie?“

Môže a nemusí. Samotný ekosystém Guix-u obsahuje tzv. build (kompilačné) farmy (bordeaux.guix.gnu.org, ci.guix.gnu.org), ktoré nepretržite kompilujú balíky z Guix-u a sprístupňujú ich ako náhradné binárne verzie — takzvané „substitutes“. Tie sú povolené a používané štandardne, ale môžeme (a o tom bude reč nabudúce) vynútiť kompiláciu na našom stroji počas inštalácie.

„Takže je to podobné ako Emerge v Gentoo?“

Ej, ale je otravný tento čitateľ.

Áno aj nie — sú to podobné mechanizmy — t.j. poskytujú predkompilované balíky, takže netreba kompilovať lokálne a tým šetriť čas/zdroje/elektrinu/prírodu.

Ale zase: Guix substitúty sú viazané na hash derivácie, kdežto Gentoo binárky sú obyčajné tarbaly/verzie (nie tak striktne deterministické). Ďalej Guix store je immutable (nemeniteľné) a umožňuje paralelnú koexistenciu viacerých verzií (pomocou hash ciest, uvediem neskôr), kdežto Gentoo inštaluje do štandardného /usr

🆒⇊

Ale nebojme sa. Cieľom Guix je umožniť používateľom jednoduchú inštaláciu, aktualizáciu a odinštalovanie softvérových balíkov bez toho, aby museli poznať postupy ich kompilácie, závislosti alebo si ručne robiť oné derivácie v Guile. Je to podobné ako s APT: tiež to používame a nemusíme vedieť, aká je štruktúra balíčka, ako sa riešia závislosti. Hoci sú medzi nami i takí machri, ktorí si robia vlastné balíčky.

Kde, čo a kedy?

No ale už sa pohnime dopredu: výsledok funkcií na zostavovanie balíkov sa ukladá do adresára nazývaného „store“ a každý balík je nainštalovaný vo vlastnom adresári v tomto „store“ úložisku.

Názov adresára obsahuje hash všetkých vstupných údajov použitých na zostavenie daného balíka. Tak sme sa konečne dopracovali, že čo s tým hashom 😀.

Konkrétne u mňa je to takto:

$ ls -l /gnu/store/ | grep '^d' | grep pcb2

dr-xr-xr-x  5 root root   4096 maj  2  2026 a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af

V /gnu/store/ mám adresár a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af, v ktorého názve je spomínaný hash, ďalej názov programu, verzia programu a na konci je identifikátor výstupu (krátky hash) rozlišujúci konkrétny výstup.

Takže ak by sme použili iné verzie knižníc pri zostavovaní programu, alebo inú verziu kompilátora, tak aj tento názov by bol iný.

Predbehnem zvedavého čitateľa a odpoviem si na nepoloženú otázku:

Guix môže zdieľať knižnice medzi balíkmi, ale len ak sú bitovo identické (rovnaký hash), vtedy sa používajú tie isté súbory v /guix/store/. Takže ak viacero programov používa tie isté knižnice a tie boli vytvorené rovnako, tak sú na disku iba jeden krát.

Konkrétne v prípade gtk+ mám len tieto adresáre, hoci programov mám viacero. Ale každý sa pri builde spolieha na tú istú (asi poslednú) verziu, ale ak by autor programu či derivácie chcel, vynútil by si existenciu inej verzie knižnice, ktorá by ale nebola v konflikte s ostatnými:

bsmbgz1cshs8bqrp1iavvla84mbksfbi-gtk+-2.24.33
c5krjkpapdgkzlzq208cwyhqf7r4lkqw-gtk+-3.24.51
4qmjk7b4knb564bflc6i8r0pbqy5y7pw-gtk+-3.24.51-bin
760ymn38cqw1swkmks5qyn76ds33izh7-gtk+-2.24.33-bin

A keď sa pozrieme na teda ten inštalovaný program pcb2gcode a kde má čo uložené, tak:

$ fdfind pcb2gcode /gnu/store

/gnu/store/dqzszzfh03245iklrdn78wwd2vm8vgkk-pcb2gcode-2.5.0-0.8c084af-builder
/gnu/store/7n3cn1fx4ckdcapjklr07mv2r3i3cwi5-pcb2gcode-2.5.0-0.8c084af-checkout.drv
/gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/
/gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/bin/pcb2gcode

Pohľad na štruktúru adresárov je nám dobre známy:

$ tree /gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/

/gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/
├── bin
│   ├── pcb2gcode
│   └── wkt_to_svg
├── etc
│   └── ld.so.cache
└── share
    ├── doc
    │   └── pcb2gcode-2.5.0-0.8c084af
    │       └── COPYING
    └── man
        └── man1
            └── pcb2gcode.1.zst

8 directories, 5 files

Takže môžeme povedať, že v rámci /gnu/store/<program> sa nám vytvorila štruktúra klasického root adresára linuxového súborového systému.

Ale bolo by nepohodlné spúšťať binárky z takýchto divných ciest, preto sa pri inštalácii vytvára sústava symlinkov, predvolene v ~/.guix-profile (ktorý si vieme pridať do $PATH).

$ tree ~/.guix-profile | grep pcb2

~/.guix-profile
│   ├── pcb2gcode -> /gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/bin/pcb2gcode
│   ├── wkt_to_svg -> /gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/bin/wkt_to_svg
│   ├── ld.so.cache -> /gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/etc/ld.so.cache
    │   ├── pcb2gcode-2.5.0-0.8c084af -> /gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/share/doc/pcb2gcode-2.5.0-0.8c084af
    │   │   ├── pcb2gcode.1.zst -> /gnu/store/a2jb7fi35df4zvxia9nmc514i4izljy4-pcb2gcode-2.5.0-0.8c084af/share/man/man1/pcb2gcode.1.zst

A koľko toho je?

Originálne substitúty Guix obsahuju výlučne slobodný softvér.

Kompletný zoznam dostupných balíkov je možné prehliadať online (https://packages.guix.gnu.org/) alebo pomocou príkazu guix package:

$ guix package --list-available | wc -l

31853

Ale možno pridať i neslobodné substitúty, napríklad pre kdejaké firmvéry. Ozačuje sa to pojmom „kanály“. O tom bude reč inokedy.

Záver a motivácia do ďalšej časti

Zhrnuté pozitíva:

• Guix nijako nekoliduje a neovplyvňuje iný používaný balíčkovací systém.
• Vždy najnovšie verzie programov. Ale súčasne aj možnosť zvoliť si pri inštalácii aj inú, staršiu. Veľmi jednoducho.
• Spoľahlivosť prostredníctvom „stroja času“ — Guix udržiava každú verziu aplikácie oddelenú. Ak sa inštalácia aplikácie nepodarí, používateľ sa môže jednoducho vrátiť k predchádzajúcemu bodu.
• Jednoduché kompilácie zo zdrojových kódov (vďaka tomu, že si stiahne sám všetky potrebné závislosti pre zostavenie i beh).
• Idempotentná konfigurácia (aplikovanie tej istej konfigurácie viackrát vedie k rovnakému výsledku ako jej aplikovanie raz — bez nežiaducich vedľajších účinkov).
• Prináša so sebou i nástroje, ako z inštalovaného programu možno spraviť prenosný (napr. AppImage) alebo balíček (napr. .deb) — a teda ho poslať niekomu, kto Guix nemá nainštalovaný.

Ale aj negatíva:

• Nižšia rýchlosť pri aktualizácii (v porovnaní napr. s APT), pretože Guix počíta všetky potrebné vstupné údaje pre kompiláciu a všetky závislé balíky, ktoré bude treba aktualizovať. Ostatné operácie, ako napríklad inštalácia, prebiehajú svižne, ale aktualizácie sú rozhodne trochu pomalšie.
• Zaberá veľa miesta na disku — Guix uchováva všetky balíky, o ktoré požiadal ktorýkoľvek používateľ a každá verzia balíka je uchovávaná samostatne. Ale povieme si nabudúce ako využiť jeho garbage collector na efektívne mazanie nepotrebných vecí.
• Malá komunita — a keďže je Guix pomerne pokročilý systém, tak aj komunita používateľov býva dosť pokročilá a predpokladá znalosť celého radu tém.
• Je to tiež projekt GNU, takže treba rátať s určitými názormi, hoci mne nie sú cudzie.

Vyzerá to parádne, no nie?