Red Heat

Sergej Pavlovič Korolëv,  Igor Vasilyevich Kurchatov, Andrej Dmitrievič Sacharov, Aleksandr Isayevich Solzhenitsyn

Per ben cominciare, cominciamo dalla fine (o quasi, come Quentin Tarantino in Pulp Fiction). Immaginiamo di essere in un fast food a mangiare un boccone.

Ad un certo punto John Travolta mi fa: "Ma, senti un po' Simone, non e' che sarai mica un pochino, come dire, ... Comunista ?". Vedi, io le ho provate tutte, ma - guarda - il comunismo e' un po' come le donne: mi affascina ma non lo capisco. Un po' come quella storia del massaggio ai piedi.....

//** ---

Cosa hanno in comune Aleksandr Isayevich Solzhenitsyn, Sergej Pavlovič Korolëv, Igor Vasilyevich Kurchatov e Andrej Dmitrievič Sacharov ?

Hanno passato una bella fetta della loro vita in un gulag.

Vivere in un gulag non e' una passeggiata. Nessuno vi puo' raccontare come funziona un gulag meglio di Solzhenitsyn. Non serve che vi leggiate l'intero Acipelago Gulag in versione originale.Una giornata di Ivan Denisovič puo' bastare. Alex e' l'unico autore che e' riuscito ad identificare e descrivere esattamente la dinamica dell'interazione guardiano/prigioniero. Non e' che vi voglio convincere per forza che dopo aver letto Alex sarete in grado, in quindici anni di prigionia, di convincere i guerriglieri delle FARC di costruire un monastero in collaborazione con missionari francescani... pero' c'e' anche chi ha fatto anche di piu'. Ad esempio il prigioniero n. 46664 ha fatto dei discreti risultati.

Abbiamo detto che Aleksandr Isayevich Solzhenitsyn, Sergej Pavlovič Korolëv, Igor Vasilyevich Kurchatov e Andrej Dmitrievič Sacharov hanno passato una bella fetta della loro vita in un gulag.
Nella migliore tradizione di RAI Report... andiamo a vedere i risultati.

Le parole di Aleksandr Isayevich Solzhenitsyn non sono un inutile spreco della foresta amazzonica (per la carta). Le sue parole sono oro puro. Rimpiango di non conoscere il russo per poterle apprezzare fino in fondo.

Sergej Pavlovič Korolëv e' il mago dietro i primi successi della conquista dello spazio. Korolev, al contrario degli americani, non aveva ne' il team di Von Braun al completo ne' tutti i disegni tecnici delle V2. Si e' inventato quasi tutto da solo. Infatti i vettori russi - che tuttora fanno la spoletta per la stazione spaziale internazionale - sono molto diversi dai modelli americani o franco-europei (Arianne). Se Korolev non fosse morto di malattia ed incompetenza, il mondo avrebbe visto sorgere una Luna comunista.

Igor Vasilyevich Kurchatov ha regalato l'energia nucleare (reattori e bombe) alla Russia. Igor aveva accesso ad una parte significativa dei documenti chiave del progetto americano attraverso un certo Klaus Fuchs. Klaus (ufficialmente la come liason con gli Inglesi) entrava ed usciva da Los Alamos con la scusa di accompagnare Richard Faynman a trovare la moglie malata. Lo scambio dei documenti veniva fatto lasciado dei rotolini di carta incollati con la gomma da masticare sotto il tavolo del fast food di fronte all'ospedale. Anche se i progetti americani hanno indicato la via ai russi, la maggior parte del lavoro venne dal sudore della loro fronte. Kurchatov mise in piedi una vera scuola di formazione per fisici ed ingegneri nucleari. Infatti, fra i sui allievi vi era un certo....

