AROS
di Bernardo Innocenti (bernie@cosmos.it) - per gentile concessione di Amiga Life
Riscrivere AmigaOS
 Nel 1994, la liquidazione di Commodore sembrava aver segnato irreversibilmente il destino di Amiga. La conseguente chiusura del centro di ricerca situato a West Chester implicava anche l'arresto dello sviluppo del sistema operativo più innovativo che sia mai esistito. All’interno della comunità Amiga, molti programmatori sentirono il bisogno di fare qualcosa per salvare AmigaOS da una fine così misera. Dal momento che i sorgenti di AmigaOS sono sempre stati mantenuti segreti, per continuarne lo sviluppo rimaneva un’unica drastica soluzione: rimboccarsi le maniche e scrivere un nuovo AmigaOS partendo da zero.
I primi tentativi in tal senso fallirono miseramente prima ancora di iniziare. Gli sviluppatori Amiga, pur essendo molto numerosi, hanno sempre sofferto di una pressoché totale mancanza di coordinazione. 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 multi-processing simmetrico, senza che fosse stata scritta una sola linea di codice.
Amiga Replacement OS
A quasi tre anni di distanza dalla scomparsa di Commodore, l'entusiasmo iniziale per questi progetti si era ormai del tutto spento assieme alle estenuanti flame wars. Escom inoltre aveva annunciato una nuova versione di AmigaOS che avrebbe accompagnato un nuovo modello denominato Walker, ma, come sappiamo, Escom fallì 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 così 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 Operating System, in breve AROS, partiva con solide premesse. L'obiettivo principale era raggiungere la completa implementazione dell'attuale OS 3.1, mantenendo per quanto possibile la compatibilità binaria con le applicazioni esistenti. A differenza del vero AmigaOS, AROS è stato progettato con un particolare riguardo alla portabilità verso altri microprocessori e piattaforme hardware. Per questo motivo la quasi totalità del codice è stata scritta in C ed i moduli dipendenti dall'hardware sono stati mantenuti separati dal resto del codice.
|
|
Riquadro 1 - I numeri di AROS
|
Le librerie dell’OS 3.1 contengono 1234 funzioni, di cui:
- 274 (pari al 20.2%) devono ancora essere scritte
- 160 (pari al 13.0%) sono in lavorazione
- 800 (pari al 64.8%) sono state completate
Esistono altre 56 funzioni al di fuori delle librerie:
- 14 (pari al 25.0%) devono ancora essere scritte
- 35 (pari al 62.5%) sono in lavorazione
- 7 (pari al 12.5%) sono state completate
|
|
Per semplificare il debug nelle prime fasi dello sviluppo, AROS è stato scritto in modo da poter essere eseguito anche come un normale programma di Linux, permettendo così agli sviluppatori di avvalersi di un ambiente di sviluppo potente e flessibile.
Open Source development
 La maggior parte dei programmi shareware o public domain per Amiga sono realizzati da un singolo programmatore, il che pone delle ovvie limitazioni alla complessità totale del software.
