Raffaele ha scritto:paolone ha scritto:Raffaele ha scritto:
Scusate ma che esperienza Amiga sarebbe questa?![]()
Esattamente lo stesso tipo di esperienza che stanno provando con gioia tutti gli utenti Apple, da quando arrivò MacOS X. Chiedi loro se tornerebbero al classic (che pure aveva i suoi fan, come AmigaOS 1-2-3) e vedi cosa ti rispondono.
Non posso far a meno di chiedere (indirettamente) a Paolo: ma allora non avrebbe avuto MOLTO più senso un progetto come Anubis? O anche lo stesso MorphOS, se solo abbandonasse il vetusto Exec e i vetusti PPC?
Dalla 7 alla 9 sono andati un po' meglio ma sempre un sistema operativo semplice e multitasking cooperativo era, e se si sono rivolti ad un BSD per fare MacOS X è perché o erano troppo pigri, o non erano capaci di far evolvere l'OS, o gli piaceva la pappa pronta fatta da altri e disponibile gratis...
Analisi abbastanza superficiale. I problemi di evoluzione dello "spaghetti code" come da te definito, sono all'incirca gli stessi che ci sono a far diventare Exec un kernel del 2011... se vuoi tenere la compatibilità ASSOLUTA non ci sono santi, certe cose non le puoi aggiungere all'OS.
Raffaele ha scritto:paolone ha scritto:Che importanza ha se 'sotto' c'è il kernel monolitico di Linux [...]
Le tue parole fanno a cazzotti con quanto hai detto nel tuo intervento precedente:paolone ha scritto:Non è escluso che in futuro io possa preparare anche una versione 'custom' di Icaros [...].[/b]
Se tu fai fare tutto a Linux nascosto nel profondo del SO, mi dici che AROS è?
Qui in effetti mi sento di straquotare... alla fine stai usando Linux, l'unica comodità è di poter tenere una sola macchina senza "muletti" e switch/alimentazione/ecc.
Per fare evolvere AROS devi trovare programmatori in gamba che gli diano quelle cose che Linux ha, e AROS/Amiga no, come la memoria protetta e la multiutenza, cambiando il codice ORIGINALE di AROS.
Imho era meglio partire con delle basi pulite e tentare l'approccio della sandbox (specie con le cpu di oggi, un core può tranquillamente gestire un vecchio kernel non smp).
A me non interessa che si mantenga la compatibilità estrema con le API AmigaOS, a cui non è facile aggiungere queste funzioni extra...
Ecco appunto, si parla di "look and feel", non solo "look".
IMHO per me si può deprecare TUTTA la vecchia struttura di AmigaOS compreso il microkernel (quello che chiamiamo tale) basato su EXEC, purché il nuovo AROS mi dia la stessa snellezza di codice, e facilità d'uso del vecchio AmigaOS, ma la soluzione adottata deve essere nuova ed originale e soprattutto NATIVA di AROS.
E poi però ti scordi la velocità di Amiga... che non è dovuta alla bravura dei programmatori (anche Amiga OS3.0 era pieno di spaghetti :D), ma semplicemente alla "rinuncia" a certe caratteristiche: memoria condivisa, prestazioni record, ma crash a go go e nessuna sicurezza su informazioni riservate.
Quello che l'amighista rifiuta di ammettere è che i kernel unix sono nati e cresciuti in ambienti di ricerca (università), e sono STUDIATI per fare le cose NEL MODO MIGLIORE. E hanno 10000+ funzionalità rispetto a un kernel di 26 anni fa (Exec).
Se si vedono rallentamenti, non è perché è "robaccia pachidermica", come si dice a sproposito qui. Semmai essi sono dovuti alla mole sempre maggiore di dati che i PC devono gestire e al gap sempre maggiore tra componenti elettroniche (RAM, cache, ecc.) e meccaniche (gli HD ormai evolvono solo in capienza).
Mettete mano a un Macbook Air (ma anche un PC con Win7) con SSD e non rimpiangerete la sensazione amigosa di cliccare su un'iconcina e vedere un programma pronto all'uso un secondo dopo... con la differenza che quel programma gestisce una quantità di dati 1000 volte superiore a quanto si faceva con macchine da 4-16 mega negli anni novanta.
Altro che pachiderma, il kernel carica quello che deve quando deve, e non spreca un byte di spazio (poi semmai la colpa è di applicazioni fatte coi piedi).