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…
Le differenze di filosofia sono dovute essenzialmente al fatto che nel 1985 un amiga doveva accontentarsi di un 68000 e poche centinaia di KB di Ram mentre una Workstation Unix poteva spaziare parecchio più in là (all’incirca Dual 68020 e qualche MB di Ram di base) quindi era cosa buona e giusta sfruttare quelle caratteristiche, nessuno si scandalizzava per questo.
Nel 2012 i tempi sono cambiati: un comune pc o sistema arm spinge abbastanza da permettere l’adozione di filosofie più complesse se necessario senza che l’utente percepisca alcun che.
Chi conta è l’utente, non il programmatore perchè è il primo che rappresenta la maggioranza che può portare soldi e permettere quindi la ripresa degli investimenti in modo massiccio, il secondo invece deve solo dimostrare di saper rendere onore al nome che porta e fare tutti i salti di qualità e gli adattamenti mentali e filosofici che servono per affrontare i cambiamenti che via via si rendono necessari.
Comunque visto che non riesci a dormire la notte sul problemone dei volumi, te lo spiego in tre frasi perchè non ne servono molte altre.
– In amiga abbiamo le partizioni dei dischi (AmigaOS: Work:) che puntano a delle “cose” chiamate DHx:
– Su windows abbiamo le partizioni (C: D: E:…) che puntano a “cose” chiamate physical device.
– Dal momento che la cosa importante non è sottostare ad una filosofia fine a se stessa ma replicare la funzione offerta, da unix viene una cosa vecchia come il cucco ma che svolge esattamente la stessa funzione (anzi fa molto di più ma per amiga basta questo): il link simbolico.
Tadaaaa… Complicato vero ? Solo per chi non ci vuole riuscire.
La cosa divertente è che solo per gli integralisti della piattaforma (da stadio e “controcampo”) Amiga os è un mondo a se, ma per tutti gli altri questo benedetto sistema è un subset di unix stesso o un qualcosa che però vi si ispira, traendone idee e reimplementando funzionalità (ovvero ai tempi è stato fatto esattamente quello che dico io adesso ma in senso contrario)
Le API di AmigaOS sono disponibili, e idem quelle di Unix/POSIX, per cui hai la possibilità di fare un bell’elenco comparativo in cui dimostri che uno è un sottoinsieme dell’altro, oppure ne evidenzi “l’ispirazione”.
Quanto ai volumi, se avessi avuto modo di studiare il commento al mio precedente articolo in cui ne parlavo, avresti già capito che la soluzione che proponi coi link software non consente di implementarli. Esempi in merito ne ho forniti.
Infine il fatto che vi fossero poche risorse a disposizione per le macchine Amiga non ha nulla a che vedere con la struttura e l’implementazione di AmigaOS. Poi che nel 1985 circolassero workstation multiprocessore (quali, poi?) che significa? Dove vorresti arrivare?
Al limite, come peraltro hai affermato prima, avrebbero potuto selezionare un sottoinsieme di API di Unix per realizzare AmigaOS, ma… così non è stato.
Dunque non capisco che c’entri (tecnicamente) questo discorso che hai tirato fuori con la struttura di AmigaOS. Puoi fornire dei dettagli più precisi? Degli esempi? Grazie.
Oramai Amiga è morta, e con lei anche il suo s.o.
Mi dispiace, certo, ma la vita è così.
Nessuna comunità potrà mai far resuscitare in modo decente l’ Amiga OS, sia perché richiede un sacco di tempo, sia perché manca in seno alla comunità, un leader conclamato, o un azienda, che detti a TUTTI le linee guida.
A parte altri discorsi, perché Linux è sopravvissuto ? Perché c’è Torvald che aveva (ha) la capacità di imporsi su tutti e in parte coadiuvato da Stallman che aveva la stessa funzione anche se in ambito diverso. Sebbene in seno agli sviluppatori linux ci siano menti del calibro di Alan Cox, Andrew Morton, Ulrich Drepper, e tanti altri che non conosco, essi non si sono mai più di tanto messi frà le ruote nelle decisioni di Torvalds… certo, alcune volte ci sono state diatribe ed hanno portato avanti il loro albero di sviluppo, ma nessuno di essi si è sognato di fare un fork indipendente del kernel.
Lo stesso dicasi di *BSD… nonostante la sua scarsa diffusione, è comunque un progetto di successo per lo stesso motivo, ossia un piccolo gruppo di sviluppatori dove le decisioni principali sulle linee guida, giuste o sbagliate che siano, sono portate avanti da un ancora più ristretto numero di persone, a cui tutti si adeguano.
Questo, purtroppo e me ne dispiaccio, non lo vedo nella community di Amiga,.
E questa è la ragione della frammentazione che ne ha decretato la morte.
@Sisko212: il problema di AmigaOS è che non è opensource
qui le uniche che hanno fatto ( e stanno facendo ) scelte sbagliate, sono le aziende che ci campano, speculando sui nostalgici e spremendoli a colpi di 3000-4000 euro alla volta
un leader non potrà mai esserci se non c’è una base da cui partire
se Amiga rinascerà sarà sotto il nome Aros
la settimana scorsa ( sull’onta dell’altro articolo ) mi sono messo a cercare un pò in rete e mi sono imbattuto in un forum di amighista, dove l’autore di questo articolo e un altro utente ( che scriveva inglese, quindi un forestiero ) discutevano animatamente su alcune scelte di varie aziende legate al mondo Amiga
tramite quel “battibecco” sono venuto a conoscenza del fatto che la stessa Hyperion sta portando a più non posso librerie e codici vari dal mondo linux
no dico, scherziamo??? iniettare le solib in AmigaOS? e allora che rimane di Amiga? se devo scrivere un software QT o GTK, faccio prima a farlo sotto Linux
del resto, mi pare di capire, che i benefici di un’eventuale porting non sono chiari nemmeno ad Hyperion, tant’è che portano quello che gli sembra più utile e promettente, ma senza avere una strategia chiara su cosa portare e come
Il punto di vista di Hyperion su Shared Object & company, dovrebbe essere questo:
http://blog.hyperion-entertainment.biz/?p=481
Era su Zap (che rivista ragazzi!) che c’erano le immagini dei giochi su Amiga? Ricordo ancora con nitidezza il mio stupore nel vedere quella grafica a quei tempi, altro che il mio vecchio C64!!!..
A parte queste note giurassiche, penso che personaggi come l’Amiga e il C64 appartengano a delle finestre temporali ben precise. Riesumarli, a parte gli emulatori ma anche qui ne abbiamo a tonnellate, non ha nessun significato. Oggi come oggi l’hardware ma anche l’esigenza e le aspettative sono ben altre.
Per il vecchio ci sono gli emulatori, meglio sforzarsi a inventarsi nuove cose. D’altronde non fecero così a quei tempi?
(c’è una nuova generazione di captcha?!?)
@andres: in effetti la fanno sembrare come una cosa positiva, ma l’unico vantaggio è di non dover caricare esplicitamente le librerie condivise ( ma mi pare che versioni recenti di amigaos permettevano comunque di evitare questo step, nonostante non supportassero gli shared objects )
ma i problemi sono relativi a cosa viene portato e come, ovvero librerie linux prese “di peso” e ficcate in un ambiente completamente diverso
ad esempio i famosi datatypes non vengono minimamente usati da queste librerie
è giusto la prima cosa che mi è venuta in mente, ma credo ci siano altri handicap
in pratica porteranno pezzo per pezzo l’userland linux in amigaos? e allora perchè usare amigaos al posto di linux? non credo bastino icone di forme differenti per fare la differenza
@Sisko212
“Oramai Amiga è morta, e con lei anche il suo s.o.”
Amiga è morta perchè i suoi utenti la vogliono così. L’unica verità è che Volere è Potere e qui semplicemente non si vuole.
Apple c’ha provato a far evolvere MacOS Classic poi un bel giorno ha capito che si doveva guardare avanti, tagliare col passato, salvare il salvabile e adesso capitalizza più di uno stato del terzo mondo (italia compresa -__-).
@alex
“no dico, scherziamo??? iniettare le solib in AmigaOS? e allora che rimane di Amiga? se devo scrivere un software QT o GTK, faccio prima a farlo sotto Linux”
Dopo tante scelte scellerate quella è una delle poche di buon senso che hanno avuto. L’alternativa sarebbe stata non avere neanche quel poco che c’è adesso ma del resto piace così. A fare le vittime ci si prende gusto.
@CdiMauro
Quale credi che sia stato il background culturale degli sviluppatori di amiga os ? Un altro amiga os sbarcato dal futuro ?
Qui trovi alcuni spunti http://lkml.indiana.edu/hypermail/linux/kernel/9907.1/0381.html
“Quanto ai volumi, se avessi avuto modo di studiare il commento al mio precedente articolo in cui ne parlavo, avresti già capito che la soluzione che proponi coi link software non consente di implementarli. Esempi in merito ne ho forniti.”
Se tu avessi letto ciò che ho scritto io avresti già capito che tutto il progetto si regge su dei layer che si occupano di tradurre un modo di fare in un altro col fine ultimo di fornire la cruda funzionalità all’utente. Se poi il programmatore deve tornare a scuola ed evolversi sono fatti suoi: nella peggiore delle ipotesi si troverà la versione linux di java e lavorerà attraverso quello così non avrà più da preoccuparsi di niente.
“Poi che nel 1985 circolassero workstation multiprocessore (quali, poi?) che significa? Dove vorresti arrivare?”
Forse che le workstation unix nel 85 (quali
? Apollo ti dice niente ?) erano un tantino più potenti di un amiga per cui, mancanza di potenza da una parte e scelte commerciali dall’altra imponevano la creazione di qualcosa che traesse spunto da unix senza poterlo essere. Guarda caso TripOS era proprio quella roba lì.
@alex: sei il benvenuto
Senza contare che stanno lavorando anche su QT che con quei processori sarà un macigno da gestire.
Rettifico quanto detto. Ho dato un’occhiata su wikipedia e mi sembra che sia vivo e vegeto, versioni 4.0 e 4.1.
Si può fare un paragone con PhospurOS, un tentativo di resuscitare BeOS usando il kernel di Linux e X. Secondo i suoi fautori era una scelta molto più realistica di quella di OpenBeOS (oggi Haiku) di riscrivere l’intero sistema, o quantomeno si poteva usare come transizione nella riscrittura di singole parti del sistema.
Sono arrivati a rilasciare una alpha con parte dell’Interface Kit di BeOS riscritto e un paio di demo (e nient’altro). Ma la morale della favola è che l’ennesima distro di Linux con un po’ di belletto sopra non interessava a nessuno, e PhospurOS è morto, mentre Haiku galoppa (ok, trotta) verso una quarta alpha con un decente livello di usabilità.
@Sisko212: sono della stessa opinione. Un progetto con una guida ha molte più possibile di andare avanti senza perdere tempo con eccessive discussioni.
@alex: mi fa piacere vedere che non ti fermi ai pezzi e ai commenti, ma fai delle tue ricerche per appurare come stiano le cose. Ovviamente condivido le tue valutazioni. ;)
Riguardo alle librerie, non vedo nessuno svantaggio rispetto agli shared object, e ti spiego velocemente il perché. Se alla tua applicazione serve una funzione racchiusa in uno shared object, prima o poi dovrai caricare il suo eseguibile, cercare la funzione, ricavarne il puntatore e usarlo. Con una libreria Amiga puoi fare lo stesso, con la differenza che tutti i simboli sono già noti a compile-time, e non devi cercare nulla; inoltre puoi anche caricarla quando ti serve, e chiuderla quando hai finito (e se non c’è nessun altro programma che la usa, il s.o. la rimuove dalla memoria).
Anche con le librerie si può mettere in piedi facilmente un sistema di plug-in, come peraltro è stato fatto in passato (qualcuno ricorda le librerie di compressione XPK?).
Insomma, non c’è nessun motivo per cui su AmigaOS si dovrebbe fare a meno delle librerie. Tant’è che si sono SEMPRE usate.
Gli shared object sono arrivati soltanto con AmigaOS 4, quindi dopo il 2000, da gente che “casualmente” lavorava alle conversioni di giochi per Linux. E infatti il vero motivo per cui sono state introdotte è chiaro, e te lo riporto subito dopo.
@andres: il punto di vista di Hyperion è chiarissimo, tant’è che l’hanno anche scritto nel link che hai fornito. Te lo riporto:
“Shared Objects are primary intended for porting of programs from other systems. Any sufficiently large or complex program from Linux or Windows will, in one way or the other, rely on shared code, for various reasons. Usually, this type of code sharing does not translate very well (if at all) to the AmigaOS shared library model. Using shared objects for such projects is almost mandatory.”
@[D]:
Con la differenza che Apple non è andata in fallimento come Commodore, e che Amiga Inc., Hyperion, & compagnia non sono minimamente paragonabili a Apple nemmeno quando questa decise di realizzare OS X (che poi all’incirca è lo stesso periodo).
Ormai AmigaOS è un prodotto di nicchia per i pochi affezionati che ancora vogliono usarlo.
Amiga, e AmigaOS in particolare, ne ha sempre fatto a meno. Non vedo perché si dovrebbe importare roba aliena che è l’unica cosa che hanno saputo fare gli altri s.o. per implementare certe funzionalità.
Perché non dovrebbe valere il contrario? AmigaOS ha messo a disposizione uno stupendo strumento che altri avrebbero potuto copiare, no? Hanno preferito fossilizzarsi su scelte vecchie quanto il cucco.
Scelte che non vogliamo condividere.
Il background è lo stesso per tutti, e mi pare ovvio che sia così.
Quando ho studiato s.o. all’università si studiava Unix; quando ho sostenuto l’esame, però, la mia tesina parlava di Exec…
Le prime 5 parole sono sufficienti a capire che chi ha scritto quella mail ha delle idee molto confuse sull’argomento.
E sia chiaro: non è facendo una rapida ricerchina cercando qualche paginetta scritta da chissà chi, che puoi dimostrare la tua assurda tesi sulla similitudine fra AmigaOS e Unix, parlando addirittura del primo come sottoinsieme del secondo.
Questo: http://www.pagetable.com/?p=193 è sufficiente per smontare il link che hai fornito. Fra i commenti trovi anche uno degli autori di Tripos…
Nel frattempo aspetto ancora una bella tabella comparativa fra le API di AmigaOS e quelle di Unix, che dimostri la tua “allegra” tesi.
Dovresti conoscermi ormai: è perfettamente inutile cercare di ribaltare la frittata cambiando discorso.
Prima hai fornito la tua soluzione basata sui link software per implementare i volumi (ti ricordo che ce ne sono di 3 tipi, come ho già scritto nell’altro pezzo), per giunta cercando di canzonarmi.
Adesso o mi DIMOSTRI che funziona, oppure sei soltanto un pinco pallino qualsiasi che non sa nulla sugli argomenti di cui parla e pretende di imporre le sue strampalate idee agli altri.
Poi che un’ALTRA soluzione sia quella di implementare un layer per far comunicare i due mondi è ovvio, ne avevamo già parlato in precedenza, e l’ho messo per iscritto anche in quest’articolo. Ma il lavoro da fare è tanto, e pure questo l’avevo già detto.
Certo, fa un po’ riflettere il fatto che sia complicato realizzare un semplice layer quando AmigaOS e Unix sono così simili, e addirittura il primo sarebbe un sottoinsieme del secondo.
Ma sono sicuro che quando hai avrai DIMOSTRATO questa tua tesi, la potrai esporre agli sviluppatori di Anubis-OS, che così in pochissimo tempo riusciranno a realizzare il loro progetto. Perché è evidente che a loro mancano conoscenze adeguate in materia, che tu, invece, possiedi…
Quindi non sai ancora dirmi TECNICAMENTE cos’è che abbia portato ad AmigaOS a essere così. Non avevo dubbi…
Cosa non ti è chiaro del fatto che se fosse stata una mera questione di scarsezza di risorse hardware, avrebbero in ogni caso potuto prendere Unix, togliere un po’ di roba, e usarlo come base per AmigaOS? Visto che siamo ai “ti dice niente”, Minix (come obiettivi, struttura e filosofia) ti dice niente?
Sì, le workstation Apollo le conosco bene, visto che vi ho lavorato un po’ di anni all’università. Ma non capisco ancora cosa c’entrino TECNICAMENTE col discorso che hai fatto prima. Anche qui, ti avevo chiesto maggiori dettagli e qualche esempio per capire la tua tesi, ma… mancano ancora. Stranamente…
Guarda caso TripOS NON era Unix né tanto meno AmigaOS era basato su TripOS (vedi il link che ho fornito).
Poi: http://www.troise.net/boliboop/download/osgenealogy/osgenealogy-1.0.0.svg
Guarda dov’è Tripos e dove si trova Unix…
Comunque, anche qui, se vuoi farmi una comparativa fra Tripos e Unix per dimostrare che Tripos è “quella roba lì”, accomodati pure…
Per chiudere, quand’è che la smetterai con le tue tesi assurde su argomenti che sconosci completamente? Non è che devi scrivere per forza se semplicemente l’argomento t’interessa. Sì, nessuno te lo impedisce, ma il buon senso dovrebbe quanto meno impedirti di parlare di cose che a te sono del tutto aliene. Chiaro?
@biffuz: infatti alla fine è ciò che sostengo da tempo. Gli appassionati di determinate piattaforme adorano QUELLE piattaforme e non dei surrogati imbellettati con roba a loro del tutto aliena. Per questo poi, puntualmente, falliscono.
Poi non posso che ripetere ancora una volta ciò che anche altri hanno riportato: se alla fine devo usare lo stesso Linux, tanto vale scegliere una delle innumerevoli distro già disponibili, con tutto il loro parco software.
Ma se voglio usare AmigaOS, beh, voglio quello e non una sua falsa copia…
@[D]
“Chi conta è l’utente, non il programmatore perchè è il primo che rappresenta la maggioranza che può portare soldi e permettere quindi la ripresa degli investimenti in modo massiccio.”
Non appena su AD arriva l’articolo divulgativo, ecco che rispunta il resident troll; non avevi molto da dire sugli articoli circa le legacy x86 di Cesare, vero?
Ad ogni modo questa è un’opinione, a dir poco, discutibile.
Se si sta sviluppando un OS di cui nessuno ha mai sentito parlare, come minimo vai a cercare quante più braccia per aiutarti. Gli utenti (coloro disposti a testare il tuo software) li cerchi quando sei al punto di avere qualcosa di presentabile.
In questo momento, se io volessi semplicemente vedere questo AnubisOS, non saprei cosa fare.
Concordo, ma non per le offese: dare del troll non si può.
Per cui, cortesemente, rimaniamo in ambito di una civile discussione (è dura, lo so). Grazie. :)
Il target? Questi mi sembrano più progetti molto amatoriali, fatti da chi ha molto tempo libero e si diverte a giocare al piccolo Dr. Frankenstein. Non è detto che sarebbero di gran aiuto entrando in altri progetti, mentre invece non è poi così male che la gente sia libera di creare e di battere la sua strada; infondo il tempo è loro e nessuno obbliga nessuno ad usare quel che tirano fuori o sbattere la testa contro il muro in attesa che concretizzino qualcosa. E poi chissà? Di fronte a problemi nuovi, potrebbero sviluppare qualche algoritmo o qualche tecnica che potrebbe essere utile anche altrove, specialmente se è opensource.
@Flare: sempre di target si tratta e comunque bisogna guardare le cose in prospettiva, pensando al futuro
pure linux era usato da 10 persone quando uscì, il resto è storia nota
quello su cui gli amighisti insistono, è il fatto di avere per le mani una superiore architettura, per la quale non sono disposti a scendere a compromessi
in effetti dover scomodare file system e stack di rete solo per comunicare dati tra due applicazioni locali usando socket AF_UNIX, è un tantinello esagerato
che poi i computer di oggi sopportano ogni tipo di bestialità a livello software, non ci autorizza a perseverare nell’errore
l’unica cosa sensata è quella di prendere in prestito codice netbsd, in modo da accelerare lo sviluppo di amigaos
il problema è che hyperion e soci non sono minimamente interessati a migliorare amigaos, preferendo contare sulla quantità piuttosto che sulla qualità
se un sistema nasce con una certa architettura, ibridarlo è una cosa assai stupida ( ma questo vale per qualsiasi software ), mentre cercare di trapiantare le feature di tale sistema su di un altro, è ancorpiù assurdo
alla fine i Frankenstein non portano vantaggi
ormai il treno è perso … AmigaOS non puo’ piu’ competere ma neanche alla lontana.
ma scusate ma oggi giorno che vantaggio puo’ venire dall’ utilizzo amigaOS?
ditemi 1 cosa che si puo fare sull’amiga e che su linux/macosx non si possa fare (che abbia senso).
a forza di parlare di shared library e tecnicismi avete perso il senso del perchè si usa un os.
Nostalgia? Hobby? L’abbiamo detto e ripetuto già parecchie volte.
AmigaOS ha alcune caratteristiche interessanti (anche queste già discusse), ma il problema più grosso è che gliene mancano alcune fondamentali (protezione della memoria, resource tracking, SMP in primis) per poter diventare “mainstream”.
Non basta un s.o. leggerissimo, reattivissimo, e che ti fa il boot in una manciata di secondi. OGGI serve anche altro.
Ma perché è così difficile aggiungere le caratteristiche che mancano ad AmigaOS, o ad AROS, per farlo diventare un s.o. “mainstream”
AmigaOS 4 supporta già internamente resource tracking e una parziale protezione della memoria, ma non vengono abilitate per una questione di retrocompatibilità, che verrebbe meno.
Non credo che servirebbe poi molto lavoro anche per il resto, ma il deterrente più grosso rimane l’attentato alla retrocompatibilità.
AROS, invece, ha un altro problema: non ha ancora completato l’implementazione di tutte le API di AmigaOS 3.1, più qualche altra cosa che si è resa necessaria (ad esempio Zune, l’implementazione di MUI).
So che gli sviluppatori già da anni hanno affrontato queste problematiche, con discussioni anche lunghe. Ma alla fine se non si completa il lavoro attuale ha poco senso cercare di fare questo grande passo.