Dá se ještě žít bez systemd?

Je to již více než rok od vydání přehledu Co se systemd a Linuxem? Jak se Linux bez systemd vyvíjí, či nevyvíjí dál?

Dá se říci, že po vlně anti-systemd, která se objevila v loňském roce, vzniklo několik iniciativ, které se pokoušejí udržovat linuxovou distribuci bez systemd. Celkem pěkný přehled toho, co někdo již vyzkoušel, je na stránce Escape from systemd. Jak je z toho vidět, situace je neradostná – sice existují distribuce bez systemd, ale většina je jich spíše neutrálních – v podstatě se jedná o systémy, které ještě nedospěly do fáze, kde se bude lámat chleba – zda udržovat něco vlastního, nebo použít systemd. Rozsáhlejší přehled distribucí pak najdete na wiki Without-systemd.

Existuje jen velmi málo distribucí, které deklarují, že chtějí být bez systemd – CRUX, Devuan (Debian), Funtoo (Gentoo), Puppy. Pokud se podíváme podrobněji na tyto jednotlivé kousky, zjistíme, že ve většině případů se jedná o distribuce udržované jednotlivci nebo malými skupinkami. Nejvýraznější je zřejme Funtoo využívající OpenRC. Udržuje i upravené Gnome a má poměrně aktivní fórum i vývoj.

Pak tu máme ještě exoty, které Gabor de Mooij ani nezmiňuje – sta.li o které se na Rootu již také psalo v článku Staticky linkovaná distribuce Stali, kterou svět (zatím) neviděl a GuixSD. O Guixu se na Rootu již také psalo. Jeden zmíněný je pak „neutrální“ distribuce Alpine Linux.

Alpine Linux

Alpine Linux sice zaujímá pouze neutrální postoj, je ale z výše zmíněných nesystemd distribucí jednou z těch starších a poměrně aktivních. Vyvíjí se přes pět let a má poměrně stabilní historii. Jedná se o minimalistickou distribuci, která je (dnes) založená na knihovně musl libc, místo glibc, a BusyBoxu s nějakým tím statickým linkováním. Jako init využívá OpenRC. Má i správce balíčků  „apk“, což je trochu nešťastné, protože název koliduje s androidími apk. Distribuce se snaží o nadstandardní bezpečnost integrací PAX a grsec. Balíky jsou podepisované.

Pokud si chcete Alpine vyzkoušet je to opravdu sympatická záležitost na pár minut (qemu):

1. Stáhnout ISO: wget http://wiki.alpinelinux.org/cgi-bin/dl.cgi/v3.2/releases/x86_64/alpine-3.2.3-x86_64.iso
2. Vytvořit disk: dd if=/dev/zero of=sda bs=512 count=4096000
3. Spustit qemu: qemu-kvm -cdrom alpine-3.2.3-x86_64.iso -hda sda -device qxl-vga
4. Login „root“, spustit „setup-alpine“, projděte instalační kroky
5. Pusťte „setup-xorg-base“ a již pomocí „apk alpine-desktop xfce4 xf86-input-mouse xf86-input-keyboard xf86-video-qxl thunar-volman faenza-icon-theme slim“ nainstalujte xfce
6. „startx“ xfce nastartuje a můžete začít používat standardní desktop.

V distribuci je aktuálně asi 7600 balíčků, najít tam nejběžnější věci je možné, apk funguje přímo bleskově.

sta.li

Postoj suckless k systemd je jedním z dobře dokumentovaných souhrnů, proč není systemd jednomyslně oblíben. Zde je pár argumentů:

