Intervista a Franco (nexime) Lanza su Devuan, il fork di Debian senza systemd

1) Chi siete e come vi è venuto in mente di realizzare il progetto?
Il gruppo iniziale che ha dato vita al progetto, quello che va sotto il nome “Veteran Unix Admins”, e’ un collettivo formato da sistemisti ed informatici per lo più’ italiani che da alcuni anni si incontra, con lo scopo dichiarato di allietarsi tra simili, in un forum privato.Il nome del gruppo proviene da qui: http://www.infoworld.com/article/2623488/unix/nine-traits-of-the-veteran-unix-admin.html

Da questo un piccolo gruppo di persone (qualche decina sul migliaio abbondante di membri che conta il gruppo), tutti sistemisti o comunque professionisti, alcuni dei quali anche Debian Developers, tutti utenti Debian, hanno deciso di avanzare prima l’ipotesi di un fork tramite il sito debianfork.org, e successivamente di procedere al fork vero e proprio lanciando il progetto Devuan.

Oggigiorno al gruppo iniziale si sono aggiunti altri sviluppatori, contributori o semplici sostenitori esterni che, chi piu’ chi meno, hanno preso parte allo sviluppo attivo del progetto.

2) Cosa non vi piace di systemd?
Non ci piace continuare a doverne parlare, questa continua connotazione “anti-systemd” ci va davvero stretta, Devuan non e’ un progetto “anti-systemd”, certo, systemd è stata se vogliamo “la goccia che fa traboccare il vaso”, ma il progetto va ben oltre il semplice antagonismo a systemd, sebbene la sua eliminazione sia il primo traguardo che ci siamo prefissati.

Se proprio devo rispondere alla domanda così come è posta, ad ogni modo, devo dire che non esiste una risposta uguale per tutti, i motivi per cui alle persone non piace systemd sono molti, alcuni anche opinabili per carità, ma non siamo tutti uguali in questo. Posso rispondere quindi per lo più a titolo personale a riguardo.

Personalmente iniziai ad usare Debian nel lontano ‘96, e, quando scelsi di usare Linux e Debian in particolare, li scelsi perché seguivano la filosofia UNIX e, grazie al sistema GNU, anche i principi di sviluppo KISS, a mio avviso due dei principali ingredienti, insieme alla filosofia del software libero, che hanno poi nel tempo permesso a GNU/Linux di divenire quello che è oggi, il primo sistema operativo in assoluto al mondo per diffusione, ed in particolare il dominatore incontrastato in ambiente server ed embedded.

Oggi l’introduzione di systemd fa venire meno queste due caratteristiche, il sistema diventa “meno UNIX” e “meno KISS”. Non è che non mi piaccia systemd in pratica, è che io ho scelto di usare un sistema diverso, e non voglio che mi sia imposto di cambiare per qualcosa che non ritengo essere una evoluzione positiva ma, al contrario, ritengo essere un’involuzione.

La nuova generazione di sviluppatori, di cui Poettering fa parte, sembra aver perso la memoria storica del perché UNIX ha determinate caratteristiche e del perché sono state fatte determinate scelte implementative che, superficialmente, a volte possono sembrare inferiori, ma che sul lungo periodo hanno ampiamente dimostrato di essere la via corretta. Forse è anche colpa “nostra”, dove per “noi” intendo “la vecchia generazione” di informatici, che non abbiamo saputo tramandare questa memoria storica, ma al di la di chi abbia la colpa, questo fa si che la storia si ripeta e si compiano di nuovo errori che erano già stati ampiamente risolti nel passato, e systemd rappresenta, per me, uno di questi errori. O meglio molti di questi errori in una volta sola.

A questo poi aggiungiamo anche che la forte interdipendenza dei componenti di systemd nel suo insieme, oltre che la dimensione stessa del solo componente di init, fanno si che il sistema finale abbia un footprint in memoria maggiore, e questo se da un lato in molti sistemi puo’ essere ignorato, in alcuni ambienti e’ un problema, di conseguenza il potenziale parco di utilizzo di una distro che utilizza systemd si riduce sensibilmente.

