Avagy miért nem mindenki rajong a modern Linux motorjáért?

Sokáig gondolkodtam, hogy megírjam-e ezt a szösszenetet, mert igazán nem akarnék "FlameWart", de akik ismernek/olvasnak, azok rájöhettek, nem vagyok nagy híve a systemdnek, és itt-ott már kérdezgették mi bajom vele, hát akkor mégis csak...!
Ha az elmúlt tíz évben telepítettél egy népszerű Linux disztribúciót, szinte biztos, hogy a systemd üdvözölt a háttérben. Gyors (he-he), párhuzamosít, és „mindent is megold”. Akkor mégis miért használok most Devuant, amelynek az egyetlen célja a systemd kigyomlálása?
Bizony a probléma nem (csak) vallási háború, vannak nagyon is konkrét technikai és filozófiai aggályok!

 - A "Mindent is" elve 

A Unix alapelve évtizedekig az volt: csinálj egy dolgot, és azt csináld jól! A systemd ezzel szemben egy digitális svájci bicska, ami mára inkább egy komplett operációs rendszernek tűnik az operációs rendszeren belül.
Már nemcsak az indításért felel, hanem kezeli a DNS-t, a hálózatot, az időt, a naplózást és a felhasználói munkameneteket is. Ez a fajta monolitikus felépítés sérülékennyé teszi a rendszert, ha egy porszem kerül a gépezetbe, az egész rendszer instabillá válhat. Egy init-rendszernek a lehető legegyszerűbbnek kellene lennie a biztonság érdekében. A systemd komplexitása több biztonsági rést (bizony számos CVE-t generált) és váratlan hibát szül. Ráadásul ez a megközelítés komoly függőségi hálót képez, lásd pl. GNOME.

 - A bináris fal: viszlát, egyszerű naplófájlok!

Na ez az amitől tényleg agyf@szt kapok! Régen, ha baj volt, elég volt egy 'cat /var/log/messages' és láttad a hibát. A systemd bevezette a journaldt, ami bináris formátumban tárolja a naplókat, és értem én, hogy így nehezebb manipulálni az állományokat, de ha megsérül a fájl, vége, nem tudod "meghekkelni" egy szövegszerkesztővel. Muszáj a journalctlt használnod, és ha a rendszer éppen félig halott, és ez az eszköz nem elérhető, vakon tapogatózol a /dev/null-ban...

 - Komplexitás mint hibalehetőség

A biztonságtechnikában az egyszerűség a barátunk. A systemd kódja azonban hatalmas és bonyolult. Ez két dolgot jelent: 1) minél több a kód, annál több a hiba. A systemdben rendszeresen találnak olyan biztonsági réseket, amik egy egyszerűbb init-rendszerben (mint a SysV vagy az OpenRC) fel sem merülhetnének. 2) lassabb hibajavítás, egy ilyen óriási gépezetben nehezebb megtalálni, mi okozza a problémát.

 - Kiszámíthatatlanság
 
Mindenki ismeri a frusztráló feliratot leállításkor: "A stop job is running for...". A systemd néha túlságosan is okos akar lenni, és percekig vár egy olyan folyamatra, amit a régi rendszerek egyszerűen (és fájdalommentesen) leállítottak volna. A párhuzamosítás miatt pedig a boot-sorrend néha kiszámíthatatlanná válik (race conditions), ami furcsa, nehezen reprodukálható hibákat szülhet.

 - A gyorsaság ígérete
 
Bár a systemd egyik fő ígérete a párhuzamosított indítás miatti gyorsaság volt, a gyakorlatban egy jól konfigurált SysVinit vagy OpenRC gyakran leiskolázza a modern óriást. A systemd egy masszív háttérfolyamat-kezelőt futtat, amely folyamatosan monitorozza a socketeket, buszokat és eszközöket, hajlamos hosszú ideig várni egy-egy szolgáltatás válaszára, a SysVinitnél a szkriptek lefutnak és kész, nincs felesleges analizálás. Ha nincs szükséged 500 különböző szolgáltatásra, a SysV villámgyorsan végez.

 - A választás szabadságának elvesztése

A Linux világát a diverzitás éltette. Mivel azonban a systemd olyan mélyen befészkelte magát az asztali környezetek és alapvető szoftverek függőségei közé, ma már rendkívül nehéz systemd-mentes modern rendszert építeni. Sokan úgy érzik (jelen!), a Red Hat által dominált projekt ráerőltette magát az egész ökoszisztémára, felszámolva a versenyt.

A systemd felfal mindent, vége a systemd-mentes világnak? Nem hinném! A legnagyobb veszélyt a függőségek jelentik, ahogy arról már beszéltünk. Az olyan projektek, mint pl. az elogind, pont azért jöttek létre, hogy a systemd-mentes rendszerek "hazudjanak" a szoftvereknek. A program azt hiszi, ott a systemd, közben csak egy vékony, kompatibilitási réteg válaszol neki. Amíg akadnak fejlesztők, akik ezeket a hidakat karbantartják, addig nincs veszve semmi.
És persze ott a közösségi dac ereje! A Linux lényege a "forkolás", pl. amikor a Debian bevezette a systemd-t, megszületett a Devuan, ha a Devuan elbukna, jó eséllyel születne valami más.
Vannak olyan disztribúciók, amelyek eleve úgy épülnek fel, hogy a systemd-t technikailag képtelenség legyen integrálni (pl. Void Linux, vagy az Alpine Linux). Ezek a rendszerek nemcsak hobbiból léteznek; komoly ipari és biztonságtechnikai hátterük van.
A valódi fenyegetés nem a systemd maga, hanem ha a Wayland és az újabb grafikus protokollok olyan szorosan összefonódnak a systemd specifikus API-jaival, hogy a hidak (mint az elogind) fenntartása túl nehézzé válik...

Végezetül egy kis ajánló systemd-mentes terjesztésekre: Devuan (Debian alapok), Artix (Arch alapok), Void (független), Alpine (független), Gentoo (független), Slackware (független), stb..

Lehet a systemdvel együtt élni? Persze, a Linux felhasználók többsége ezt teszi! Muszáj vele? Szerencsére (még) nem! Ha magamfajta, évtizedek óta Linuxot nyúzó vénségek vagytok, valószínűleg átérzitek a kínjaimat, ha pedig nem, egy kalandot mindenképpen megér a systemd-mentes világ!
Újra szeretném leszögezni, az írás nem azért készült, hogy egymásnak ugrasszam az embereket! Ez egy vén trotty Linuxos magánvéleménye, és köszi hogy elolvastad!

Berus