Nella comunità di sviluppatori UNIX, invece, la prassi è di rendere immediatamente disponibili i sorgenti dei programmi in modo da incoraggiare altri a correggerne i bug e ad aggiungere funzionalità. Utilizzando strumenti appositi, è 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 e allo scopo di ogni singola modifica.
Gli sviluppatori hanno la possibilità 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 aros-dev è possibile discutere le questioni implementative prima di procedere nel lavoro.
Ogni partecipante può offrirsi volontario per sviluppare una parte del sistema operativo. L'assegnazione dei lavori è stata automatizzata mediante un apposito Job Server, che permette di tenere traccia dello stato di avanzamento di ogni singolo lavoro.
|
Tabella 1 - Stato del Job Server
|
| Modulo | Funzioni | Da Fare | In corso | Completate | |
DevCMD | 129 | 70.54% | 27.13% | 2.33% | |
HIDG | 28 | 39.29% | 60.71% | 0.00% | |
alib_commodities | 7 | 0.00% | 100.00% | 0.00% | |
alib_stdio | 7 | 0.00% | 100.00% | 0.00% | |
arp | 70 | 52.86% | 2.86% | 44.29% | |
asl | 6 | 16.67% | 83.33% | 0.00% | |
battclock | 3 | 0.00% | 0.00% | 100.00% | |
commodities | 29 | 0.00% | 0.00% | 100.00% | |
console | 2 | 50.00% | 0.00% | 50.00% | |
datatypes | 15 | 0.00% | 0.00% | 100.00% | |
diskfont | 5 | 60.00% | 40.00% | 0.00% | |
dos | 154 | 11.69% | 7.14% | 81.17% | |
exec | 118 | 0.85% | 6.78% | 92.37% | |
expansion | 21 | 38.10% | 4.76% | 57.14% | |
gadtools | 19 | 0.00% | 47.37% | 52.63% | |
graphics | 165 | 18.79% | 9.09% | 72.12% | |
icon | 12 | 0.00% | 0.00% | 100.00% | |
iffparse | 40 | 0.00% | 0.00% | 100.00% | |
input | 1 | 0.00% | 0.00% | 100.00% | |
intuition | 124 | 25.81% | 4.84% | 69.35% | |
keymap | 4 | 0.00% | 25.00% | 75.00% | |
layers | 32 | 0.00% | 21.88% | 78.12% | |
locale | 24 | 0.00% | 8.33% | 91.67% | |
lowlevel | 15 | 73.33% | 26.67% | 0.00% | |
mathffp | 12 | 0.00% | 0.00% | 100.00% | |
mathieeedoubbas | 12 | 0.00% | 25.00% | 75.00% | |
mathieeedoubtrans | 17 | 0.00% | 11.76% | 88.24% | |
mathieeesingbas | 12 | 0.00% | 0.00% | 100.00% | |
mathieeesingtrans | 17 | 0.00% | 0.00% | 100.00% | |
mathtrans | 17 | 0.00% | 0.00% | 100.00% | |
misc | 2 | 0.00% | 0.00% | 100.00% | |
timer | 5 | 20.00% | 0.00% | 80.00% | |
utility | 38 | 0.00% | 0.00% | 100.00% |
|
|
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 è possibile generare AROS per diverse CPU e in diversi flavour (gusti). Attualmente esistono due flavour principali: il nativo, che su CPU m68k mantiene la compatibilità a livello binario con le applicazioni di Amiga e l'emul, che permette di eseguire AROS in un sistema operativo ospite.
Attualmente la configurazione più matura è l'emulazione su sistemi UNIX, perché è l'ambiente preferito dalla maggior parte degli sviluppatori di AROS. I sistemi UNIX supportati finora sono Linux i386 e m68k e FreeBSD i386. La versione Linux 68k, mantenuta da Kars de Jong, permetterà di eseguire le applicazioni native di Amiga senza richiederne la ricompilazione.
Il porting verso altri sistemi UNIX richiede un numero molto contenuto di modifiche, tra cui 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 è molto simile a ciò che si ottiene usando UAE, ma con l'importante differenza che tutto il codice è effettivamente compilato per la CPU del sistema ospite anziché 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 è possibile effettuare il boot solo da floppy disk e poiché non sono ancora completi i driver delle schede grafiche, non è ancora possibile utilizzare Intuition. Michael Schultz, principale autore di questo flavour, sta ora lavorando per completare i driver mancanti.
Su Amiga è possibile compilare AROS per ottenere una collezione di librerie e di eseguibili che possono essere usate per sostituire le corrispondenti versioni che sono presenti nella ROM del Kickstart e nel Workbench. Viene fornito un tool chiamato arosboot che permette di caricare selettivamente le librerie di AROS per renderle disponibili al successivo reboot. Se tutto va bene, il computer dovrebbe riavviarsi normalmente e non si dovrebbe notare alcuna differenza rispetto al normale funzionamento del sistema.
|
Attualmente, gli unici moduli che offrono una compatibilità 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 utilizzabili su Amiga perché 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 è stato progettato in modo da essere facilmente portato in una varietà di ambienti diversi ed i flavour attualmente disponibili costituiscono solo un inizio. L'unico vero limite alla possibilità di portare AROS su altri sistemi in modo nativo o emulato è costituito dalla disponibilità di sviluppatori che si offrano volontari per realizzare il lavoro. Qualche mese fa nella mailing list è stata discussa la possibilità di un port per PowerPC.
Przemyslaw Szczygielski sta lavorando ad una versione di AROS che girerà indistintamente su Linux APUS, Linux PPC e MkLinux. Claus Herrmann sta invece lavorando ad una versione nativa per Amiga dotati di schede PowerPC. Non si tratterebbe dell'ennesimo kernel PPC come quelli offerti da Phase5 ed Haage & Partner: AROS sarà 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 un flavour emulato come in UNIX, lanciando quindi AROS per PowerPC in uno schermo a parte mentre sul 68000 continua a funzionare la versione originale di AmigaOS.
Lavori in corso
A metà dello scorso anno, lo sviluppo di AROS iniziò a rallentare fino ad un ristagno pressoché 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 più possibile proseguire senza prima aver completato la parte più complessa di AmigaOS: Intuition. Nel design di AmigaOS, Intuition, input.device, Graphics e Layers sono moduli strettamente interdipendenti. Non è possibile ottenere una versione funzionante di uno qualsiasi dei quattro senza avere gli altri tre. Il tutto su AROS era complicato dalla necessità di aggiungere uno strato di astrazione dall'hardware per grafica e input.
Alla fine del 1998, dopo una serie interminabile di discussioni tecniche, la progettazione è ripartita in grande stile. 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 maturità sufficiente a poter proseguire lo sviluppo di GadTools, Asl e Boopsi.
 Johan Alfredsson, che ha da poco completato commodities.library e datatypes.library, sta ora lavorando alla realtime.library e alle parti mancanti del console.device, grazie al quale sarà presto possibile aprire la shell all'interno di una finestra CON: come avviene su Amiga. Quando Michael Schultz avrà completato i necessari driver, sarà possibile creare partizioni FastFileSystem sull'hard disk di un PC per poter effettuare il boot della versione ibmpc-native. Nel frattempo, Branko Collins si è offerto di aggiornare e correggere la documentazione di AROS e di rinnovare il look del sito web in modo da renderlo più accessibile agli utenti non programmatori. La nuova home page dovrebbe essere disponibile on-line entro Settembre.
