0. ABSTRACT =========== Nel 1994, la rovinosa liquidazione di Commodore sembrava aver segnato irreversibilmente il destino di Amiga. Oggi, dopo quasi sei anni di travaglio, Amiga esiste ancora a dispetto delle previsioni di molti. Tra gli sviluppatori, il fallimento di Commodore implicava anche l'arresto dello sviluppo del suo sistema operativo. Molti sentirono quindi il bisogno di fare qualcodsa per evitare una simile perdita. AmigaOS e' un sistema proprietario e quindi i suoi sorgenti non sono pubblicamente disponibili. Rimaneva percio' un'unica drastica soluzione: rimboccarsi le maniche e riscrivere da zero l'intero sistema operativo. I primi tentativi fallirono miseramente prima ancora di iniziare. Gli sviluppatori Amiga, pur essendo molto numerosi, hanno sempre sofferto di una pressoche' totale mancanza di coordinazione. Raggruppare un numero consistente di programmatori e' un compito tuttaltro che facile. E cosi', le mailing list dei primi progetti di riscrittura di AmigaOS, tra cui uno chiamato AOS, vennero letteralmente soffocate da polemiche infruttuose su dettagli tecnici quali la protezione della memoria ed il multiprocessing simmetrico, senza che fosse ancora stata scritta una sola linea di codice. 1. Amiga Replacement OS ======================= A quasi tre anni di distanza dal fallimento di Commodore l'entusiasmo iniziale per questi progetti si era ormai spento. Escom inoltre aveva annuncio' una nuova versione di AmigaOS che avrebbe accompagnato il nuovo modello denominato Walker, ma come tutti sanno Escom falli' prima di poter completare il progetto. Fu allora che nacque quello che sembrava essere l'ennesimo progetto di riscrittura di AmigaOS. Nell'inverno del 1995 Aaron Digulla decise di porre rimedio alla pietosa situazione di stasi inviando alla mailing list di AOS un RFC (Request For Comment) nel quale suggeriva di stabilire definitivamente le specifiche minime di un nuovo AmigaOS. Fu cosi' che Aaron divenne il coordinatore di un nuovo progetto al quale aderirono fin da subito numerosi sviluppatori. A differenza dei suoi predecessori, l'Amiga Replacement Operative System, in breve AROS, partiva con solide premesse. L'obiettivo principale era la completa implementazione dell'attuale OS 3.1, mantenendo per quanto possibile la compatibilita' binaria con le applicazioni esistenti. A differenza del vero AmigaOS, AROS e' stato progettato con un particolare riguardo alla portabilita' verso altri microprocessori ed architetture. Per questo motivo la quasi totalita' del codice e' stata scritta in C ed i moduli dipendenti dall'hardware sono stati mantenuti separati dal resto del codice. Inoltre, per facilitare il debugging nelle prime fasi dello sviluppo, il codice di AROS e' stato scritto in modo da poter girare anche come un normale programma di Linux, permettendo cosi' agli sviluppatori di avvalersi di un ambiente di sviluppo potente e flessibile. 2. Problemi di Visibilita' ========================== Molti si domanderanno come mai un progetto di tale importanza sia rimasto nell'ombra per quasi tre anni. Il principale motivo e' che la posizione legale di AROS nei confronti di Amiga Inc. e' a dir poco dubbia. E' possibile, anche se non accertato, che la distribuzione di un sistema operativo funzionalmente identico ad AmigaOS costituisca una violazione di alcuni dei brevetti di proprieta' di Commodore, passati adesso nelle mani di Gateway 2000. In caso di un'azione legale da parte di Amiga Inc., il team di AROS non possiederebbe la forza economica necessaria per potersi difendere adeguatamente. Negli ultimi due anni Aaron Digulla e gli altri sviluppatori hanno tentato di contattare Petro Tyschtschenko, Jeff Schindler e Bill McEwen. Anche se i pareri personali dello staff di Amiga Inc. sono sempre stati positivi riguardo ad AROS, ancora oggi non e' stato possibile ottenere una risposta ufficiale definitiva. Riscrivere un sistema operativo coperto tutelato da brevetti non puo' essere considerato un reato fintanto che il prodotto non viene distribuito pubblicamente. E non essendo possibile fare altrimenti, fino ad oggi soltanto gli sviluppatori coinvolti nel progetto hanno avuto accesso ai sorgenti di AROS. Recentemente e' stato possibile esaminare il testo dei brevetti depositati da Commodore presso lo U.S. Patent Office. Pare che sia possibile evitare di infrangere questi brevetti apportando lievi modifiche al funzionamento di Intuition. 3. Open Source development ========================== La maggior parte dei programmi shareware o public domain per Amiga sono prodotti realizzati da un singolo programmatore, il che pone delle ovvie limitazioni alla complessita' totale del progetto. Nella comunita' di sviluppatori UNIX, invece, la prassi e' di rendere disponibili i sorgenti in modo da incoraggiare altri a correggerne i bug e ad aggiungere funzionalita'. Utilizzando strumenti appositi, e' possibile coordinare centinaia di sviluppatori freelance in progetti di dimensioni mastodontiche. AROS utilizza un modello di sviluppo di questo tipo. I sorgenti sono mantenuti da un server CVS (Concurrent Version System) accessibile via Internet. Il CVS risolve i problemi legati alla sincronizzazione delle modifiche apportate dagli sviluppatori e mantiene dei log che permettono di risalire all'autore ed allo scopo di ogni singola modifica. Ogni sviluppatore ha la possibilita' di aggiornare la propria copia dei sorgenti collegandosi al server, ed eventualmente inviare le proprie modifiche in modo che siano rese disponibili anche agli altri. Grazie alla mailing list gli sviluppatori possono discutere delle questioni implementative prima di procedere nel lavoro. Ogni partecipante puo' offrirsi volontario per sviluppare una parte del sistema operativo. L'assegnazione dei lavori e' stata automatizzata mediante un apposito Job Server che permette di tenere traccia dello stato di avanzamento di ogni singolo lavoro. 4. I /gusti/ di AROS ==================== AROS dispone di un sistema di /build/ piuttosto sofisticato, che permette di ottenere diverse distribuzioni a partire dagli stessi sorgenti. Modificando la configurazione e' possibile generare AROS per diverse CPU e in diversi /falvour/ (gusti). Attualmente esistono due flavour principali: il "nativo", che su CPU m68k mantiene la compatibilita' a livello binario con le applicazioni di Amiga e l'"emul", che permette di eseguire AROS in un sistema operativo ospite. Attualmente la configurazione piu' matura e' l'emulazione su un sistema UNIX, perche' e' l'ambiente preferito dalla maggior parte degli sviluppatori. I sistemi UNIX supportati fin'ora sono Linux i386 e m68k e FreeBSD i386. La versione Linux 68k, mantenuta da Kars de Jong, permette l'esecuzione nativa di applicazioni Amiga senza richiederne la ricompilazione. Per il porting su altri sistemi UNIX e' necessario innanzitutto adattare le routine di Exec che effettuano il task switching e l'esecuzione degli interrupt. Tutti i flavour emulati su UNIX possono aprire finestre di X Window per visualizzare gli schermi di Intuition. L'effetto e' molto simile a cio' che si ottiene usando UAE, ma con l'importante differenza che tutto il codice e' effettivamente compilato per la CPU del sistema ospite anziche' essere emulato via software. Esiste inoltre il flavour ibmpc-native, che permette ad AROS di girare su un PC standard come un qualsiasi altro sistema operativo. Per adesso e' possibile effettuare il boot solo da floppy disk e dal momento che non sono ancora completi i driver delle schede grafiche, non e' ancora possibile utilizzare Intuition. Michael Schultz, princiaple autore di questo flavour, sta attualmente lavorando per completare i driver mancanti. Su Amiga e' possibile compilare AROS per ottenere una collezione di librerie e di eseguibili che possono essere usate per sostituire le versioni corrispondenti presenti in ROM e nel Workbench. Viene fornito un tool chiamato /arosboot/ che permette di caricare selettivamente i moduli di AROS e di renderli disponibili al reboot al posto di quelli originali. Se tutto va bene, il sistema dovrebbe riavviarsi normalmente e non si dovrebbe notare alcuna differenza rispetto al normale funzionamento del sistema. Al momento gli unici moduli che offrono una compatibilita' binaria sufficiente con l'OS 3.1 sono exec.strap, alert.hook, utility.library, keymap.library e commodities.library. Gli altri moduli non sono ancora disponibili per Amiga perche' la maggior parte dei partecipanti utilizza il flavour Linux e preferisce concentrarsi sull'implementazione delle parti mancanti di AmigaOS, lasciando la fase di testing e debug in ambiente nativo per ultima. AROS e' stato progettato in modo da essere facilmente portato in una varieta' di ambienti diversi ed i flavour attualmente disponibili costituiscono solo un inizio. L'unico vero limite alla possibilita' di portare AROS su altri sistemi in modo nativo o emulato e' costituito dalla disponibilita' di sviluppatori che si offrano volontari per realizzare il lavoro. Qualche mese fa nella mailing list e' stata discussa la possibilita' di un port per PowerPC. Przemyslaw Szczygielski sta lavorando ad una versione di AROS che girera' indistintamente su Linux APUS, Linux PPC e MkLinux. Claus Herrmann invece sta lavorando ad una versione nativa per Amiga con dotati di schede PowerPC. Non si tratterebbe di un ennesimo kernel PPC come quelli offerti da Phase5 ed Haage & Partner. AROS sara' invece un sistema completamente nativo PowerPC sul quale le vecchie applicazioni 68000 non potranno essere eseguite senza ricorrere ad un emulatore software. In alternativa, sarebbe possibile realizzare una flavour emulato di AROS come in UNIX, lanciando quindi un AmigaOS PowerPC in uno schermo a parte mentre sul 68000 continua a girare la versione originale di AmigaOS. 5. Lavori in corso ================== A meta' dello scorso anno, lo sviluppo di AROS inizio' a rallentare fino ad un ristagno pressoche' totale. Il progetto aveva raggiunto una svolta difficile. Dopo aver riscritto le parti di AmigaOS che ne costituiscono il kernel (exec, dos, expansion e utility), non era piu' possibile proseguire lo sviluppo senza prima aver completato la parte piu' complessa di AmigaOS: Intuition. Nel design di AmigaOS, Intuition, input.device, graphics e layers sono moduli strettamente interdipendenti. Non e' possibile ottenere una versione funzionante di uno qualsiasi dei quattro senza avere gli altri tre. Il tutto su AROS era complicato dalla necessita' di aggiungere uno strato di astrazione dall'hardware per grafica e input. Alla fine del 1999, dopo interminabili discussioni tecniche, la progettazione e' ripartita in grande stile. In seguito Nils Henrik Lorentzen, Stefan Berger, Henning Kiel e Bernhard Fastenrath hanno formato una task-force che in pochi mesi ha portato Intuition, Graphics e Layers ad uno stadio di maturita' sufficiente a poter proseguire lo sviluppo di GadTools e Boopsi. Johan Alfredsson, che ha da poco completato la commodities.library e la datatypes.library, sta ora lavorando alla realtime.library ed alle parti mancanti del console.device, grazie al quale sara' presto possibile aprire la shell all'interno di una finestra CON: come avviene su Amiga. Quando Michael Schultz avra' completato i necessari driver, sara' possibile creare partizioni FastFileSystem sull'hard disk di un PC per poter effettuare il boot della versione ibmpc-native. Nel frattempo, Branko Collins si e' offerto di aggiornare e correggere la documentazione di AROS e di rinnovare il look del sito web in modo da renderlo piu' accessibile agli utenti non programmatori. La nuova home page dovrebbe essere disponibile on-line entro Settembre. 6. Gli HIDD =========== I moduli che in AmigaOS accedono direttamente all'hardware di Amiga (graphics.library, gameport.device, keyboard.device, serial.device, etc.), su AROS utilizzano invece dei driver indipendenti dall'hardware chiamati HIDD (Hardware Indepentent Device Driver). Si tratta in realta' di classi boopsi che sfruttano l'ereditarieta' tipica di un sistema orientato agli oggetti al fine di minimizzare il lavoro necessario per implementare un nuovo driver. Grazie ad una accurata fase di design, questa flessibilita' aggiuntiva e' stata ottenuta con una penalita' minima in termini di prestazioni. Un driver di una nuova scheda grafica puo' essere scritto in poche ore implementando semplicemente il codice che inizializza il framebuffer grafico ed una funzione che permetta di disegnare singoli pixel. Tutti gli altri metodi del driver HIDD possono essere ereditati dalla classe generica "dispositivo grafico", che e' in grado di emulare qualsiasi funzione di disegno chiamando soltanto il metodo WritePixel. Ovviamente in seguito e' possibile ottimizzare il driver implementando direttamente altri metodi in modo da sfruttare eventuali acceleratori grafici. A questo punto la graphics.library si riduce ad una sorta di interfaccia di alto livello per accedere agli HIDD sottostanti. Attualmente esiste un HIDD che permette di usare una finestra di X11 come dispositivo di output grafico ed altri per poter ricevere da essa l'input del mouse e della tastiera. Il flavour IBM-PC possiede degli HIDD equivalenti che accedono direttamente all'hardware dei PC. Nessuno ha ancora iniziato a scrivere degli HIDD per l'hardware di Amiga, ma ovviamente non ci sarebbero difficolta'. 7. Accessori ============ A mano a mano che le varie parti del sistema operativo vengono completate, diventera' possibile portare su AROS il software attualmente esistente per Amiga. I progetti di interesse per AROS sono molti. Per non dissipare risorse inutilmente, il team di AROS ha deciso di non iniziare a riscrivere le utility di sistema per i quali esiste gia' una versione alternativa su Aminet. Il Workbench, per esempio, potrebbe essere sostituito da Scalos oppure dal Directory Opus. Sono innumerevoli i programmi che, negli anni, hanno sostituito e migliorato gli equivalenti forniti con AmigaOS 3.1. Ogni buon utente Amiga ha installato dozzine di questi programmi, tipicamente assieme a varie patch che migliorano l'estetica o la funzionalita' del sistema. Queste ultime su AROS diverrebbero del tutto superflue e superate: disponendo dei sorgenti dell'intero sistema operativo sarebbe infatti piu' semplice aggiungere queste migliorie direttamente nel sistema anziche' ricorrere a dei patch. 8. Conclusioni ============== Oggi AROS e' senza dubbio il piu' maturo tra i progetti di riscrittura di AmigaOS ed il giorno in cui gli utenti potranno iniziare ad usufruirne si avvicina sempre di piu'. I sorgenti depositati nel server CVS occupano ormai oltre 30MB ed il Job Server indica che il 60% delle funzioni di sistema sono state gia' scritte. Al progetto partecipano ormai oltre 60 sviluppatori ed il lavoro procede sempre piu' velocemente grazie al progressivo consolidamento del sistema. Il successo di AROS dipendera' in larga misura dalla capacita' degli sviluppatori Amiga di adeguare la propria mentalita' ad un sistema operativo open source, lavorando non piu' a progetti individuali, ma contribuendo attivamente al miglioramento dell'intero sistema. Ormai sono innumerevoli i modelli di progetti di successo a cui ispirarsi. Basta nominare Linux o FreeBSD per rendersi conto che, anche nel mondo del software, l'unione fa la forza. Home Page: http://www.aros.org Bernardo Innocenti bernie@cosmos.it