La linea d'ombra: debian

«Io faccio i bit e i byte, cavalco una bici d'epoca senza contachilometri, né GPS».
Se potesse essere racchiuso in una definizione, Alessandro Rubini

Alessandro Rubini è laureato in Ingegneria Elettronica all'Università di Pavia e lavora come consulente indipendente, specializzato nello sviluppo di device driver per sistemi Linux.
Ha abbracciato la causa del software libero ed è autore, assieme a Jonathan Corbet e Greg Kroah-Hartman di Linux Device Driver, pubblicato da O'Reilly, che ha raggiunto la terza edizione e di numerosi articoli tecnici apparsi su riviste specializzate in Italia ed all'estero.
Maggiori dettagli sono disponibili presso la sua pagina personale.

sarebbe un samurai dei nostri tempi, una personalità spiazzante, grande esperienza tecnica, un uomo che ha fatto del software libero il suo bushido.
Lo abbiamo contattato per una intervista e lui ci racconta del kernel, delle sue strutture e solleva un velo sui suoi, presunti, malanni.

La linea d'ombra: Andrew Morton afferma che il kernel sta invecchiando e riesce con fatica a captare l'interesse delle nuove leve.
E' una diretta conseguenza del fatto che un numero, sempre maggiore, di aziende sia entrata nel kernel e lo abbia trasformato in uno strumento industriale oppure Linux sta pagando la sua scarsa diffusione in ambito desktop, con un lento deterioramento dei programmatori interessati o curiosi di svilupparlo?
Alessandro Rubini: Ci credo che non ci sono giovani.
Quando ho cominciato era molto più semplice, adesso è tutto orribilmente complicato.
E ci sarebbero anche altre considerazioni.
No, non credo che il problema siano le aziende e del resto nemmeno la diffusione.
Ogni mese conosce, comunque, una crescita. Non si tratta di percentuali subito apprezzabili ma, in numero assoluto, la crescita c'è.

LD: Quindi, per esclusione, penso che i problemi siano di natura preminentemente burocratica, cioè proporre idee e sottoporre nuovo codice è diventato molto meno immediato?
AR: No, anzi, è diventato più facile.
Linus Torvalds ha scritto lo strumento di sviluppo Git, che ha facilitato mostruosamente la creazione e la sottomissione di contributi.
Ma è difficile contribuire.
E` il codice che è diventato difficile.

LD: Com'era quando hai cominciato?
AR: Facile.
Bastava sapere due cose e contribuivi.
Andava solo su pc, l'orribile pc, e su un solo processore, niente multi-core, quindi non c'erano problemi di portabilità, ma nemmeno di locking.
Il locking é difficilissimo.

LD: E adesso?
AR: Adesso é difficile.
E` bellissimo, documentatissimo, efficientissimo.
Ma essere efficienti ha dei costi: la complessità.

LD: Parli, anche, di altre considerazioni da fare: quali?
AR: Spesso la complessità è necessaria per semplificare, ma è un concetto difficile da capire per chi è nuovo.
L'implementazione degli strumenti, per esempio sysfs o rc-update, è complicatissima, ma l'uso è semplificato.
Se stai alle regole, non introduci bachi, ma imparare le regole richiede tempo.
Prima, diciamo fino al kernel 2.4, potevi scrivere abbastanza facilmente cose che funzionicchiavano.
Per farle funzionare bene, però, dovevi imparare molto di più sui trucchi che serviva usare.
Adesso è più difficile perché devi stare alle regole, e le regole sono tante, anche per le cose semplici.
I trucchi sono stati già usati centralmente.
Quindi il kernel é diventato più complesso per essere più semplice e, per un nuovo sviluppatore, rimane un gradino molto alto.

