Progetti per quanto riguarda la creazione di nuove distribuzioni Linux se ne vedono ogni giorno; ma se qualcuno, nella community degli sviluppatori, avesse deciso di scardinare le regole per costruire qualcosa di assolutamente unico nel suo genere? È così che sono venuto a conoscenza di Maui, il progetto di Pier Luigi Fiorini per un sistema operativo basato su Linux con componenti d´avanguardia.
Systemd, Wayland, Qt5 sono solo alcuni dei pezzi che compongono lo stack software di Maui, che in maniera dirompente promette di farci riflettere a fondo su quello che è Linux oggi e sulle possibili innovazioni della struttura del sistema. Ho colto l´occasione per una chiacchierata con Pier Luigi, perché mi spiegasse la filosofia dietro il progetto, e quali traguardi si è posto.
Ciao Pier Luigi, cosa fai nella vita, che cosa ti ha portato ad utilizzare Linux? Miguel De Icaza ha annunciato la morte di Linux sul desktop: credi che questa sia una realtà?
Sono uno sviluppatore software presso un´azienda di Bologna specializzata in soluzioni Linux-based. Utilizzo Linux ormai da molti anni e ci sono stati diversi motivi che mi hanno spinto verso Linux. Sono stato attirato principalmente perchè sul piano tecnico era nettamente migliore rispetto a Windows ed era più versatile e poi successivamente ho potuto apprezzare i benefici del software libero.
Per quanto concerne le dichiarazione di Miguel De Icaza devo dire che la tematica è molto complessa tuttavia cercherò di essere più sintetico possibile.
L´incompatibilità tra le varie distribuzioni e tra diverse versioni delle stesso software sono problemi sempre esistiti e in fatto di attitudine bisognerebbe imparare dal software proprietario. La compatibilità binaria è attuabile anche nel software libero, ad esempio è rimasto uno degli obiettivi di Qt anche ora che c´è la Open Governance (ed è uno dei vari motivi che mi hanno fatto scegliere questo toolkit per Maui) e sicuramente una maggiore stabilità di componenti fondamentali dello stack come il kernel darebbe un impulso importante a tutto l´ecosistema.
Su un punto non mi trovo molto d´accordo cioè sull´incompatibilità tra le distribuzioni. Noto che ultimamente in fatto di componenti utilizzati dalle distribuzioni sta avvenendo una certa convergenza e con systemd sono convinto che ciò coinvolgerà anche la fase di boot e diversi file di configurazione. Altre grosse differenze rimaste riguardano la gestione dei pacchetti ma la maggior parte delle distro usano RPM o dpkg+apt quindi non siamo di fronte ad un´eccessiva frammentazione.
Quello che realmente manca è l´attenzione verso i dettagli tipica di un prodotto come MacOS X che può piacere o meno ma è indiscutibilmente un ambiente che funziona "out of the box". Secondo me nel mondo Linux si è proprio sbagliato l´approccio con le distribuzioni. Non ne ho ancora trovata una indirizzata realmente ed esclusivamente al desktop. Per realizzare un buon sistema bisogna avere una visione, un obiettivo e bisogna concentrarsi su quello. Chiaramente se all´interno della stessa distro esistono diverse soluzioni in competizione tra loro è impossibile percepire il sistema operativo come un unico prodotto.
Chiarissimo. Effettivamente anch´io sto apprezzando la convergenza delle distribuzioni verso uno standard de facto come systemd. Ma ora parlaci del progetto Maui: quali obiettivi ti sei prefissato?
Il progetto di fatto è nato parecchi anni fa ma all´epoca c´era il toolkit giusto (Qt 4 che era in sviluppo), e non c´era il sistema a finestre giusto inoltre una diversa gestione del boot era da scrivere da zero mentre oggi è realtà. Gli obiettivi che mi sono prefissato riguardano velocità, responsività, integrazione, coerenza, semplicità e cura per i dettagli.
Da quando ho visto per la prima volta Wayland ho deciso di riprendere in mano il progetto, nel frattempo Qt stava cambiando molto grazie a QML e QtQuick che sto utilizzando con enorme entusiasmo per la shell ed il compositor. Noto anche che la mentalità di molti utenti Linux è cambiata, in passato nonostante fosse diffuso un certo dissenso nei confronti di X11 un nuovo sistema a finestre era considerato un´eresia anche se i toolkit piano piano stavano cercando di bypassare il vetusto X11 (si veda ad esempio [1]).
Il sistema non include una pletora di desktop environment, ma ne offre uno solo realizzato appositamente cercando di superare i limiti di quelli attuali. Per quanto riguarda la configurabilità la politica è default sensati per la maggior parte delle esigenze ed equilibrio tra i due approcci di KDE e GNOME cioè troppe opzioni di configurazione o troppo poche. L´ambiente è modulare quindi è possibile creare una shell ottimizzata per ogni tipo di utilizzo, sia desktop che tablet. Secondo me la UX deve seguire le peculiarità del dispositivo sul quale gira, uno dei punti di forza di QtQuick è che facilita molto la suddivisione tra un backend C++ e una GUI moderna realizzata con un comodo linguaggio dichiarativo e JavaScript. Quando ci sarà una maggiore diffusione di questa tecnologia vedremo sempre più applicazioni dotate di interfacce diversificate per desktop e mobile come Snowshoe [2].
La scelta di affidarsi esclusivamente a Qt, di fatto promuovendolo a toolkit ufficiale per lo sviluppo delle applicazioni ha diversi motivi. Sul piano tecnico è un framework object-oriented, elegante e dalle capacità invidiabili utilizzato anche da importanti realtà come Autodesk, Skype e Sennheiser (si veda [3] per un elenco completo). Il parco software realizzato con Qt è cresciuto e sta crescendo per due ragioni: oltre ad essere un framework eccezionale è anche multipiattaforma.
Qt è svilupato come un SDK, è ben documentato, ha esempi che tal volta sono delle applicazioni quasi complete e garantisce la compatibilità binaria all´interno della stessa major release. Sono aspetti importanti per gli sviluppatori e garantiranno al progetto Maui un buon livello di stabilità. Sul versante grafico sono stati fatti notevoli miglioramenti in Qt che insieme a Wayland consentono di avere una GUI senza flickering e sincronizzata con il VSync (si veda [4] per qualche dettaglio tecnico). QML e QtQuick inoltre consentono di realizzare facilmente applicazioni gradevoli con accelerazione hardware.
Affidarsi ad un unico toolkit consente di mantenere la coerenza tra applicazioni diverse, lo stesso comportamento e riduce gli sforzi di mantenimento dei pacchetti all´essenziale rendendo quindi fattibile la manutenzione anche ad un piccolo team di sviluppo che può dedicarsi ad ottimizzare al meglio il software. Può sembrare una scelta "autistica" ma il software per Qt non manca e altri toolkit e relative applicazioni possono essere mantenuti da terze parti come bundle esterni.
Non è importante la sola integrazione delle applicazioni tra loro ma anche l´integrazione con i servizi esterni come Google+, Facebook, Twitter etc. Ritengo che tale funzionalità debba essere demandata a dei plugin che offrono determinate funzionalità piuttosto che alle singole applicazioni che diventerebbero quindi fruitrici di una API in grado di semplificare l´accesso ai servizi. Ad esempio una foto può essere pubblicata su Flickr come su Facebook, un aggiornamento di stato può essere pubblicato su Facebook come su Twitter. Con questo approccio l´accesso a questi servizi viene standardizzato e lo sviluppatore dell´applicazione non deve fare altro che preoccuparsi della propria applicazione. Un ulteriore passo verso l´integrazione avviene con i contatti ai quali possono essere attribuiti dei metadati per identificare l´utente sui vari servizi.
Parte di una buona esperienza utente è data anche dal boot. A questo scopo mi affido a systemd, finalmente il tempo in cui i servizi partivano sequenzialmente e utilizzavano lenti script di shell sono lontani. Allo stato attuale riesco ad ottenere un boot di circa 3,5 secondi escluso il login manager ma seguendo i consigli degli autori si dovrebbe riuscire ad ottenere un ulteriore miglioramento ad esempio eliminando initramfs includendo nel kernel i moduli utilizzati dalla maggior parte delle macchine (ad esempio SATA e il file system). Una parte importante dell´equazione è rappresentata anche dai servizi stessi, ad esempio per il networking sto utilizzando ConnMan che sta maturando molto ed è più leggero di NetworkManager e dhcpcd. Arrivare a 4 secondi compreso il login manager sulla maggior parte delle installazioni è una possibilità concreta.
Uno dei problemi che ho sempre detestato riguarda l´affidabilità degli aggiornamenti. Non credo sia capitato solo a me di aver avuto problemi in fase di aggiornamento dei pacchetti. Certo spesso la causa è la mancanza di test della distribuzione, ma è davvero possibile garantire un livello di test accettabile data la complessità delle distro?
I pacchetti si installano in un unico sistema e tutti interagiscono tra di loro, ad esempio l´applicazione A richiede l´aggiornamento di una libreria per funzionare correttamente ma questo può causare un malfunzionamento sull´applicazione B. Andrebbero quindi testate tutte le combinazioni possibili, una cosa molto difficile sicuramente impossibile per distribuzioni mastodontiche come Ubuntu. L´installazione di un pacchetto modifica il sistema a runtime, i risultati possono cambiare al variare dell´insieme dei pacchetti e delle configurazioni. Un package manager tradizionale inoltre non consente ne l´installazione di un´applicazione per il singolo utente ne di far girare più versioni dello stesso programma simultaneamente.
Maui nasce come un sistema con un set di programmi e librerie ben definito e non opzionali il tutto installato nella directory /system, le applicazioni di terze parti finiscono invece in un´area denominata /common. Il nocciolo del sistema ha una ABI ben definita che non può cambiare (sicuramente non all´interno della stessa major release). La /system è un´immagine che viene montata in read-only quindi è impossibile alterare lo stato del sistema principale, in caso di aggiornamento si scarica un xdelta della nuova build, si costruisce la nuova immagine e grazie a BTRFS è possibile tornare indietro in caso di problemi. In caso di problemi con le applicazioni di terze parti è possibile decidere di caricare la sola /system escludendo /common dai giochi che comunque non può contenere funzionalità importanti per il boot.
Le applicazioni di terze parti e perchè no le applicazioni offerte da Maui ma opzionali sono distribuite come bundle self-contained che non interagiscono tra di loro e continuano a funzionare anche in successive versioni del sistema finchè la ABI rimane stabile. I bundle sono pensati per essere aperti con un doppio click oppure trascinati nella cartella delle applicazioni che li "fonde" con il resto del sistema senza scompattarli. L´unico neo dei bundle riguarda il caso in cui due bundle forniscono la stessa libreria, in tal caso la libreria sarebbe caricata due volte in memoria e l´accesso al disco avverrebbe in due posti diversi. Per risolvere il problema i bundle hanno un indice dei file con un hash, quando due bundle condividono un file con lo stesso hash viene caricato il primo mantenendo quindi i vantaggi delle librerie condivise.
[1] http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/
[2] http://snowshoe.qtlabs.org.br/
[3] http://qt.nokia.com/qt-in-use/
[4] http://labs.qt.nokia.com/2010/12/02/velvet-and-the-qml-scene-graph/
Ottimo: è un sistema ingegnoso. Da questa preview che mi hai dato, tuttavia, riesco a capire che hai intenzione di implementare un tuo gestore di pacchetti che si discosti in maniera evidente dalle alternative odierne; per citarne alcune tra le maggiori, Pacman di Arch Linux, APT/dpkg di Debian, RPM/yum per Fedora. Se c´è una cosa comoda - e che personalmente apprezzo - dei package manager attuali è l´esistenza dei repository e dell´installazione automatizzata del software. Il tuo package manager come intende affrontare questi aspetti?
In realtà non si tratta di un gestore dei pacchetti.
Il sistema attualmente manca della funzionalità dei bundle e utilizza Pacman (per il quale un giorno offrirò una birra agli autori) semplicemente perchè funziona bene e fa tutto quello che mi stavo accingendo ad implementare prima di conoscerlo. Dato che il sistema principale sarà un´immagine continuerò ad usare pacman per la creazione dei pacchetti grazie all´ottimo makepkg e per l´installazione nell´immagine stessa.
Le applicazioni distribuite come bundle non richiedono un package manager perchè semplicemente si scarica il file e lo si esegue un pò come si fa sul Mac solo che qui non si lasciano file in giro (se non i file che può eventualmente creare una applicazione a runtime ma questo vale anche per i pacchetti tradizionali).
La funzionalità dei repository è importante e non voglio rinunciarvi, ma a questo punto dato che l´approccio è diverso da quello tradizionale si limiterà ad essere uno store visto che ormai va di moda ;-P
Di fatto il concetto di repository cos´è se non un´interfaccia di ricerca dei programmi?
In questo modo, ipotizzando un po´ di numeri maggiori per Maui quando sarà il tempo, dovrebbe essere anche un vantaggio presso i produttori di software nel caso in cui decidano di supportare il sistema, o anche per la community, vero? Che struttura vorresti dare al progetto per quanto riguarda la disponibilità del software? Mi spiego meglio: in una distro Linux canonica, il software viene pacchettizzato da dei maintainer. In OSX il maintainer è il produttore del software (grossomodo). In Maui, chi dovrebbe mantenere il bundle, e come dovrebbe renderlo disponibile agli altri utenti?
Se il bundle riguarda un´applicazione di interesse sarà almeno inizialmente mantenuto dal progetto perchè finchè non diventa una realtà conosciuta dubito che gli autori prendano in considerazione la pacchettizzazione che per quanto banale possa essere richiede sempre del tempo per la compilazione e il testing.
Esempi di applicazioni che mi interessano sono Scribus, Yarock, Clementine e QtMediaHub. Ma ce ne possono essere altre. Sicuramente inizialmente sarà scelta la migliore applicazione per ogni categoria.
Andando avanti raggiunto l´adeguato seguito potrà occuparsene la comunità se non lo farà direttamente l´autore. Il bundle comunque è concettualmente semplice e non ha una curva di apprendimento ripida come i formati di pacchetti tradizionali questo potrebbe aiutare la diffusione presso gli autori di applicazioni. Di sicuro il repository/store sarà aperto anche ad eventuali sviluppatori di software proprietario e commerciale una volta che il progetto sarà strutturato adeguatamente per gestire la cosa.
Mi sembra giusto. Ma sono aspetti che sicuramente in futuro avranno occasione per essere esaminati in maniera più rigida: torniamo a parlare un po´ del core del sistema. Come si comporterà Maui nei confronti delle tradizionali applicazioni per Linux? Non pensi che la rottura con la tradizionale gerarchia del filesystem potrebbe portare a dei problemi? Come pensi di gestirla?
Indubbiamente una diversa gerarchia è fonte di problemi, patchare ogni singolo programma è un´impresa titanica e fine a se stessa. La soluzione più semplice ed efficace è con dei semplici collegamenti simbolici che per ragioni "estetiche" possono essere nascosti, GoboLinux docet.
Ora come ora sceglieresti di farti dare una mano nel progetto? Che figure cerchi, visto che stai anche sviluppando una shell, più programmatori o più designer?
Qualsiasi aiuto è bene accetto. Non è necessario saper programmare. Servono designer e programmatori ma anche persone che mi aiutino a tirare su il sito che attualmente è molto scarno sia di grafica che di contenuti. Ci sarebbe anche da lavorare su un tema di icone originale.
Se possibile mi piacerebbe lavorare in parallelo su diverse cose, ad esempio mentre il progetto viene completato sarebbe bello portare avanti il sito per gli sviluppatori per raccogliere informazioni utili a chi vuole avvicinarsi al progetto per essere pronti quando verrà il momento di rilasciare la prima technology preview.
Fino ad ora dove sei arrivato? Ho visto su Google+ che stai scrivendo un file manager, e la shell somiglia ad un incrocio onestamente interessante tra Unity e GNOME Shell.
Ho lavorato su diverse applicazioni contemporaneamente al fine di implementare un livello minimo di funzionalità e le applicazioni più complete attualmente sono il terminale, il file manager, il visualizzatore di immagini e il browser. Per la shell sto provando diverse impostazioni non è detto che questo sarà l´assetto definitivo, ne sperimenterò altri, una possibile variante potrebbe essere una sola barra in basso che contiene le icone delle applicazioni e gli indicatori, le icone delle applicazioni potrebbero essere scalate una volta riempita la barra.
Per la prima anteprima ci saranno le applicazioni principali con l´insieme minimo di funzionalità per poterle utilizzare.
Pensi di rendere configurabile anche l´impostazione dell´ambiente desktop rendendo attuabili le alternative più interessanti a livello di layout dell´interfaccia?
Sicuramente orientamento e posizionamento saranno configurabili con un pò di flessibilità.
Ultima domanda: ho visto che suoni il basso. Che genere suoni con il tuo gruppo?
Suoniamo inediti non cover/tributi, il genere è rock direi anni ´90 anche se ognuno ha le proprie influenze e i testi sono in lingua italiana.
Benissimo, l´intervista è terminata. Grazie di averci concesso il tuo prezioso tempo. C´è ancora qualcosa che vorresti dire ai nostri lettori?
Vorrei dire loro di rimanere "sintonizzati", il sito di Maui sta per essere aggiornato con più contenuti e informazioni su come collaborare. Colgo l´occasione per ringraziarti della visibilità concessami con questa intervista.
Ringrazio anch´io Pier Luigi per il tempo e le risposte estremamente approfondite che ci ha regalato.