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!

ScicosLab is now free

La gabbia non c'e' piu': il volatile e' libero! (semantica resistente a qualunque tipo di traduttore ma chiarissima per che e' nato e vissuto in Toscana).

Ci sono un sacco di motivazioni che stanno dietro a questa scelta (altra semantica resistente a qualunque tipo di traduttore ma chiarissima per che e' nato e vissuto in Toscana).

Per farla corta, preferisco guardare avanti ad un futuro dove ScicosLab sia un vero progetto Open Source e fare dei post tecnicamente significativi, piuttosto che perdere tempo in sterili polemiche relative ad un passato oramai morto e sepolto.

Qui prodest?

Devo dire che tenere questo blog mi ha fatto rivalutare l'Italiano. E sto facendo su un pesierino sulle lingue classiche come il latino ed il greco. Perche'? Perche' cosi' complico la vita a chi sta passando al pettine fine questo blog alla disperata ricerca di una effermazione che possa essere usata contro di me e contro i miei colleghi che sviluppano ScicosLab. Le sfumature della lingua italiana sono veramente difficili da apprezzare ed ancora piu' difficili da comprendere.

Tranquilli.

L'unica cosa che riusciranno a trovare sara' il loro imbarazzo. Noi navigheremo tranquilli fino alle calde spiagge di Cuba (non so se mi sono spiegato). Vi raccontero' i dettagli di progettazione dell' Красный Октябрь in un prossimo post. Per adesso mi raccomando di controllare la temperatura dell'elio liquido perche' sopra 4.2 Kelvin il superconduttore NbSn collassa e addio viaggio tranquillo fino alle calde spiagge di Cuba.

Ritorniamo a RTAI.


La filosofia di RTAI e' semplice e geniale allo stesso tempo. Invece di costringere tutti i programmi a vivere nel mondo hard real time, stravolgere lo scheduler del kernel e obbligare la riscrittura di tutti i driver, RTAI vi permette di continuare a far vivere in un normale ambiente Linux "soft real time" le applicazioni che usate di solito (e senza bisogno di ricompilare nulla), mentre "a lato" crea un ambiente misto kernel/user space dove "vivono" i programmi hard real time.

Per attivare queste funzionalità, l'unica cosa che bisogna fare e' applicare una patch al kernel e ricompilarlo.

Tranquilli: applicare la patch e ricompilare il kernel e' facile. La cosa difficile e' far funzionare corretamente la baracca. Putroppo esistono un sacco di fattori di disturbo che possono rendere la vita con RTAI molto ma molto difficile. Un primo ostacolo sono di driver proprietari delle schede video NVIDIA e ATI. Succede spesso che i driver binari si allocano troppe risorse per troppo tempo, a scapito della velocita' di risposta di Linux RTAI. Evitate quindi di mischiare Linux RTAI con driver binari, cercate di usare hardware supportato tramite driver open source.

Ma la cosa che pou' mandarvi in paranoia e' il chipset della vostra scheda madre. Non solo ne esistono una infinita', ma i costruttori di mother board sono degli specialisti nel mischiare le carte in tavola.

Paolo ha fatto del tuning molto spinto per ottimizzare i tempi di risposta. Dubito fortemente che possiate riuscire ad avere delle latenze migliori di RTAI. Purtroppo il team di Paolo non ha le risorse per fare dei test esaustivi su tutte le configurazioni possibili di PC. Quindi le cose potrebbero andarvi lisce alla prima, come potreste entrare in un brutto giro di cazzotti a colpi di SMI, interrupt persi, interrupt sporadici ed inspiegabili quanto improvvisi picchi di latenza.

Non pensate che i vostri problemi siano dovuti a software open source di scarsa qualità. Ho provato la patch hard real time di Real Time Windows Target (Mathworks) su 12 PC diversi. Su 4 il PC si pianta e siete costretti al reboot. Su due e' instabile. Sugli altri funziona perfettamente. Il problema e' sempre lo stesso: nessun sviluppatore software puo' testare ed ottimizzare il codice su tutte le combinazioni hardware/software immaginabili, nemmeno un gigante come Mathworks.

Come si fa allora a migliore la situazione?

Risposta: si usano gli utilizzatori come cavie da laboratorio. Puo' sembrare inumano ma e' cosi' che l'Open Source funziona. E' un sistema a loop chiuso. Gli sviluppatori onesti cercano di fare del loro meglio, pubblicano il software e aspettano il feedback degli utilizzatori per correggeri i bug.

Perche' Linux non e' hard real time

Prima di tutto, bisogna convincersi che Linus Torvalds non e' un coglione: dietro ogni singola linea di codice ci sono profonde considerazioni; considerazioni sue, e di chi e' venuto prima di lui.

Avere un sistema operativo con funzionalita' hard real time vuol dire essere in grado di fornire delle garanzie dure sulla tempistica di esecuzione di uno o piu' processi.
Quindi si deve per forza accettare che le risorse di sistema possano essere monopolizzate da uno o piu' processi che hanno elevate priorita' di esecuzione. Tali processi hanno una priorita' elevata perche' si vuole dare delle garazie della loro completa esecuzione in tempi prestabiliti.

Il determinismo nell'esecuzione e' indispensabile per poter applicare le moderne teorie di controllo digitale. Esse si basano su di un assioma semplice quanto "duro": il processo sara' eseguito con una certa cadenza periodica (fissa o variabile) e avra' una durata predeterminata.

Accettare queste specifiche significa accettare la possibilita' che qualche processo, con priorita' bassa, non vada MAI in esecuzione, perche' la CPU risulta sempre occupata con i processi ad alta priorita'.

Questo e' esattamente quello che Linus non vuole! Lo scheduler di Linux funziona con un sistema di priorita' dinamiche ("the elevator" , l'ascensore) che assicurano l'esecuzione (prima o poi) anche dei processi a priorita' bassa.

Per cercare di spiegare meglio la cosa bisogna capire che esistono due tipi di attivita' che richiedono due diversi approcci:

1. Non ci sono deadline (limiti temporali invalicabili). Se la Moglie arriva tardi all'appuntamento, non e' che ci scappa il morto (di solito).

2. Se un sistema di controllo di una centrale nucleare non reagisce in tempi prestabiliti, il reattore fonde. In questo caso di morti ce sono. E tanti.

L'attivita' (1) e' tipica del mondo civile, mentre la (2) e' tipica di quello militare. Infatti il compito dei militari e' difendere la democrazia, non applicarla. Una organizzazione che richiede - per sua natura - una risposta in tempi prestabiliti, deve essere necessariamente piramidale e non democratica (al suo interno).

Linus, che e' un ex militare pure lui, ha capito bene questa cosa ed e' per questo che si e' sempre opposto all'introduzione di funzionalita' hard real time nel kernel. Inoltre, la presenza di funzionalita' hard real time implica un ulteriore - potenziale - enorme falla di sicurezza.

Ma non per questo Linus ha impedito ad altri di fare delle patch hard real time per Linux.

Volete l'hard real time per forza? Con RTAI potete averlo :-).

RTAI and the Xenomai fork

Oggi ho avuto un interessante scambio di idee con Paolo Mantegazza, il leader del progetto RTAI (www.rtai.org).

Riparlare con Maestro Paolo mi ha fatto ritornare in mente tante cose.

La piu' importante di tutte (almeno per me) fu quello che disse Philippe Gerum il giorno che annuncio' Xenomai (www.xenomai.org): "Xenomai is not a fork of RTAI. Xenomai is a split.".

Ci ho messo un bel po di tempo a capire cosa significava, cosi' come ci ho messo un bel po' ti tempo per capire come e perche' Paolo gestisce RTAI in un modo che molti trovano discutibile, ma che merita lo sforzo di essere compreso.

Prima di entrare nei dettagli tecnici e' pero' necessario capire due o tre cose:

1. Perche' Linux non e' hard real time
2. Cos'e' ed a cosa serve un sistema operativo hard real time
3. Qui prodest? Ovvero, chi ci guadagna e chi ci perde ?

Scicos ITM is for ....

... for ScicosLab 4.3. What else ?

ITM sta per Integrated Tokamak Modeling. Lasciate che vi racconti com'e' andata.

Se avessi la possibilita' di viaggiare nel tempo e nello spazio, ma avessi UN SOLO biglietto (gratuito, A/R) sarei dilaniato per la scelta tra:
- Palestina, 30 D.C. circa
- Los Alamos, primi anni '40.

Per mia fortuna, tale bigletto ancora non esiste. Inoltre la settimana prossima devo prendere un aereo per Cadarache quindi, piuttosto che preoccuparmi del passato, devo concentrare la mia attenzione sul momento presente.

Grande Giove: tutti questi casini spazio temporali mi mandano in paranoia.

La Francia sa bene che l'energia nucleare da fissione e' un cavallo dalla vita breve. Sanno bene che potranno allungarne la vita con nuove generazioni di reattori, ma i problemi di sicurezza, proliferazione nucleare (ma che ve ne fate della bomba, investite nel software o nelle biotecnologie) e - al peggio non c'e' mai fine - le maledette scorie nucleari, sono fardelli dal peso non trascurabile.

La Francia (ovvero il CEA, all'interno di una organizzazione internazionale) ha quindi fatto (e sta facendo) l'impossibile per sviluppare una tecnologia nucleare intrinsecamente pulita ed intrinsecamente sicura: la fusione termonucleare. Putroppo, nonostante tutti gli forzi messi in atti fin dagli anni '40 (soprattutto in Russia, da cui il nome "tokamak") nessuno e' ancora riuscito a costruire un reattore con Q>1 ovvero dove l'energia prodotta dalla fusione e' maggiore dell'energia iniettata nel reattore.

Perche' ancora non funziona?

I motivi sono tanti e complessi. Ad oggi sembra che la chiave del problema stia nella stabilizzazione della reazione. La reazione di fusione termonucleare, oltre ad essere difficile da innescare e' dannatamente difficile da controllare. Non tanto perche' esista il problema di una possibile esplosione (impossibile in un tokamak, c'e' troppa poca materia per fare il botto), ma perche' la reazione diventa instabile e si spegne da sola, un po' come un bambino che cade di bicicletta perche' perde l'equilibrio.

I fisici hanno capito che per avere una reazione stabile ed efficiente hanno bisogno di un sistema di controllo "con le palle" (per i tecnici tra di voi sto parlando di "robust control").

Come prima cosa un reattore a fusione non si guida: si pilota. Esistono delle persone particolarmente competenti che sanno trovare le giuste combinazioni di parametri per massimizzare il rendimento della reazione e conoscono i limiti della loro macchina. Anche se una esplosione catastrofica e' impossibile, il rischio di danneggiare la macchina e' sempre presente. A tutt'oggi non siamo riusciti a trovare una compagnia assicurativa dispobile ad offrire una polizza. Tore Sopra e' gia' passato attraverso alcuni incidenti (senza ne' morti ne' feriti) con fatture dell'ordine di milioni di euro.

Il mio amico Sylvain e' uno dei piloti del reattore Tore Supra, il "muletto" che usiamo per per prove in pista (in attesa della disponibilita' di ITER).

Quando i fisici cel CEA decisero (2006) che avevano bisogno di migliorare le loro tecniche di controllo si misero a cercare il meglio disponibile sulla piazza.
Beh, la risposta ve la potete immaginare da soli.... (Project METALAU, INRIA Rocquencourt).
All'inizio i miei colleghi non erano molto positivi al riguardo, ma alla fine Francois e Jean-Pierre decisero di cominciare a lavorare seriamente con Sylvain. Dopo qualche articolo, molte simulazioni e un stop "politico" di quasi due anni, siamo arrivati ai giorni nostri.

Il CEA sta finanziando (indirettamente, mi pagano lo stipendio) lo sviluppo di Scicos-ITM, una toolbox per ScicosLab utile sia alla generazione di codice per la simulazione che per l'implementazione sulle unita' di controllo del reattore.

Il lavoro e' stato fatto con il vecchio ScicosLab 4.3 semplicemente perche il 4.4 non era ancora stabile quando ho cominciato a lavorarci (Settembre 2009).

Tore Supra non puo' andare molto oltre unita' ed - in ogni modo - l'energia prodotta viene semplicemente dissipata, alla faccia del riscaldamento globale. Lo so che e' un bello spreco, ma all'epoca (primi anni '80) non pensavano che Tore Supra sarebbe stato usato per cosi' tanto tempo e che funzionasse cosi' bene (come muletto).

ITER invece nasce per produrre energia fin dal primo giorno, con la speranza di arrivare almeno a Q=10 ovvero 500MWatt di potenza elettrica generata per 50MWatt spesi per mantenere la reazione stabile.

Insomma, il codice prodotto da Scicos-ITM dovra' gestire 50MWatt. Sara' meglio che mi concentri bene per fare un lavoro pulito senza sbavature.

Ad oggi, lo stato dell'arte dice che un reattore a fusione termonucleare funzionera' tanto meglio tanto sara' piu' grande. Sono sicuro che questo fa piacere a CEA e EDF, ma un po' meno a me.

A me serve un dispositivo portatile (o almeno trasportabile).

Volete i sorgenti? Mandatemi una mail (l'indirizzo e' sempre lo stesso).

Scicos HIL is for ...

... for ScicosLab 4.4. What else?

I'm a lazy man. Come dice sempre Maestro Alessandro (Rubini): "Le cose difficili si fanno solo quando si e' materialmente costretti a farle." Per dirla con parole toscane: "Mi fa fatica (arf)". Quindi - adesso - non lo faccio.

Quello che mi e' arrivato sul groppone negli ultimi due anni mi ha fatto desistere ad aggiornare Scicos-HIL. Per l'intervento di forze oscure, la versione aggiornata non ha mai visto la luce.

Adesso le cose stanno cambiando velocemente. Qualche settimana fa sono stato contattato da Jeff, un simpatico ingenere di un laboratorio del CNRS di Lille.

Jeff crede fermamente nell'Open Source, cosi' sta mettendo su una catena di acquisizione dati basati integralmente su strumenti liberi. Potevo negarli il mio aiuto? Ovviamente no.

Mi sono preso la giornata di ieri per aggiornare Scicos-HIL e mandare dei sorgenti freschi e pronti all'uso a Jeff. In serata abbiamo fatto la messa in servizio (ancora un po' macchinosa) insieme.

Funziona?

Come dice sempre il mio caro amico NanniX: "Certo che funziona, mica stiamo qua a giocare a palline!".

Jeff sta testando la mia ultima release per ScicosLab 4.4 con Linux Ubuntu 9.10 e Comedi. Il fatto che funzioni a me non vuol dire nulla: deve funzionare SEMPRE ed in qualunque configurazione, oltre ad essere facile da installare.

Volete partecipare al test? Mandatemi una email ! (simone.mannori at gmail.com).

Pubblicazione (www.scicos.org) prevista per Aprile 2010.

P.S. No, non e' un pesce d'Aprile, e' che a noi piace pubblicare codice ben testato...

The cage (][)

La lettura dell'ennesimo articolo sulla "singolarità tecnologica" (riferimento principale) mi ha fatto ritornare in mente la scomoda eredita' del test di Turing.

Alan Turing era un vero genio: se oggi potete un computer per leggere un blog e' anche merito suo. Purtroppo e' nato in un'epoca dove le sue tendenze affettive venivano considerate un reato punibile per legge. Venne quindi obbligato a seguire delle cure mediche che distrussero la sua psiche fino a spingerlo a suicidio.

Alan Turing aveva qualcosa da nascondere. Il test di Turing, erroneamente venduto come primo test sull'intelligenza artificiale, nasce dalla necessita' di Alan di nascondersi dietro un terminale, una telescrivente che gli permettesse di interagire intelligentemente con altre entita' senzienti senza dover passare attraverso un'interazione "umana" (attribuzione che, come Spock, trovo a dir poco offensiva).

In realtà il test di Turing non serve: il giorno che la singolarità tecnologica si manifesterà, la cosa' sara' cosi evidente che non ci sarà nessuno bisogno di un test.

La conclusione e' che ognuno di noi vive all'interno della gabbia un po' fatta da noi stessi e un po' dagli altri. La liberta' assoluta non esiste (solo i Sith pensano in termini assoluti). Bisogna imparare a saper fare un uso moderato della propria liberta', esattamente come e' necessario fare un uso saggio della Forza. Lo so: la tentazione di usare la Forza per entrare gratis al cinema e' grande (specialmente quando il biglietto costa 14 euro) ma bisogna imparare a trattenersi.

Vivere all'interno di una gabbia non vuol dire rinuciare ad usare il proprio cervello.

The cage

Purtroppo "the cage" (la gabbia) esiste ancora. Sarebbe bello far riferimento all'episodio pilota di Star Trek, adanto in onda l'anno in cui sono nato (1966). Potrebbe essere un'ottima scusa per dire male di James Tiberius Kirk, probabilmente il peggior comandante che la flotta stellare abbia mai avuto la sfortuna di avere in servizio. Diciamocela tutta: fece carriera perche' non c'era niente di meglio disponibile e perche' ebbe la fortuna di avere un equipaggio eccezionale (a partire da Spock).

Dopo aver attentamente riflettuto, sono arrivato alla conclusione che non posso spiegarvi che cosa rappresenta la gabbia perche' sarei costretto a violare il silenzio che mi sono impegnato a rispettare sul Lato Oscuro. Il giorno che la gabbia non ci sara' piu', ve lo potro' spiegare nei dettagli, ma a quel punto non vi interessera' piu' perche' la gabbia non avra' piu' motivo di esistere.

La liberta' e' qualcosa che si apprezza quando se ne e' sentita la mancanza. Purtroppo c'e' chi pensa che a volte e' necessario togliere la vita di alcuni per tutelare la liberta' di altri; forse ha ragione o forse no. Io non ho un'opinione predefinita a proposito (solo i Sith pensano in temini assoluti). In questo caso dico: "...pazienza, miei giovani apprendisti: un giorno la gabbia sparira' .".

Ricordatevi che Scicoslab e' come Muhammad Ali: danza come una farfalla, punge come una vespa e non fa le sporche guerre dei bianchi razzisti del KKK.

Simone's List

Come diceva Giuseppe (Stalin), la morte di un uomo e' una tragedia, mentre la morte di un milione di uomini e' una statistica.

Gli uomini che fanno ScicosLab non sono una statistica: sono fatti di carne, ossa e sangue.

Io mi ritengo una persona estremamente fortunata perche' ho avuto l'opportunita' di conoscerli praticamente quasi tutti. Li conosco oramai cosi' bene che capisco chi ha scritto il codice quando leggo i sorgenti.

Questa e' la lista delle persone che quotidianamente contribuiscono a ScicosLab ordinata in ordine di "build" ovvero come ScicosLab viene compilato:

Jean-Philippe Chancelier
Francois Delebecque
Jean-Pierre Quadrat
Francois Vogel
Ramine Nikoukhah
Alan Layec
Masoud Najafi
Fady Nassif

Per maggiori informazioni: http://www.scicos.org/history.html

La lista di Simone e' - ovviamente - non esaustiva, perche' bisogna tener conto di chi si occupa delle toolbox esterne:

Roberto Bucher : Scicos-RTAI, Scicos-FLEX, Scicos-ITM, etc..
Paolo Gai & "Evidence's boys" : Scicos-FLEX
Matteo Morelli : RTSS
Zhang Dong, Kang Cai : Scicos-HDL

Settanta anni fa qualcuno decise - per sue ragioni strettamente personali - di sterminare un popolo intero.
La risposta fu quella che potete vedere nella foto. Come diceva Confucio, un' immagine vale piu' di mille parole. In questo caso vale 100.000 morti in 100 millesimi di secondo.


Per quelli che ci vogliono cancellare, la mia risposta e' meno esplosiva, meno distruttiva e senza spargimento di sangue (oltre che ad essere molto piu' efficace beninteso): http://www.iter.org

