SystemD: il software Linux più controverso di sempre

SystemD, il sistema di inizializzazione più diffuso per l’avvio di sistemi Linux, anima da sempre accesi dibattiti online tra i membri della comunità Linux. Vediamo di cosa si tratta, come funziona e perché è così odiato.

Systemd, amato ed odiato

La comunità Linux è unica: un mondo animato da persone che assumono posizione su qualunque progetto o componente software. Non fa eccezione, anzi, il sistema di init, cioè inizializzazione, responsabile dell’avvio dei servizi di un computer equipaggiato con Linux.

Quello ad oggi più diffuso nella stragrande maggioranza delle c.d. distribuzioni Linux è systemd, un vero e proprio demone. Come la maggior parte dei processi software il cui nome termina con la lettera d. Ma non nel senso biblico. Sono infatti così chiamati tutti i programmi software che, anche se non hanno una finestra e non li vedi, restano sempre in esecuzione dietro le quinte, in background come si dice in gergo. Pronti ad occuparsi di qualche servizio all’avvio del PC o appena si verificano le condizioni previste per il suo intervento.

Come detto, systemd fa parte della categoria software dei sistemi di inizializzazione. Ogni distribuzione ne ha uno. È il primo software a partire all’avvio del sistema operativo e resta sempre in esecuzione.

In pratica, ogni sistema Linux (e non solo) assegna un ID univoco ad ogni processo software in esecuzione, Process ID, abbreviato in PID. All’avvio, il kernel cerca PID 1, cioè l’init, il quale poi si occupa di avviare e gestire tutti gli altri.

Per essere più precisi systemd non è un demone ma un insieme di demoni, ciascuno con il proprio compito. Questi sono effettivamente responsabili del funzionamento del sistema perché si occupano di avviare servizi e programmi di base secondo un preciso ordine. In modo da fornirti un ambiente protetto da potenziali danni al kernel, una schermata di login, un ambiente desktop, servizi di connettività, allestire un registro di eventi e pianificazioni e tantissimo altro.

Cosa è systemd

Ad oggi systemd è il più diffuso sistema di init nei sistemi Linux. È stato progettato principalmente da due ingegneri tedeschi dipendenti di Red Hat nel 2010 per sostituire il datato meccanismo dei sistemi Unix SysVinit. Lo scopo era ridurre i tempi di avvio, fargli svolgere più compiti in parallelo e limitare la quantità di risorse hardware utilizzate in background.

Il sito ufficiale di systemd lo definisce come “una suite di elementi costruttivi di base di un sistema Linux. Fornisce un gestore di sistema e servizi che parte come primo processo ed avvia il resto del sistema“.

Systemd è stato ovviamente provato sul campo da Red Hat dapprima in Fedora a partire dal 2011, anno in cui ha sostituito il meccanismo predefinito SysVinit. Ma è stato presto adottato anche da OpenSuse, Mageia, Arch Linux, Debian, Ubuntu e tantissime altre distribuzioni.

Chi lo apprezza sostiene che Systemd abbia reso possibile semplificare molti aspetti di gestione di un PC Linux, migliorandone le performance. Ma malgrado abbia rapidamente conquistato buona parte del mondo Linux, molte distribuzioni non lo hanno mai adottato come sistema di init predefinito. Tra queste AntiX, Alpine, MX Linux, Knoppix, Void Linux, Devuan, Slackware e Peppermint OS.

Systemd bloated?

La prima delle ragioni per cui vi sono accaniti oppositori di systemd è che si ritiene sia un software bloated come si dice in inglese. Cioè che il suo codice sia lievitato a dismisura, tradendo lo scopo inizialmente dichiarato, finendo per occuparsi di tantissimi aspetti che vanno ben oltre l’inizializzazione del sistema.

Con una crescita smisurata del suo codice, un maggiore impiego di risorse, compatibilità con una cerchia ristretta di sistemi operativi, limitazione della scelta per gli amministratori. Contrariamente alla filosofia di derivazione Unix per cui “un software dovrebbe fare una sola cosa e farla per bene“.

In effetti documentarsi su demoni, utilità, sulle librerie di systemd e sulle sue c.d. unità è un’impresa ardua per chiunque, come me, non sia un tecnico. Systemd, solo per fare un elenco molto circoscritto delle sue funzioni, sovrintende all’avvio ma anche all’arresto o al riavvio del sistema. Gestisce il processo di login e altri sistemi di autenticazione.

Si occupa di mettere a disposizione supporti e periferiche connesse al sistema, di gestire i meccanismi di rete e relativi canali di comunicazione, i c.d. socket. Ma come si può vedere dal grafico, il suo campo di intervento è enorme.

