Bár nagyon megszerettem az Arch Linuxot pár dolog miatt, amikor a héten olvastam, hogy átállnak az init scriptekről systemd-re, kissé felment a pumpa. Nem emiatt az egy hír miatt, hanem mert ez már a harmadik vagy negyedik olyan változtatás, ami alapjaiban rengeti meg a rendszert, mióta használom ezt a terjesztést.

Azon is felháborodtam természetszerűleg, hogy miért kellett a /usr/lib alá bemozgatni a /lib tartalmát, és miért szimbolikus linkkel kell helyettesíteni. Illetve; a probléma inkább nyilván az volt, hogy miért a felhasználókkal kell elvégeztetni az ehhez szükséges, rengeteg buktatóval teli munkát, amihez még külön wiki bejegyzést is írtak.

Ez előtt volt, hogy kiszedték az installert, erről írtam is egy kis bejegyzést.

Én csak használni szeretném az operációs rendszeremet, nem heti szinten hegeszteni. Volt idő, amikor bejött ez a dolog, akkor Gentoo-t használtam, és végül ott is belefáradtam a gyakori fordítgatásokba, amiket ott sem lehet hagyni, mert közben ír ki alapvetően szükséges megteendő lépéseket. Lehet, hogy múltkor rossz terjesztést választottam?

Talán ennyire nem gáz a helyzet. Viszont a heti hír, miszerint a jól átlátható, működésében tetszőlegesen befolyásolható systemV initscriptek lecserélésre kerülnek, és helyette a Red Hat által fejlesztett systemd lesz nemsokára az alapértelmezett, kicsit rosszul esett. A fő dolog, ami miatt az Archot választottam, az az volt, hogy az Ubuntut már nem lehet átlátni, rengeteg egymáshoz integrált szoftver dolgozik együtt és nem hagyja, hogy én megmondjam, mit is szeretnék a rendszeremmel. Itt pedig azzal kellett szembesülnöm, hogy havi szinten más irányt vesznek a fejlesztések, és a felhasználók csak lobognak a fejlesztők által keltett szélben.

Mi az az init és miért kellene lecserélni?

UNIX-alapú operációs rendszereknél az init a legelső processz, ami elindul, és direkt vagy indirekt módon az összes többi processz szülője. Őt a kernel indítja el közvetlenül, név konvenció alapján (a Linux kernelben az init=xxx paraméterrel állítható).

Az init futási szinteket (runlevel) használ, amely bizonyos szinten megmondja, hogy a rendszer milyen állapotban van. Sok implementációja van, de úgy kell elképzelni, hogy pl. 1-es egyfelhasználós mód, 2-es többfelhasználós mód, 3-as hálózat, 5-ös grafikus felület, 6-os reboot, 0-ás leállítás. Az "init 1" paranccsal például át lehet váltani egyfelhasználós módba, ha ezt az adott UNIX változat támogatja. Indításkor az init belenéz a /etc/inittab fájlba, és annak megfelelően elindít egy nagy halom egyéb szkriptet és programot. A bootkor elindítandó funkciókat shell szkriptekkel oldották meg, ezek elég lazán vannak egymáshoz csatolva és nagyjából egymás után futnak le; viszont megadható, hogy melyik futási szinten melyik szkript fusson le. Általában minden szoftver komponens indítására és megállítására is van szkript ("komponens" alatt olyanok értendők, mint pl. az X-Window, szerverek esetén a különböző szolgáltatások stb); például az X indító szkriptje az 5-ös runlevelhez van hozzárendelve, a megállító a 0-ás és 6-oshoz minimum, de pl. ha meg akarjuk teremteni a lehetőségét a 3-as szintre visszavaló váltáshoz, akkor oda is be kell tenni a leállítási szkriptet (ha grafikus felületből valaki visszavált sima parancssoros multiuserre, akkor le kell állítani az X-et).

A fenti leírás alapján is látszik, hogy ez egy mondhatni ősi, robosztus, könnyen szerkeszthető és bővíthető rendszer; viszont az is, hogy amikor megtervezték, a mai igények nem léteztek. Az indítandó processzek párhuzamosítása, az indítások optimalizációja és az ehhez szükséges függőségi tábla (tehát hogy pl. az X elindításához kell networking, dbus és log gyűjtés) még egyáltalán nem volt napirenden, hiszen ha egy UNIX szerver nem 2 perc, hanem 2:30 alatt indul el, az senkit nem érdekel, hiszen 5 évente van újraindítva. Csakhogy, a Linux ma már jóval több, mint egy UNIX szerver változat.

Initng-launchd-systemd-upstart

"Mi lenne, ha meg tudnánk határozni, hogy a processzek hogyan függnek egymástól, és így optimalizáltabban lehetne elindítani őket? Mi lenne, ha kihasználnánk a több processzor és processzormag előnyeit a párhuzamos indításhoz? Mi lenne, ha nem korlátozott számú futási szinthez, hanem szinte tetszőleges eseményhez lehetne kötni a programok elindítását?"

Ilyen gondolatok bukkantak fel a fejlesztők fejében az utóbbi időben. Nem lenne pompázatos, ha mondjuk

• akkor indulna el a bluetoothd, ha csatlakozni szeretnénk egy másik Bluetooth-os eszközre? A CIFS akkor indulna el, ha odaváltok a Windows megosztás könyvtárára?
• a letöltő alkalmazás szólhatna a network szolgáltatásnak, hogy "kis barátom, ne állj le, még hátravan 300Mb"?
• nagy terhelés esetén a rendszer el tudná dönteni, hogy melyik processznek ad több kapacitást?

Valóban nem rossz gondolatok ezek. El is indult jó pár kezdeményezés az init leváltására, és bár ennek már több éve, az init még mindig elég jól tartja magát. Miért van ez?

Az init előnyei

• Az init egyszerű és egységes, míg a "trónkövetelők" még nem forrták ki magukat, többen is vannak tehát nehéz a választás
• a szoftverek indítására az init szkriptek már készen vannak, minek változtatni, ha valami működik?
• sokak szerint felesleges ez az "anyáskodás" a processzek felett, az init lazán csatolt működése bevált és jól kontrollálható
• Az init szkriptekbe bárki belenyúlhat, és bár igaz, hogy a bash interpreter mindig lassabb lesz, mint egy erre a célra írt szoftver, a flexibilitás kárpótol

Mindkét tábornak van sok követője; és lehet találni összehasonlításokat, amelyek persze általában a saját megoldás fényezésére vannak kihegyezve. A legegyszerűbb megnézni, hogy nekünk mire van szükségünk és az alapján választani.

Mi is a bajom?

Nem a systemd-vel van bajom egyáltalán, hanem az Arch-os hozzáállással, ahogyan átrendezik a rendszert hétről hétre, és emellett nem adnak a felhasználók számára sem választási lehetőséget, sem segítséget mondjuk egy automatikus migrációval; jó ha egy-egy wiki oldalt kapunk arra, hogy annak segítségével áthegeszthessük a rendszert, pedig nem is akartunk hozzányúlni. És ha ezt nem tesszük meg, akkor a rolling distro repo-k változása miatt két hét múlva már nem tudunk egy programot telepíteni, mivel annak már új verziója az aktuális, ami mellesleg magával vonzza a fél Gnome frissítését is. Öreg vagyok és csak használni szeretném a rendszeremet, nem folyamatosan foltozgatni!