Il sistema di controllo del reattore a fusione ITER e' simulato e realizzato con ScicosLab, Scicos ed un sistema automatico di generazione di codice (Scicos-ITM, Itegrated Tokamak Modeling) sviluppato in collaborazione con il team di fisici ed ingegneri dei laboratori CEA di Cadarache.

ScicosLab. What else?

The Death Star

Tutti sanno che la prima Morte Nera aveva un bug. Come bug era bello grosso, ma almeno era uno solo. Tutto sommato lo si poteva pure giustificare, viste le dimensioni del progetto e del fatto che si trattatava di una versione 1.0.

La cosa veramente scolvolgente e' che Morte Nera v. 2 era ancora piu' grossa ed ancora piu' buggata della versione precedente. Buggata al punto tale che non riuscirono nemmeno ad utilizzarla.

Non riusciro' mai a capire le scelte del Lato Oscuro.

P.S. Nella documentazione imperiale originale, la prima morte nera e' indicata "v. 5.0" probabilmente per la stessa ragione per cui Adolf Hitler aveva la tessera del partito nazista n.500 (non si voleva far sapere in giro che erano solo una ventina di disgraziati capitanati da un pazzo furioso ...).

Un buon cavallo

Per fare del GPU computing serio serve un buon hardware. Per una serie di considerazioni relative al supporto software (che spiegheremo in un prossimo post) abbiamo scelto ATI come piattaforma di riferimento. Non é che NVIDA ci faccia schifo, al contrario: CUDA e' una piattaforma eccellente. Abbiamo pero' sperimentalmente vericato che il "matrimonio" con ScicosLab e' piu' semplice con "la rossa" (ATI) piuttosto che con "la verde" (NVIDIA) . Per non citare la potenza brutale delle ultime 58xx.

