OpenRC o systemd

1. Che cos’è un init system

Quando il kernel ha finito di inizializzare l’hardware avvia un solo programma, a cui assegna l’identificativo di processo numero 1. Tutto il resto discende da lì. Questo primo processo, l’init, ha tre compiti che non può delegare:

• avviare gli altri processi, nell’ordine giusto: prima i filesystem, poi la rete, poi i servizi che ne hanno bisogno;
• adottare i processi orfani e raccoglierne lo stato di uscita, perché non restino in tabella come zombie;
• gestire l’arresto, chiudendo i servizi e smontando i dischi senza perdere dati.

Se il PID 1 termina, il kernel va in panic e la macchina si ferma. È il motivo per cui la tradizione Unix ha sempre voluto questo programma piccolo: meno codice gira in quella posizione, meno cose possono rompersi dove non ci si può permettere una rottura.

Attorno all’init vero e proprio c’è il gestore dei servizi, cioè la parte che sa come si avvia un demone, da che cosa dipende, come lo si ferma. In molti sistemi le due cose sono programmi distinti. È una distinzione che torna utile più avanti, perché systemd le unisce e OpenRC no.

2. Da SysV a systemd: breve storia

Per vent’anni le distribuzioni GNU/Linux hanno usato SysVinit, ereditato da Unix System V: un init minimo che esegue, uno dopo l’altro, gli script di shell contenuti in /etc/init.d. Era lento all’avvio, perché procedeva in serie, e ogni distribuzione scriveva i propri script a modo suo.

I tentativi di superarlo furono diversi. OpenRC nacque nel 2007 dentro Gentoo, per mano di Roy Marples, come riscrittura in C del vecchio sistema di script della distribuzione. Ubuntu sviluppò Upstart, basato sugli eventi. Nel 2010 Lennart Poettering e Kay Sievers, allora dipendenti di Red Hat, pubblicarono systemd, con un’idea più ambiziosa: avviare i servizi in parallelo, descriverli con file dichiarativi anziché con script, e tenerli sotto controllo tramite i cgroup del kernel.

L’adozione fu rapida: Fedora nel 2011, Arch Linux nel 2012, Red Hat Enterprise Linux nel 2014, Debian e Ubuntu nel 2015. In Debian la scelta passò per un voto del comitato tecnico, nel febbraio 2014, e provocò una spaccatura: un gruppo di sviluppatori se ne andò e fondò Devuan, una Debian senza systemd.

Due precisazioni rispetto a quello che si legge di solito. systemd non è un prodotto di Red Hat in senso stretto: è un progetto libero, pubblicato con licenza LGPL, nato da suoi dipendenti e a lungo sostenuto dall’azienda. Poettering è poi passato a Microsoft nel 2022 e nel gennaio 2026 l’ha lasciata per fondare una propria società, Amutable. Non è quindi l’essere open source a distinguere OpenRC da systemd: lo sono entrambi. Li distingue quanto codice bisogna leggere per capire che cosa fanno.

Quanto al perché abbia vinto, l’abitudine di chi comincia con Fedora o Ubuntu conta, ma non basta a spiegarlo. systemd risolveva problemi reali: dava a chi scrive software un’interfaccia unica al posto di dieci dialetti di script, e a chi mantiene una distribuzione molto meno lavoro. Chi lo critica deve partire da qui, altrimenti critica una caricatura.

3. Che cosa fa systemd oggi

Il nome inganna. systemd non è un singolo programma ma una raccolta di alcune decine di eseguibili, sviluppati nello stesso repository e rilasciati insieme. Il PID 1 è uno di questi. Gli altri si occupano di:

• log (journald), in formato binario, consultabili con journalctl;
• sessioni utente e postazioni (logind);
• dispositivi (udevd, assorbito nel 2012);
• rete e risoluzione DNS (networkd, resolved);
• orologio (timesyncd) e operazioni pianificate (i timer, al posto di cron);
• avvio (systemd-boot), cartelle utente cifrate (homed), container (nspawn), anagrafica degli utenti (userdb).

Dire che systemd è «monolitico» è quindi impreciso, e i suoi sviluppatori lo fanno notare da anni: i componenti sono processi separati e molti sono facoltativi. L’obiezione seria è un’altra. Questi componenti parlano tra loro tramite interfacce interne, che cambiano da una versione all’altra, e sono pensati per funzionare insieme. Sostituirne uno con un programma esterno è possibile sulla carta e faticoso in pratica. È un accoppiamento stretto più che un monolite, ma per chi deve mantenere il sistema la conseguenza è simile: si prende tutto, o si lavora molto per prendere di meno.