• Značná část nesouhlasných názorů pramení z požadavků, aby init (a tedy PID 1), který má v systému poněkud výjimečné poslání, byl co nejjednodušší a co nejrobustnější. První systemd zjevně nesplňuje, seznam vlastností je impozantně strašidelný (a již částečně zastaralý) – minimalistický init je např. na EWONTFIX, ale patří sem i suckless sinit, který je z něj odvozen; druhé je vždy věc názoru a konkrétních zkušeností. Každopádně tak obrovský init jako je systemd vyžaduje při update mnohem častěji reboot, i když k eliminaci mělo dojít zavedením systemd daemon-reexec, přesto je upgrade pomocí správce balíčků a následný totální rozpad systému stále poměrně běžný jev především při upgradu verze OS. Zvláště pozor je potřeba si dávat v poznámkách k vydání na informace jako:

  "The minimal required util-linux version has been bumped to 2.26."
  "Again: you need to update util-linux to at least v2.25 when updating systemd to v217."

• Vytváření démonů pro poskytování obsahu, který byl dříve dostupný v jednoduchém souboru – hostnamed, resolved, localed.
• Journald – ten je vůbec trnem v oku mnoha lidem. Ani já s ním doposud nemám dobré zkušenosti. Ať už se ho snažím mít zapnutý nebo vypnutý, nikdy to nefunguje jak má, problém jsou především aktualizované instalace. Prohledávání journálu je pomalé, do nedávna journal obsahoval i celé coredumpy atd.
• Zavedení zpětné kompatibility, která je po poražení „zastaralé“ technologie odebrána – např. funcionalita ForwardToSyslog se změnila z výchozího Yes na No, od verze 214 byla odstraněna i podpora pro SysV init skripty (náhradou je generátor, který z nich dělá unit soubory). Podpora pro utmp byla z výchozí konfigurace vypuštěna ve 217. Odebrání podpory mapování runlevelů na různé targety v 220 (zadrátováno napevno 2,3,4=multiuser, 5=graphical)…
• Strukturu souborového systému dle LSB systemd překonal, vše je v /usr/lib/ nebo /run apod. Např.: /dev/log, /dev/initctl → /run, resolv.conf → /run/systemd/resolve/, /etc/passwd a /etc/groups → /usr/lib/sysusers.d/…
• Neustálé změny (mizení různých částí či jejich přesuny, např. shutdownd), pohlcovaní jiné funkcionality a její export v obskurních parametrech INI.. pardon unit souborů.
• Přetrvávající problémy s démony pro synchornizaci času vyřešil systemd napotřetí tak, že pokud chcete použít jiný než timesyncd, musíte u konkurence zadat „Conflicts=systemd-timesyncd.service“.
• Přetrvávající neschopnost mechanismu pro fsck vypořádat se s hibernací.
• Systemd zahrnuje spoustu „zjednodušených“ verzí něčeho. Pokud potřebujete něco složitějšího odkazuje na „plné“ alternativy. Jenže kdo je bude používat, když většina uživatelů to ani neví a následně bude jejich „podpora“ odebrána ze systemd definitivně.

Vraťme se ke sta.li. Stále platí, že tuto distribuci asi jen tak neuvidíme, nicméně zastánci statického linkování už při troše snahy mají k dispozici aspoň statický rootfs pro x86_64. Je v něm ovšem v podstatě „jen“

• sbase – suckless základní utility, které jsou portovatelné na různě unixy
• ubase – suckless utility, které jsou specifické pro linux
• sinit – suckless init – obsáhlý popis celého initu v provozu s daemontools najdete na jedné stránce
• smdev – suckless mdev
• lksh – legacy korn shell založený na mksh

V rootfs zatím chybí i /etc ve kterém mají být suckless init scripty, nebo další core části, nemluvě o jádru, X11 apod. aby bylo vůbec možné provozovat surf, dwm atd.

O něco kompletnější je distribuce morpheus, což je dnes již odvržené dítě některých členů suckless, nicméně ještě mezi nimi panuje jistá symbióza.

1. Stáhnout: wget http://morpheus.2f30.org/img/morpheus-x86_64–0.0–11062014.img.xz (16MB)
2. Něco jako: qemu-system-x86_64 -hda morpheus-x86_64-.img -enable-kvm -vga cirrus