3) Perché affermate che systemd non è unix se in realtà è composto da vari moduli?
Un sistema UNIX ha tante caratteristiche, tra le quali la modularità. Ma questa da sola NON è sufficiente, oltre alla modularità è necessaria l’indipendenza.

In un tipico sistema UNIX troviamo tanti piccoli componenti che svolgono un compito solo e lo svolgono al meglio, e tentano di farlo nella maniera più indipendente possibile dagli altri componenti presenti nel sistema.

Questo, a sua volta, permette di dare reale potere al sistemista, che è in grado di “piegare”, “addomesticare” il sistema alle proprie esigenze, scegliendo in prima persona il mix di componenti più adatti allo specifico compito che dovrà svolgere la macchina che sta amministrando.

Systemd è si modulare, ma i suoi moduli sono tutti strettamente legati fra loro e, per svolgere appieno il loro compito, necessitano anche anche molti componenti esterni si leghino a systemd. Questo rende la modularità di systemd solo apparente, perché l’insieme dei suoi moduli si comporta poi a tutti gli effetti come un monolite che leva al sistemista la libertà di adattare al proprio uso il sistema, e, al contrario, occorre che sia il sistemista ad adattarsi alle scelte operate dagli sviluppatori di systemd, che possono essere più o meno valide, ma sicuramente non possono essere in nessun caso “universali” e adatte a tutti gli use case.

4) Systemd, così come tutti i grandi progetti progetti, ha bisogno di un po’ di tempo per stabilizzarsi. Se fosse perfetto lo usereste?

Se ci fate caso fino ad ora non ho mai parlato dei problemi di gioventù di systemd ne dei suoi bug.

Certo, systemd ha molti bug attualmente, alcuni peraltro abbastanza ridicoli, altri per scelte sbagliate “imposte dall’alto”. E non solo, c’e’ anche un certo atteggiamento da parte del gruppo di persone che ne porta avanti lo sviluppo che tende a rispondere troppo spesso con un “WONTFIX” o un “NOTABUG” quando si fanno notare certe scelte di sviluppo che sono oggettivamente opinabili proponendo delle soluzioni o delle patch.

Ma nessuno di questi e’ il reale problema di systemd. Anche qualora questo fosse per ipotesi del tutto esente da bug e perfettamente stabilizzato, e anche ammettendo che l’atteggiamento degli sviluppatori di systemd divenisse più collaborativo, non cambierebbe nulla.

Ciò che è sbagliato in systemd sono i concetti e la filosofia di base, e l’unico modo per correggere questo genere di problemi è quello di non usare systemd.

5) Cosa rispondete a quelli che dicono che siete solo dei vecchi retrogradi che non accettano le innovazioni?

Risponderei citando Henry Spencer: “Those who do not understand Unix are condemned to reinvent it, poorly.”
E aggiungerei: noi siamo assolutamente favorevoli all’innovazione. Siamo però selettivi e vogliamo solo le innovazioni positive, non quelle che consideriamo regressioni.6) Perché nessuno si è messo a implementare qualcosa di meglio di systemd che includa alcune feature interessanti in modo da combattere systemd?

Non posso rispondere a questa domanda per il semplice fatto che parte da una affermazione falsa.

Ad oggi esistono diversi init alternativi al buon vecchio sysvinit i quali, in parte, affrontano alcuni dei problemi che systemd tenta di risolvere, come, giusto per citarne solamente uno che mi piace molto, OpenRC, ma non e’ certo l’unico.

Esistono poi diversi altri progetti, esterni e slegati dal sistema di init, che affrontano altri dei problemi che systemd vuole affrontare, come daemontools per la gestione dei servizi, sempre per citarne uno solo, ma anche alcuni nati in seno a devuan come vdev, che si propone di sostituire udev (che a proposito, se fosse rimasto esterno a systemd non avrebbe avuto bisogno di essere sostituito), loginkit, che si propone di sostituire systemd-logind, calzetta, che si propone di offrire in maniera KISS le api sd_notify introdotte da systemd.