Tutti sanno che ogni buon Jedi si costruisce da solo la sua Arma. Lo stesso vale per chi lavora con ScicosLab. Al contrario di altre entità oscure che dispongono di budget smisurati di milioni di euro ed eserciti di cloni (usati per costruire la solita Morte Nera piena di bug), noi siamo abituati a lavorare con quello che gli altri buttano nel cestino ...

Ci siamo quindi procurati due HD4870 di seconda mano. Daniele ha preso una "x2": l'Allievo deve sempre superare il Maestro :-).

Abbiamo presto scoperto che la situazione si stava scaldando un po' troppo. Io ho montato una ventola piu' grossa, mentre Daniele ha optato per un'approccio piu' "radicale". Lascio a lui la parola

Play nice with proprietary software

In un mondo perfetto tutto il software sarebbe Open Source e l'hardware sarebbe completamente documentato.

Purtroppo la realta' e' ben lontanata dal mondo ideale di cui sopra. Oggi ho ricevuto una toolbox per ScicosLab sviluppata da due simpaticissimi giovani ricercatori cinesi http://scicoshdl.sourceforge.net/
Purtroppo la versione attualmente in sviluppo utilizza un compilatore SystemC disponibile solo come dll a sorgente chiuso sotto Windows, per cui la versione Linux arrivera' (se arrivera') con ampio ritardo.