L’utilità systemctl fornisce accesso completo alle funzionalità di systemd. Le sue funzioni sono esaminare lo stato del sistema e gestire il sistema stesso e i relativi servizi. L’utilità journalctl consente di ispezionare gli eventi di sistema gestiti da systemd. Con systemd-cgtop puoi verificare l’impegno attuale di CPU, RAM.

No, systemd è un insieme di unità distinte

Chi difende systemd sostiene che si, oggi esso possa sovrintendere anche a tanti aspetti supplementari rispetto all’avvio del sistema. Ma ritiene che non si tratti di un gigantesco monolite ma piuttosto di un sistema modulare, composto da molteplici parti di software, ciascuna delle quali prevista effettivamente per un singolo specifico scopo. E che in questo senso rispetti ancora la filosofia Unix.

Differenti sistemi operativi implementano e si appoggiano a systemd in modo differente, quindi tali scelte influenzano molto la presenza massiccia o meno delle sue possibili componenti.

Va pure detto che systemd è un software sia molto ben documentato che mantenuto, aggiornato quindi molto di frequente, e vi contribuiscono, a vario titolo, migliaia di sviluppatori di tutto il mondo.

È un dato oggettivo che il software sia soggetto a lievitare nelle dimensioni e nelle funzionalità che implementa, perciò pare possa diventare problematico da gestire per un amministratore che necessiti di limitare l’impiego di risorse.

I registri non sono testuali ma binari

C’è chi rimproveri a systemd anche che certi meccanismi siano nascosti all’utente che vorrebbe disporre di file testuali di configurazione. Quando invece le informazioni sono conservate in file binari non ispezionabili se non attraverso le utilità stesse di systemd.

In questo senso si era espresso anche Linux Torvalds, che, come fa spesso, risponde di non avere una precisa opinione ma definiva questo aspetto come un limite ma non un effettivo problema.

Dipende tutto da systemd

Un’altra critica mossa a systemd è che la sua dilagante diffusione faccia si che una miriade di altre componenti software sia progettata per dipendere da esso. Cioè che qualunque software utilizzi una componente di systemd per funzionare, richiederà che esso sia installato nel sistema ospite o, nella migliore delle ipotesi, avrà funzionalità limitate.

Vista dal lato opposto, si osserva che sono sia la quantità delle componenti di systemd che la semplicità con cui i programmatori possono sviluppare ad esempio sistemi di login, gestori di connessioni di rete o di analisi degli eventi di sistema, a renderle spesso requisito di tali programmi.

Ma ciò non significa che non sia possibile realizzare questo genere di software senza systemd. Soltanto che è molto più complesso e può venire valutato sconveniente da piccoli o grandi team di sviluppatori attorno ad un progetto. I quali dovrebbero mettere in conto lavoro extra per progettare, sviluppare, testare e mantenere aggiornate soluzioni alternative.

Systemd è di Red Hat

Come premesso, due ingegneri tedeschi alle dipendenze di Red Hat, capostipite delle grandi aziende tecnologiche nel business dell’open-source, sono i progettisti e sviluppatori originari di systemd (e non solo).

La sua provenienza è un fattore che lo renda ancora più sgradito ad una bella fetta di membri della comunità Linux. Così come altre tecnologie sviluppate internamente a Red Hat tra cui i meccanismi di instradamento dei segnali audio PulseAudio, opera del medesimo Lennart Poettering alla base dello sviluppo di systemd. Oppure il più nuovo server audio PipeWire e il server grafico Wayland.

Ma per essere precisi, alcuni difensori di systemd, stanchi di sentir dire che esso sia il piano di Red Hat per la conquista del mondo, invitano a verificare le attribuzioni di systemd-core, il nucleo di systemd, sottolineando che esso sia riferibile a Lennart Poettering in persona e non all’azienda. Perciò che resterebbe comunque lui il proprietario della tecnologia. E che quindi è improprio dire che systemd sia di Red Hat.

Red Hat è di IBM

In ogni caso, a guastare ulteriormente il quadro della situazione vi è l’acquisizione della totalità di Red Hat da parte di IBM che si è conclusa nel 2019 con una transazione da 34 miliardi di dollari.

La nuova gestione ha già portato un cambio di orientamento di Red Hat nei confronti della propria comunità, con limitazioni alla diffusione dei codici sorgenti delle soluzioni Red Hat Linux Enterprise, che sono quindi da molti considerate meno open.

Anche Canonical, la società che rilascia il diffusissimo Ubuntu, aveva destinato un bel po’ di risorse a sviluppare Upstart, una soluzione alternativa al meccanismo di init dei sistemi Unix, fino ad allora onnipresente. E avevo iniziato qualche anno prima che cominciasse lo sviluppo di systemd. Salvo poi rendersi conto che sarebbe stato molto più semplice e finanziariamente conveniente, adottare systemd ed abbandonarne lo sviluppo nel 2014, anno in cui Ubuntu è stato rilasciato per la prima volta con systemd.

