LINUX, CHI COMANDA VERAMENTE? É possibile avere un Linux moderno ma senza systemd

Partiamo da una premessa: Linux non è un sistema operativo "democratico". Non esiste una Microsoft o una Apple che decide la direzione. In realtà è un ecosistema di comunità, sviluppatori e aziende che si coordinano, ognuno con il proprio ruolo. E proprio per questo, all'interno di Linux esistono delle vere e proprie fazioni, soprattutto quando si parla di systemd.

Le tre fazioni su systemd

Chi usa Linux si divide in tre gruppi principali:

• Gli indifferenti: la maggioranza. Usano systemd perché è già lì, non hanno opinioni forti in merito. Soprattutto i nuovi arrivati non capiscono perché questo componente generi tanto dibattito.
• I nostalgici: gli storici che vorrebbero tornare al vecchio modo di fare le cose, senza systemd e senza Wayland.
• I critici pragmatici: non sono contro la modernità, ma vedono in systemd una "monocultura". Un insieme di progetti che parlano solo tra loro, rendendo difficile per chiunque voglia innovare inserirsi nell'ecosistema.
  Questa distinzione è importante. Essere contro systemd non significa per forza voler tornare indietro. Significa spesso volere un sistema più modulare, dove i componenti restino indipendenti.

Fedora dice no a una proposta di systemd

Un caso recente molto interessante riguarda Fedora. Systemd ha proposto che le variabili d'ambiente vengano gestite direttamente da lui, invece che nei classici .bashrc o .zshrc. La proposta arrivava da FreeDesktop, dove le specifiche di systemd vengono definite.
Fedora l'ha rifiutata. Il motivo? Obbligare i container Linux a dipendere da systemd avrebbe rotto molte configurazioni server e reso i container più pesanti, visto che avrebbero dovuto includere systemd al proprio interno invece di averlo solo sull'host. Sulla discussione del forum Fedora, su 51 votanti solo il 33% era favorevole. La proposta non è passata.
Questo caso mostra bene la tensione: una proposta utile dal punto di vista tecnico, ma che avrebbe creato dipendenze scomode per chi usa container e ambienti server.

Alternative a systemd: si può fare

Se non si vuole systemd, le alternative esistono. Praticamente si dividono in due approcci:

L'approccio nostalgico

Distribuzioni come Void Linux hanno scelto di usare Runit al posto di systemd e Vendewolf, XLibre al posto di Wayland. Funziona, ma ci sono compromessi reali. Senza Wayland, per esempio, il pinch to zoom non è fluido e lo scroll inerziale non funziona bene. Su hardware moderno, Wayland porta benefici concreti in termini di usabilità.

L'approccio moderno alternativo a systemd: dinit

Qui la cosa si fa interessante. Dinit è un sistema di init molto simile a systemd: gestisce processi in parallelo e in modo asincrono, permette di specificare dipendenze tra servizi, supporta il logging. La differenza chiave? Non impone altri componenti aggiuntivi ed è molto più leggero in termini di codice e responsabilità.
Distribuzioni che usano Dinit:

• Chimera Linux: usa componenti non GNU ma quelli di FreeBSD all'interno di Linux, con Dinit come sistema di avvio.
• Artix Linux: dà la libertà di scegliere il proprio init, permettendo di provare Dinit su una distribuzione reale.

Il problema KDE e GNOME

La questione si allarga ai desktop environment. GNOME ha già una visione molto opinionata, legata a systemd. Ma anche KDE sta valutando se seguire la stessa strada. Se entrambi i grandi ambienti desktop diventassero dipendenti esclusivamente da systemd, chi usa alternative resterebbe senza le sessioni complete di questi ambienti.
La distribuzione KaOS, orientata alle librerie Qt, sta già pensando a soluzioni. Per chi non vuole systemd, suggerisce l'approccio NIRI come compositor e COSMIC come ambiente desktop. COSMIC, sviluppato da System76, funziona senza forzare un sistema di init specifico e nemmeno un compositore particolare. Lo si può usare con NIRI, LabWC o Hyperland, mantenendo i componenti desktop separati.

Conclusione

La questione systemd non è semplicemente "pro o contro la modernità". È una questione di architettura: quanto un singolo componente deve controllare? Il dibattito è aperto, le alternative esistono e stanno maturando. La scelta, come sempre in Linux, sta all'utente.