E’ come sempre un ottimo spunto per riflettere quello espresso da Paul Venezia in merito all’evoluzione futura di Linux.
Questa volta infatti il blogger di infoworld.com non si sofferma (come fatto in precedenza) limitatamente al discorso systemd, ma affronta in una questione più ampia il futuro di Linux e la strada che questo dovrà seguire nel mercato. Mercato a suo dire diviso nettamente in Desktop e Server.
In particolare Venezia afferma:
Those two workloads are very different, however, and as computing power continues to increase, the workloads are diverging even more.
(In ogni caso i carichi di lavoro sono molto differenti e visto che la potenza computazionale aumenta in continuazione i carichi di lavoro sono destinati a differenziarsi ulteriormente)
Da qui la conclusione: perché non dividere Linux in distribuzioni Server e Client, così come per dire ha sempre fatto Microsoft con Windows? E’ vero che esistono già distribuzioni che rendono disponibili versioni server e versioni desktop (Ubuntu su tutte), ma di fatto si tratta dello stesso sistema (Kernel in primis) che monta pacchetti diversi.
Divergendo gli obiettivi sempre più, non è quindi giunto il momento di separare fisicamente i due contesti?
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
A che pro?
Per aumentare l’entropia che ha sempre caratterizzato i sistemi Microsoft?
Per i desktop, una distro general purpose è sufficiente.
Per i server, un’installazione minimal di partenza da cui selezionare opportunamente i pacchetti opportuni (automatizzabile anche attraverso puppet), è sempre stata un’ottima soluzione.
Trovo giusto che se ne occupi il sistemista invece che distribuire il carico su tutta la filiera: sviluppatori, manutentori, pacchettizzatori ecc. aumentando notevolmente una ridondanza di pacchetti fra i due rami che, a lungo andare, rischierebbe di essere nociva.
Il discorso di Venezia è più ampio e si basa su due principali aspetti:
1) L’aver rilevato che sui server ammennicoli come systemd e gnome3 sono inutili (e systemd non può essere banalmente disabilitato dal sistemista che configura la macchina);
2) L’esposizione in termini di sicurezza delle macchine server che montano componenti desktop.
Per quanto mi riguarda condivido in pieno il punto 1 e non mi è ancora chiaro il motivo per cui Red Hat ha scelto systemd per la release 7 (dopo aver pasticciato con la 6 in upstart), ma non le considerazioni relative alla sicurezza. Se non che, potrebbe essere utile avere finalmente un Kernel “slim” adeguato ai server (e inadatto ai desktop) che nascono per svolgere unicamente una funzione e muoiono avendola svolta (mi vengono in mente gli Hypervisor, ad esempio).
Credo che in ciò, Gentoo sia avanti anni luce (lo è da anni, fin dalla sua nascita).
La distro è unica. Ma non c’è assolutamente nulla di default. Neanche i componenti essenziali. Permettendoti di scegliere il sistema “assemblando” i singoli componenti sw. Un po’ la differenza che c’è tra comprare un computer già assemblato, o assemblarsene uno su misura, scegliendo ogni singolo componente.
Così, allo stesso modo per cambiare sistema di init è sufficiente una sola riga/comando.
Mi viene però una curiosità: Come mai systemd non è consigliabile per server?
Leggo che ne parlano tutti male, io non mi sono ancora informato e non ne so nulla (ma non credo lo farò mai… mi trovo bene con openrc e non ho motivo di cambiare)
Ciao Matteo, sono d’accordo che l’aspetto descritto di Gentoo ne faccia il suo maggior punto di forza. Ad oggi poi che la potenza dei PC è molto maggiore rispetto al passato (e quindi non bisogna passar due giorni a ricompilare per avere un sistema completamente operativo) di certo il discorso ha perfettamente senso.
Per quanto riguarda Systemd il problema è esattamente quello che hai evidenziato: ne parlano tutti male. L’autore originale dell’articolo (Paul Venezia) lo ha più volte sottolineato: a prescindere dal fatto che ogni tecnologia ha punti a favore o meno, se in molti evidenziano anomalie ed aspetti che non funzionano allora quella tecnologia non è pronta per la produzione. Da qui l’idea che systemd sia inadatta ai sistemi server di produzione. Chiaramente passibile di smentita 😉