Il timore principale di molti è che vi sia un pericolo legato al controllo da parte di un’unica potentissima realtà, di meccanismi assai diffusi per l’autenticazione nel sistema, la gestione di connessioni di rete e altri servizi vitali e delicatissimi con cui un OS Linux è avviato e gestito. Ma va anche notato che, seppure systemd sia stato per così dire concepito all’interno di Red Hat, vi contribuiscono, ad oggi anche tantissime persone che non sono legate a Red Hat.

Systemd limita la libertà di scelta

La enorme diffusione di systemd e la quantità di compiti che i suoi moduli sono in grado di svolgere, secondo alcuni, indurrebbe un atteggiamento di team di sviluppo dei più svariati progetti ad uniformarsi. Penalizzando l’interesse verso progetti differenti e l’effettiva possibilità di sviluppare soluzioni alternative. Finendo per limitare quindi la scelta dell’utente su come il sistema operativo Linux debba essere gestito nella fase di avvio e nei meccanismi di base.

A questo assunto c’è chi risponde che la questione è spesso la mancanza di conoscenza e talvolta pure il disinteresse di tantissimi utenti Linux nei confronti di queste questioni, anche se rilevanti Perché di alternative a systemd ce ne sono e altrettanti sono i sistemi operativi che le utilizzano, che offrono un’esperienza gratificante e ciascuno ha i propri vantaggi e svantaggi.

E che non si tratti solo di sistemi di nicchia. Debian ad esempio, malgrado l’adozione di systemd come init predefinito, nella sua documentazione ufficiale prevede istruzioni per la sua sostituzione in fase di installazione.

Systemd è pieno di bug critici e falle di sicurezza

Difficile trovare critiche a systemd senza che siano citate le sue più o meno recenti CVE, le common vulnerabilities and exposures, cioè bug e falle di sicurezza, incubo di tutti i programmatori.

Il fatto che un unico meccanismo sia alla base dell’avvio e della gestione di servizi di una innumerevole quantità di computer equipaggiati con Linux, è da molti visto come un problema di sicurezza per niente trascurabile. Un malintenzionato potrebbe prenderli tutti di mira semplicemente sfruttando una di queste vulnerabilità.

In secondo luogo, siccome systemd è enorme e può gestire così tanti aspetti delicatissimi del sistema operativo, molti ritengono che la sua diffusione e i suoi difetti contribuiscano ad ampliare la c.d. superficie di attacco di Linux, ovvero le possibilità di esposizione ad accessi o modifiche da parte di utenti non autorizzati.

Altri rispondono che la presenza dei moduli di systemd piuttosto che di meccanismi alternativi e ad esso estranei, renda la superficie di attacco di un sistema Linux esattamente la stessa. E di preferire che la gestione di tali meccanismi sia affidata a progetti ben mantenuti con alle spalle grandi realtà tecnologiche piuttosto che da progetti gestiti da una manciata di sviluppatori.

In ogni caso Lennart Poettering, è stato insignito ai Pawnie Awards del 2017, premi attribuiti sia per eccellenza che incompetenza nel settore della sicurezza informatica, del premio per la più ridicola gestione dei problemi sorti con i bug di Systemd. Dal 2022 ha lasciato Red Hat per passare a Microsoft.

Systemd o non systemd

Insomma, mastodontico o meno, bacato oppure no, creatura di Red Hat o no, Systemd per molti esperti ha semplificato tanti aspetti di gestione di un PC Linux e dopo 15 anni anima ancora accesi dibattiti nella comunità Linux.

Ogni volta che qualche utente in un commento ad un articolo blog ad un video, mi ha citato systemd, è stato infatti per segnalarmi l’adozione di questa o quella distribuzione Linux o BSD che non ne fa uso.

Io lo ripeto se ce ne fosse ancora bisogno, non sono un tecnico ma rilevo che diverse delle distribuzioni tra le mie preferite, utilizzano systemd come init predefinito. Non temo la catastrofe. Sono felice che, come sempre, esistano alternative sia tra le distribuzioni Linux che tra quelle BSD che systemd lo hanno sempre lasciato da parte.

Penso sempre che se una tecnologia concorrente migliore emerge, questa possa diventare la nuova strada maestra così come è stato per tante altre tecnologie legate a Linux. E sono anche contento del fatto che, chi non voglia adeguarsi alle scelte più in voga, abbia sempre a disposizione più di un’alternativa nel mondo dell’open-source.

Tu di quale categoria fai parte? Alimentiamo ancora il dibattito nei commenti. Grazie per la lettura!