Il 26 settembre, dopo ben 5 release candidate, a testimonianza di lunga riflessione, è uscita la Slackware 14.0.
L’annuncio ufficiale cita le svariate novità di questa versione, che spaziano dal kernel Linux 3.2.29, a XOrg X11R7; la Glibc 2.15; Firefox & Thunderbird 15.0.1; KDE 4.8.5 (anche se è possibile reperire già la versione 4.9.2 dai repository di AlienBOB); le ultime versioni di Perl e Python, la versione 2.8.x di Gimp, in cui viene finalmente introdotta l’interfaccia a finestra singola.
Spicca inoltre la presenza del compilatore Clang/LLVM, di origine Apple e ormai divenuto il compilatore ufficiale per FreeBSD, che ha guadagnato la scena negli ultimi tempi come realistica alternativa a GCC, il quale è anche lui presente alla release 4.7.1.
Viene inoltre introdotto l’utilizzo di NetworkManager come metodo unificato per la gestione delle interfacce di rete sia ethernet che wireless, e tutta la struttura di script della distribuzione è stata adattata per la gestione dinamica degli indirizzi sulle interfacce, anche se rimane sempre possibile configurarle con il metodo tradizionale del file .conf. Rimane anche presente Wicd, l’altro gestore di interfacce di rete, che ha meno diffusione nel mondo Linux ma è ugualmente stabile e valido.
A margine della felicità per la release, voglio anche citare quelle che sono le preoccupazioni che si stagliano all’orizzonte per il futuro delle distribuzioni come Slackware, ossia quelle che non si assimilano alle scelte mainstream. Mi riferisco all’avvento di Systemd e Udisks2.
Systemd si propone come gestore dell’init di sistema a soppiantare integralmente sysvinit e l’intera filosofia di gestione avvio e servizi in stile System V o BSD, che da decenni sono alla base di tutti i sistemi operativi di derivazione Unix. Negli ambienti legati a Redhat e GNOME si è affermata l’idea che sia necessario liberare Linux da ogni eredità della tradizione Unix. Immagino che anche il successo di Android, il quale unisce il kernel Linux a una struttura di sistema non di derivazione GNU/Unix, abbia alimentato questa teoria. Non ci sarebbe di per se nulla di male, dato che nel mondo OpenSource da sempre tutti sono liberi di sviluppare nuove soluzioni e alternative, ma in questo caso i sostenitori e gli sviluppatori di Systemd pongono forti pressioni sul fatto che non ci si preoccupi di mantenere più alcun tipo di compatibilità con il sistema init tradizionale, e ne incoraggiano apertamente l’abbandono e la scomparsa, definendo obsoleti e irrilevanti i sistemi che vogliono ancora legarsi a una concezione di stretta derivazione Unix, tra i quali l’intera famiglia *BSD. E’ evidente che questo tipo di approccio, espresso anche in maniere irrispettose e arroganti, se dovesse diffondersi su larga scala potrebbe segnare la fine delle distribuzioni che non volessero adeguarsi ad adottare questo nuovo init, in quanto i vari servizi necessari al funzionamento di un sistema Linux andrebbero a legarsi in maniera sempre più stretta e indissolubile a Systemd rendendo difficile, se non addirittura impossibile, riadattarli all’uso in un sistema init tradizionale.
Systemd inoltre, ed è questo l’aspetto più minaccioso per ragioni che chiarisco poco più avanti, avoca a se le funzioni di dialogo con l’hardware che finora sono state svolte da Udev, il quale è stato fuso in Systemd cessando di esistere come software autonomo.
Udisks2 si inserisce sulla stessa scia, come nuovo metodo di gestione del montaggio dei dispositivi di storage che si distacca dal metodo tradizionale a tal punto che non è più possibile montare i device da linea di comando usando il comando mount!
Vale la pena di sottolineare poi che questi due nuovi software portano con se anche altri due effetti. Il primo è che GNOME 3.2 è totalmente dipendente da systemd e Udisks2, e questo lo lega in maniera esclusiva a Linux e ne impedisce l’uso su BSD. Devo però ammettere che questo è l’aspetto che mi preoccupa di meno, dato che Gnome non mi è mai piaciuto, e non vedo nessun disagio nel non poterlo usare. L’altro effetto è quello di togliere il terreno sotto i piedi a tutti gli altri desktop environment e desktop manager, tra cui appunto KDE, ma anche Xfce e gli altri minori, i quali sono stati integralmente costruiti per dialogare con l’hardware di sistema attraverso Udev e messagebus, e modificarli per lavorare con Systemd sarebbe un lavoro non indifferente, quando fosse possibile.
Le principali ragioni in positivo che spingono all’adozione di questi nuovi sistemi sono il desiderio di velocizzare l’avvio iniziale di un sistema Linux, parallelizzando la partenza dei servizi in modo tale che in pochissimi secondi tutto sia attivo, e il pieno supporto all’inserimento e disinserimento a caldo delle periferiche di storage esterne.
I punti di forza di un sistema init tradizionale invece sono la semplicità e leggibilità delle configurazioni, e la predicibilità della sequenza di avvio, che segue un ordine di partenza dei servizi ben preciso e calcolato, al prezzo di una lentezza nella partenza del sistema, che a mio avviso è assolutamente irrilevante e trascurabile considerate le prestazioni dei moderni sistemi.
Ora, è chiaro che tutto ciò assume un aspetto negativo solo nella misura in cui si attribuisca importanza al mantenimento di un’architettura Unix tradizionale all’interno di una moderna distribuzione Linux, e il tutto sarebbe legittimo e rispettabile se non ci fossero gli espliciti incoraggiamenti e le effettive spinte all’abbandono di ogni compatibilità con il sistema tradizionale.
Bisognerà quindi vedere se nel futuro Slackware sarà obbligata ad adottare Systemd e ad abbandonare la sua proverbiale struttura di file di avvio leggibili e comprensibili, o se si apriranno spazi per la sopravvivenza di un init tradizionale. Tempi duri.