I driver per le schede video (non importa la marca) e i relativi toolbox per il GPU computing, anche se basati su standard aperti (come OpenCL) sono comunque implementazioni proprietarie.

Certo, quando possibile scelgo sempre la strada Open Source, ma alle volte non ci sono alternative e bisogna usare software prorietario.

Stallman mi perdonera' oppure mi condannera' a bruciare per l'eternita' in quel di Redmond?

Mi consolo pensando che Dio ha fatto l'Universo completamente Open Source (almeno nei limiti del principio di inderminazione di Hisemberg e l'assioma di irriducibilita' della Donna), salvo poi dimenticare di pubblicare il manuale.

Reverse engineering, miei giovani apprendisti.

Ma il manuale dove'e' ?

Non ci sono molti libri su ScicosLab (Google ?); la maggior parte delle informazioni che trovate su Scilab 4.x sono applicabili alla linea di comando di ScicosLab.
Per Scicos e' un altro discorso. Il sito (www.scicos.org) vi mette a disposizione diverso materiale in linea (sezione "Documentation").
Abbiamo fatto il massimo sforzo per far uscire ScicosLab 4.4 in parallelo all'ultima edizione dello "Yellow Book" (http://www.scicos.org/newbook.html).
Il libro giallo contiene molte informazioni ed e' un buon punto di partenza anche per i novizi, ma non e' ancora quello che piacerebbe a me.
Vivendo nel mondo dello sviluppo Open Source ho notato come la maggior parte degli sviluppatori non amino "perdere tempo" a fare della buona documentazione.
In particolare gli risulta molto, ma molto difficile entrare nel sistema di riferimento di chi - alle prime armi - prova ad utilizzare il loro lavoro.
Figuratevi che sono il primo del team che ha aperto un blog !