Chi controlla systemd su una macchina controlla i servizi, l’avvio, i log, le sessioni, l’alimentazione e, se sono attivi i moduli relativi, la rete e i nomi di dominio. È una concentrazione di responsabilità che nessun altro software di sistema ha mai avuto su GNU/Linux, kernel escluso.

4. OpenRC: che cos’è e che cosa non è

OpenRC è un gestore di servizi basato sulle dipendenze. A rigore non è nemmeno un init: per anni ha lavorato sopra SysVinit, che restava il PID 1, e solo dal 2017 include un proprio init minimo, openrc-init, che si può usare al suo posto.

Che cosa offre:

• Script di servizio leggibili. Ogni servizio è un file di shell in /etc/init.d, di solito di poche righe, con una funzione depend() che dichiara di che cosa ha bisogno. La configurazione sta a parte, in /etc/conf.d.
• Runlevel con un nome. boot, default, shutdown: cartelle che contengono collegamenti ai servizi da avviare. Si aggiunge un servizio con rc-update add, lo si controlla con rc-service e rc-status.
• Avvio in parallelo, facoltativo, e supporto ai cgroup.
• Portabilità. Funziona su Linux e sui BSD, con la libreria C di GNU e con musl. Per questo lo usa Alpine, la distribuzione su cui gira buona parte dei container.
• Licenza BSD a due clausole.

Che cosa non offre, ed è bene saperlo prima:

• Non sorveglia i servizi, se non glielo si chiede. In modo predefinito avvia il demone e ne annota il PID; se il demone muore, resta morto. Esiste supervise-daemon per riavviarlo, ma va attivato servizio per servizio.
• Non ha attivazione su richiesta tramite socket, né un equivalente dei timer.
• Non isola i servizi. systemd permette di chiudere un demone in una gabbia con poche righe (ProtectSystem=, PrivateTmp=, NoNewPrivileges=, filtri sulle chiamate di sistema). Con OpenRC lo stesso risultato richiede strumenti esterni come bubblewrap o firejail, o le regole di AppArmor e SELinux.

Quest’ultimo punto va detto con onestà, perché riguarda la sicurezza: su una macchina con systemd ben configurato un servizio compromesso può fare meno danni che sulla stessa macchina con OpenRC lasciato com’è. Il vantaggio di OpenRC è altrove: nella quantità di codice privilegiato che gira, e nella possibilità di capire per intero che cosa fa.

5. Lo stesso servizio, due scritture

Un esempio vale più della descrizione. Ecco un demone inventato, prima come unit di systemd:

# /etc/systemd/system/miodemone.service
[Unit]
Description=Il mio demone
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/miodemone --config /etc/miodemone.conf
Restart=on-failure
NoNewPrivileges=yes
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

E come script di OpenRC:

#!/sbin/openrc-run
# /etc/init.d/miodemone
description="Il mio demone"
command="/usr/bin/miodemone"
command_args="--config /etc/miodemone.conf"
command_background=true
pidfile="/run/miodemone.pid"

depend() {
    need net
    after firewall
}

I comandi di tutti i giorni si corrispondono quasi uno a uno:

Le due scritture sono lunghe uguali. La differenza sta in ciò che c’è dietro. La unit è un elenco di direttive interpretate da un programma grande, di cui bisogna conoscere il manuale. Lo script è codice di shell: se qualcosa non va, lo si apre e lo si esegue riga per riga. Il primo modello chiede fiducia, il secondo chiede competenza.

6. Semplice non vuol dire facile

Il confronto che mi sembra più chiaro è quello tra una bicicletta e un’automobile di ultima generazione. Quale delle due è più comoda? L’automobile, senza dubbio: porta più lontano con meno fatica. Ma per dare quella comodità è una macchina enormemente più complessa. E se dovessi ripararle entrambe, da solo, con gli attrezzi che ho in casa? La bicicletta la sistemo in un pomeriggio. L’automobile la porto in officina, dove la collegano a un computer del produttore.

Semplicità e facilità sono due cose diverse. Lo ha detto bene il programmatore Rich Hickey in una conferenza del 2011, Simple Made Easy: facile è ciò che ho sotto mano e mi costa poco sforzo; semplice è ciò che non è intrecciato con altro. Un sistema può essere facile da usare e complicatissimo dentro, e viceversa. systemd è facile. OpenRC è semplice.

