Quando Debian, con la release Jessie (dell’aprile 2015), decise di usare come init primario systemd, creò molto malcontento: favorevoli e contrari si schierano tutt’ora uno contro l’altro in una vera e propria guerra. Tanto che è nata (almeno) una distribuzione Debian systemd-free: Devuan (di cui abbiamo spesso parlato).

In realtà il passaggio non è mai stato né assoluto, né completo: sono ancora mantenuti i pacchetti per altri init (come sysvinit), e molti servizi sono avviati più da script di init che da unit di systemd.
Il cambiamento di init era dettato – soprattutto – da problemi di dipendenze: alcuni software parecchio usati (GNOME, o Firefox, per dirne un paio) avevano (o stavano per avere) componenti esclusivi di systemd, come systemd-logind o DBus, tra i requisiti; mantenere sysvinit avrebbe costretto alcuni utenti a (più o meno) complicati switch di init. In particolare, si è cercato di agevolare gli utenti desktop che, spesso, sono i meno abituati a modifiche tanto sostanziali (e in profondità) del sistema.

Bene, quindi, tutti felici? Quasi: la scelta di mantenere sysvinit tra i pacchetti costringe ad avere sviluppatori e manutentori dedicati ad almeno ruoli:

• Creazione/manutenzione dei pacchetti sostitutivi dei componenti di systemd (come elogind al posto del componente systemd-logind);
• Verifica delle modifiche di qualunque pacchetto avvii un demone per garantire la presenza e compatibilità dello script di init – spesso usato anche dalle unit di systemd.

Tutta questa introduzione era necessaria per inquadrare quanto scritto qualche giorno fa da Sam Hartman – Debian Project Leader (DPL), ovvero l’autorità massima nel progetto Debian – in una nota che riguarda proprio la sua attività di DPL. Gran parte di questa nota cerca di valutare lo stato delle cose nell’offrire la possibilità di cambiare init, e come andare avanti.
E la situazione non sembra delle più buone. Hartman prende in esame il caso di elogind, e di come i vari gruppi coinvolti (systemd, elogind, apt) abbiamo trovato difficoltà nel comunicare tra loro per risolvere i problemi, evidenziando la fatica e la frustrazione sorte.

Per questo, e da DPL, Hartman si interroga se continuare ad offrire un’alternativa a systemd, e nel caso offrire – e chiedere – maggiore supporto reciproco, o se abbandonare tale possibilità e accettare systemd come dipendenza mandatoria. Ma non sa quale sia la cosa migliore, e nemmeno se c’è una terza via.
Le domande rivolte a se stesso, con ogni probabilità, diverranno una General Resolution, ovvero una votazione aperta a tutti gli sviluppatori Debian per poter prendere una decisione – che poi dovrà essere seguita. E in questo caso la possibilità di lasciare solo systemd non è così remota.

Non sappiamo quale possa essere la strada giusta, ma segnaliamo che l’alternativa systemd-free esiste – e (almeno nel caso di Devuan) sembra apprezzata. Potrebbe aver senso concentrare lo sviluppo su due distribuzioni parallele, e avere libertà di scelta tra queste.

Forse troppa libertà di scelta è dannosa quanta nessuna libertà? Voi cosa votereste?

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.