Ci sono poi una classe di problemi che “non sono problemi” e che quindi non necessitano alcuna risoluzione, come i log con journald, che sono una pessima soluzione a un problema inesistente e non va certo risolto.

E ancora c’è un’altra classe di soluzione di systemd che, per noi, non sono soluzioni ma volontà di mettere in mano i sistemi a “operai dell’informatica” invece che a sistemisti (senza offesa per gli operai), come ad esempio l’integrazione con cgroups o molto altro che era fattibile anche prima, solo che prima occorreva un sistemista con un pò di testa sulle spalle e un pò di buon caro vecchio scripting per fare le cose, oggi “systemd sa’ come è meglio farle per te”. Peccato che quel che è meglio per systemd non sempre è meglio per i miei scopi.

La verità è che systemd introduce si qualche piccola innovazione positiva, ma di contro introduce anche moltissime scelte pessime, e anche le poche soluzioni innovative realmente presenti in systemd sono state comunque implementate in un pessimo modo, contrario al buon senso.

7) Pensate di farcela a gestire il carico di lavoro necessario a mantenere una distro? Avete mai preso in considerazione di prendere altre distro come base e nel caso di passare agli rpm (che poi sarebbero lo standard)?

Rispondo prima all’ultima parte della domanda, e lo faccio con una domanda a mia volta: da quando rpm è diventato standard?

Nel mondo linux non esiste una forma di pacchettizzazione standard, ci sono vari formati, alcuni più diffusi e altri meno. Non so quale dei due tra rpm e deb sia più diffuso sinceramente, ma sicuramente i deb se non sono i più diffusi, sono i secondi più diffusi in assoluto.

Non abbiamo mai pensato di passare a rpm o di prendere altre distro come base, tutti noi in Devuan proveniamo da lunghi anni in Debian, consideriamo quindi Devuan la naturale evoluzione di Debian dopo che questa ha smesso di essere il “sistema universale” ed e’ rapidamente cambiata con l’introduzione di systemd e non solo.Se qualcuno vorrà avere a disposizione una distro rpm based o comunque basata su altro diverso da Devuan e senza systemd, potrà seguire il nostro esempio e forkare a sua volta, ma non è nostro compito questo.

Pensiamo di farcela a gestire il carico di lavoro necessario? No, non pensiamo di farcela. Ne siamo assolutamente certi.

8) Che ne pensate del progetto Debian LTS che estende il supporto per la oldstable con dei backport?

Il progetto LTS di perse’ è valido e permette una maggiore penetrazione e affidabilità a Debian in ambienti professionali di un certo tipo. Probabilmente anche Devuan proporrà un progetto simile.

Ma mi chiedo, come mai dobbiamo parlare di Debian? non sarebbe meglio parlare di Devuan?

9) Cosa fareste nel caso in cui logind diventasse una dipendenza necessaria per tutti i DE?

Non credo che questo succederà mai, esistono altri OS UNIX e POSIX oltre a Linux (che è uno UNIX-like, non uno UNIX ufficiale, ma che possiamo considerare tale ai nostri fini), e systemd-logind su questi non gira. Ci sarà quindi sempre la possibilità di patchare i sorgenti per evitarlo. E comunque abbiamo loginkit che prima o poi sarà maturo, qualora ce ne fosse proprio bisogno.

10) Nonostante i numerosi tentativi di includerlo KDBUS non fa parte del kernel vanilla, credete che le obiezioni di Linus Torvalds siano leggittime e che l’attuale versione del daemon DBUS spende buona parte del suo tempo in userspace a reimpallarsi GObject invece di fare il suo lavoro e andrebbe semplificata o ritenete che si sbagli e che DBUS sia il modo giusto di fare IPC?

Entriamo in un argomento molto controverso. Un numero rilevante di persone che orbitano attorno al progetto Devuan sembra considerare KDBUS il male fatto codice.

