Home
Accesso / Registrazione
 di 

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-hardw...) 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.

 

 

Scrivi un commento all'articolo esprimendo la tua opinione sul tema, chiedendo eventuali spiegazioni e/o approfondimenti e contribuendo allo sviluppo dell'argomento proposto. Verranno accettati solo commenti a tema con l'argomento dell'articolo stesso. Commenti NON a tema dovranno essere necessariamente inseriti nel Forum creando un "nuovo argomento di discussione". Per commentare devi accedere al Blog
ritratto di Boris L.

Beh, se uno fosse ancora

Beh, se uno fosse ancora indeciso se andare o meno al Better Embedded questa intervista gli fa decisamente cambiare idea... :)
Sono state fatte delle domande estremamente valide!
Bravi!

ritratto di Ivan Scordato

Bhe... se se ne ha la

Bhe... se se ne ha la possibilità conviene davvero andarci :)

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 1 utente e 24 visitatori collegati.

Utenti online

Ultimi Commenti