La distinzione ha una storia lunga. Il principio KISS (keep it simple, stupid) viene dall’aeronautica: lo si attribuisce a Kelly Johnson, capo progettista della Lockheed, che voleva aerei riparabili sul campo da un meccanico qualunque con pochi attrezzi. La filosofia Unix dice una cosa vicina con parole proprie. Nel 1978 Doug McIlroy la riassunse così: ogni programma faccia una cosa sola e la faccia bene, e i programmi siano scritti per lavorare insieme. Nella programmazione a oggetti lo stesso criterio si chiama principio di singola responsabilità: se una classe ha più di un motivo per cambiare, vanno fatte due classi.

L’idea comune è che la complessità si paga. Un sistema complesso è più difficile da capire, nasconde più errori, offre più appigli a chi lo attacca ed è più costoso da mantenere. Vale per una classe di cinquanta righe e vale per il primo processo di un sistema operativo.

Su GNU/Linux questa non è una posizione di nicchia. Il kernel e gli strumenti di base non sono nati per essere comodi all’utente finale, ma per restare robusti e mantenibili nel tempo; la comodità è arrivata dopo, con le distribuzioni che ci hanno costruito sopra. systemd rovescia la priorità: parte dalla comodità di chi integra il sistema e accetta la complessità che ne deriva.

7. Il costo della centralizzazione

Centralizzare vuol dire far dipendere molte cose da un anello della catena. Se quell’anello cede, cede ciò che vi è appeso. Non serve immaginarlo: è successo.

La backdoor di xz (2024). Nel marzo 2024 lo sviluppatore Andres Freund scoprì che le versioni 5.6.0 e 5.6.1 della libreria di compressione xz contenevano una backdoor, inserita con pazienza da un collaboratore che si era guadagnato la fiducia del manutentore in oltre due anni. Il bersaglio era il server SSH. OpenSSH non usa xz. Ma Debian, Fedora e altre distribuzioni lo modificavano per collegarlo a libsystemd, così da notificare a systemd l’avvenuto avvio; e libsystemd dipendeva da liblzma, cioè da xz. Per una funzione di poche righe, il demone più esposto di un server caricava una libreria con cui non aveva nulla a che fare. L’attacco fu fermato per caso prima di arrivare alle versioni stabili. Le distribuzioni senza systemd non erano raggiungibili per quella via.

Le falle nel codice privilegiato. Nel 2019 la società Qualys pubblicò tre vulnerabilità di journald, due delle quali permettevano a un utente locale di diventare root. Nel 2021 la stessa società ne trovò una nel PID 1: un percorso di montaggio abbastanza lungo mandava in crash systemd, e con lui l’intero sistema (CVE-2021-33910). Tutte corrette in fretta, e nessun software è esente da errori. Ma un errore pesa in proporzione a dove sta, e qui sta nel processo da cui dipende ogni altro.

La superficie d’attacco. Più codice gira con privilegi elevati e ascolta input esterni (pacchetti di rete, risposte DNS, nomi di file, messaggi su D-Bus), più punti ci sono da cui entrare. Un sistema con OpenRC, un demone di log e un client DHCP espone meno codice, scritto da gruppi diversi, che non condividono gli stessi errori.

A onor del vero, il bilancio non è a senso unico. Ho già detto dell’isolamento dei servizi, che systemd rende alla portata di tutti. Dopo il caso xz, inoltre, libsystemd carica le librerie di compressione solo quando servono, e OpenSSH ha imparato a notificare l’avvio senza collegarsi a libsystemd. Il sistema si corregge. Resta il fatto che la dipendenza esisteva, e che nessuno l’aveva considerata un rischio finché non è stata sfruttata.

8. Quando il desktop pretende l’init

C’è un secondo costo, meno tecnico e più politico. Quando un componente diventa lo standard di fatto, il software costruito sopra smette di prevedere le alternative. Non per ostilità: mantenere due strade costa lavoro, e i volontari sono pochi. L’effetto però è che la scelta dell’init, che dovrebbe riguardare solo l’amministratore, finisce per decidere quale desktop si può usare.

Gli ultimi dodici mesi lo mostrano bene.