Andrej Dmitrievič Sacharov ed il suo team (erano in tre) hanno fatto la prima bomba termonucleare russa da soli. Visti i risualti, Andrej convise se stesso e gli altri di non andare oltre. All'inizio l'idea era quella di usare la fusione per la produzione di energia. Sacharov investi' gran parte del suo tempo in questa direzione, ma senza ottenere risultati significativi dal punto di vista applicativo. Gli mancava un pezzo del mosaico, l'ingrediente fondamentale per fare la torta o, per meglio dire, la ciambella.

 Tutte e quattro si dicevano comunisti. Sono vissuti e morti da comunisti. Anche se il regime sovietico gli ha causato enormi problemi, di fatto, non hanno mai messo in discussione le idee di base del comunismo.

//** --

Ritorniamo nel nostro fast food. John Travolta mi guarda con i suoi occhi traversi, spenti e venati di sangue da cocainomane incallito, mentre aspira distrattamente la sua sigaretta,  Zucchino e Coniglietta organizzano una rapina estemporanea.

Butto la mia mazzetta di dollari (con i bigletti da 100 sull'esterno, tenuta insieme da una molletta d'argento) nel sacco della spazzatura che la donna usa per ramazzare il bottino. "Non fare il furbo negro! Dammi anche la valigetta! Si, quella con l'uccello giallo e nero !".

Con lo sguardo piu' freddo della notte su Rura Penthe gli rispondo:

"No. la valigetta NO. La valigetta ed il suo contenuto non vi appartengono.".

Il suo Zucchino arriva di riforzo e rinnova la minaccia puntandomi la sua misera 38" sei colpi in faccia e mi urla:

"Sporco negro comunista, non fare il furbo e dacci la valigetta con l'uccello del !"

« Ezechiele, 25:17. Il cammino dell'uomo timorato è minacciato da ogni parte dalle iniquità degli esseri egoisti e dalla tirannia degli uomini malvagi. Benedetto sia colui che nel nome della carità e della buona volontà, conduce i deboli attraverso la valle delle tenebre, perché egli è in verità il pastore di suo fratello e il ricercatore dei figli smarriti. E la mia giustizia calerà sopra di loro con grandissima vendetta e furiosissimo sdegno su coloro che si proveranno ad ammorbare, e infine a distruggere i miei fratelli. E tu saprai che il mio nome è quello del Signore, quando farò calare la mia vendetta sopra di te! »

Una settimana pesante

Questa settimana e' stata particolarmente pesante: una missione di 5 giorni filati per Scicos-ITM (Itegrated Tokamak Modeling). Il lavoro procede bene, soprattutto per merito dei miei colleghi di INRIA e CEA.

Devo pero' ammettere che sento una certa vibrazione negativa nella Forza. E' possibile che sia la vecchiaia che avanza, ma c'e' qualcosa che non mi torna.

Per fare la prima bomba atomica ci abbiamo messo pochi anni. I problemi da superare erano veramente enormi. Gli strumenti di misura erano - a dir poco - rudimentali. La Hewelett e Packard era appena nata e la Tektronix non esisteva ancora. Il computer: lo hanno inventato apposta per risolvere alcuni problemi di progettazione della bomba. Come dice Hideo Kojima (il genio padre della serie Metal Gear) la bomba ed il computer sono le due facce della stessa moneta.

Pero' per la fusione nucleare siamo ancora al palo. Ancora non funziona. I progetti avanzano, ma a rilento. I soldi ci sono, ma sono bloccati. C'e' troppa politica.

Lo so che si tratta di una misura veramente drastica, ma la cura per i progetti che arrancano esiste. Non e' simpatica, e' politicamente scorretta. Ma funziona.

Bisogna militarizzare il progetto. Si prendono tutti i tecnici, ingegneri e scienziati, si ficcano in un posto sperduto, lontano dalle loro famiglie. Si privano dei loro diritti civili. Dopodiche' il contratto e' semplice: o funziona oppure non si mangia. Tornerete a casa quando il lavoro sara' finito.

Visto che questo tipo di approccio e' semplicemente illegale, vedo una sola possibilita' per metterlo in pratica: trovare delle persone che accettino volontariamente questo metodo di lavoro.

