Rieccomi finalmente tornato al mondo dei blogger con un nuovo articolo strettamente informatico.
Mi scuso in anteprima per eventuali errori e mancanze in questo post, ma mi ritrovo attualmente a scrivere dal mio Nintendo DS dato che l’alimentatore del mio amatissimo MacBook ha deciso di abbandonarmi con uno spettacolo di luci e suoni davvero indimenticabile (in altre parole si e’ bruciato), ho avuto cosi’ la necessita’ di riuscire a trovare un dispositivo che sostituisse almeno in parte cio’ che mi permetteva di fare il mio portatile, ecco quindi che entra in scena il Nintendo DS: 67 MHz di CPU x 4+32MB di RAM, Flashcart M3DS Real e SDHC da 8GB.
Ebbene spero non mi si bruci anche l’alimentatore del DS dato che lo uso 24 ore su 24 per fare praticamente di tutto: dalle operazioni piu’ semplici come navigare su internet, leggere email e ebook, guardare video e ascoltare musica, a cose piu’ complesse come programmazione e networking, il tutto ovviamente grazie ad applicazioni come Opera, DSLinux e Sakura (il nuovo sistema operativo di M3DS Real orientato al multimedia), ma considerate che con 67 MHz di CPU ci vuole davvero tanta tanta pazienza, l’altro giorno sono stato quasi un’ora per scompattare un file ZIP di 166 MB!
La scarsa stabilita’ di DSLinux mi ha spinto alla ricerca di nuovi port di sistemi operativi per Nintendo DS ed e’ proprio cercando nella mailing list di NetBSD che scopro InfernoDS, recentissimo port di Inferno per la console di casa Nintendo.
InfernoDS si presenta davvero bene, parte immediatamente con l’interfaccia grafica, le finestre e il resto sono comandabili dal touch screen, mentre lo schermo superiore rimane finora inutilizzato.
Presenta naturalmente una shell con comandi simil-Unix, ma il toolkit grafico Wm (che a moltiricordera’ immediatamente Fluxbox) presenta ancora evidenti problemi in questo port.
Per i possessori di Nintendo DS piu’ curiosi ecco il link della release che ho personalmente testato icds.nds, mentre se volete visionare altre release piu’ recenti (viene aggiornato abbastanza spesso) andate qui.
Ma diamo un’occhiata piu’ da vicino alle origini di questo sistema operativo, per chi ancora non lo conoscesse.
Tutto ebbe inizio in America verso la meta’ degli anni 80ad opera di un centro di ricerca chiamato CSRC (Computing Sciences Research Center) internoalla Bell Labs, che faceva ancora parte della AT&T.
Al CSRC furono partoriti i sistemi e i linguaggi che hanno influenzato il mondo dell’informatica fino ai giorni nostri, Unix e i linguaggi C e C++, per non parlare di strumenti fondamentali per la programmazione e la compilazione come make, lex e yacc.
Il CSRC ha vantato la presenza di diversi guru dell’informatica, tra cui Ken Thompson, Dennis Ritchie e Brian Kernighan. Dennis Ritchie in particolare ha diretto per diversi anni un gruppo di ricerca nello sviluppo di un sistema operativo chiamato Plan 9, progettato come successore di Unix e che ha visto la sua prima release pubblica nel 1992.
I sistemi a kernel monolitico sono ormai considerati obsoleti (vedi Tanenbaum vs Torvalds), Plan 9 non eredita infatti codice da Unix ma viene riscritto “from scratch” e progettato come sistema distribuito a kernel ibrido, diventando subito il sistema operativo primario su cui vengono concentrate le ricerche del CSRC, prendendo quindi a tutti gli effetti il posto di Unix.
Spiego il termine “distribuito” per chi non fosse ancora molto addentrato in questo campo: fermatevi un attimo a guardare la macchina da cui state leggendo questo blog: vedete un monitor, una tastiera, un mouse…tutto controllato da un sistema operativo. Immaginate adesso tante di queste macchine, tutte collegate in rete, ma ancora con un unico sistema operativo che le controlli ed ecco la configurazione base di Plan 9: diversi terminali per l’interazione con il sistema operativo (i vostri mouse, tastiere, monitor), dei fileserver per l’immagazzinamento dei dati in dispositivi di memoria non volatile (il vostro hard disk), cpuserver dedicati alle computazioni (il vostro processore) e altri server di uso generale.
Dopo la quarta e ultima release di Plan 9, denominata Brazil e progettata per macchine piu’ moderne e reti molto piu’ veloci, Dennis Ritchie decide di passare a un nuovo capitolo, siamo nel 1995, e’ cosi’ che nasce Inferno.
Logo Inferno 4
Inferno prende il suo nome dalla Divina Commedia di Dante Alighieri, cosi’ come Vita Nuova Holdings che nel 1997 collabora strettamente con Bell Labs, ormai passata a Lucent, e che nel 2000 ne ottiene i copyright.
Vita Nuova si occupa quindi della produzione e distribuzione di Inferno e Plan 9, che vengono rilasciati sotto licenza Open Source.
Inferno, che eredita gran parte dei principi del design di Plan 9, e’ un sistema distribuito con kernel a macchina virtuale e puo’ girare nativamente in diverse piattaforme come x86, XScale, PowerPC, SPARC e ARM, risulta anche molto compatto e puo’ girare persino in dispositivi con soli 1 MB di RAM.
Inoltre Inferno puo’ essere eseguito anche come host in altri sistemi operativi tra cui Windows, Mac OS X, FreeBSD, Linux, Irix, Solaris, AIX, HP/UX, UnixWare e Plan 9.
Un'anteprima di Inferno eseguito come plugin su Internet Explorer
Ma vediamo le peculiarita’ di questo sistema operativo.
La progettazione di Inferno, come per il suo antecedente Plan 9, si basa su tre principi fondamentali:
- Un unico protocollo standard per la comunicazione, chiamato Styx (identico a 9P2000, successore di 9P in Plan 9), viene usato per l’accesso a qualsiasi risorsa, sia essa in locale o in remoto.
- Tutte le risorse vengono rappresentate come dei file, ordinati gerarchicamente in un filesystem, a cui le applicazioni possono accedere con delle semplici istruzioni di read e write. Programmatori di ambienti Unix-like vedranno familiare questo aspetto, dato che e’ una caratteristica comune a Unix seppure qui ancora piu’ estesa. Consideriamo ad esempio l’ambiente grafico di un sistema operativo comune (anche Unix-like), un’applicazione deve usare particolari interfacce per fare riferimento alla proprieta’ di una delle sue finestre, in Inferno invece anche le finestre di un’applicazione vengono rappresentate come un file system privato, accessibile quindi solo dall’applicazione che “possiede” la finestra, possiamo quindi accedere anche in questo caso alle proprieta’ di una finestra con delle semplici istruzioni di read e write.
- Anche la rete viene rappresentata come un singolo coerente namespace, apparendo alle applicazioni come un file system gerarchico che puo’ rappresentare risorse sia locali che remote, in pratica qualsiasi risorsa di rete remota viene vista come un file in locale.
Se in Inferno il core e’ scritto come di tradizione in linguaggio C, per il resto del sistema (librerie, moduli e driver) e’ stato usato Limbo, un linguaggio type-safe progettato appositamente per la scrittura di applicazioni in Inferno.
Diretto successore di Alef in Plan 9,Limbo e’ un linguaggio di programmazione che viene compilato in byte-code: un particolare tipo di p-code, codice oggetto a 3 indirizzi simile al linguaggio macchina ma che risulta indipendente dalla sua architettura. Quando il codice byte-code deve essere caricato in memoria per l’esecuzione, questo viene interpretato da una macchina virtuale a 3 indirizzi chiamata Dis.
Byte-code puo’ essere opzionalmente compilato in codice macchina prima dell’esecuzione o durante (on-demand) tramite un compilatore JIT in modo da renderne l’esecuzione molto piu’ veloce.
Sia l’interprete che il compilatore JIT sono caricati nel kernel.
Esecuzione del codice di un'applicazione in Inferno
E a proposito di byte-code, questa parola avra’ fatto suonare il campanello Java nella testa di qualcuno, andiamo ad osservare le differenze fra i concetti di Inferno e le tecnologie Java un po’ piu’ da vicino.
Anche Java viene compilato in byte-code ed eseguito per mezzo di una macchina virtuale, denominata JVM (Java Virtual Machine), che -come Dis – utilizza la compilazione JIT per ottimizzare l’esecuzione di byte-code, esistono inoltre particolari processori detti “Java processor” che comprendono Java byte-code direttamente nel loro Instruction Set, trasformando quindi di fatto JVM da macchina virtuale a macchina concreta. Un esempio molto diffuso di questo tipo di processore e’ ARM926EJ-S, che guarda caso e’ la CPU usata proprio da Nintendo DS (vedi ARM9E).
Inoltre nel 1996 Sun crea JavaStation, un particolare tipo di “Network Computer”, un thin-client che potete considerare come un comune PC low-cost ottimizzato per la navigazione web. Niente dischi quindi per JavaStation (i file venivano memorizzati in server remoti), un semplice sistema operativo chiamato JavaOS, un browser chiamatoHotJavae altre eventuali applicazioni Java a scelta dell’utente.
Con architettura a microkernel e scritto principalmente in Java, JavaOS usa la Java Virtual Machine come sua componente principale. JVM si occupa infatti di gestire persino i driver, scritti anch’essi in limguaggio Java, in modo simile a quanto visto precedentemente con Dis e Inferno.
JavaStation viene infine abbandonata nel 2000 e con essa muore anche JavaOS, ma esistono comunque altri sistemi simili, tra cui il degno di nota JX, sistema open source a microkernel, scritto anch’esso in Java e sviluppato in Germania ad opera dell’Universita’ di Erlangen.
In conclusione, Java risulta ormai uno standard indiscusso per sistemi embedded, dato che offre la comodita’ di codice portabile su qualsiasi piattaforma e senza il bisogno di ricorrere a cross-compiler (alcuni dispositivi possono essere talmente scarsi come capacita’ di memoria e computazione da rendere praticamente impossibile la compilazione in locale),concetto su cui si basa la progettazione di Inferno e Limbo.
Inferno e’ indubbiamente un sistema operativo particolarmente interessante per i concetti avanzati su cui si fonda, ma per la sua minimalita’ e compattezza non e’ orientato all’usabilita’ come sistema desktop, inoltre rimane ancora poco utilizzabile dalla massa a causa dello scarso parco software che presenta il linguaggio Limbo.
Una grave pecca a mio avviso rimane la mancanza di un compilatore C, C++ per byte-code eseguibile da Dis, il che permetterebbe un porting piu’ facile dei software piu’ diffusi dalla comunita’ open source anche su Inferno.
Esiste comunque il set di compilatori xc (0c, 1c, 2c, 5c, 6c, 7c, 8c, kc, qc e vc) per linguaggio C, ma che producono codice dipendente dall’architettura, rompendo quindi la filosofia del codice portabile su tutti i sistemi Inferno anche se installati in diverse architetture.
Allo stato attuale, l’unico strumento per la “portabilita’(?)” di codice C su Inferno rimane c2l, che si occupa di tradurre fin dove possibile un sorgente da linguaggio C in Limbo, sara’ poi il compilatore limbo a mostrare eventuali problemi nel sorgente tradotto, eventualita’ che diventa una certezza nella presenza di stringhe e di altri costrutti che non sono facilmente traducibili in Limbo.
Cito direttamente dalla man page di c2l :
“C2l translates the named Cfileinto Limbo. The translated code should be almost always syntactically correct but will certainly never be semantically correct as certain constructs in C (strings for example) are almost impossible to convert automatically into Limbo. Otherwise it tries to do a good job of translating the C constructs that have some sort of equivalence in Limbo.”
Collegamenti utili:
http://www.vitanuova.com/inferno/
http://cm.bell-labs.com/cm/cs/who/bwk/interps/pap.html
http://doc.cat-v.org/inferno/4th_edition/
http://ftp.bme.hu/OS/inferno/faq.html
http://www.adityabansod.net/things/papers/infernointro.htm
http://code.google.com/p/inferno-os
http://www.vitanuova.com/inferno/design.html
http://kny.iki.fi/inferno/
http://tldp.org/HOWTO/JavaStation-HOWTO/whatischapter.html
Sottoscrivi RSS 
RSS FeedBurner
Sonic Frequencies 
Commenti recenti