• GNOME 49 (settembre 2025) ha eliminato da gnome-session il codice che permetteva l’avvio senza systemd. Le correzioni basate su elogind, che per anni avevano tenuto in piedi GNOME sulle altre distribuzioni, non bastano più. Artix ha tolto GNOME dai propri repository: i manutentori hanno scritto di non avere né il tempo né l’interesse per riscrivere quella parte.
• KDE Plasma 6.6 (febbraio 2026) ha introdotto un nuovo gestore degli accessi, Plasma Login Manager, che richiede logind e non funziona né sulle distribuzioni senza systemd né sui BSD. Plasma in sé resta utilizzabile, avviandolo con SDDM o da terminale.
• systemd 260 (marzo 2026) ha rimosso il supporto agli script di servizio in stile SysV: chi distribuisce software con un solo script di avvio deve ora scrivere una unit.
• Linux From Scratch, il progetto che insegna a costruire un sistema GNU/Linux compilando ogni pezzo, ha annunciato il 1º febbraio 2026 l’abbandono dell’edizione SysV. Le ragioni dichiarate sono due: il carico di lavoro di chi tiene aggiornati i libri, e il fatto che GNOME e Plasma richiedono funzioni che solo systemd fornisce. I manutentori stessi hanno definito la decisione spiacevole.

Va riconosciuto un movimento in senso contrario: systemd 259 (dicembre 2025) ha aggiunto un supporto sperimentale a musl, la libreria C usata da Alpine e postmarketOS, con una lunga lista di funzioni che non vanno e nessuna garanzia per il futuro.

La tendenza resta leggibile. Ogni anno chi non usa systemd deve rinunciare a qualcosa in più, o mantenerlo da sé.

9. E la privacy?

Sull’argomento circolano accuse più grandi dei fatti, e conviene separare le une dagli altri.

I fatti. journald raccoglie in un unico archivio i messaggi di tutti i servizi e del kernel. resolved, se attivo, vede ogni nome di dominio che la macchina risolve. Sono dati che restano sul disco locale: systemd non invia telemetria a nessuno. Il problema è un altro. Un archivio unico e ben strutturato è comodo per l’amministratore ed è altrettanto comodo per chi mette le mani sulla macchina, che sia un intruso o chi la sequestra. Ridurre ciò che si registra e per quanto tempo lo si conserva è una misura di igiene che vale con qualunque init, ma che con systemd va fatta in modo esplicito (Storage=volatile, SystemMaxUse=, limiti di conservazione).

Il caso del 2026. In marzo è stata accettata in systemd una modifica che aggiunge all’anagrafica degli utenti (userdb) un campo facoltativo birthDate, la data di nascita. La motivazione dichiarata sono le leggi sulla verifica dell’età approvate in California, in Colorado e in Brasile, che impongono ai sistemi operativi di comunicare alle applicazioni la fascia d’età di chi li usa. L’autore della modifica ha precisato che si tratta di un dato dichiarato dall’amministratore, senza alcun controllo d’identità; Poettering ha sostenuto che systemd è uno strumento neutro e che la tutela spetta all’isolamento delle applicazioni. I critici hanno parlato di piano inclinato, ed è nato un fork che rimuove il campo.

Il campo, in sé, è poca cosa. Quello che l’episodio mostra è il meccanismo: quando un solo progetto gestisce l’identità degli utenti su quasi tutte le distribuzioni, una legge approvata in uno Stato americano diventa una riga di codice presente ovunque. Con componenti separati e sostituibili, la stessa richiesta avrebbe dovuto convincere molti progetti, uno alla volta.

Di init e di comunicazione tra processi parlo anche nella documentazione di Tutanum, dove la scelta fa parte di un progetto di sistema più ampio.

10. Le distribuzioni che ne fanno a meno

Sono poche rispetto al totale, ma non sono marginali: Alpine da sola regge una parte enorme dei container in produzione.

Fuori da Linux la questione non si pone: FreeBSD, OpenBSD e NetBSD usano il proprio sistema rc, configurato in /etc/rc.conf, e systemd non è portabile perché dipende da funzioni specifiche del kernel Linux.

Un limite comune alle derivate, Artix e Devuan in testa, è la documentazione: per quasi tutto rimandano a quella della distribuzione madre, che dà per scontato systemd. Chi le usa impara presto a tradurre.

11. La mia esperienza: Artix, Arch e Gentoo

Uso Artix con OpenRC. La gestione dei servizi è lineare: si installa il pacchetto del programma, si installa il pacchetto con lo script (programma-openrc), lo si aggiunge al runlevel. Il caso scomodo è il software preso da AUR, che di solito porta con sé solo la unit di systemd: lo script di OpenRC bisogna scriverselo. Di rado sono più di quindici righe, ma è tempo che con systemd non si spende. È il costo della bicicletta.

