Hlavní navigace

Mladá linuxová distribuce distri zkouší rychlý balíčkovací systém

23. 8. 2019
Doba čtení: 6 minut

Sdílet

 Autor: David Ježek
Balíčkovací systémy a správci balíčků v linuxových distribucích mají několik žab na prameni. Michael Stapelberg představil koncept, který by mohl vydavatele DEB i RPM distribucí minimálně inspirovat.

Motivace Michaela Stapelberga

Balíčkovací systém je pro mnohé hlavní a často pro mnohé uživatele rozhodující výhodou či vlastností oproti jiným systémům (v čele s Windows). Jedni preferují DEB, jiní RPM, další nedají dopustit na „balíčkovací systém“ Slackwaru, jiní nostalgicky vzpomínají na doby, kdy se TrueOS jmenoval PC-BSD a přišel s PBI balíčky – a ti obvykle dnes vedou debaty na téma zdali Snap nebo FlatPak či co si vlastně myslet o AppImage.

Michael Stapelberg v tom má jasno. Za svůj život zbuildoval ohromné množství balíčků (je správcem mnoha balíků v Debianu), ale také třeba napsal dlaždicového správce oken i3 a posílá patche do projektů jako APT, Chromium atd. V Debianu byl mezi léty 2012 a 2019 vývojářem, ale právě ono časté používání mu způsobilo frustraci a z Debianu relativně nedávno (před necelým půl rokem) odešel.

Mnohokrát v minulosti si všiml rozdílu mezi možnou maximální rychlostí průběhu operace (balíčkovacího systému) a realitou, kdy musejí být prováděny různé mezivýpočty. Problematice pomalosti balíčkovacích systémů, resp. nástrojů pro správu balíčků, věnoval před pár dny podrobnější článek, ze kterého vyšlo, že je to rychlostně opravdu leckdy bída (měřil na poměrně výkonném stroji s Core i9–9900K + NVMe SSD Samsung 970 Pro).

Dospěl ke stejnému logickému závěru jako mnozí před ním, na rozdíl od nich však na velmi moderním hardwaru. A sice, že je tu nemalý potenciál buď k optimalizaci správce balíčků, nebo snížení komplexnosti činností, které v těchto souvislostech dělá samotný systém. Po krátkém experimentu pak dospěl k závěru, že pomalost není obecný, neodstranitelný problém distribucí a je možné jej řešit. O kódu APT však ví natolik málo, že si netroufá tvrdit, že řešení bude jednoduché.

Každopádně navrhuje následující ideje…

1. Balíčky jsou obrazy, nikoli archívy

Část zdržení dle Michaela padá na bedra skutečnosti, že balíčky jsou obvykle komprimované archivy. Správci jako dpkg používají typicky např. tar s nějakou kompresí. Jím představená distribuce distri místo toho používá SquashFS, což znamená ve výsledku jednodušší souborový formát, rychlejší k práci.

Tato idea se nijak zásadně neliší od konceptů AppImage a snappy, které tež používají obrazy, nicméně v jejich případě pro celkové „instalátory“ daných aplikací, nikoli jednotlivé balíčky se závislostmi. distri tak neobsahuje duplicity sdílených knihoven (tedy nadále si drží onu výhodu balíčkovacích systémů oproti „instalačkám typu windowsích“).

Dalším kladným efektem použití obrazů místo archivů je jejich read-only povaha, která je odolnější proti nějaké škodlivé modifikaci.

2. oddělené hierarchie

Obsah balíčků je dostupný pod nějakou plnou cestou, například všechny soubory poskytované balíčkem zsh-amd64-5.6.2-3 jsou dostupné v /ro/zsh-amd64-5.6.2-3 (ro jako read-only), což je krátká cesta. Tato metoda uživatelských prefixů typu /ro/… je široce podporována díky linuxovým distribucím (buildují software s prefixy jako /usr, případně /usr/local jako u FreeBSD).

Díky tomu, že tato metoda se běžně používá, upstream s korektností prefixů obecně počítá a málokdy vyžaduje software nějaký patch, který by cesty zkorigoval do potřebné podoby.

3. výměnné adresáře

Balíčky programů často předávají data umístěním souborů do známých adresářů, například:

  • gcc(1) pro libusb(3) headery používá /usr/include.
  • man(1) lokalizuje manuálovou stránku nginx(1) skrze  /usr/share/man.
  • zsh(1) lokalizuje spustitelné programy za pomoci komponent v PATH  jako třeba  /bin.

V distri jsou takovéto lokace označovány jako výměnné adresáře a jsou dostupné skrze FUSE v /ro. Výměnné adresáře jsou dvojího typu:

  • globální – adresáře jako /rp/share poskytují sjednocení pro sdílení podadresářů všech balíčků. Jsou široce použity z důvodů kompatibility.
  • pro jednotlivé balíčky – pevně svázané s programem, například irssi(1) negarantuje žádné ABI vlastnosti, takže pluginy jako irssi-robustirc  mohou deklarovat, že pro své potřeby chtějí například /ro/irssi-amd64-1.1.1-1/out/lib/irssi/modules jako svůj vlastní dílčí výměnný adresář, který bude obsahovat soubory z jejich  lib/irssi/modules.

Vyhledávací cesty někdy potřebují opravit

