Systemd, cui prodest?

Credo che siano molto poche le persone interessate al mondo linux che non siano a corrente delle polemiche sull’implementazione di molte distribuzioni linux del pacchetto systemd in sostituzione del veterano SysVinit.

Su questo punto si è scritto di tutto e di più e abbiamo assistito ad una netta separazione di posizioni, quasi si fosse tifoserie accese ad una partita di calcio.

La questione è però molto complessa. SysVInit è oggettivamente un sistema antiquato, con un elenco di noti difetti, il principale dei quali è sicuramente la grande lentezza derivante dall’approccio seriale all’avvio dei servizi. L’idea di sostituirlo con un prodotto più moderno e meglio ingegnerizzato è, quindi, tutt’altro che sbagliata. Peraltro, la creatura di Lennart Poettering non è la prima a tentare questa impresa.

Il problema reale è che systemd sta andando ben oltre questo encomiabile tentativo, ma sta fagocitando al suo interno tutta una serie di servizi che con la gestione dei processi e la creazione dello ‘spazio utente’ poco hanno a che fare. Approccio, questo, che viola radicalmente le logiche della filosofia Unix, che sono alla base non solo dei Linux che usiamo oggi, ma in larga parte di quella che è l’informatica moderna.

Chi, come me, ha iniziato l’attività in un fase storica in cui i sistemi proprietari erano assolutamente predominanti, ha ben chiaro quale impatto questa filosofia abbia avuto nell’evoluzione dei sistemi, e quanto siano importanti siano i precetti che Mike Gancarz, componente del team di sviluppo di X Window, delineò venti anni or sono:

  • Piccolo è bello.
  • Ogni programma fare una cosa, e bene.
  • Crea un prototipo appena possibile.
  • Preferisci la portabilità all’efficienza.
  • Memorizza i dati in semplici file di testo.
  • Utilizza il potere del software a tuo vantaggio.
  • Usa gli script di shell per migliorare potenza e portabilità.
  • Evita di usare “interfacce utente progioniere” (1).
  • Fai di ogni programma un filtro.

Così come sono da tenere a mente le parole di Doug McIlroy, capo del centro di ricerca scientifica dei Bell Labs ed inventore della unix pipe, che ebbe ad affermare

La filosofia Unix è: scrivi programmi che fanno una sola cosa, e la fanno bene. Scrivi programmi che lavorino assieme. Scrivi programmi che gestiscano flussi di testo, perché questa interfaccia è universale.

Ed è andato ancora oltre,  raccontando l’approccio che avevano ai Bell Labs

Tutto era piccolo… ed il mio cuore ha un colpo per Linux quando ne vedo le dimensioni (…) Solitamente sedevamo nella unix room e discutetevamo: “Cosa possiamo togliere? Perché c’è quella opzione?” Spesso è perché c’è qualche deficienza nella progettazione di base – non hai centrato il giusto punto. Anzichè aggiungere una opzione, ragiona su cosa ti abbia forzato ad aggiungere quella opzione.

E’ evidente che l’approccio seguito dal team di sviluppo di systemd sia diametralmente opposto alle filosofie che hanno fanno, di unix prima e di linux poi, un elemento così importane nell’evoluzione dell’informatica di oggi. Non solo: è evidente che il processo che ha in carico il PID 1 è quello più delicato di tutto il sistema operativo. Un processo per il quale sarebbe giusto e prudente applicare tutte le precauzioni possibili, dato che potenzialmente può compromettere la stabilità dell’intero sistema. Ma anche in questo caso, nonostante il recente caso del bug ‘debug’, la scelta di sostituire il lento, vecchio, ma affidabilissimo SysVinit è proseguita senza alcun problema e/o ripensamento. Come mai?

Ricordo sempre il vecchio detto  “a pensar male spesso si finisce per avere ragione“, e temo che le ragioni siano tutt’altro che tecniche.  Systemd è nato sotto l’ombrello di RedHat, che nel mondo linux ha un grande peso e vaste ramificazioni, sia con il progetto Fedora, che con la sostanziale acquisizione del progetto Centos. Ho l’impressione che systemd stia diventando il cavallo di troia per consolidare ed estendere questo predominio commerciale nel mondo Linux. La filosofia unix rende, per progetto, ogni elemento facilmente sostituibile con alternative. La filosofia di systemd (che mi ricorda tanto quella componenti di altri sistemi operativi commerciali) è quella di accentrare in sé tutto ciò che sia accentrabile. Questo, unito al design progettuale che esclude la portabilità, ed al fatto che già si iniziano a vedere sottosistemi che sono dipendenti da systemd, mi lascerebbe pensare che certe scelte siano tutt’altro che casuali; che lo scopo sia solo quello di affermare la posizione di predominio di RedHat, cercando nel contempo di estendere la penetrazione di Linux verso una clientela normalmente interessata ad altre famiglie di sistemi operativi.

Quindi, tornando alla domanda del titolo, systemd: cui prodest?

Temo a pochi, non credo proprio all’ecosistema linux.


(1) le CUI (captive user interface) è uno stile di interazione con i programmi che prevede che l’input venga gestito (fatto ‘prigioniero’) dal programma e che sia necessario interagire con esso per terminarne l’esecuzione e restituire il controllo all’interfaccia di comandi del sistema operativo. E’ il motivo per cui la quasi totalità dei programmi unix sono controllati da  opzioni (‘switch’) inseriti sulla linea di comando al momento di lanciare il programma. Ciò permette sia l’esecuzione da parte degli utenti, ma anche di essere inseriti in script senza problemi.

Pubblicato in Linux Taggato con: ,
2 comments on “Systemd, cui prodest?
  1. Matnix ha detto:

    Non è che forse si tratta solo di resistenza al nuovo che avanza 😉 ?

    • grutig ha detto:

      Certamente no. Io per mia natura non solo dedico molto tempo alla sperimentazione di tutto ciò che è nuovo, ma del mondo unix/linux ho sempre proprio apprezzato proprio la capacità di evolversi nel tempo mantenendo una integrità ed una coerenza di fondo. I miei primi approcci li ho avuti con Sco agli inizi degli anni ’80, e da quel tempo di acqua sotto i ponti ne ho vista passare tanta. Ci sono state altre polemiche sull’introduzione di nuove tecnologie in passato, ma nessuna ha in prospettiva un impatto della portata di Systemd.
      Io parto dal presupposto che ogni nuova tecnologia debba essere utile. Il 99.9% dei sistemi che seguo sono operativi 24/7 e hanno tempi di uptime che si misurano in mesi. Quanto può essere utile per tutti coloro che si trovano nelle mie condizioni (e sono tanti) un sistema di init che, sostanzialmente, annota fra i benefici solo un tempo di avvio più breve rispetto a SysVInit? Ed è giusto pagare come ‘prezzo’ lo stravolgimento delle filosofie di base che hanno reso unix/linux un caso unico nella storia dell’informatica?
      Ognuno può darsi la sua risposta.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*