LD: Linus ha detto, qualche mese fa, che il kernel è ingrassato troppo ed è diventato qualcosa di molto diverso da quello che aveva in mente quando ha cominciato a scriverlo.
Intel sancisce, con un suo studio, che è vero, il kernel ha perso circa il 12% delle performance negli ultimi 10 rilasci.
AR: Tutti i progetti nascono piccoli per poi crescere, se non rimangono di nicchia.
All'università mi avevano dato i sorgenti di /bin/cat, ed erano due pagine: ricordo ancora il fascino.
Era il primo sorgente vero che vedevo, e si capiva tutto.
Le coreutils di oggi sono un'altra cosa.
Dispiace anche a me, perché nelle cose piccole si vede l'intelligenza, mentre quando crescono, l'originalità si perde nei mille casi particolari, nell'internazionalizzazione, nelle ottimizzazioni più strane.
Questo mi dà, anche, qualche problema nella didattica: raramente posso mostrare il codice reale per far capire un concetto.
Al massimo faccio vedere poche righe, qualche definizione, una struttura dati ogni tanto.
Il sorgente completo è troppo esteso e difficile, oggi.
Riguardo alle misure di Intel, che non conoscevo, credo che lascino un po' il tempo che trovano.
Si sa che i benchmark non sono mai significativi, dipendono sempre da chi li fa e da come li fa.
Inoltre, ogni caso d'uso è diverso e la complessità delle macchine é tale che gli effetti di una piccola variazione sono imprevedibili.
Nel caso di Linux la scelta é sempre stata quella di privilegiare le macchine più potenti, anche a discapito di quelle piccole.
Ti faccio un esempio: se per ordinare mille numeri si preferisce quicksort, per ordinarne tre preferisco fare i confronti a mano.
Allo stesso modo, per rendere efficiente la gestione di memoria su macchine con vari GB di RAM e centinaia di processi che usano decine di librerie, devo scegliere un algoritmo evoluto che é perdente in una macchina con 8MB di RAM e 10 processi in tutto.
Così, anche per la gestione del multiprocessore introduce strutture dati e controlli che sono inutili sul monoprocessore.
Tuttavia si preferisce che la configurazione predefinita delle distribuzioni vada su tutte le macchine, piuttosto che far andare meglio il monoprocessore al prezzo di usare un solo core delle macchine che ne offrono 8.
Se uno ha la macchina vecchia può, comunque, far girare una versione vecchia del sistema.

LD: Un progetto così enorme, a cui contribuiscono migliaia di persone, poteva seguire un destino diverso?
AR: No, ma non per le migliaia di persone.
Per il successo e la eterogeneità dei casi d'uso.
Anche le grandi aziende proprietarie dicono di avere migliaia di programmatori e anche il loro codice esplode, molto più del nostro, ma con una qualità realizzativa mediamente molto peggiore.
Comunque, la maggior parte dei contributori segue sottosistemi particolari o solo un limitato insieme di driver, quindi non generano rumore nell'infrastruttura centrale.
Uno dei motivi dell'ingrandimento della base di codice é la complessità delle macchine.
I processori sono sempre più complicati e per sfruttarne a fondo le caratteristiche serve un sacco di codice.

LD: Ed é davvero un problema, considerando che, anche, la potenza dell'hardware è sensibilmente aumentata rispetto agli esordi su 386?
AR: Ricordo il mio primo 386, ero impressionato dalla sua potenza di calcolo: usavo senza problemi emacs mentre avevo due compilazioni in corso, con 4MB di RAM in tutto, ma il sistema di allora non potrebbe gestire un PCI, un USB, un serial-ATA, una VPN o una cifratura 802.11, senza nemmeno parlare di Java o Gnome.
Oggi abbiamo più potenza di calcolo, ma più necessità che introducono nuovi livelli di astrazione, fondamentali per controllare la complessità generale.
La risposta é, comunque, sì: il 10% di differenza nelle prestazioni è comunque significativo e perderlo é un problema.
In certi contesti vuol dire il 10% di differenza nella durata della batteria, in certi altri vuol dire avere il risultato un'ora prima (9 ore invece di 10), oppure avere una macchina in meno in sala server (9 macchine invece di 10).

