3Domande a Alessandro Rubini – Ing. Elettronico e Programmatore @CERN

Alessandro Rubini

E’ con vero piacere che oggi rivolgo le 3 domande ad Alessandro Rubini, relatore al prossimo Better Embedded di Firenze. Ingegnere elettronico e programmatore su microcontrollori e Kernel Linux. Attualmente lavora su “White Rabbit” e progetti correlati (disponibile con licenze libere) presso il CERN.

Emanuele: Per prima cosa vorrei chiederti di presentarti alla community, raccontaci le tue attività lavorative e la tua esperienza nel mondo dell’elettronica e della programmazione.

Alessandro: Sono ingegnere elettronico, ma nelle mie giornate maneggio bit molto piu` che transistor perche` dovendo comunque stare tutto il giorno al computer preferisco comandare io la macchina e non viceversa. Ho iniziato a scrivere codice sul 6502, scrivendomi l’assemblatore perche` non ne avevo uno; poi con l’universita` sono passato al mondo Unix, che mi ha subito affascinato anche perche` era arricchito da tutto lo GNU allora disponibile.

Appena possibile ho comprato un 386 per avere il mio Unix a casa, ovviamente software libero. Sono libero professionista e mi occupo di periferiche e sistemi integrati perche` mi piace controllare veramente i miei sistemi; vorrei usare saldatore e oscilloscopio piu` del browser, ma in pratica non riesco. Tengo un corso all’universita` e seguo alcuni tesisti ogni anno, con alterne soddisfazioni. Ultimamente ho lavorato principalmente per il CERN: da buon ente pubblico rende disponibili tutte le sue realizzazioni ai cittadini: software, gateware, hardware. Il mio gruppo pubblica su ohwr.org, “Open HardWare Repository”.

