Qualche tempo fa era stato citato, nei commenti di un altro articolo, come esempio di esperimento fallito, ma improvvisamente, dopo circa 4 anni di inattività, il progetto ha mostrato segni di vita, come sembrerebbe da un messaggio del programmatore in un noto forum amighista.
Come si può leggere dalla home page, si propone di realizzare un sistema operativo moderno ispirato ad AmigaOS, ma con funzionalità come l’SMP, e che giri sulle ultime versioni dell’architettura ARM (v6 e v7).
In realtà il progetto originariamente si trovava su un’altra pagina e aveva un nome in codice diverso (ARIX: AROS-Linux?), ma alla fine entrambi condividono lo stesso stato: completa assenza di file e documentazione dai quali poter apprendere in che modo raggiungere gli obiettivi prefissi.
A parte le poche informazioni che si trovano sul nuovo sito, è difficile risalire a qualcos’altro di prima mano. Cercando un po’ si trovano link a discussioni di quattro anni fa su forum, blog, che riportano alcune idee. Qui e qui si può ricavare qualche dettaglio in più.
Alcune analisi e riflessioni credo siano d’obbligo. Intanto la scelta di usare Linux, che è quanto di più distante da AmigaOS: un kernel monolitico estremamente complesso (di cui tempo fa si è lamentato perfino lo stesso Torvalds) che si contrappone a un microkernel semplice e leggerissimo.
A parte questo dettaglio macroscopico, parliamo proprio di due filosofie completamente diverse. Linux rientra nel novero dei s.o. UNIX/POSIX-compliant (in realtà è “soltanto” il kernel), mentre AmigaOS è stato realizzato su misura per le macchine di casa Commodore, implementando a modo suo alcuni concetti presenti nella letteratura informatica dei s.o..
Ovviamente parliamo di API completamente diverse, ma non solo. Non esiste in AmigaOS il concetto di appiattire le risorse e il loro uso facendo un ossessivo, ubiquo ricorso al “paradigma del file” (tutto viene mappato a livello di file / filesystem), ma al contrario esistono soluzioni (e API) specializzate per gestire il tutto in maniera pulita ed efficiente.
Divergenze talmente grandi, che potremmo parlare tranquillamente di situazioni diametralmente opposte. Un esempio concreto salta fuori dall’analisi delle tecnologie che sembra vogliano utilizzare gli sviluppatori anche per gestire la grafica.
Sempre da alcuni link sopra riportati, il tutto dovrebbe essere basato su XCB / Xlib (e quindi X-Window alla fine), GLib / GTK, con qualche parte presa da Zune (l’unico elemento AmigaOS-like) .
Adesso proviamo a immaginare un possibile scenario d’utilizzo per un’applicazione “nativa” di Anubis-OS che voglia effettuare qualche operazione con un widget grafico. Fa la richiesta a Zune, che la passa a GTK, che la gira a GLib, che la rimbalza a Xlib, che la codifica in un bel pacchetto che spedisce al socket aperto per comunicare col server X-Window, il quale è messo in ascolto sul socket, che riceve il pacchetto, lo decodifica per capire di che tipo di richiesta si tratti e degli eventuali parametri, la gira al sottosistema grafico di basso livello (DirectFB, OpenGL, o quant’altro; l’esperto linuxiano mi correggerà), che la smista al driver, il quale infine la sottopone all’hardware.
In un s.o. AmigaOS/like il passaggio sarebbe da Zune a intuition.library, che girerebbe la richiesta al sottosistema grafico (la graphics.library; la layer.library, se necessario), che la smista al driver, il quale infine la sottopone all’hardware. Nell’AmigaOS originale non è presente nessun driver, per cui la comunicazione fra graphics.library e hardware avviene direttamente.
I due sistemi sono molto, molto simili; ma proprio, uguali uguali! Specialmente se teniamo conto anche del fatto che su Linux si fa ricorso ai socket e che, quindi, si scomoda addirittura il networking per arrivare alla scheda video (anche se fortunatamente alcuni stanno lavorando a soluzioni moderne e, soprattutto, di buon senso), e che inoltre su AmigaOS, oltre a non essere presente nessuna aberrazione del genere, si lavora quasi esclusivamente in user-space (mentre in un kernel monolitico come Linux quando si fanno chiamate di sistema si deve effettuare un context-switch in kernel-space, e di nuovo un altro per tornare in user-space).
Chissà cos’altro salterà fuori con l’audio, dove Linux versa in una situazione ben peggiore. Alcune informazioni in merito si trovano qui e qui, ma nel frattempo sono saltate fuori soluzioni come PulseAudio e JACK, che stanno prendendo piede.
A parte questo, su AmigaOS/like l’audio si controlla tramite l’audio.device, che s’interfaccia col driver e questi con l’hardware, oppure tramite la libreria AHI (divenuta lo standard di fatto ormai), che espone un set di librerie per pilotare direttamente il sottosistema audio. Un modello ancora più semplice e leggero rispetto alla grafica e, anche qui, nulla a che vedere con la catena di rimpalli che si scatena su Linux et similia.
Comunque alla fine non è nemmeno una tragedia: avendo scelto Linux come kernel, se ne condividono pregi e difetti. D’altra parte l’obiettivo era/è di ottenere un s.o. che implementi SMP, protezione della memoria, e resource tracking, oltre ad attingere a un vasto parco hardware grazie alla pletora di driver: tutte cose già a disposizione, per cui gli sviluppatori di Anubis-OS non devono spendere altro a tempo a riguardo.
Posto che sul “moderno” ci sarebbe di che discutere visto che Unix ha più di 40 anni alle spalle (le diverse incarnazioni no, ovviamente), avendo sostanzialmente buttato via AmigaOS si dovranno occupare, a questo punto, di realizzare una sorta di framework per Linux che metta a disposizione alcune API AmigaOS-like. Soltanto quelle che necessarie a ricreare quello che loro chiamano AmigaOS-workalike; quindi qualcosa che nel funzionamento assomigli ad AmigaOS.
Data la diversità fra i due s.o., di cui in parte ho parlato nei commenti del precedente articolo su AmigaOS, sarà interessante vedere cosa s’inventeranno i programmatori per costruire questo “ponte” fra i due mondi (il pensiero è sempre ai volumi, per fare l’esempio più noto agli amighisti), e ancor più interessante sarà vedere cosa, essenzialmente, rimarrà in effetti di AmigaOS, visto che non si sa nemmeno se verrà utilizzato un filesystem AmigaOS-like, oppure se verrà mantenuta la shell e/o i vecchi comandi, ad esempio.
L’unica cosa certa è che attingeranno ad AROS per il framework, che lavorerà in “user-land“, per cui non si vedono nemmeno modifiche a Linux all’orizzonte, che, pertanto, dovrebbe rimanere inalterato.
Considerato che AROS non è ancora completo (e proprio Zune non è ancora al livello delle ultime versioni di MUI, anche se di recente ha fatto passi da gigante) e abbisogna di manodopera, ci si potrebbe chiedere per quale motivo non si potrebbe continuare a contribuirvi per portarlo quanto meno a una situazione di stabilità e maturità, per poi avviare un progetto come Anubis-OS.
Frammentare ulteriormente gli sviluppatori non può certo far bene né all’uno né altro. Tra l’altro finora ho parlato di sviluppatori, quindi, al plurale, ma al momento al progetto si sa che ci lavora soltanto una persona (quello che ha effettuato l’annuncio, che ne è anche il “proprietario”), mentre quattro anni fa furono molti di più i coder che da AROS passarono ad Anubis-OS.
Non si sa che fine abbiano fatto gli altri, e considerato il lavoro immane che c’è dietro, non credo che una sola persona, per quanto abile, possa arrivare molto lontano. Tutt’altro.
D’altra parte che il progetto risulti decisamente ridimensionato rispetto al passato lo si evince anche dalla scelta di avvalersi di un kernel derivato da Android (che a sua volta arriva da Linux, anche se di recente vi è nuovamente confluito), di supportare esclusivamente le ultime due versioni dell’architettura ARM, restringendo anche l’insieme di dispositivi su cui dovrebbe girare (Raspberry Pi e Beagleboard in primis).
Rimangono, dunque, forti dubbi che tutti gli sforzi (ancora nulli, visto che non c’è nemmeno una riga di codice) possano portare a qualcosa di concreto, che sarà utilizzabile in futuro, anche remoto.
D’altra parte nemmeno il nome lascia ben sperare, visto che Anubi (Anubis in inglese) era il dio della morte egizio, e le ombre che ammantano il progetto non possono, quindi, che richiamarne alla mente altri (Amithlon il più famoso) la cui sorte è stata tutt’altro che gloriosa.
Rimane, in ogni caso, la questione più importante: a chi dovrebbe/potrebbe essere utile? A una comunità Amiga che è già lacerata in lotte fratricide fra AmigaOS 4, MorphOS, e AROS? Come si può pensare che venga accettato Linux sul quale non gira niente del genere, ma soltanto un surrogato delle API di AmigaOS?
Il target non può, quindi, che essere un altro. Quale, non si sa…
