SystemD paranoia da nostagici o pericolo per l'ecosistema Linux ?

systemd è nato nel 2010 come iniziativa di Lennart Poettering e Kay Sievers (Red Hat) per sostituire SysVinit, ormai inadeguato per l'hardware moderno (boot sequenziale, nessuna gestione delle dipendenze, nessuna supervisione dei servizi). Ha risolto problemi reali: boot parallelo, dipendenze, sandboxing via cgroups, socket activation. Oggi è adottato da tutte le distribuzioni mainstream (Fedora, RHEL, Debian, Ubuntu, Arch, SUSE).

Il problema non è ciò che systemd fa, ma ciò che è diventato: da init system si è espanso in una piattaforma che assorbe sempre più parti del sistema operativo:

Ogni release aggiunge competenze: systemd 260-261 include un installer OS, supporto cloud IMDS, gestione storage centralizzata (storagectl).

I punti di preoccupazione più concreti

1. Feature creep e monotono interdipendente

systemd non è veramente modulare: resolved dipende dall'infrastruttura systemd, journald da PID 1, networkd da systemd. Non puoi prendere un singolo componente e usarlo in isolamento. Come scrive un amministratore su Fedora 42: "3000 thread kernel spawnati da systemd al boot, 25-35 servizi attivi. Doveva aprire l'edificio la mattina, ora è anche il guardiano, l'addetto alle pulizie e decide chi riceve la posta."

2. Attacco superficie e vulnerabilità

systemd 258-259 ha avuto CVE-2026-4105 (privilege escalation via systemd-machined, fix incompleto sui rami stabili) e CVE-2026-40223 (denial of service via cgroups). Più codice in PID 1 = più superficie d'attacco. Il fix di CVE-2026-4105 è stato backportato parzialmente: la namespace check Varlink manca su v258/v257.

3. Il caso age attestation (2026)

La PR #40954 ha aggiunto un campo birthDate ai JSON user records in userdb. systemd sostiene sia "solo un campo opzionale per standardizzare". I critici obiettano:

• Normalizza la memorizzazione di dati demografici nel cuore dell'OS
• Crea un'infrastruttura che altri componenti (xdg-desktop-portal, browser) possono usare per age verification
• Si allinea con leggi statali (California AB 1043, Colorado SB 26-051) che molti nella comunità open source ritengono problematiche

Poettering ha personalmente chiuso la PR di revert (#41179). La motivazione ufficiale del revert è stata:

"Introducing birth date storage creates a new class of sensitive user data in the OS that didn't exist before. It risks normalizing permission-like checks inside the desktop session."

Dopo enorme backlash, la PR di revert #41179 è stata chiusa con la nota che il progetto non implementerà age attestation a livello OS. Ma il campo birthDate è rimasto.

4. Erosione della scelta

• KDE Plasma 6.6: SDDM e DrKonqi ora richiedono systemd. KaOS Linux (13 anni, KDE-only) ha abbandonato KDE per migrare a Dinit.
• Flatpak-NG: Richiederà systemd-appd, tagliando fuori non-systemd distro (Alpine, Devuan, MX Linux, Slackware, Artix). Flatpak è per molte di queste l'unico accesso al mercato delle app Linux.
• Alpine Linux (storica bandiera anti-systemd) sta testando compatibilità systemd, perché l'ecosistema (GNOME, tooling enterprise, container) assume systemd.

5. Dipendenza da una singola azienda

I maintainer principali sono pagati da Red Hat (IBM). Le decisioni strategiche su systemd influenzano tutto l'ecosistema Linux. Con l'assenza di una reale competizione (OpenRC, runit, s6 sono di nicchia), non c'è pressione evolutiva.

6. Binary log (journald)

I log in formato binario rompono decenni di tradizione Unix (plaintext, componibile via grep/awk/sed) e sono illeggibili su un sistema rotto senza systemd funzionante.

La posizione contraria (pro-systemd)

• Risultati concreti: Boot 3-30 secondi, supervisione affidabile, sandboxing che ha migliorato la sicurezza dell'intero ecosistema
• Standardizzazione necessaria: Prima ogni distro aveva init script diversi. Ora systemctl status funziona ovunque
• Non è un monolite tecnico: Sono 69+ binari separati (anche se interdipendenti)
• Adozione per merito: Arch, Debian, Ubuntu hanno scelto systemd dopo valutazione tecnica, non per imposizione
• Le alternative non tengono il passo: OpenRC, runit, s6 mancano di funzionalità che i sistemi enterprise moderni richiedono

Conclusione

Le preoccupazioni sono giustificate se le inquadri come:

• Preoccupazione architetturale: systemd rappresenta un cambio di paradigma dal modello Unix classico (componibilità, minimalismo, piccoli strumenti) a un modello integrato (piattaforma unica, astrazioni potenti ma opache)
• Preoccupazione politica: Una singola entità (Red Hat/IBM) controlla di fatto lo "strato sistema" di Linux. Le decisioni controverse (age attestation, rimozione SysV compat, assorbimento di sempre più funzionalità) vengono imposte all'ecosistema perché non ci sono alternative praticabili
• Preoccupazione tecnica: Feature creep + aumento superficie d'attacco + log binari + complessità di debugging

Non sono tutte giustificate: systemd ha indubbiamente migliorato Linux su molti fronti (boot, supervisione, sandboxing, consistenza). Molte critiche nascono da nostalgia o resistenza al cambiamento. Ma la deriva centralizzatrice e la mancanza di competizione sono problemi reali e non irrisolti.

Come dice un articolo del 2026: "systemd ha vinto il default, ma non ha vinto la discussione, perché la discussione non è mai stata puramente tecnica. Riguarda filosofia architetturale, rischio operativo, e cosa vuoi che PID 1 sia responsabile di fare."

La vera domanda è: puoi permetterti di non usare systemd oggi? Per la maggior parte degli utenti, la risposta è no — e questo è precisamente il problema che i critici segnalano da 15 anni.