Perche' facciamo ScicosLab

Abbiamo liberamente deciso di sviluppare ScicosLab non perche' e' facile ma perche' e' difficile.
Molto difficile. La maggior parte della gente che ha provato a metterci le mani dentro senza prendere il tempo per capire "come funziona" si e' presa delle belle scottature.

"Considerate la vostra semenza:
Fatti non foste a viver come bruti,
ma per seguir virtute e conoscenza."
Inferno, canto XXVI (‘Ulisse’)

Peggio per loro. Che brucino all'Inferno.

Anche tolti di mezzo tutti i problemi di carattere "politico" (licenze, finanziamenti, entità oscure, fork improvvisi, etc.) rimangono i problemi di carattere squisitamente tecnico.

Per sviluppare ScicosLab bisogna aver avuto la pazienza (e la possibilita') di mettere insieme il mix giusto di conoscenze. In particolare bisogna essere capaci di esplicitare il soggetto in un linguaggio comprensibile per una macchina.

Nel caso specifico, si tratta di fare un investimento non indifferente per apprendere a guidare ScicosLab.

Se poi volete fare veramente la differenza, dovete imparare a "pilotarlo"

Il buongiorno si vede dal mattino

Ieri sera ho passato due ore, tra email e chat, con due ricercatori cinesi e stamani mattina sono stato piu' di un'ora a scrivere una mail di risposta per un ricercatore che lavora in Israele.
ScicosLab e' un lavoro a tempo pieno, nel senso che finisce per assorbire tutte le vostre energie.

Mi hanno domandato se ne vale la pena.

Secondo me si. Sebbene non porti piu' la divisa da tempo, mi considero tuttora un militare di professione. Ma sono contento di fare un altro lavoro.
Cosa c'e' di meglio di lavorare in un team dove un iraniano ed israeliano condividono lo stesso codice, ovvero lavorano insieme piuttosto che spararsi addosso?
Se volete spararvi addosso vi consiglio Modern Warfare 2 oppure Crysis. Procuratevi un PC con una CPU multi core (piu' sono, meglio e') e una buona scheda video, possibilmente con il supporto nativo della doppia precisione con OpenCL.

Quando vi sarete stancati di "giocare alla guerra", vi serviranno per usare al meglio p_ScicosLab 4.4.1.

P.S. Ricordatevi di salvare spesso !

The Right Tool (][)

Adesso le mie due macchine di produzione sono due portatili "pesanti" con processore quad core (Core Duo e i7) e scheda video top (NVIDIA 9800GTS e ATI HD5850).

Ma che te fai dei quad core e GPU se ScicosLab e' ancora una applicazione 2D (3D in software only) e single thread?

Risposte:

• non avete ancora l'accesso alla versione SVN
• pazienza, miei giovani apprendisti. "Answers will come" (Morpheus).

Perche' due portatili? Perche' - come diceva il mio superiore diretto nell'Arma (dei Carabineri) - un uomo con una pistola nella fondina e' molto piu' pericoloso di un uomo con un cannone inchiodato a terra.

The Right Tool

Tutti sanno che per fare un lavoro fatto bene, ci vuole l'attrezzo giusto. E poi bisogna saperlo usare. ScicosLab si compila un po' dappertutto quindi, in linea di principio, una distro vale l'altra.

Dopo tanti anni di Suse, Slackware e Fedora, ho saltato il fosso e uso Ubuntu ovunque (tenete conto che ho una moglie, un figlio e una dozzina di PC con tutte le possibili combinazioni di hardware e software che potete immaginare). Adesso la mia distro di riferimento e' la Ubuntu 9.10 x86 64 bit. La mia macchina di produzione e' ancora una 9.04 32 bit, ma la terro' ancora per poco.

Scicoslab, le ha provate tutte e - per adesso - Ubuntu e' quella che gli piace di piu'.

Open Source pleasures

Il mio primo amore Open Source e' stato Linux, il kernel di Linux. Lo so: chi ben comincia e' a meta' dell'opera. In particolare a me serviva un kernel pecciato per supportare funzionalita' "hard real time", quindi ho passato giorni e giorni a pecciare e compilare il kernel con RTAI (www.rtai.org). Devo dire che e' bello vedere le linee di codice che si compilano una dopo l'altra. Molti anni fa, una mia cara amica e collega ingegnere mi fece notare che l'importanza di un programma e' porzionale al suo output sulla console. Aveva ragione: benedetto sia il Makefile.

Veniamo a noi. Se non avete ancora accesso l'SVN di ScicosLab (perche' non mi avete ancora mandato una mail?) potete sempre scaricare Scicoslab 4.3 (www.scicoslab.org) e cominciare fare esercizio.