Programy využívající výměnné adresáře někdy mohou používat vyhledávací cesty pro přístup k více výměnným adresářům. Například výše zmíněné: gcc s INCLUDEPATH, man s MANPATH, zsh s PATH. Tyto cesty jsou prominentní, obecně pak ale některé hodnoty vyhledávacích cest jsou odvozeny z --datadir=/ro/share  a vyžadují určitou pozornost navíc. Jiné zase mohou být odvozeny, např. --prefix=/ro/zsh-amd64-5.6.2-3/out a tudíž vyžadovat směrování na výměnný adresář skrze specifickou značku příkazové řádky.

Pro vytvoření iluze zapisovatelné vyhledávací cesty během sestavování balíčku jsou cesty přesměrovány dle této ukázky:

  • $DESTDIR/ro/share$DESTDIR/$PREFIX/share
  • $DESTDIR/ro/lib$DESTDIR/$PREFIX/lib

Kompatiblita s Filesystem Hierarchy Standard

Globální výměnné adresáře zajišťují distri dostatečnou kompatibilitu s FHS, na což spoléhají různé nástroje třetích stran. Zahrnuje to i vývojové prostředí jazyka C. Michael dodává, že úspěšně otestoval běh několika programů z jejich binárních balíčků, například Google Chrome, Spotify či MS Visual Studio Code.

Rychlost správce balíčků

Zkrátka ve srovnání s konvenčními správci balíčků v linuxových distribucích je ten v distri dle autora extrémně rychlejší. Jeho hlavní brzdou, dle měření, je typicky síťové připojení, a to i velmi rychlé linky. Autor tvrdí, že jeho správce v distri je brzděn sítí i na 100Gbit/s lince(!). Autor dodává čtyři aspekty..

  • Obrazy balíčků mohou být přidávány atomicky do „obchodu“, lze se tak bezpečně vyhnout fsyncu. Poškození budou odstraněna automaticky. Robustnost není důležitá, pokud je instalace přerušena, uživatel prostě úkon zopakuje.
  • Jelikož všechny balíčky jsou instalovatelné souběžně díky odděleným hierarchiím, nejsou zde konflikty na úrovni balíčkovacího systému a žádné řešení závislostí není potřeba. Ve výměnných adresářích lze řešit konflikty vybráním balíčku s nejvyšším číslem revize.
  • distri dokazuje, že lze vytvořit linuxovou distribuci kompletně bez zádrhelů. Díky tomu, že balíčky nemusejí být instalovány v nějakém pořadí, lze stahovat maximální rychlostí linky (dodejme: a také cesty k repozitáři, resp. jeho nastaveném uploadu) více balíčků současně.
  • Jelikož se využívá obrazů místo archivů, nemusí být nic rozbalováno. To znamená, že instalace balíčku znamená prosté zapsání dat programu a metadat do systému. Operace zápisu tak může běžet sekvenčně, což dodejme je u HDD nejrychlejší metoda (u SSD, zejm. s NVMe, by se o míře přínosu sekvenčního zápisu už daly vést debaty, ale přínos zde vždy nějaký bude).

Rychlá tvorba balíčků

Na rozdíl od běžných distribučních balíčkovacích nástrojů builder balíčků v distri reálně nic neinstaluje do buildovacího prostředí. Místo toho poskytuje filtrovaný pohled na kompletní databázi balíčků v /ro  v rámci buildovacího prostředí. Díky tomu i pro hodně rozsáhlé stromy závislostí nastavení buildovacího prostředí lze provést ve zlomku sekundy. Díky tomu je povyšování verzí balíčků výrazně komfortnější.

Zdroje balíčků

V distri probíhá instalace programu tak, že balíček obrazu je nahrán ze vzdáleného zdroje balíčků do lokálního zdroje v /roimg, kde je zpřístupněn mount  /ro.

Zdroj balíčků je implementován jako adresář s balíčky obrazů a jejich asociovanými metadaty v souborech. Zdroj balíčků tak lze jednoduše vytvořit exportem z distri a vytvořit například lokální mirror na vlastní síti, který bude periodicky aktualizován ze vzdáleného zdroje do této lokální kopie. Nejsou potřeba speciální nástroje (jako třeba debmirror na Debianu).

Tvorba derivátů je jednoduchá: stačí pouze přidat vlastní balíčky do lokální kopie zdroje balíčků. Obecně pak jednoduchost návrhu zdrojů je záměrná, aby bylo co nejsnadnější je spravovat a distribuovat.

První vydání distri a budoucnost

Pokud vás nový koncept prezentovaný v distri zaujal, prvotní verze je k dispozici na GitHubu. Takto se autor může v kódu dále vrtat, aniž by lidem rozbil jejich instalace.

Automatický nástroj na sestavení je schopen generovat obrazy pro běh na reálném hardwaru, v QEMU, VirtualBoxu, Dockeru či Google Cloudu. Domovskou stránkou projektu je distr1.org, repozitář je na GitHubu.

UX DAy - tip 2

Výhled do budoucna je takový, že pro autora je tohle projekt, na kterém si zkoumá linuxové distribuce. Nedoporučuje nikomu, aby distri používal jinak než k podobnému zkoumání a nemá ani žádné střednědobé plány na změnu. Žádá, aby jej kontaktoval každý, kdo bude chtít použít distri jako základ čehokoli většího, aby mohli diskutovat omezení či očekávání projektu.

Zkrátka a dobře: uvidíme, kam se distri se svými ideami posune. Michael Stapelberg bude spokojený, pokud si zavedené linuxové distribuce z distri vezmou alespoň jednu či dvě ideje.

Byl pro vás článek přínosný?

Autor článku

Příznivec open-source rád píšící i o ne-IT tématech. Odpůrce softwarových patentů a omezování občanských svobod ve prospěch korporací.