La zece ani de la lansare, sistemul systemd continuă să genereze opinii puternic polarizate în comunitatea Linux. Deși a fost adoptat de majoritatea distribuțiilor majore, opoziția fermă față de el persistă.
Secvența de inițializare Linux
Procesul de pornire al unui computer începe cu activarea hardware-ului, urmată de execuția fie a Master Boot Record (MBR), fie a Unified Extensible Firmware Interface (UEFI), în funcție de sectorul de boot utilizat. Ambele metode au ca ultimă acțiune lansarea nucleului Linux.
Nucleul este încărcat în memorie, dezarhivat și inițializat. Un sistem de fișiere temporar, de obicei creat de initramfs sau initrd, este instalat în RAM, permițând identificarea și încărcarea driverelor necesare. Această etapă pregătește terenul pentru încărcarea sistemului de fișiere din spațiul utilizator, finalizând crearea mediului necesar.
Procesul init, primul lansat de nucleu în spațiul utilizator, este responsabil de gestionarea acestui mediu. Având un ID de proces (PID) de 1, el devine baza pentru toate celelalte procese, fie direct, fie indirect.
Înaintea apariției systemd, varianta standard pentru procesul init era o adaptare a Unix System V init. Deși existau alternative, System V init era alegerea preferată în majoritatea distribuțiilor derivate din non-Berkeley Software Distribution (BSD). Mulți consideră acest sistem ca fiind „metoda oficială” de inițializare, datorită originii sale direct din System V Unix, considerat strămoșul spiritual al Linux.
Procesul init pornește toți demonii și serviciile necesare pentru funcționarea interactivă și eficientă a sistemului de operare. Acești demoni se ocupă de elemente esențiale, cum ar fi stiva de rețea, gestionarea hardware-ului și afișarea interfeței de pornire.
Mulți dintre acești demoni continuă să ruleze în fundal, înregistrând evenimente, detectând modificări hardware și gestionând sesiunile de utilizator. Sistemul init include, de asemenea, funcții de administrare a serviciilor.
Pentru a identifica procesul cu PID 1, putem folosi comanda ps cu opțiunile f (format complet) și p (PID):
ps -fp 1
De obicei, acest rezultat va indica systemd. Cu toate acestea, pe unele sisteme, cum ar fi Manjaro Linux, se poate afișa /sbin/init, care este de fapt o legătură simbolică către systemd:
ps -fp 1
ls -hl /sbin/init
Utilizând opțiunea ppid (ID proces părinte) împreună cu ps, putem vedea procesele lansate direct de systemd:
ps -f --ppid 1
Această listă este extinsă, așa cum se observă în imaginea de mai jos.
Alternative la systemd
De-a lungul timpului, mai multe proiecte au încercat să creeze alternative la tradiționalul System V init. Una dintre principalele deficiențe ale System V init este pornirea secvențială a proceselor, unul după altul. Multe alternative au adoptat paralelismul pentru a îmbunătăți eficiența secvenței de pornire, lansând procesele simultan și asincron.
Câteva alternative notabile includ:
Upstart: Dezvoltat de Canonical, a fost utilizat în Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 și Fedora 9.
runit: Este folosit pe sisteme FreeBSD și alte derivate BSD, macOS și Solaris, precum și pe Linux. Este, de asemenea, sistemul init implicit pe Void Linux.
s6-linux-init: Conceput ca un înlocuitor pentru System V init, respectă filozofia Unix, care se concentrează pe realizarea eficientă a unui singur lucru.
Există și alte alternative, fiecare cu propriile caracteristici și design, dar niciuna nu a generat aceeași intensitate de reacții ca systemd.
Ascensiunea systemd
systemd a fost lansat în 2010 și implementat în Fedora în 2011. Ulterior, a fost adoptat de numeroase distribuții. Dezvoltatorii săi au fost Lennart Poettering și Kay Sievers, ingineri software de la Red Hat.
systemd depășește cu mult rolul unui simplu sistem init, fiind o suită de aproximativ 70 de binare care se ocupă de inițializarea sistemului, gestionarea demonilor și serviciilor, înregistrarea jurnalelor și multe alte funcții care anterior erau gestionate separat în Linux. O mare parte din aceste funcții nu au legătură directă cu inițializarea sistemului.
Câțiva dintre demonii furnizați de systemd includ:
systemd-udevd: Gestionează dispozitivele fizice.
systemd-logind: Gestionează autentificările utilizatorilor.
systemd-resolved: Asigură rezoluția numelor de rețea pentru aplicațiile locale.
systemd-networkd: Detectează și gestionează dispozitivele de rețea și configurațiile asociate.
systemd-tmpfiles: Creează, șterge și curăță fișierele și directoarele volatile și temporare.
systemd-localed: Gestionează setările locale ale sistemului.
systemd-machined: Detectează și monitorizează mașinile virtuale și containerele.
systemd-nspawn: Permite lansarea unei comenzi sau a altui proces într-un container ușor de spațiu de nume, oferind funcționalități similare cu chroot.
Aceasta este doar o mică parte din complexitatea systemd, aspect care a devenit și problema centrală: systemd a depășit cu mult funcțiile unui sistem init, ceea ce, conform criticilor, reprezintă o extindere nejustificată a scopului.
„Prea mult. Prea complex.”
Criticii systemd evidențiază amestecul divers de funcționalități pe care le include. Deși majoritatea acestor funcții existau deja în Linux și unele dintre ele ar fi putut beneficia de o reîmprospătare, integrarea lor într-un sistem init este problematică din punct de vedere arhitectural.
Systemd a fost criticat ca fiind un punct unic de eșec pentru prea multe funcții vitale, o afirmație care nu pare a fi pe deplin justificată. Cu toate acestea, el contrazice filozofia Unix de a crea instrumente mici și specializate care să funcționeze împreună, în locul unor pachete software masive care fac totul. Deși systemd nu este monolitic în sens strict (fiind compus din multe binare), el include o multitudine de instrumente și comenzi de gestionare sub o singură umbrelă.
Chiar dacă nu este monolitic, systemd este un sistem voluminos. Pentru a înțelege dimensiunea sa, am numărat liniile de text din baza de cod a nucleului 5.6.15 și din ramura master a systemd, din depozitul GitHub.
Această măsurătoare a fost una brută, numărând toate liniile de text, inclusiv comentarii și documentație, nu doar linii de cod. Totuși, ea ne-a oferit un punct de referință simplu pentru comparație:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Nucleul avea aproximativ 28 de milioane (27.784.340, mai precis) de linii de text. Systemd, în schimb, avea 1.349.969, adică aproape 1,4 milioane. Conform acestei măsurători simpliste, systemd are aproximativ 5% din dimensiunea nucleului, un procent semnificativ.
Ca o altă comparație, o implementare modernă a System V init pentru distribuția Arch Linux are doar 1.721 de linii.
Poettering nu pare să respecte nici Institute of Electrical and Electronics Engineers (IEEE) Computer Society, nici standardul Portable Operating System Interface (POSIX). De fapt, el a încurajat dezvoltatorii să ignore POSIX:
„Obțineți o copie a interfeței de programare Linux, ignorați tot ce scrie despre compatibilitatea POSIX și creați software Linux uimitor. Este destul de simplu!”
Au existat acuzații conform cărora systemd ar fi un proiect Red Hat care avantajează doar Red Hat, dar este impus întregii lumi Linux. Deși a fost creat în Red Hat și este guvernat și condus de aceasta, doar o mică parte din cei 1.321 de colaboratori lucrează pentru Red Hat.
Așadar, care sunt avantajele Red Hat?
Jim Whitehurst, președintele IBM și fost CEO al Red Hat, a declarat:
„Red Hat a analizat multe opțiuni, inclusiv Upstart de la Canonical pentru Red Hat Enterprise Linux 6. În cele din urmă, am ales systemd deoarece oferă cea mai bună arhitectură, cu extensibilitate, simplitate, scalabilitate și interfețe bine definite pentru problemele actuale și viitoare.”
Whitehurst a menționat și beneficiile pentru sistemele încorporate. Red Hat colaborează cu mari furnizori în industria telecomunicațiilor și auto, unde stabilitatea și fiabilitatea sunt prioritare.
Aceste motive par solide din punct de vedere tehnic. Se înțelege nevoia de fiabilitate a companiei și este normal ca Red Hat să aibă grijă de propriile interese, dar este justificată adoptarea generală a acestui sistem?
Aderarea necondiționată la systemd?
Unii oponenți ai systemd susțin că distribuțiile și utilizatorii urmează orbește exemplul Red Hat și adoptă sistemul.
Cu toate acestea, expresia „a bea Kool-Aid” nu este în totalitate corectă. Termenul a apărut după Jim Jones, liderul unui cult, și sinuciderea a peste 900 de adepți prin ingerarea unui lichid cu aromă de struguri amestecat cu cianură. Deși grupul a consumat Flavour Aid, Kool-Aid a rămas asociat cu acest eveniment tragic.
Mai mult, distribuțiile Linux nu urmează necondiționat Red Hat; adopta systemd după ample deliberări. Discuțiile pe această temă au durat mult timp pe listele de corespondență Debian. În cele din urmă, în 2014, comunitatea a votat pentru adoptarea systemd ca sistem de init implicit, dar cu suport pentru alternative.
Debian este un exemplu relevant, deoarece nu este derivat din RedHat, Fedora sau CentOS. Nu există influență directă a Red Hat asupra Debian. De asemenea, Debian, ca PID 1, are mulți descendenți, inclusiv Ubuntu și numeroasele sale derivate.
Deciziile comunității Debian sunt ample, dezbătute intens și supuse votului, utilizând metoda de vot Condorcet. Comunitatea nu ia astfel de decizii superficial.
În decembrie 2019, comunitatea a votat din nou pentru a continua să se concentreze pe systemd și să exploreze în continuare alternative. Acesta este un exemplu de democrație și libertate de alegere, nu de aderență necondiționată.
Limitările alegerii
De regulă, nu se poate alege dacă se utilizează systemd cu o anumită distribuție Linux. Distribuțiile decid să-l folosească sau nu, iar utilizatorii aleg distribuția preferată. Trecerea unei distribuții preferate la systemd poate fi dificilă.
Utilizatorii care folosesc Debian, Fedora, CentOS, Ubuntu, Arch, Solus și openSUSE, dar care se opun adoptării systemd, se pot simți dezamăgiți. Dacă sunt puternic convinși de anumite opțiuni arhitecturale, reducerea domeniului de aplicare sau nerespectarea POSIX, pot considera dificilă continuarea utilizării distribuției respective.
Există un spectru de opinii: de la cei care nu înțeleg problema (sau nu se preocupă de ea) până la opozanții fervenți. Unii sunt nemulțumiți de schimbări, dar nu sunt suficient de deranjați pentru a schimba distribuția. Ce se întâmplă cu cei care nu se mai pot regăsi în distribuția preferată din cauza principiilor lor?
Din păcate, nu este simplu să instalezi orice sistem de init dorit. Mulți nu au competențele tehnice necesare și se confruntă cu probleme atunci când aplicațiile sau mediile desktop, precum GNOME, au dependențe de systemd.
Trecerea la o altă distribuție este o opțiune. Devuan a apărut ca un fork al distribuțiilor non-systemd (în acest caz, Debian) care adoptaseră systemd. Utilizarea Devuan ar trebui să fie similară cu distribuția părinte, dar nu este valabil pentru toate fork-urile non-systemd. De exemplu, trecerea de la Fedora la AntiX, Gentoo sau Slackware ar oferi o experiență foarte diferită.
Systemd, un viitor sigur
Apreciez unele aspecte ale systemd (mecanisme simple și standardizate de control al proceselor). Nu înțeleg alte aspecte (jurnalele binare). De asemenea, nu-mi plac unele decizii (restructurarea dosarelor de acasă).
Distribuții precum Debian acționează în mod inteligent și explorează alternative, păstrându-și deschise opțiunile. Cu toate acestea, systemd a venit să rămână.
Dacă administrați mașini Linux pentru alții, familiarizați-vă la fel de bine cu systemd ca și cu System V init. În acest fel, veți putea face față oricărei situații.
Utilizați Linux acasă? Atunci, alegeți o distribuție care să răspundă atât nevoilor tehnice, cât și ideologiei dvs. Linux.