Devuan non è un errore di battitura né un nomignolo sarcastico di qualche complemento di tecnologia. Devuan è una distribuzione Linux, l’ennesima. Devuan è il fork di Debian promesso da coloro che avevano messo in piedi debianfork.org, primo tra tutti Robert Leigh. Il solito fork del fork si potrebbe pensare, tuttavia il segnale – soprattutto perché Debian è una delle distribuzioni madre più longeve – lanciato è forte: il fork c’è e ci sarà in tutti i casi, meglio ancora se la comunità sarà disposta a versare fondi per “la causa”.
Ma la causa quale è? Perché la technical board di Debian si è letteralmente sfasciata, perché c’è tanto fermento nella comunità Linux e c’è praticamente minaccia di fork ovunque, cosa sicuramente non positiva visto il già disastrato scenario della frammentazione nell’ambito delle distribuzioni Linux-based? Una sola parola che dice tutto e niente ed alla quale, nelle righe successive, cercheremo di dare un senso relativo all’intera questione: systemd.
Init, in un sistema operativo Unix, è il primo processo che il kernel manda in esecuzione dopo che il computer ha terminato la fase di bootstrap. Esso ha il compito di portare il sistema in uno stato operativo, avviando i programmi e servizi necessari. Dato che init è il primo processo eseguito, esso ha tipicamente PID 1.
Come avrete sicuramente avuto modo di capire, systemd è un nuovo init system in grado di gestire in maniera differente l’avvio di dispositivi, servizi e demoni precedente alla fase di effettiva usabilità del sistema operativo; in parole povere, systemd andrebbe presumibilmente a migliorare la gestione dei processi – d’avvio, appunto – rispetto ai suoi predecessori come upstart e sysvinit.
Il problema con systemd, tuttavia, sono proprio le sue modalità d’azione: è la politica con cui i nuovi meccanismi approcciano alle componenti di sistema, prima tra tutte il kernel: da una prospettiva puramente tecnica, systemd è un init system tutt’altro che modulare e per natura crea diversi livelli di dipendenza, “obbligando” in qualche modo parte dei pacchetti core di sistema ad instaurare forti dipendenze con esso.
Questo, come scrivevano i detrattori alla base del sito boycottsystemd.org (offline al momento della stesura dell’articolo), va contro tutti i principi della filosofia UNIX, filosofia che quasi tutti i sistemi operativi Linux-based – almeno quelli desktop – seguono meticolosamente come fosse l’ABC della propria esistenza (ed in un certo senso, lo è davvero):
systemd va contro la filosofia Unix “fai una cosa e falla bene”, poiché rappresenta un insieme complesso di dozzine di binari fortemente collegati tra loro. Le sue responsabilità vanno ben oltre quelle di un init system poiché gestisce il controllo dell’alimentazione, i dispositivi, i punti di mount, cron, la cifratura del disco, i socket API/inetd, systlog, la configurazione di rete, la gestione di login e sessioni, il readahead, le partizioni GPT, la registrazione dei container, data, ora e hostname ed altre cose. Mantieni le cose semplici, stupido. (KISS)
Alla base di Devuan, infatti, c’è la “parziale” eliminazione di systemd – o l’eventuale sostituzione con uno shim qualora gli sviluppatori, come decretato dalla Tech Board di Debian, decidano di rendere tightly coupled i propri pacchetti rispetto all’init system:
Il primo pacchetto di Devuan è devuan-baseconf, un installer Debian con preseed di sysvinit-core e diversi pacchetti che contengono chiavi, file di repository e pinnings. Una volta installato ed aggiornato, questo pacchetto evita la richiesta [da parte del sistema] di systemd con PID 1 ed adotta systemd-shim quando strettamente necessario.
Inoltre, sempre secondo i detrattori, systemd sarebbe un meccanismo che non raggiungerà mai uno stato stabile poiché non ha una direzione ben definita; in poche parole, neanche gli sviluppatori di systemd saprebbero cosa questo effettivamente è:
systemd non sa neanche chi diavolo vuole essere. Ci si riferisce genericamente ad esso come un “demone di sistema” o uno “userspace di base che costruisce blocchi da cui costruire un sistema operativo”, definizioni entrambe fortemente ambigue. Adotta funzionalità che appartengono a util-linux, agli strumenti per il wireless, a syslog e ad altri progetti. Non ha una direzione chiara che non siano i capricci degli stessi sviluppatori. Ironicamente, anziché standardizzare le distribuzioni Linux, non ha esso stesso uno standard chiaro ed è in perpetuo rolling.
Riassumendo tutto in poche parole e senza tecnicismi, secondo i detrattori systemd sarebbe troppo invasivo ed imporrebbe, a causa delle forti dipendenze tra le sue stesse componenti, che i sistemi operativi Linux-based dispongano di un set di funzionalità obbligatorie anche se, magari, non ne hanno bisogno.
Ad esempio, siccome Systemd è in grado di gestire i driver wireless, tali tool di gestione andrebbero ad essere integrati a prescindere anche in sistemi per i quali, magari, si potrebbe fare tranquillamente a meno e senza la possibilità di eliminarli, a causa della forte integrazione con la restante infrastruttura dell’init system.
Quel che riguarda systemd è un argomento controverso ed anche abbastanza delicato, che vede contrapposti i concetti di praticità e di integralismo. Perché systemd è pratico per gli utenti e (soprattutto) per gli sviluppatori – oh se lo è – ma va contro tutti (o quasi) i principi che hanno “preservato” l’integrità di Unix e dei Linux-based. Integrità che non è detto venga persa dopo systemd, anzi, ma che sono in tanti a mettere in dubbio.
Morale della favola: Debian ha un fork “quasi” ufficiale in un mondo dove nascono fork – anche se per motivi molto più “futili” – un giorno si e l’altro pure, un fork promosso proprio da color oche parlano di “standardizzare le distribuzioni”.
Ai posteri l’ardua sentenza: chi ha ragione? Chi ha torto?