Personalmente ho una visione un po’ diversa, e ritengo che al momento attuale le critiche di Linus siano sacrosante e corrette, ma ritengo al contempo che si arriverà alla sua integrazione nel Kernel, è solo questione di tempo, i sostenitori di KDBUS alla fine arriveranno a farne una implementazione con uno standard qualitativo sufficiente per l’inclusione nel Kernel e troveranno altre motivazioni più valide della sola velocità di esecuzione che è stata così fortemente criticata da Linus.Tuttavia non ritengo questo un problema perchè sono convinto che in nessun caso KDBUS diverrà obbligatorio nel kernel, quindi se non lo si vuole sarà sufficiente non abilitarlo.

Ritengo anzi che KDBUS potrebbe addirittura finire con l’aggiungere al kernel anche qualche funzionalita’ valida che potrebbe eventualmente permettere di essere anche riutilizzata per aggiungere ulteriori interfacce diverse da DBUS nel kernel stesso, sfruttando il codice di backend che sostiene KDBUS, favorendo quindi anche sistemi non basati su systemd. Ma sottolineo che questo è un parere del tutto personale e controcorrente rispetto a tante voci che sento gravitare in questo momento intorno al progetto Devuan.

11) Secondo te quali sono i capisaldi che devono e dovranno sempre essere mantenuti nel futuro di Linux? E quali sono i punti dolenti e meno efficaci che dovrebbero essere abbandonati e smussati?

I capisaldi, a mio avviso, sono, qui in ordine sparso:

• rimanere software libero (nessun dubbio su questo)
• osservanza delle filosofie UNIX e degli standard POSIX ed eventualmente successivi nel segno della continuità con questi.
• filosofia KISS
• varietà’ ed eterogeneità

Occorre abbandonare il tentativo di unificazione estrema e di eccessiva omogeneità, l’eterogeneità e l’ecosistema vario e complesso sono stati e saranno sempre il vero caposaldo fondante del successo odierno di GNU/Linux, per chi si ricordasse ancora cosa sia, vorrei lanciare un piccolo ricordo a “La cattedrale e il bazar” di Eric S. Raymond, sempre molto attuale.

Occorre smussare la volontà di essere “desktop first”, perchè un eccessiva focalizzazione a un determinato ambiente va, gioco forza, a scapito degli altri ambienti, e un punto di forza molto importante in GNU/Linux e’ stato sempre quello di essere estremamente malleabile e adattabile agli ambienti più disparati.

Se posso permettermi, alle risposte di cui sopra, vorrei aggiungere una piccola nota finale.

Mi piacerebbe moltissimo se in futuro si parlasse di più di Devuan, del progetto, dei nostri obiettivi, di quel che stiamo facendo e di quel che abbiamo fatto, e meno di systemd e del perchè noi non lo usiamo.

Molto codice è stato già scritto e molta infrastruttura tecnica e sociale è già stata costruita, e molto altro abbiamo nella nostra lista “TODO”, ridurre il progetto Devuan solo a “siamo quelli senza systemd” e’ davvero scalfire solo la superficie di ci che vogliamo rappresentare e che ci poniamo come obiettivo finale, che non è quello di eliminare systemd, ma è quello di riportare in prima linea la comunità e le sue esigenze, i tecnici, i sistemisti, le persone che sanno dove mettere le mani in un sistema per adattarlo alle proprie esigenze che, fino ad oggi, si è sempre potuta avvalere di quello che io considero il miglior OS sulla piazza, mentre tutti gli altri si facevano guidare dagli sviluppatori di Microsoft o di altre aziende, e che, a causa anche ma non solo di systemd, oggi vede messa in pericolo questa possibilità e si sente schiacciata a dover diventare mera utilizzatrice di cose preconfezionate per esigenze commerciali di terzi, perdendo il primato e la proprietà effettiva del proprio sistema.

Siamo sistemisti, siamo sviluppatori, siamo informatici, ma prima di tutto siamo persone che conoscono a fondo il proprio sistema e i propri scopi, e vogliamo continuare a poter scegliere cosa deve e cosa non deve girare sui nostri sistemi, quali siano le soluzioni più adatte per raggiungere i nostri obiettivi, vogliamo essere liberi eventualmente anche di sbagliare ed imparare dai nostri errori.

Devuan fondamentalmente è un progetto di libertà.
Franco (nextime) Lanza