A mano a mano che i vari moduli di sistema verranno completati, diverrà possibile portare su AROS il software attualmente esistente per Amiga. Per non dissipare risorse inutilmente, il team di AROS ha deciso di non iniziare a riscrivere le utility di sistema per le quali sono già presenti delle versioni sostitutive nel pubblico dominio. Sono infatti innumerevoli i programmi che, negli corso degli anni, hanno sostituito e migliorato gli equivalenti forniti con AmigaOS 3.1. Il Workbench, per esempio, potrebbe essere sostituito da Scalos oppure da Directory Opus.
Ogni buon utente Amiga ha installato dozzine di questi programmi, tipicamente assieme a varie patch che migliorano l'estetica o la funzionalità del sistema. Queste ultime su AROS diverrebbero del tutto superflue e superate: disponendo dei sorgenti dell'intero sistema operativo sarebbe infatti più semplice aggiungere tutte queste migliorie direttamente nel sistema anziché ricorrere a dei patch.
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 realtà di classi boopsi che sfruttano l'ereditarietà tipica di un sistema orientato agli oggetti al fine di minimizzare il lavoro necessario ad implementare nuovi driver. Grazie ad un'accurata fase di design, questa flessibilità aggiuntiva è stata ottenuta con una penalità minima in termini di prestazioni.
 Un driver di una nuova scheda grafica può 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 è in grado di emulare qualsiasi funzione di disegno chiamando soltanto il metodo WritePixel. Ovviamente in seguito è possibile ottimizzare il driver implementando direttamente altri metodi in modo da sfruttare eventuali acceleratori grafici. Perciò in AROS 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 difficoltà.