Molte delle persone che hanno sviluppato ScicosLab hanno - di fatto - usato questo metodo. C'e' chi ha lasciato la moglie in un altro paese, all'altro capo del mondo per anni. Quando uso ScicosLab, quando leggo il codice sorgente, non posso fare a meno di percepire i sacrifici delle persone che hanno portato ScicosLab al livello di oggi.

Dopo cinque giorni di lavoro pieni, h24, mi ci e' voluto un pomeriggio intero per recuperare il mio usuale equilibrio mentale. Molti anni fa mi sono assunto la responsabilita' di andare in giro in divisa ed armato per difendere la democrazia. Per difenderla, ma non per applicarla. Purtroppo e' necessario che qualcuno sacrifichi un po' della sua liberta' personale per permettere che gli altri possano dormire tranquilli ed al caldo.

Oggi la scelta e' tra cercare di assicure l'accesso a delle risorse strategiche, oppure trovarne di nuove.
Il petrolio prima di tutto: ci sono due conflitti maggiori tuttora aperti, senza contare le centinaia di conflitti locali.

Io ho fatto la scelta di mettere in pratica quello che mi hanno insegnato alla ricerca di nuove e pulite fonti di energia.

Quello che succedera' adesso dipende da voi.

Io ho fame, quindi vado a mangiarmi una bella Pizza. La Pizza e' come il rock and roll: vince sempre :-).


.

Completely Fair Schedulers, Bankers and Anaesthesists

Uno degli ingredienti chiave della ricetta Linux RT_PREEMPT e' la modifica allo scheduler ovvero l'adozione di CSF (Completely Fair Scheduler) sviluppato e mantenuto da Ingo Molnar (si, sempre lui).

A causa un errore di battitura nella finestra di ricerca di Google, sono andato a finire su questo link:

http://it.wikipedia.org/wiki/Federico_Guglielmo_Raiffeisen

Insomma, ho trovato un banchiere onesto. Leggere che la chiesa cattolica ed un banchiere ebreo si sono messi a lavorare insieme per migliorare le condizioni economiche delle campagne italiane, fa semplicemente impressione.
Certo, erano altri tempi. Penso che sia inutile che vi citi recenti esempi di malefatte di banchieri ebrei e istituti cattolici: questo blog non vuole focalizzarsi troppo sul Lato Oscuro. Ce n'e' piu' che abbastanza, inutile fare ulteriore pubblicita' gratuita. Come dice sempre Camilleri, cerco sempre di parlare il meno possibile della Mafia.

Lavorare nel mondo Open Source e' interessante perche' s'incontra della gente strana. Se frequentate i soliti ambienti professionali, dopo quanche anno vi renderete conto i personaggi sono preconfezionati al livello di "Camera Caffe". Vi restano quindi due alternative:
(pillola blu): continuate ad andare prendete il caffe' con i vostri soliti colleghi di lavoro;
(pillola rossa): saltate il fosso: andate a vedere quanto e' profondo il pozzo di Alice.

Lo scheduler CFS, anche se e' scritto e mantenuto da Ingo, deve molto ad un lavoro pluriennale di un medico anestesista australiano. Chi meglio di un anestesista poteva decidere come e quando mettere a dormire e risvegliare i processi di Linux?