Practice make it perfect.

The New Yellow Book

Il punto di riferimento per tutti quelli che sono interessati ad usare ScicosLab è il libro giallo, del quale abbiamo fatto una edizione speciale - ancora calda - per ScicosLab 4.4. Lo potete comprare dove vi pare. Io l'ho comprato qua:
http://www.amazon.com/Modeling-Simulation-Scilab-Scicos-ScicosLab/dp/1441955267/ref=sr_1_1?ie=UTF8&s=books&qid=1265449901&sr=8-1

L'ho comprato sopratutto per vericare che Amazon inviasse la versione giusta :-).

Le persone interessate allo sviluppo potranno trovare una abbondante documentazione nel sito di Scicos (www.scicos.org).

Non resisto: ho bisogno dei sorgenti adesso !

Ti capisco bene mio giovane apprendista. Io ho lasciato moglie e figlio per due lunghi anni per avere la possibilità di lavorare all'interno del team.

Vuoi l'accesso all'SVN? Basta chiedere.

Mandami una mail ("simone punto mannori at gmail.com") e vediamo quello che si puo' fare.

Per gli uomini che hanno una parola sola, la porta di ScicosLab e' sempre aperta.

Perche' non pubblicate il codice sorgente ?

Ci sono due semplici motivi

• alcuni sezioni (il compilatore Modelica ad esempio) sono state sviluppate in collaborazione con aziende private all'interno di progetti europei. In questi casi i sorgenti diventano pubblici sei mesi dopo la chiusura del progetto. In questo modo si assicura una certa confidenzialità e vantaggio commerciale a chi investe nello sviluppo Open Source. Per non parlare del fatto che il codice pubblicato e' veramente ben messo a punto;
• ci siamo stufati di essere depredati del frutto delle nostre fatiche da entità malevole interessate solo ad attribuirsi meriti che non hanno guadagnato col sudore della fronte. Ma non voglio parlare di queste entità oscure.

Normalmente i sorgenti vengono resi pubblici sei mesi dopo la release binaria della versione stabile. In questo caso, visto che ScicosLab 4.4 esce a Febbraio, i sui sorgenti saranno disponibili entro Agosto.

Italiano: lingua di Santi, Navigatori e Poeti

Per navigare nel codice di ScicosLab ci vuole la pazienza di un santo e il coraggio di un esploratore. Ma per saperlo apprezzare, bisogna aver maturato una certa sensibilità poetica. Infatti la bellezza sta nell'occhio che guarda (il codice). Il codice di ScicosLab è come una bella donna che non ci sta alla prima. Pazienza, miei giovani apprendisti ....

Pensavo fosse più difficile

Onestamente pensavo fosse più difficile aprire un blog. Invece no: ce l'ho fatta al primo tentativo.

Cominciamo dall'inizio.

Perche' questo blog e' in Italiano ?

Hello World :-)

Salve a tutti.