Nezbytný screenshot:

GuixSD

Guix od doby svého zrodu prošel přejmenováním na GuixSD (System Distribution), resp. guix je stále označení pouze pro funkcionálního správce „balíčků“. Od minule vydané verze 0.8.3 prošel dalším vývojem a čerstvě je k dispozici jako GuixSD 0.9.0. Pokud ještě stále nevíte o co jde, pak doporučuji pročíst stránku Guix(SD) Alana Webbera, která je velmi heslovitým a názorným popisem.

Co je podstatné, je vzestupný počet vývojářů, kteří se na guixu podílejí, narůstající aktivita v konferencích a přidávání nových vlastností – v poslední verzi nezbytné kontejnery, zajímavé grafování závislostí balíků i služeb, nebo příkaz pro ověření, že balíček (substitute) skutečně odpovídá kódu ze kterého deklaruje že vznikl. Je potřeba říci, že vývojáři primárně nevytváří distribuci, ale „jen“ nástroj, kterým se celá distribuce dá vytvořit a spravovat.

Datum vydání  Verze           Počet vývojářů u vydání
18 Jan 2013   GNU Guix 0.1    1?
12 May 2013   GNU Guix 0.2    5
17 Jul 2013   GNU Guix 0.3    5
27 Sep 2013   GNU Guix 0.4    5
11 Dec 2013   GNU Guix 0.5    11
09 Apr 2014   GNU Guix 0.6    16
25 Jul 2014   GNU Guix 0.7    14
18 Nov 2014   GNU Guix 0.8    22
29 Jan 2015   GNU Guix 0.8.1  21
14 May 2015   GNU Guix 0.8.2  24
22 Jul 2015   GNU Guix 0.8.3  25
05 Nov 2015   GNU Guix 0.9.0  34

Screenshot GuixSD by mohl pocházet z kdejaké distribuce, která používá XFCE, jen zde je zobrazen nezbytný ~/.guix-profile, který byste jinde marně hledali. Přestože pokrok v 0.9.0 je velmi znatelný, je třeba říci, že to stále není úplně pro běžné použití, protože spousta věcí se chová jinak než jste zvyklí. Je to krom jiného i daň za čistotu distribuce, ale především je to dáno zcela jinou filosofií práce s „balíčky“.

Samozřejmě, stále existuje možnost používat OS jako je Slackware, který je ale jen ve vleku událostí a systemd ho nejspíš nemine, obdobně to dopadne u PCLinuxOS. Pak už vám zbývá jen Linux From Scratch a spousta práce.

Nelinuxový svět nebo overlay

Zajímavé je, jak se se systemd vyrovnává nelinuxový svět, především BSD, případně ten linuxový ale nesystemovyd.

V Ubuntu např. nejdříve vznikl systemd-shim, který byl v podstatě vrstvou nad stávajícím initem a zprostředkoval služby, které systemd poskytuje přes D-Bus apod. a jsou nezbytné k fungovaní zbytku světa. Shim používal i Debian, v momentě kdy Ubuntu i Debian přešly na systemd, se shim v podstatě přestal vyvíjet.

Podobný osud zdá se postihl i openrc-settingsd.

Zajímavá byla i nutnost vytvořit fakesystemd pro docker kontejnery, která ale zdá se byla poněkud kontraproduktivní.

Dalším pokusem, který zdá se nebude pokračovat, je uselessd, kde je i popsáno, proč vývoj nebude dále pokračovat – nedostatek zájmu a neustále se měnící chování systemd, což je podstatou celého problému s vytvořením jakékoli „compat“ vrstvy pro systemd.

BSD ale v podstatě jinou možnost než vytvořit něco jako systemd-shim nemá. Zatím to vypadá na systembsd.

Co bude dál?

Dle mého soudu je to poměrně jednoduché. Rozeberme si jednotlivé skupiny.