Perche' un medico anestesista si dovrebbe mettere a sviluppare una delle parte piu' critiche (forse la piu' critica di tutte) di un sistema operativo complesso come Linux ?

La risposta e' semplice: Con Kolivas si era stufato di vedere il desktop di Linux rimanere congelato per decine di secondi.

Per capire meglio il problema, saltiamo sulla nostra mitica DeLorean e ritorniamo nel lontano Novembre 1999, quando il mondo era sulle spine per il Millenium Bug.

Windows '98 era uscito da alcuni mesi. Mentre tornavo a casa dal lavoro, nei 45 minuti di auto, mi dovevo sorbire almeno tre spot sull'ultima trovata proveniente da Redmond. Lavoravo in una ditta che aveva deciso di usare Windows 95 a tappeto per gli applicativi e le interfacce uomo/macchina delle macchine "robotiche" che produceva. La cosa mi toccava fino ad un certo punto, visto che tutte le funzioni critiche erano gestite da una scheda DSP dedicata: hardware e software proveniente dalle manine d'oro del sottoscritto e dei suoi colleghi. Facciamola corta: non siamo mai riusciti a misurare l'affidabilita' della nostra creazione perche' il PC ospite (con Win 95) aveva un uptime medio di otto ore.
Nel manuale d'istruzioni c'era scritto chiaro e tondo che la macchina doveva passare attraverso un ciclo completo di reboot all'inizio di ogni turno di lavoro (di otto ore appunto).

Siccome i miei colleghi che avevano provato il '98 mi avevavo raccontato storie allucinanti, colsi al volo l'occasione per guardare altrove.

Verso la fine del 1999, mi comprai una scatola di cartone con Corel Linux 1.0 dentro. Corel aveva creato una distribuzione completa con KDE 1.0: il primo vero desktop di Linux che non spaventava troppo gli utenti provenienti da Windows.
Usarlo era un vero piacere, salvo che, ogni tanto, il desktop restava congelato. La cosa piu' strana era che il mouse non si muoveva piu'. Su Windows, se il puntatore del mouse rimane congelato non c'e' piu' nulla da fare. Su Corel Linux accadeva piuttosto spesso, poi tutto continuava a funzionare come al solito.

I giochi (spettacolare il primo porting di Quake III Arena per Linux su Voodoo 3000 AGP) andavano bene, salvo dei fastidiosi momenti di "freeze". Erano ancora i tempi del kernel 2.4.x.

Nel bene e nel male Linux e' stato sempre piu' ottimizzato per applicazioni server piuttosto che per applicazioni desktop. Solo recentemente si e' posta la necessaria attenzione all'utente singolo.

Con Kolivas comincio' quindi a pensare di modificare lo scheduler per evitare questi fatidiosi tempi morti senza per questo bruciare il 25% del processore solo per spostare il bitmap del mouse come succedeva con Win 95.

Siccome il software non e' mai stato il mio forte, all'epoca decisi di risolvere il problema con un altro approccio: farmi la mia prima macchina biprocessore. La Intel aveva lasciato il supporto SMP attivo sui processori economici di classe Celeron (che costavano la meta' dei Pentium III dell'epoca, Dicembre 1999).

La Abit produsse una motherboard con due zoccoli (BP6) Celeron compatibili. Decisi quindi di fare la spesa: mother board e due processori nuovi di zecca.

Una volta arrivato a casa, verificato che il PC funzionava, feci il boot con il disco di Linux. Close but not cigar. Il kernel fornito di serie NON supportava il multi processore.

Una delle cose simpatiche della scatola di cartone di Corel era il manuale allegato. In uno degli ultimi capitoli c'era spiegata la procedura passo passo per ricompilare il kernel, con una sezione dedicata alle macchine SMP.
Dopo i canonici 15 minuti necessari alla ricompilazione, reboot e ... voila! Due processori ! Quake volava, fluido come non mai.
Anche la risposta agli interrupt era migliorata in modo significativo, anche se non era ancora hard real time.

Purtroppo la mia fidata BP6 mori' nel 2000 a causa di un colpo diretto da fulmine, un fulmine a cel sereno che mise fuori uso anche televisore e lavatrice. Da quel giorno ho installato filtro, trasformatore d'isolamento e UPS.

Qualche anno fa mi sono comprato, per una manciata di euro, una scheda doppio processore con due Pentium II SLOT-1. Bella, ma non e' la stessa cosa. La VP6, successore della mitica BP6, non arrivo' mai ad Arezzo. 

(...continua...)

ScicosLab Revolution

Work in progress.

Qui prodest ? (IV)

Linus sta per mollare l'OS(sso): anche se non ha dato un via libera definitivo ed uffciale a RT_PREEPT, siamo molto ma molto vicini al botto: funzionalita' hard real time di serie nel main line kernel.

Metto subito le mani avanti per i maniaci della sicurezza: non andremo il giro col proiettile in canna. Per farla corta, le funzionalita' hard real time saranno pronte ma in stand by: bisognera' essere "root" per attivarle, un processo alla volta.

Chi ha fatto il lavoro?

Ingo Molnar e' la mente dietro il colpaccio.

Come ha fatto? 

Ingo, con una pazienza certosina, si e' ripassato tutto il codice del kernel alla caccia delle sezioni critiche. Le sezioni critiche sono quelle parti di codice dove e' necessario garantire una atomicita' delle operazioni, ovvero non si puo' essere interrotti a meta'.

Disabilitare le interruzioni ha pero' l'effetto secondario di diventare insibili agli stimoli esterni. Per un sistema operativo real time disabilitare le interruzioni per un tempo significativo puo' essere catastrofico.

E' per questo che ADEOS prende il controllo dell'interrupt controller; inoltre la patch (RTAI o Xenomai) disabilita la coppia di istruzioni "cli /sti" che rendono il codice delle sezioni critiche atomico e le sostituisce con una redirezione verso ADEOS.

RT_PREEMPT non crea un ambiente preferenziale hard-real time isolato dall'ambiente standard Linux (soft real-time). RT_PREEMPT lima il codice standard del kernel al fine di eliminare tutte le atomicita' lunghe (note anche come "the big kernel lock").

Eliminare le atomicita' lunghe ha pero' lo svantaggio di penalizzare le prestazioni in alcuni ambiti applicativi, ad esempio file e Internet server. Per fare un prova facile, provate a copiare un file monolitico - and esempio una immagine ISO - di qualche giga. Vedrete subito come il desktop diventi lento a rispondere. Questi ritardi sono (una bella rottura per l'utente normale) catastrofici per un sistema operativo hard real time.

Ricordatevi che un OS hard real time non guarda in faccia a nessuno: se siente a priorita' 99 (il massimo) entrate e - una volta dentro - nessuno (nemmeno un altro processo a priorita' 99) vi puo' interrompere. Dovete essere voi a "passare la mano".

A livello di prestazioni, RT_PREEMPT ha una latenza massima intorno a 100us, contro 10us di Xenomai e 1us di RTAI.
Per sistemi elettromeccanici normali, dove i loop veloci sono dell'ordine di 1ms, 100us sono piu' che accettabili. Se volete andare piu' veloci dovete passare a Xenomai o RTAI.

Una latenza massima di 1ms e' accettabile anche per applicazioni audio professionali dove, anche se la frequenza di campionamento e' di decine di kilo Hertz, si lavora "ad anello aperto" e quindi si possono usare buffers di dimensioni consistenti ... ma non si puo' accettare che ci siano del "buchi" nelle registrazioni o che l'audio sia troppo "sfasato" dal video.

Una latenza massima dell'ordine di 1ms e' indispensabile anche per le transazioni finanziarie automatiche in tempo reale. La maggior parte di voi - penso - non e' a conoscenza che molti dei problemi di instabilita' dei mercati finanziari sono dovuti alla possibilita' di fare transazioni automatiche - dove non c'e' intervento umano - con tempi di giro tra 2 e 5ms.

Questo vuol dire che e' possibile spostare miliardi di euro in frazioni di secondo (e fumare il sigaro allo stesso tempo).

Qualunque professionista serio che ha lavorato davvero con sistemi di controllo digitale vi dira' che aumentare troppo la frequenza di campionamento, non solo e' INUTILE ma e' DANNOSO perche' si finiscono per introdurre delle instabilita' derivanti dalla precisone finita delle operazioni di calcolo. In parole povere, un computer non riesce piu' vedere la differenza tra "x" e "x+dx" se "dx" e' troppo piccolo rispetto ad "x".

Se non fate attenzione ai vostri investimenti, questo effetto di "cancellazione" si potrebbe propagare rapidamente fino al vostro conto corrente e mettere in ginocchio l'economia di intere nazioni.

Per non parlare delle oneste lavoratrici degli strip club di Wall Street, finite sul marciapiede per mancanza di clienti economicamente superdotati.

Non e' possibile fare del sano capitalismo (quel gioco magico dove tutti vincono e nessuno perde) con tempi di reazione di 1ms. Bisogna ricominciare a pensare in termini di investimenti e non speculazioni.

Si dice che Henry Ford era anti semita. E' falso. In realta' lui odiava a morte i banchieri. Gli industriali si fanno un mazzo cosi' perche' hanno bisogno di soldi per fare investimenti sulle strutture. I lavoratori poi si fanno ancora piu' mazzo, perche' hanno bisogno di soldi per arrivare in fondo al mese.
Ma un banchiere che fa?
Per una serie di circostanze storiche, i banchieri con i quali Henry aveva a che fare erano tutti di origine ebrea. Ma se fossero stati italiani, sarebbe stato anti-italiano.

Non voglio fare lo stesso errore di Ford dicendo che tutti i banchieri sono speculatori e malfattori (Madoff_atori). Statisticamente parlando e' impossibile: qualche banchiere ragionenvolmente onesto ci deve essere per forza. Speriamo di trovarlo quanto prima.

Soprattutto per sollevare le sorti delle oneste lavoratrici degli strip club di Wall Street (senza dimenticare i nostri poveri conti correnti).

Qui prodest ? (III)

Facciamola corta: Xenomai non ha prodotto i risultati sperati. I fork, come le rivoluzioni non producono mai i risultati desiderati. Come dice sempre Milena (Gabbanelli, Rai Report): "Andiamo a vedere com'e' andata a finire.".

Rivoluzione Francese: risposta transitoria fortemente oscillante di durata secolare con forti picchi positivi e negativi. Sono arrivati alla V Repubblica perche' hanno avuto l'enorme botta di culo di trovare un militare con le palle che ha saputo resistere alla tentazione della dittatura e ha trovato il coraggio di credere nella democrazia. Chapeau, mon General.

Rivoluzione Russa: chiusa per bancarotta. Nikita provo' a fare una prima - grossa - patch, ma duro' poco. Gorby ce l'ha messa tutta con una patch di dimensioni epocali. Niente da fare. E' andata a finire come tutti sappiamo. Un vero peccato, perche' i Russi hanno saputo produrre dei risultati spettacolari. Esempio lampante di come una strategia di controllo rigidamente centralizzato sia inevitabilmente destinata al fallimento.

Rivoluzione Cubana: vedi sopra. Speriamo che gli eredi di Fidel sappiano tenere la giusta distanza tra gli estremi. Senno' ci tocca a addio alle calde spiagge di Cuba. Ricordatevi che l'autonomia operativa di un sommergibile nucleare e' limitata solo dalla durata della vedura fresca e del caffe'. Finita la prima, inizia il malcontento, ma quando finisce il caffe' scatta il panico. Speriamo di approdare a qualcosa di diverso da una Las Vegas Due oppure un allargamento del Guantanamo Bay Resort Inn. 

Rivoluzione Cinese: la partita per il dominio del mondo si gioca tra la Cina e Google. Entrambi sono "good" e "evil", "yin" e "yang". Entrambi usano Linux (ma cosa altro vorreste usare per andare a conquistare il mondo?). Entrambi hanno capito che la partita si gioca sul dominio tecnologico. Dimenticate gli altri giocatori. Non domandatemi chi vincera' perche' non e' la domanda giusta.

Che cosa e' mancato - e tuttora manca - a Xenomai?

I tool e le applicazioni al contorno. Come dice sempre Linus, il sistema operativo non serve a nulla se non ci sono le applicazioni. Per RTAI sono stati sviluppati molti tool. Per me - ma vi posso assicurare che sono in buona compagnia - il piu' importante e' RTAI-Lab e derivati.
Con RTAI-Lab potete produrre delle applicazioni RTAI complete usando la generazione automatica da Scicos e Simulink senza scrivere una singola riga di codice.
E' stato Maestro Robi (Roberto Bucher) che ha fatto il miracolo. Ma il suo capolavoro e' stato insegnarmi ad usare ed a sviluppare la generazione automatica di codice. Questo vuol dire che tutti (a parte la solita ventina di pseudo-Nazi ...) possono riprodurre i nostri risultati.

Oltre per mancanza di tool e applicativi, Xenomai non e' riuscito a farsi accettare nel main line kernel. Xenomai e RTAI condividono il codice dello stesso nano-kernel (ADEOS), scritto da Philippe Gerum. Il metodo usato da ADEOS non e' piaciuto agli sviluppatori del kernel. Secondo me perche' non gli piace l'idea di avere qualcuno "sotto" di loro che gli pilotava. ADEOS e' un substrato di codice a livello molto basso che si mette tra il sistema operativo "ospite" (quello non real time) e l'hardware.

Agli sviluppatori del kernel piace avere il controllo diretto del metallo (hardware), controllo che pero' hanno perso definitivamente con i moderni sistemi di virtualizzazione come VirtualBox, VMWare, Qemu, etc.

La virtualizzazione e' una tecnologia cosi' forte che neanche Neo, quando incontra l'Architetto, puo' contrastare. L'unica opzione che gli resta e' usare uno dei due exit point e fare un reload (reboot a caldo). L'Architetto, che lavora a livello hypervisor, e' convinto di essere intoccabile. E forse lo e', almeno fino quando qualcuno non dimostra il contrario.

Perche' dopo Reload arriva Revolution.

ScicosLab Revolution, what else?

Qui prodest? ( ][ )

La posta in gioco e' tanto facile da spiegare tanto difficile da raggiungere: se siete gli autori di una sezione significativa del kernel di Linux voi ed il vostro progetto hanno un futuro assicurato.

Un po' come riuscire ad aprire il deposito del Banco National de la Mesa Verde. 

Purtroppo RTAI non e' riuscito a farsi accettare nel main line kernel, ovvero il sorgente di riferimento che viene utilizzato da tutte le distribuzioni. Abbiamo gia' discusso le ragioni tecniche del "niet" di Linus.

Alla fine del 2005 Philippe Gerum, che per molti anni aveva collaborato con Paolo ed il suo team, decise di staccarsi ("split") e lanciare Xenomai. La scommessa di Philippe era quella di "limare gli angoli" di RTAI per tentare di nuovo di essere accettato nel kernel. La "limatura degli angoli" avrebbe dovuto migliorare l'interoperabilita' tra i processi "standard" (soft real time) di Linux ed i processi hard real time. Inoltre il team di Philippe fece un grosso forzo iniziale per creare una documentazione leggibile anche da persone relativamente inesperte, magari provenienti da ambienti e modi di lavorare piu' vicini al software propietario. Fin dal giorno zero, Xenomai offriva le stesse funzionalita' sia per x86 che PPC (Power PC, il processore anticamente usato dalla Apple).

La documentazione per principianti ed il supporto PPC furono i due fattori principali che mi convinsero a buttarmi a pesce nel progetto. Siccome all'epoca non ero in grado di entrare nei dettagli dei sorgenti, mi offrii volontario (insieme al mio fido PoweBook 15" nuovo fiammante) per testare il nuovo kernel Linux Xenomai.

In un paio di giorni di lavoro h24 (ero bloccato a letto dalla solita influenza stagionale) riuscii infine a tirare fuori una configurazione del kernel stabile e capace di far girare delle piccole demo, inclusa la comunicazione con una scheda di acquisizione dati USB della Measurement Computing che Ramine mi aveva procurato (mai mollare un leader che ti equipaggia con l'hardware giusto).

La cosa pero' non ando' molto piu' avanti: fare un fork - anche con le adeguate conoscenze tecniche e una solida esperienza - non e' una passeggiata di piacere. (Lascio alla vostra immaginazione dipingere lo scenario di un fork senza adeguate conoscenze tecniche).

Tenete giu' la testa perche' il prossimo post avra' la miccia corta!