Ho provato anche la strada più ripida, togliere systemd da Arch Linux. Non la consiglio. Arch non la prevede e non la documenta: systemd è una dipendenza diretta o indiretta di una grande quantità di pacchetti, a cominciare dal gestore dei dispositivi, udev, che ne fa parte. L’alternativa storica è eudev, un fork di udev creato nel 2012 dagli sviluppatori di Gentoo proprio per usarlo senza il resto. Su AUR il pacchetto era fermo da anni, e mi sono trovato a scaricare i sorgenti dal repository, compilarli e impacchettarli da me. C’era una ragione: Gentoo ha annunciato nel 2021 di non voler più mantenere eudev, che è passato a un gruppo di contributori di Alpine, Devuan e Gentoo e da allora procede lentamente.

Su questo punto devo correggere un’idea che mi ero fatto. Artix usa udev, e non una sua alternativa: nel 2021 è passata da eudev alla versione originale, compilata da sola a partire dai sorgenti di systemd, senza il resto del progetto. È una soluzione pragmatica, e dice qualcosa: nemmeno le distribuzioni nate per evitare systemd riescono a fare a meno di tutto il suo codice.

Resterebbe Gentoo, che è la casa di OpenRC e la scelta più coerente. Richiede però conoscenze più profonde, tempi di compilazione lunghi, e non ha un deposito ricco come AUR. Per l’uso di tutti i giorni Artix è il compromesso che mi permette di lavorare.

La regola che ne ricavo è che, a parità di obiettivo, un sistema più controllabile chiede più tempo. Non è una legge: è il prezzo corrente, finché la strada meno battuta resta meno battuta.

12. Conclusioni

systemd è diventato lo standard perché ha risolto problemi veri a chi costruisce distribuzioni, e non c’è bisogno di immaginare altro per spiegarne il successo. Le obiezioni reggono lo stesso: concentra in un progetto solo funzioni che la tradizione Unix teneva separate, mette molto codice in posizione privilegiata, e trascina con sé il software che gli sta sopra fino a rendere le alternative impraticabili per chi vuole un desktop moderno.

OpenRC non è migliore in assoluto. Fa meno, isola meno, chiede più lavoro manuale. È preferibile per chi dà valore a tre cose: capire per intero che cosa gira sulla propria macchina, poter sostituire un pezzo senza cambiare tutto, e dipendere dal minor numero possibile di decisioni prese altrove.

Mi ero chiesto, scrivendo la prima versione di queste note, se in futuro per garantirci privacy e anonimato saremmo stati costretti a reinventare la ruota, compilando un sistema da zero con Linux From Scratch. Nel frattempo la domanda ha avuto una risposta ironica: dal 2026 anche Linux From Scratch insegna a costruire soltanto sistemi con systemd. La ruota, se servirà, andrà reinventata un po’ più in basso. Per ora esistono ancora Gentoo, Alpine, Artix, Devuan, Void e i BSD: conviene usarli, documentarli e contribuirvi, perché un’alternativa che nessuno mantiene smette di esistere.

Sul rapporto tra controllo del software e libertà di chi lo usa rimando a Come preferire il software libero al software proprietario; sulla protezione dei dati a macchina spenta, a Cifratura delle memorie.

Riferimenti

• The Register, Systemd daddy quits Microsoft to prove Linux can be trusted, 29 gennaio 2026.
• Linuxiac, Artix Linux Drops GNOME Desktop Support Over Systemd Dependence.
• Adrian Vovk, GNOME and systemd dependencies, 10 giugno 2025.
• The Register, KDE Plasma 6.6 beta ships a login manager that won’t log in without systemd, 26 gennaio 2026.
• Phoronix, Linux From Scratch Abandoning SysVinit Support, febbraio 2026.
• Phoronix, systemd 260 Released, 17 marzo 2026; Systemd 259 Released With Experimental Musl libc Support, dicembre 2025.
• Privacy Guides, Systemd Offers Optional Age Verification, 30 marzo 2026.
• It’s FOSS, Inside the Systemd Age Verification Debate.
• Snyk, The XZ backdoor (CVE-2024-3094).
• Gentoo, eudev retirement, 24 agosto 2021.
• Rich Hickey, Simple Made Easy, Strange Loop, 2011.
• M. D. McIlroy, E. N. Pinson, B. A. Tague, UNIX Time-Sharing System: Foreword, The Bell System Technical Journal, 1978.