mercoledì 1 ottobre 2014

Di nuovo su systemd

Come forse saprete c'è un notevole grado di insofferenza nei confronti di systemd da parte di certi vecchi amministratori di sistemi UNIX con una folta barba. Parte di questa insofferenza è data dalla natura Linux-centrica (Linux inteso come solo kernel) di systemd e dalla quantità abnorme di feature che sono implementate in quello che, secondo la filosofia UNIX, dovrebbe essere un processo semplice e snello che assolve a due soli compiti: avviare/spegnere il sistema e raccogliere i processi orfani ponendo fine alle loro sofferenze.

I fautori di systemd sostengono che ci sono degli indubbi vantaggi nell'approccio da loro scelto (li potete leggere tutti dal sito personale di Lennart Poettering: http://0pointer.de/blog/projects/systemd.html e http://0pointer.de/blog/projects/the-biggest-myths.html ) e che le obiezioni arrivano da dinosauri incartapecoriti che non accettano il cambiamento.

Essendo io uno dei suddetti dinosauri capirete che sono fortemente di parte e che non dovete prendere le mie parole per oro colato.

Sì, lo so, ne avevamo già parlato e rischiamo di essere monotoni, ma sono successe due nuove cose che meritano di essere commentate.

  1. uselessd ( http://uselessd.darknedgy.net/ )
  2. Il progetto sviluppato dallo studente Ian Kremlin per la Google Summer of Code.

Il primo è una versione ridotta del codice di systemd-208-stable (il default in Fedora 20) a cui hanno levato quasi tutto e a cui hanno migliorato la compatibilità con le librerie C diverse dalla GNU libc (sì, systemd compila solo se si usano le glibc perché si basa su alcune aggiunte/modifiche che non sono presenti nello standard o che sono specifiche dell'implementazione GNU).

L'obiettivo a breve termine di uselessd è quello di dare all'utenza GNU/Linux una versione più snella di systemd che contenga solo l'essenziale per far funzionare un init system ma che conservi i due principali vantaggi della creatura di Lennart Poettering:

  1. L'avvio basato su dipendenze definite dall'amministratore (per cui il servizio B che dipende da A non sarà avviato finché A non sarà in grado di offrire i suoi servizi).
  2. L'isolamento e la gestione dei gruppi di processi tramite i cgroups (o meccanismi equivalenti come le jails di FreeBSD).

L'obiettivo a lungo termine è portare uselessd su altri sistemi operativi (principalmente FreeBSD) così da porre fine alle due principali obiezioni che vengono rivolte a systemd: fare troppe cose e non essere portabile.

L'autore ci tiene a precisare che la ragione per cui ha cominciato questo fork è stato per studiare il funzionamento di systemd e che smontare e togliere componenti gli è venuto naturale. In fin dei conti una delle pratiche del reverse-engineering consiste proprio nel vedere cosa smette di funzionare se si tolgono X e Y.

Insomma un esercizio didattico pienamente contemplato dalla licenza LGPL 2.1 (usata da systemd) il cui scopo non è sostituire systemd, ma dimostrare qual è l'insieme minimo di feature che compongono un init system moderno.

uselessd però diventa interessante se appaiato con il secondo punto della lista in apertura: il progetto di Ian Kremlin per la Google Summer of Code 2014.

Tutto da nasce da alcune parole di Lennart Poettering:

We also have pretty comprehensive documentation (all linked from the homepage) about pretty much every detail of systemd, and this not only covers admin/user-facing interfaces, but also developer APIs.

Siccome una delle frasi tipiche degli sviluppatori di OpenBSD è "if you have a problem you can either shut up and hack a solution or pay someone to do that" hanno suggerito agli studenti della GSoC di leggersi la documentazione menzionata da Poettering e di creare dei rimpiazzi API-compatibili per logind, hostnamed, localed e timedated che non avessero altre dipendenze oltre a quello già installato di default nel sistema base di OpenBSD (leggasi: ben poca roba).

Ian Kremlin ha raccolto questo suggerimento, compilato una proposta che è stata approvata e ha lavorato a spese di Google per scrivere questi rimpiazzi completandoli tutti ad eccezione di logind (che per sua natura è decisamente complesso e presenta numerose sfide di implementazione).

L'obiettivo a breve termine è facilitare il port di GNOME 3 su OpenBSD (sì, ad alcuni dinosauri piace GNOME 3) scrivendo dei daemon che siano compatibili a livello di chiamate D-BUS coi corrispettivi in systemd.

L'obiettivo a lungo termine è scrivere un'implementazione portabile su vari sistemi POSIX-compatibili così da fornire delle alternative a chi volesse fare uso delle funzionalità esposte ma non potesse o non volesse installare systemd sul proprio sistema.

A differenza di uselessd il codice di questi daemon è stato scritto da zero basandosi sulla documentazione rilasciata dagli sviluppatori di systemd. Non hanno riscritto l'init system, hanno solo emulato alcune delle chiamate che systemd recepisce.

La speranza di alcuni è che questi due progetti messi insieme possano offrire un'alternativa valida e funzionale a quanti criticano il modus operandi degli sviluppatori di systemd ma si trovano obbligati ad utilizzare in qualche modo i suoi servizi.

Per quanto mi riguarda sono entrambi dei progetti che hanno una buona ragione di esistere: il primo perché dimostra quanto sia possibile fare anche con un init minimale e che apre le porte all'uso di systemd su sistemi che hanno pochissime risorse a disposizione (non ci sono solo desktop e server, ma anche numerosi apparecchi che non hanno abbastanza risorse per far girare tutto quanto ma che beneficerebbero dall'uso di certe parti di systemd). Il secondo progetto ha ancor più ragione di esistere perché offre un'implementazione alternativa che consentirebbe di testare l'effettiva compatibilità con le specifiche da parte di sviluppatori terzi.

Detto questo io torno nel mio antro ad accarezzare la mia folta barba!