Emanuele: L’hardware open source è sicuramente una gran cosa e l’open hardware repository è assolutamente un progetto nobile ma: la mancanza di un controllo sul rispetto delle licenze (problema al quale nemmeno Alicia Gibbs riesce a trovare una soluzione (http://it.emcelettronica.com/intervista-con-alicia-gibb-presidente-oshwa-open-source-hardware-association) e la mancanza di tempo che porta ad avere spesso tempi lunghi di realizzazione e quindi non al passo con i tempi oppure ad accettare dei compromessi ( un esempio può essere questo http://it.emcelettronica.com/mi-rifiuto-di-sopportare-gli-strnzi-programmatori) non credi stiano portando l’open source verso un lento declinio? Forse i principi dai quali è nato dovrebbero evolversi così come si evolvono le economie?

Alessandro: Ci sono due tipi di hardware aperto (come due tipi di software aperto e anche due tipi di cultura, in tutti i campi). C’e` il livello amatoriale, basato sul concetto di volontariato e spesso colorato di
“comunita`”, ma c’e` anche quello professionale. L’attivita`amatoriale soffre dei problemi descritti, e non puo` che continuare a soffrirne: il tempo e` cronicamente assente nella nostra societa`, e la parte burocratico/amministrativa non attira certo risorse all’interno di attivita` che sono comunque di svago e creativita`.
Ben vengano i tentativi di organizzazione e potenziamento del mondo amatoriale, ma e` un settore che pur essendo importantissimo e`destinato a restare di nicchia.

L’iniziativa ohwr (come altre iniziative di hardware aperto e un numero considerevole dei progetti di software libero di successo) si pone invece sul lato professionale. I componenti sviluppati, a tutti i livelli (hardware, gateware, software) vedono il coinvolgimento di persone retribuite e l’allocazione delle risorse necessarie per i vari ruoli, compreso quello legale. Questo perche` le aziende e gli enti coinvolti hanno interesse a produrre e usare le schede in questione. Pero` il risultato di questo lavoro non rimane riservato ma e` libero e a disposizione di tutti, con licenze di diritto d’autore che rispecchiano quelle di successo nel settore software.
Il concetto funziona: le schede vengono prodotte e commercializzate da aziende che si pongono sul mercato in concorrenza leale tra loro e con gli altri; altre aziende prendono i nostri progetti e li modificano per usi prima inaspettati, preservando i termini di licenza; i singoli componenti possono essere riutilizzati senza dover reinventare gli stessi mattoni solo perche` la casa e` diversa. Da parte nostra riutilizziamo molti componenti di opencores.org e ovviamente attingiamo dal software libero a tutti i livelli; questo ci da` un vantaggio iniziale rispetto agli sviluppi chiusi. La liberta` del progetto nel suo complesso permette a noi stessi di comprare i macchinari a prezzi piu` bassi che se li costruissimo autonomamente, non dovendoci confrontare col monopolio di un solo costruttore, e
permettendo ai costruttori stessi di avere migliori fattori di scala perche` possono vendere i nostri sistemi anche ad altri. Alcuni dei nostri progetti sono seguiti anche da grandi aziende di tradizione monopolista: credo che tutti questi vantaggi nell’apertura dell’informazione siano destinati a vincere in molti settori, nonostante le resistenze di una tradizione tecnologica oscurantista.

Il rispetto delle licenze non e` un problema di questo settore, non piu` che in tutti gli altri. Ci sono realta` che non rispettano le licenze proprietarie copiando cio` che non devono, e ci sono personaggi che non rispettano le licenze libere monopolizzando cio` che e` pubblico. In certi casi si decide di agire legalmente, in certi altri no, come in tutti i campi. In specifico, la tutela legale della liberta` dei progetti del CERN e` seguita dall’ufficio legale, come in altre realta` professionali — pero` in questo caso l’ufficio legale si chiama “knowledge transfer”, in quanto il fine dell’ente e`trasmettere conoscenza come dovrebbe essere per tutti i centri di ricerca pubblici.

I problemi interpersonali poi esistono sempre. Ma l’arroganza, citata nell’articolo che mi indichi, e` una delle tre virtu` del programmatore (o del progettista in generale), come ci ricorda Larry Wall, autore di Perl. In tutti i gruppi di lavoro si discute e si litiga, e in tutti i gruppi aperti alla partecipazione pubblica si intrufolano personaggi potenzialmente dannosi. Siamo persone, nel bene e nel male, e dobbiamo imparare anche a gestire i rapporti interpersonali che sono comunque arricchenti (io per esempio ho imparato a scaldarmi di meno per quello che leggo sulle liste tecniche).

Emanuele: Al Better Embedded di Firenze (8 & 9 Luglio 2013) terrai un talk sull’importanza del Tempo nel Kernel Linux (http://www.betterembedded.it/conference/talks/il-tempo-nel-kernel-linux). Decisamente interessante, il timing è il cardine di qualsiasi programma, figuriamoci per un sistema operativo ed addirittura per un Kernel. Puoi anticiparci qualcosa, magari anche in relazione a soluzioni embedded oppure facendo confronti con sistemi operativi chiusi?

Alessandro: Alla conferenza faro` due interventi: uno sul tempo nel kernel e uno sul meccanismo di sincronizzazione temporale a cui stiamo lavorando nell’ambito del progetto White Rabbit, un progetto software/hardware che raggiunge allinemanti entro 50 picosecondi tra due schede di acquisizione, ed entro il nanosecondo tra migliaia di schede distribuite entro qualche decina di chilometri. White Rabbit e tutti i suoi componenti sono disponibili su ohwr.org.

Il primo intervento, piu` introduttivo, e` volto a mostrare come una buona scelta dell’astrazione da usare e delle relative strutture dati puo` semplificare notevolmente il lavoro dei progettisti e mettere al riparo dal tipo piu` comune di malfunzionamenti. Credo che il livello della discussione non si possa applicare a sistemi chiusi, ma confesso la mia ignoranza in materia; sicuramente la soluzione adottata da Linux e` rivoluzionaria rispetto alla API classica per l’interfaccia tra il sistema e i blocchi hardware di temporizzazione. Non si tratta di realizzazione nuove, ma di una base di codice allo stato dell’arte, molto interessante dal punto di vista dell’ingegneria del software e ancora ignota a molti tecnici.

Nel secondo intervento invece presentero` un nuovo pacchetto, chiamato PPSi, che stiamo completando nei primi mesi del 2013. Si tratta di un’implementazione di PTP, un protocollo di sincronizzazione temporale attraverso la rete. A differenza di NTP, che raramente garantisce sincronizzazione migliori del millisecondo, PTP riesce a mantentere le macchine allineate entro qualche microsecondo in una rete normale, ma arriva alla frazione di microsecondo se si usano schede Ethernet di fascia alta e cablatura diretta tra i calcolatori. La nostra implementazione e` compatibile con le altre ma e` progettata specificamente per la portabilita` in varie direzioni: hardware specializzato, estensioni al protocollo, ambienti senza sistema operativo. Questa modularita` e` assente negli altri progetti di cui siamo a conoscenza, compreso quello da cui abbiamo derivato il codice in uso oggi. PPSi e` nato per White Rabbit, ma speriamo possa essere utile anche ad altri progetti che vogliano estendere PTP senza dover riscrivere tutto il motore o modificare in maniera irreversibile una delle implementazioni esistenti.

2 Comments

  1. Boris L. 5 giugno 2013
  2. IvanScordato Ivan Scordato 5 giugno 2013

Leave a Reply