LD: Quali sono secondo la tua esperienza, i punti forti e quelli ancora deboli del kernel Linux e dove si potrebbe intervenire per migliorarne le prestazioni?
AR: A livello di kernel mi sembra tutto molto pulito e ordinato.
Il punto forte principale è la portabilità e la modularità, oltre, naturalmente, alla disponibilità del sorgente, senza il quale lavorare diventa difficilissimo.
Il punto debole che più sento è la complessità, che però è necessaria, come dicevo.
Sul come migliorare le prestazioni non ti so dire con certezza: se fosse così facile dirlo sarebbe già stato fatto da qualcuno.
Si può intervenire su problemi specifici, dopo un attento studio, anche se, in certi casi, l'unico modo è rompere la pulizia concettuale e scavalcare i livelli di astrazione.
Sono cose che talvolta si fanno in ambito industriale, tramite modifiche non pubblicabili, ma che per un uso interno vanno benissimo.

LD: Cosa pensi di Android. Google sta dando una mano al software libero oppure se ne serve in modo spregiudicato per aumentare la sua popolarità e, soprattutto, i profitti?
AR: Non conosco Android.
Io faccio solo i bit e i byte, i mega e i giga li lascio agli altri.
Google sta facendo sicuramente entrambe le cose, come ci si può aspettare da un'azienda di quelle dimensioni e così basata sull'immateriale.
Ma non sono in grado di dare un giudizio, ci sono troppe cose che ignoro.
Odio i computer e mi limito a lavorare nell'area dove si vede ancora l'intelligenza dei programmatori senza condizionamenti commerciali o altri secondi fini.

LD: In quale progetto sei coinvolto, di cosa ti occupi in questo momento?
AR: Device driver e sistemi embedded, da sempre. Sono un abitudinario.
In questo periodo sono principalmente sistemi ARM di uso industriale e domotico, talvolta più vicini ai telefoni cellulari.
E un po' di formazione, nelle aziende e in università, come professore a contratto (dall'anno prossimo senza compenso, grazie ai tagli generalizzati).

LD: Leggendo i tuoi articoli, emerge che il professionista impegnato nell'ambito del software libero è, quasi, una specie di "sarto" che confeziona soluzioni "su misura" per il proprio cliente. E' davvero così?
AR: Piu` o meno.
La qualità delle stoffe e delle pezze da cui partire è ottima, anche se ci ostiniamo a chiamarle, solo, patch.

LD: Ed esiste effettivamente un mercato, anche in italia, che permetta di lavorare e vivere col software libero?
AR: Domanda difficile: non ho una visibilità così ampia sul sistema paese.
Certo, tiene ancora molto il modello proprietario: l'idea di scrivere il programma una volta e venderlo tante volte con tecniche di lock-in e aggiornamenti obbligatori é una cosa che attira molti.
Finché il cliente accetta di essere preso per il collo è una tecnica che funziona e rende bene, ma perché accetti, di solito, pretende una certa dimensione da parte del fornitore, sperando che chi é grande non cada facilmente.
A parte le considerazioni etiche sulle rendite di posizione, che non sono condivise da tutti, credo che per il piccolo attore il software libero sia una strada migliore perché si è credibili anche verso clienti di una certa dimensione.
Ovviamente devono essere clienti già avvezzi all'idea.
Sono sempre di più, ma non sono certo tutti.
Sicuramente la fornitura di software libero non permette rendite da lock-in, ma vuole anche dire scontrarsi con problemi nuovi, senza dover seguire sempre gli stessi, con gli stessi clienti.

LD: Quale distribuzione usi per il tuo lavoro?
AR: Non posso dirlo, sarebbe pubblicità occulta. E poi, RMS mi scomunicherebbe.

LD: Stefano Zacchiroli è, adesso, il leader del progetto Debian. Lo conosci?
Quale pensi che saranno le innovazioni che potrà portare la sua gestione?
AR: Purtroppo non lo conosco: ormai siamo tanti, non possiamo più conoscerci tutti direttamente.
So che è della scuola bolognese, per cui ho ottime aspettative.

LD: KDE o Gnome? Tu, personalmente, cosa usi?
AR: Nessuno dei due.
Riflettono un modo di pensare che non è il mio, oltre ad essere di una lentezza esasperante sulle mie macchine obsolete.
Non dico che siano fatti male, ma usando software libero posso scegliere di usare strumenti diversi.

- testo raccolto da kurtz77 per la linea d'ombra, la riproduzione/divulgazione di questa intervista è concessa solo se accompagnata da questa nota -