Intervista a Pier Luigi Fiorini, autore di Maui Project
Secondo appuntamento della settimana con le interviste ai programmatori italiani. Il pacco di Marco ha questa volta avuto il piacere di intervistare Pier Luigi Fiorini, autore di Maui, il primo sistema operativo Linux interamente basato su Wayland, Qt5 e QtQuick. Altra caratteristica della distro è che come DE utilizza Hawaii, una shell che mira a creare un ambiente facile da utilizzare e con un default che accontenti tutti gli utenti.
A voi le domande e buona lettura 🙂
 |
| Maui |
1) Come prima cosa che ne diresti di presentarti ai lettori di Marco’s Box parlando un po’ di te, dove sei nato, cosa fai nella vita etc
Sono nato a Bologna e nella vita indovina un pò faccio l’analista programmatore 🙂
Nel mio lavoro “vero” sviluppo software su Linux quindi sono molto soddisfatto di essere riuscito a fare quello che mi piace nella vita. Ho anche l’hobby della musica e suono il basso elettrico a tempo perso.
2) A che età il primo approccio con l’informatica? Quando invece con GNU/Linux?
Intorno ai 13/14 anni con un vecchio IBM Portable PC con monitor integrato color ambra dal peso di circa 14kg (alla faccia del portatile) [1] e monitor esterno [2].
Qualche anno più tardi colonizzai il 386 di mio padre installando Slackware e da lì in poi, salvo un piccolo periodo passato su MacOS X, ho sempre utilizzato Linux ma ho avuto modo di apprezzare una perla dell’informatica come BeOS.
BeOS e MacOS costituiscono i miei punti di riferimento per quanto riguarda i desktop environment.
3) Quando ti è nata la passione per la programmazione? Qual è il tuo linguaggio preferito?
Direi quasi da subito, quando mi piace qualcosa sento l’esigenza di capire come funziona.
Alle scuole medie ci fecero provare un po di programmazione con QBasic e a casa sul “portatile” avevo GW-BASIC quindi il divertimento non terminava a scuola.
Dopo sono passato agli strumenti visuali di Microsoft, Delphi e poi su Linux ho iniziato ad interessarmi a GTK+ e fino alla scoperta di Qt che dalla versione 4 è diventato un framework veramente moderno e completo catturando definitivamente il mio interesse.
Non ho un solo linguaggio preferito, diciamo che dipende da ciò che devo fare.
Per lo scripting sicuramente adoro Python e lo uso anche nello sviluppo Web insieme a Django.
Per tutto il resto tendenzialmente utilizzo C++. Non disdegno Perl se devo fare un uso massiccio di regular expression, da shell spesso lo preferisco a sed e awk.
4) Ma passiamo alla Maui, la tua creatura, parlacene un po’, come è nata l’idea, quanto tempo gli dedichi etc…
L’idea è nata tanti anni fa. Data la mia esperienza su BeOS e la sua prematura scomparsa ho seguito il progetto OpenBeOS diventato qualche anno più tardi Haiku e mi sono dedicato a qualche progetto sperimentale per portare le API di Haiku e di conseguenza le applicazioni su Linux. Su Haiku ho poi contribuito con diversi progetti, principalmente sulle notifiche e l’instant messaging ma questa è un’altra storia.
Su Linux non c’era un sistema a finestre decente, ricordo che XFree86 era peggiore di ciò che è oggi Xorg quindi l’unica alternativa valida era DirectFB così mi rimboccai le maniche e portai a termine un prototipo. Questo progetto mi diede anche l’occasione di giocare con Cairo, fu molto divertente.
Mi resi conto che su Linux c’erano tante cose che non andavano.
Erano ancora i tempi di HAL e hotplug, il boot di un sistema Linux era lentissimo e coinvolgeva una valanga di script bash e non ci voleva molto a capire che rimpiazzare gli script con del codice C sarebbe stato meglio.
Mancava poi un file system che consentisse delle ricerche veloci e l’indicizzazione dei metadati come su Haiku, inoltre la gerarchia del file system era a mio avviso da rivedere ad esempio spostando alcune directory toplevel come /bin, /sbin e /lib dentro /usr e magari una spolveratina ad una struttura un pò vetusta.
Installare le applicazioni non era ancora un processo facile e spesso non c’era una relazione 1:1 tra pacchetto e applicazioni quindi sentivo l’esigenza di gestire la cosa in maniera differente. Beh direi questo aspetto non è cambiato molto.
Gli aggiornamenti poi erano problematici, infatti capitava spesso di aggiornare componenti in esecuzione trovandosi a gestire diversi problemi, gli avanzamenti di versione poi erano spesso poco praticabili anche per la notevole mole di pacchetti da scaricare e di sicuro le linee dell’epoca non aiutavano.
C’era troppo lavoro da fare per una persona sola, coinvolgere altre persone era complicato perchè molte delle cose che volevo fare non erano recepite bene 10 anni fa. Ad esempio, proporre di attivare solo il login grafico come sta avvenendo oggi nel contesto di systemd e Wayland era considerato eresia.
Senza un sistema a finestre degno di questo nome era comunque impossibile continuare.
Poi arrivò Wayland e ripresi in mano questo progetto.
Fortunatamente nel corso di questi anni alcuni di questi punti sono stati risolti per cui oggi non solo abbiamo Wayland ma anche systemd e Qt 5 ha portato tantissime novità.
Tuttavia sulla mia macchina Fedora 20 stando a systemd-analyze il boot impiega 55 secondi (il tempo per kernel e initrd è comparabile ad Archlinux, quello che impiega tanto è userspace) e questo a mio avviso è segno che forse c’è qualche servizio di troppo che parte e c’è spazio di manovra per le ottimizzazioni.
5) Com’è strutturata la distro? Che gestore processi pacchetti usa? Ci sarà mai una versione a 32bit?
Il fulcro della distribuzione è OSTree, una sorta di git ottimizzato per i binari del sistema operativo. Ad ogni aggiornamento del sistema operativo vengono scaricati solamente i file che sono cambiati riducendo di molto il peso del download, poi viene fatto il deployment del nuovo albero e riavviando la macchina è possibile utilizzare il nuovo albero.
L’aggiornamento quindi non ha un impatto sul sistema durante la sua esecuzione, inoltre è possibile tenere anche le versioni precedenti del sistema operativo per tornare indietro in caso di regressioni.
Le immagini live vengono create da un tool in Python che si chiama mauibuild. Questo programma legge un manifest JSON che elenca i vari componenti della distro e il sistema base che attualmente è Yocto e compila i vari componenti da git o da tarball importati su un repository git producendo diversi alberi: runtime, devel, debug e live.
Come è facile intuire runtime è l’albero del sistema operativo per gli utenti, devel contiene gli strumenti di sviluppo, debug è una copia di devel con i simboli di debug e live è uguale a runtime ma ha alcuni componenti specifici per l’immagine live. I file presenti su diversi alberi si contano una volta sola, quindi sul repository il loro peso non si moltiplica per gli alberi in cui sono presenti.
Tutto ciò è utile anche per lo sviluppo, se mauibuild viene usato in modalità continuous integration è possibile compilare ogni singola modifica ai vari componenti e procedere poi per bisezione alla ricerca del commit che ha causato la regressione.
Il tool mauibuild, anche se non è ancora sofisticato, è pensato per effettuare dei test automatizzati sull’intero sistema.
Il sistema operativo gestito da OSTree risulta immutabile, serve quindi una diversa gestione delle applicazioni: non più pacchetti ma bundle.
Tale formato di bundle sarà sicuramente standardizzato in futuro, oltretutto so che anche gli sviluppatori di GNOME sono interessati.
L’unione fa la forza quindi non ho certo intenzione di introdurre un mio formato ma di collaborare con chi è interessato alla cosa.
Anche il progetto KDE si prospetta utile per raggiungere questo obiettivo, pare infatti che stiano realizzando uno store chiamato Bodega per contenuti FOSS, software inclusi.
Bodega potrebbe essere il vettore di bundle giusto, inoltre con un formato noto, standard e diffuso trovo plausibile che altri sviluppatori pacchettizzino le loro applicazioni in questo formato.
Per ora non ho pianificato una versione a 32bit perchè ormai tutte le macchine moderne sono a 64bit, tuttavia rimangono fuori alcune macchine non recentissime che potrebbero far girare Maui lo stesso e alcuni sistemi Atom.
Per il futuro sto considerando l’ipotesi di utilizzare Fedora come base realizzando una spin (quindi totalmente compatibile con Fedora) con OSTree. Due eventi mi hanno portato ad accarezzare l’ipotesi: recentemente un paio di sviluppatori Fedora hanno iniziato a pacchettizzare Hawaii per Fedora e sarà disponibile per F22 (o forse anche prima, per F21), inoltre è in sviluppo un plugin yum per OSTree. Il passaggio a Fedora porterebbe diversi vantaggio: delegare il build, lo sviluppo della distribuzione e il supporto per diverse architetture (inclusi i 32bit) ad un team molto più grande guadagnando l’accesso ad un vasto repository di software da usare per una transizione indolore verso il sistema dei bundle e mi consentirebbe di concentrarmi sul desktop.
Oltretutto questa soluzione non creerebbe frammentazione anzi andrebbe a completare la già ottima Fedora. Presto potreste vedermi girare con questo cappello [3].
6) Hawaii Shell è la shell che utilizzi su Maui per la gestione del desktop. Ho visto che è ancora un work in progress (leggevo che volevi rimuovere il pannello superiore). Hai già una idea su come sarà la versione finale o è ancora tutto lasciato all’ispirazione del momento?
Il design rispetto alla prima bozza che si trova sul wiki è cambiato e sta diventando abbastanza stabile.
Il pannello superiore sarà quasi certamente rimosso per dare più spazio alle finestre quindi si dovrà trovare una collocazione più intelligente per gli indicatori.
Gli indicatori attualmente sono dei menù, è una soluzione simile a quella attuata da MacOS X. Questo approccio si presta ad introdurre troppi controlli nei singoli menù, replicando in parte funzionalità che dovrebbero essere nel pannello di controllo.
Per la nuova implementazione penso di fare un vassoio di indicatori popolato a seconda delle necessità (ad esempio su un fisso non sarà visibile l’icona della batteria, oppure in assenza di hardware audio non ci sarà l’icona del volume) con un unico menù per controllare i vari indicatori.
Nel prossimo futuro ci saranno anche i desktop elements che sarà possibile muovere all’interno di un dashboard richiamabile con una sequenza di tasti.
7) Quando uscirà la prima versione stabile?
Presumibilmente per dicembre rilascerò Hawaii 0.2.
8) Come fare per poter contribuire a Maui? Cercate programmatori? Che requisiti devono avere?
Programmatori che conoscono Qt e QML sono sicuramente bene accetti, ma abbiamo bisogno di qualsiasi tipo di aiuto.
Per esempio il sito è molto facile da mantenere per chi conosce HTML e CSS, quello nuovo è totalmente statico e generato da Awestruct.
La Human Interface Guideline è in fase di scrittura, al responsabile di questa guida farebbe sicuramente comodo una mano.
Servono poi persone per gestire il wiki ed organizzare uno spazio per la comunità, traduzioni, guide, help in linea, design, grafica e volontari disposti a dare presentazioni del progetto a vari eventi come il Linux Day. Una personalizzazione del tema di icone sarebbe di notevole aiuto così come nuovi wallpaper.
9) Perché un utente dovrebbe provarla e perché dovrebbe preferirla ad altre alternative leggere (LXDE e XFCE in primis)?
LXDE e XFCE sono rimasti indietro, inoltre Qt è un framework più completo e con più possibilità di espandersi rispetto a GTK+.
La fusione tra Razor-Qt e LXDE darà luogo a LXDE-Qt che purtroppo rimarrà ancora per un pò su Xorg e i “vecchi” QtWidgets. Ho proposto una collaborazione ma ancora non c’è interesse a spostarsi su – e quindi ad imparare – QtQuick e Wayland, inoltre Hawaii al contrario di Razor-Qt punta ad avere un ambiente più coerente ed integrato con una Human Interface Guideline che ha dei punti di contatto con GNOME, Pantheon e MacOS X.
Hawaii si colloca a metà strada tra GNOME e KDE: l’appeal di GNOME utilizzando Qt senza però portarsi dietro un grande framework, compatibilità con sistemi non-Linux e un’architettura troppo complessa. Ad esempio per le applicazioni scritte con QML si utilizzano i QtQuick Controls invece di proporre un set di controlli custom, anzi l’intento è quello di contribuire upstream con qualsiasi cosa possa essere poi utilizzata da applicazioni di terze parti.
10) Passiamo ora alle domande sulla concorrenza 😛 Secondo te cosa manca a GNOME Shell e a KDE? Cosa apprezzi di loro e cosa non riesci a sopportare? E di Unity cosa ne pensi?
GNOME Shell: è troppo focalizzato su una UI stile tablet (o una sorta di ibrido desktop/tablet) quando secondo me è meglio separare business logic e UI lavorando su layout ottimizzati per ogni form factor che invece è la strada più spontanea per progetti basati su QtQuick che quindi intendo seguire con Hawaii. GNOME tende anche a semplificare troppo riducendo le opzioni a disposizione.
KDE è l’esatto opposto: troppe opzioni che si traducono in una notevole complessità di tutta l’architettura che moltiplica il lavoro degli sviluppatori e di conseguenza i bug.
Un ambiente desktop secondo me deve essere pronto all’uso, devono esserci default adatti alla maggior parte degli usi anzi deve esserci un’utenza target che è in contrasto con una moltitudine di opzioni.
Unity non mi è piaciuto molto, forse sono stato influenzato dalle prime versioni non proprio eccezionali e lo vedo più azzeccato sui tablet.
11) Vediamo di generare un po’ di flame con qualche domanda. Cosa ne pensi di Mir e della scelta di Canonical di andare controcorrente? Pensi che quella di Canonical sia una scelta sbagliata?
Penso che Mir sia stato un errore, è una parte dello stack troppo delicata per disperdere così le energie inoltre non è così facile da realizzare come sembra ed effettivamente Mir sta incontrando alcune difficoltà ultimamente.
Non sembrano nemmeno esserci valide ragioni tecniche tali da giustificarlo e nessun dubbio su Wayland è stato espresso prima del lancio di Mir, oltretutto può danneggiare lo stesso progetto Ubuntu sottraendo energie allo sviluppo di applicazioni e dello stesso Unity.
12) Passiamo alle domande più leggere: sei pro Torvalds o pro Stallman?
Stallman risulta talvolta eccessivo ma in genere mi trovo d’accordo con lui.
Se si ama il software libero si deve auspicare ad una totale diffusione dello stesso a scapito del software proprietario, ma non è un obiettivo che raggiungeremo presto quindi di tanto in tanto serve il pragmatismo di Torvalds.
13) È di questi giorni la notizia del prossimo rilascio di SteamOS. Pensi che sia un bene per l’ecosistema Linux (per i driver) o che sia un cavallo di Troia?
Valve sta realizzando un’architettura sufficientemente aperta da essere interessante, almeno per me. Non si sa ancora molto ma sospetto che il suo software sarà installabile anche su altre distro così come è stato per il client di Steam.
Questa mossa spingerà notevolmente Linux, purtroppo non si tratta di una soluzione 100% libera.
E’ quindi un cavallo di Troia per quanto riguarda l’introduzione di software proprietario nell’ecosistema libero di Linux ma sta dando una notevole spinta allo sviluppo dei driver e questo è un bene.
Sempre più desktop si spostano verso OpenGL quindi avere driver performanti è una priorità di tutti, non solo dei videogiocatori.
Mi piace pensare che l’apertura di NVIDIA a nouveau sia frutto degli annunci di Valve.
Più driver e giochi più utenti quindi più applicazioni, spero che contemporaneamente ci sia una diffusione maggiore di software e contenuti liberi.
14) Bene, prima di congedarti hai qualche saluto/ringraziamento/appello da fare?
Ti ringrazio per lo spazio concessomi e colgo l’occasione per ringraziare pubblicamente Rodolfo Panerai e Giuseppe Imperato per il lavoro iniziale sul design di Hawaii e Christopher Meng e Lubomir Rintel che stanno pacchettizzando Hawaii su Fedora. A presto!