Uživatelé

Většina uživatelů o tom, zda jejich distribuce bude či nebude obsahovat systemd, nebo zda budou mít možnost zvolit něco jiného, nerozhoduje, protože je to nezajímá, je to pod jejich rozlišovací schopnost. Noví (a často mladí) uživatelé, budoucí správci, nic jiného nepoznají a jsou pro každou špatnost, staří nemají čas s každou verzí lámat přes koleno základní stavební kámen OS, na kterém pracují.

Správci

Současní správci běžících verzí Linuxu se systemd ještě nebyli nuceni přijít do styku, protože správci jsou konzervativní. Například Debian 7 jej neobsahuje – čas se ale pomalu nachyluje (podpora 7 končí 2016–02, zřejmě bude prodloužena stejně jako u 6 až do 2018–05). Stejně tak CentOS 6 resp. RHEL 6 (Q2 2017), Ubuntu 14.04 LTS (2019–04). Správce tedy reálné masovější nasazení systemd teprve čeká. Je to vidět i na tom, že hledáním ve vyhledávačích je prakticky nemožné najít relevantní informace k různým problémům. Protože desktopoví uživatelé problémy nemají/neřeší (nebo řeší tak, že třeba logování v podstatě vypnou) nebo je nedokáží spojit se systemd.

Každému správci pak doporučuji sledovat „černou kroniku“ (případně další ze stránek sytemd – třeba Fedory) a doufat, že zrovna jeho verze systemd bude ve stabilním vydání upgradeovatelná na poslední opravenou verzi, protože i Fedora spojuje upgrade systemd často s celým novým vydáním. Každý SW má chyby, jen správce by byl rád, kdyby jich init měl hodně málo.

Distribuce

Pro tvůrce distribucí je vždy nejjednodušší jít s davem, který se pomalu ale jistě vytvořil tlakem systemd. Je to takový efekt „El Niño“ – podle jedné povídky bylo možné čůráním do vody na správném místě, kdesi v jižní Americe, změnit počasí na jiné části zeměkoule. Vzhledem k tomu, že doposud žádná alternativa nevznikla a v podstatě jediná při životě udržovaná alternativa je OpenRC, je zde volba jasná, což dokazují i všechny velké distribuce.

Vývojáři

Poslední skupina, která by mohla mírně systemd ovlivnit jsou vývojáři všeho možného balastu. Jejich vztah k systemd bude ale víceméně neutrální, dokud jim systemd neintegruje a nezruinuje zrovna jejich koníček. Půlka jich pak migruje na systemd a půlka se na vývoj vykašle, protože to za ně udělá systemd a oni to stejně dělali jen volném čase. Výsledek je jasný.

Co zbývá?

Jak se snaží naznačit i tento příspěvek systemd není tak hrozný a není to ani konec světa nebo vývoje. Faktem ovšem zůstává, že má poměrně dalekosáhlé důsledky, které přesahují i hranice linuxového písečku, neboť morfují i doposud široce portovatelná prostředí.

Osobně ve mně vzbuzuje jemné obavy i prohlášení, cituji:

We try to get rid of many of the more pointless differences of the various distributions in various areas of the core OS. As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration. This is never exclusive though, distributions can continue to deviate from that if they wish, however, if they end-up using the well-supported default their work becomes much easier and they might gain a feature or two.

Tyto „nepodstatné“ rozdíly, totiž tvořily právě samotné distribuce distribucemi. Znesnadňovalo to sice univerzální vývoj pro Linux, ale zároveň vytvářelo prostředí heterogenní, které brání šíření malware. Čas ukáže zda a jak dobrý to byl nápad.

Po dalším roce vývoje se tedy dá říci, že budoucnost bez systemd neexistuje – pokud tedy nejste akademik nebo šílenec. Je tedy nakonec jedno, zda budete používat systemd na Linuxu nebo na Windows.

Touto bombou dnes končíme.