init in Debian: ne rimarrà uno solo?

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 HartmanDebian 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?

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.

Tags: , ,