Problemi di Visibilità
Molti si domanderanno come mai un progetto di tale importanza sia rimasto nell'ombra per quasi tre anni. Il principale motivo é che la posizione legale di AROS nei confronti di Amiga Inc. è a dir poco dubbia.
È possibile, anche se non accertato, che la distribuzione di un sistema operativo funzionalmente identico ad AmigaOS costituisca una violazione di alcuni dei brevetti di proprietà 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 possederebbe la forza economica necessaria per potersi difendere adeguatamente.
Nel corso degli 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 è stato possibile ottenere una risposta ufficiale definitiva. In mancanza di informazioni certe sullo stato legale di AROS, fino ad oggi soltanto gli sviluppatori coinvolti nel progetto hanno avuto accesso ai sorgenti di AROS.
Public Release
 Recentemente è stato possibile esaminare il testo dei brevetti depositati da Commodore presso lo U.S. Patent Office. Pare che per evitare di infrangere questi brevetti sia necessario apportare lievi modifiche al funzionamento di Intuition.
In seguito a questa scoperta, è stato possibile avviare una discussione sulla possibilità di rilasciare AROS al pubblico. Il cardine del dibattito è stata la scelta di una licenza di distribuzione. Sebbene all'interno del progetto tutti fossero unanimi nella scelta di una licenza open source di tipo non commerciale, il team era diviso tra chi desiderava una licenza stile GPL e chi avrebbe preferito una licenza stile BSD. Nel corso del dibattito sono state proposte numerose alternative, tra le quali quella di scrivere unaw licenza ad-hoc. Alla fine la scelta è ricaduta su una licenza MPL. La MPL presenta diverse analogie con la GPL, ma permette al team di AROS di offrire i sorgenti a terze parti con licenze di tipo diverso, consentendo così a compagnie come Amiga Inc., Phase 5 e Haage & Partner di utilizzare AROS in parte o per intero come base per lo sviluppo di prodotti commerciali senza avere l'obbligo di distribuire i sorgenti.
Successivamente, Aaron Digulla ha stabilito una dead-line per la prima distribuzione pubblica di AROS, invitando tutti ad inviare eventuali lavori non ancora rilasciati. Il primo upload su Aminet è avvenuto in concomitanza con il World Of Amiga. La distribuzione è suddivisa in 4 archivi che contengono i sorgenti, la documentazione, gli eseguibili per Amiga e quelli per Linux.
Conclusioni
Sebbene siano passati quasi sei anni dal fallimento di Commodore, a dispetto delle previsioni di molti Amiga ed il suo sistema operativo esistono ancora ed è imminente il rilascio di una nuova versione. Tuttavia la necessità di avere una versione free-software di AmigaOS rimane importante perché slegherebbe lo sviluppo dell’OS da decisioni di carattere economico, con evidenti vantaggi per gli utenti.
Oggi AROS è senza dubbio il più maturo tra i progetti di riscrittura di AmigaOS, ed il giorno in cui gli utenti potranno iniziare ad usufruirne si avvicina sempre di più. I sorgenti depositati nel server CVS ammontano ormai a oltre 31MB e il 65% delle funzioni di sistema sono state già scritte. In AROS sono impegnati oltre 90 sviluppatori e grazie al progressivo consolidamento del sistema il lavoro procede sempre più rapidamente.
In futuro, il successo di AROS dipenderà in larga misura dalla capacità dei programmatori Amiga di adeguare il proprio modo di lavorare ad un sistema operativo open-source. Anziché disperdere le proprie energie lavorando individualmente a programmi di piccole e medie dimensioni, gli sviluppatori dovranno contribuire attivamente al miglioramento dell'intero sistema. Ormai sono innumerevoli gli esempi di progetti di successo a cui ispirarsi. Basta nominare Linux o FreeBSD per rendersi conto che, anche nell’ambito del software, l'unione fa la forza.
Bernardo Innocenti
Riferimenti
Tratto da Amiga Life n.105 - (C) Pluricom - Ringraziamo l'editore per aver concesso la pubblicazione su AmiWorld.
Per maggiori informazioni su AmigaLife: http://www.pluricom.it/amigalife
|
 |
|
![[Made On Amiga]](../../images/amiga.gif){kind=small}
