Ennesimo articolo di cdimauro

[ShInKurO]

Francamente non ho idea di come sia implementato il kernel sulle varie architetture su AROS.

Ricordo che, lavorando al mio emulatore 80186 per Amiga, sono incappato in alcune parti del s.o./kernel che erano legate al 68000.

Comunque anche così era ed è possibile astrarre il kernel in modo da gestire indifferentemente qualunque processore. Si tratta di adattare alcune strutture riservate in base all'ISA. Poi il resto viene gestito in maniera del tutto trasparente.

Quindi non vedo alcuna difficoltà per AROS.

Non era questo il senso della mia domanda: AmigaOS4 richiede l'MMU per funzionare, tutta la gestione della memoria è virtualizzata come nei sistemi moderni. AmigaOS4 utilizza gli slab.
MorphOS se non sbaglio ha anch'esso gestione della memoria virtualizzata, e dunque richiede MMU per funzionare.
Se AROS su 68k non richiede MMU significa che la sua gestione della memoria non è virtualizzata, ma assegnata fisicamente, come in msdos, e non c'è bisogno di dilungarci su queste cose perchè sia io che te sappiamo benissimo cosa significhi una simile roba nel 2012.

La seconda domanda, cioè se il kernel 68k è lo stesso che gira su x86 e x64 era appunto per capire se almeno nelle altre architetture AROS utilizza la MMU o meno, se la risposta è la seconda va da se che il kernel di AROS è moolto indietro rispetto a quello di OS4 e MOS.

Sia MOS quanto OS4 utilizzano la MMU anche per altri scopi, per esempio OS4 la impiega anche per l'emulazione 68k.

Perché l'MMU con Unix è il minimo indispensabile per riuscire a risolvere elegantemente alcune problematiche (in particolare sull'uso del fork; che, fortunatamente, NON c'è mai stato su AmigaOS).

Non è fork che importa, quanto invece la gestione virtualizzata degli indirizzi della memoria...

Non so quanto sia vero questo. A naso dovrebbero semplicemente prender possesso dell'hardware, una volta che la scheda PowerPC è stata inizializzata dalla expansion.library, richiamando l'apposito entry-point della scheda.

No funziona così:

-Kickstart3.1 inizializza tutto e poi va a cercare la startup-sequence su disco;
-la s-s contiene una chiamata a un programma che va a mappare in ram (come area rad) tutto il nuovo kickstart/kernel;
-il programmino softresetta l'amiga;
- il nuovo kernel parte;

Identica situazione che avveniva quando mappavi ks1.3 su macchine con 2.0+.

[cdimauro]

Francamente non ho idea di come sia implementato il kernel sulle varie architetture su AROS.

Ricordo che, lavorando al mio emulatore 80186 per Amiga, sono incappato in alcune parti del s.o./kernel che erano legate al 68000.

Comunque anche così era ed è possibile astrarre il kernel in modo da gestire indifferentemente qualunque processore. Si tratta di adattare alcune strutture riservate in base all'ISA. Poi il resto viene gestito in maniera del tutto trasparente.

Quindi non vedo alcuna difficoltà per AROS.

Non era questo il senso della mia domanda: AmigaOS4 richiede l'MMU per funzionare, tutta la gestione della memoria è virtualizzata come nei sistemi moderni. AmigaOS4 utilizza gli slab.
MorphOS se non sbaglio ha anch'esso gestione della memoria virtualizzata, e dunque richiede MMU per funzionare.
Se AROS su 68k non richiede MMU significa che la sua gestione della memoria non è virtualizzata, ma assegnata fisicamente, come in msdos, e non c'è bisogno di dilungarci su queste cose perchè sia io che te sappiamo benissimo cosa significhi una simile roba nel 2012.

Bene. AROS non richiede espressamente l'uso dell'MMU, da cui le conseguenze che riportato.

La seconda domanda, cioè se il kernel 68k è lo stesso che gira su x86 e x64 era appunto per capire se almeno nelle altre architetture AROS utilizza la MMU o meno, se la risposta è la seconda va da se che il kernel di AROS è moolto indietro rispetto a quello di OS4 e MOS.

Il kernel è lo stesso, ma si appoggia a un device per gestire l'MMU. Se è presente, è possibile sfruttarla, a seconda delle capacità che offre, per implementare le stesse cose che offrono MorphOS e AmigaOS 4.

Nel documento di cui ho fornito il link se ne parla in maniera dettagliata.

Sia MOS quanto OS4 utilizzano la MMU anche per altri scopi, per esempio OS4 la impiega anche per l'emulazione 68k.

Immagino che sia per il trapping dell'accesso all'hardware dei chip custom, in modo da intercettare gli accessi, emulando quanto possibile e sollevando un'eccezione quando la richiesta non è assolutamente gestibile.

Cosa fattibilissima anche con AROS, posto che la piattaforma ne fornisca il supporto. Ma, come sai, Janus-UAE è ancora in lavorazione; non credo che offra un supporto simile, al momento, e Paolo mi correggerà eventualmente.

Perché l'MMU con Unix è il minimo indispensabile per riuscire a risolvere elegantemente alcune problematiche (in particolare sull'uso del fork; che, fortunatamente, NON c'è mai stato su AmigaOS).

Non è fork che importa, quanto invece la gestione virtualizzata degli indirizzi della memoria...

La gestione virtualizzata degli indirizzi di memoria è ovviamente l'applicazione più nota e utile, ma non è la sola.

L'MMU è fondamentale per forkare i processi (duplicando data segment e stack segment, mantenendo però il code segment di padre e figlio), e nel caso degli shared object per mappare il data segment "privato" del processo che ne fa uso.

Non so quanto sia vero questo. A naso dovrebbero semplicemente prender possesso dell'hardware, una volta che la scheda PowerPC è stata inizializzata dalla expansion.library, richiamando l'apposito entry-point della scheda.

No funziona così:

-Kickstart3.1 inizializza tutto e poi va a cercare la startup-sequence su disco;
-la s-s contiene una chiamata a un programma che va a mappare in ram (come area rad) tutto il nuovo kickstart/kernel;
-il programmino softresetta l'amiga;
- il nuovo kernel parte;

Identica situazione che avveniva quando mappavi ks1.3 su macchine con 2.0+.

OK, ma si poteva sfruttare tranquillamente l'expansion.library, quindi il famoso Autoconfig (funzionalità Autoboot), per fare tutto subito, senza nemmeno far partire AmigaOS.

[cdimauro]

L''ho scritto anch'io che poi ognuno può fare quello che vuole (sull' "installare legalmente" NON sono d'accordo con te).

Ho visto adesso che avevi aggiunto quest'ultima parte che ho evidenziato.

Non mi sembra che ci siano gli estremi per impedire l'installazione di qualsiasi s.o. DOPO che la macchina Amiga sia stata venduta.

Ciò emerge chiaramente sempre dal documento che hai fornito. Sono vincoli che riguardano le Amiga Parties, ma non l'utente finale.

[ShInKurO]

Il kernel è lo stesso, ma si appoggia a un device per gestire l'MMU. Se è presente, è possibile sfruttarla, a seconda delle capacità che offre, per implementare le stesse cose che offrono MorphOS e AmigaOS 4.

Nel documento di cui ho fornito il link se ne parla in maniera dettagliata.

Aria fritta
Nel senso che la documentazione AROS è tutto fuorchè affidabile, basta andare nella ml degli sviluppatori per trovare questo (risalente a giugno di quest'anno):

Memory fragmentation is a HUGE issue in AROS - on limited memory
systems. It's just masked by the fact that most AROS ports are running
on systems with enormous quantities of memory.

Keep in mind that most 68k Amigas DO NOT HAVE an MMU in their processors. This includes the new N68050 softcore in the NatAmi. Let's keep the MMU requirements limited to debug builds if possible on 68k. As for the other architectures that do not have to worry about backward compatibility, do what you will. It should be on the roadmap for ABI v2 at the very least for them.

Dunque va da se che AROS non implementerà una normale gestione della MMU per mooolto tempo...

Cosa fattibilissima anche con AROS, posto che la piattaforma ne fornisca il supporto. Ma, come sai, Janus-UAE è ancora in lavorazione; non credo che offra un supporto simile, al momento, e Paolo mi correggerà eventualmente.

Tu hai molta fiducia in AROS, ma guarda che non è così che funziona il suo sviluppo. Lo sviluppo di AROS è di un relativo che Albert Einstein se fosse qui potrebbe utilizzarlo come esempio per la teoria della relatività generale. Oggi galoppa, domani è fermo, in modo del tutto random, non c'è nessuno che si prende carico di un modulo se qualcun'altro decide di andare in mountain bike in giro per il mondo invece che sviluppare.
Per farti un esempio su MorphOS MUI non vede aggiunte di codice da parte dell'autore originale da almeno 10 anni (a lui piace andare in mountain bike), ma questo non significa che il suo sviluppo si sia bloccato, anzi.
Stessa cosa su OS4 e la application.library, non si sente il suo autore da almeno 8 anni, ma il suo sviluppo va avanti (io però aspetto ancora arteffect nativo os4, visto che lo aveva già portato nel 2004...).

Prima che la gente si decidesse a fare quello che io scrivevo su tutti i forum per anni con OWB, vennero fuori 3 versioni distinte di OWB per ciascun sistema, e quella di AROS era mantenuta da un programmatore di cui poi non si seppe più nulla...boom, quella versione di OWB morì li, poi finalmente (dopo un paio d'anni) qualcuno si svegliò e decise che il mio bounty era accettabile e iniziò a lavorare correttamente (e il processo fu lungo, passando per "no il tuo bounty chiede trooooppe coseee").
Stessa cosa è accaduta per molti altri moduli su AROS e, se la perseveranza non è un'opinione, accadrà ancora.

E' una caratteristica intrinseca dello sviluppo di AROS l'anarchia e lo sviluppo senza seguire una linea guida stabilita precedentemente (per questo la documentazione sui siti è inutile, ogni giorno spunta il programmatore A e decide di implementare una cosa a modo suo), esattamente come su OS4 qualsiasi scemenza implementata rappresenta la resurrezione di cristo per i suoi utenti (io intanto mi sono laureato, ho trovato lavoro, mi sono trasferito, ho cambiato vita, ecc... ma la shell nuova ancora non si è vista...chiedere un workbench nuovo sarebbe avanguardia pura), e su morphos la cura per la UI è uguale a quella che avevamo su OS3.1 a partire dal 1995 fino al 1999 (le proporzioni della skin di default sono scandalose, e le altre skin sono assolutamente non professionali... insomma sembrano prese da aminet nel 1996 così da utilizzarle con sysihack e birdie).

Essenzialmente i programmatori fedelissimi di AROS sono 2 o 3, gli altri vanno e vengono.
Solo che questi 3 non vanno a toccare parti su cui non hanno mai lavorato (legittimo), quindi...

Il fatto che tu confidi sullo sviluppo futuro di AROS è praticamente paragonabile a quando gli utenti di OS4 esultano per aver avuto il supporto dell'ide sull'x1000: naif, solo che tu non lo sai perchè dal 1998 al 2008 non hai seguito la scena.
Le uniche cose certe su Amiga sono il passato e il presente; il futuro invece è di un relativo che fa paura, soprattutto per ciò che concerne lo sviluppo di AROS, le piattaforme sulle quali girerà OS4 e il suo workbench, e le skin e le icone di MorphOS.

[cdimauro]

Che lo sviluppo di AROS sia caotico non è una novità. I programmatori fanno quello che vogliono, perché è un progetto completamente libero.

Nonostante tutto, riesce ad andare avanti e a migliorare a vista d'occhio.

Penso anch'io che quella dei bounty sia una buona soluzione per convergere le energie su precisi punti del s.o., fornendo quindi una "direzione". Molte cose interessanti di AROS sono arrivate proprio dai bounty.

Comunque non ho una cieca fiducia. So bene che c'è un sacco di lavoro da fare, e alcune di quelle esposte prima sono mie idee di fattibilità. Quando... non si sa, appunto.

Ma non è il solo a trovarsi in certe condizioni, come hai descritto prima. Anche se dietro agli altri progetti c'è un'azienda, non è garanzia di affidabilità.

[Amiga Supremo]

Non mi sembra che ci siano gli estremi per impedire l'installazione di qualsiasi s.o. DOPO che la macchina Amiga sia stata venduta.

Nei termini contrattuali dell'accordo extragiudiziale tra AMIGA Inc. e HYPERION infatti le limitazioni si esprimono solamente in merito a "the software", come definito e formulato nel documento stesso, unitamente ai propri allegati e memorie.
Linux lo puoi installare benissimo SENZA problemi, per esempio e così infatti la sublicenziataria del marchio AMIGA, C=USA si è mossa.

Ciò emerge chiaramente sempre dal documento che hai fornito. Sono vincoli che riguardano le Amiga Parties, ma non l'utente finale.

Tralasciando il pregresso,
HYPERION è un'entità diversa ed estranea alle "Amiga Parties", però NEPPURE il proprio prodotto AmigaOS lo possono installare su macchine AMIGA.
La materia giuridica è sempre piuttosto complicata se non esiste un vero interesse economico.
Un tempo una limitazione simile esisteva anche per le macchine Apple e il suo OS; quì nel Ns. Paese però per esempio, i termini della licenza inerenti a questo discorso decadevano automaticamente, ricadendo nella valenza di clausole vessatorie, che nel Ns. ordinamento giuridico non sono tollerate (ma anzi vengono perseguite).

Esistono però anche gli accordi tra Paesi...

[cdimauro]

Hum. Mi sembra strano che le Amiga Parties non possano nemmeno vendere AmigaOS (fino alla 3.x).

Secondo i termini, non devono utilizzare i 4 marchi citati oppure la dicitura "Amiga operating system"), ma per il resto dovrebbero poterlo farlo (idem per AROS).

In ogni caso l'utenza è libera di fare ciò che vuole una volta acquistato il prodotto. Su questo dovremmo essere d'accordo tutti.

[Amiga Supremo]

Tutti per esempio sono liberi di circolare su un motociclo senza indossare il casco, oppure guidare l'automobile senza allacciare le cinture di sicurezza, oppure ancora scaricare dalla rete materiale protetto da diritti d'autore; il punto è però: E' legale tutto ciò?

[cdimauro]

Ma infatti la questione qui riguarda puramente la legalità.

In primis dal documento in oggetto non si evince nessun limite nei confronti degli acquirenti. Io posso comprare un accessorio Amiga, che ricade nei termini dell'accordo fra Hyperion e le Amiga Parties, per poi farci legalmente ciò che voglio, poiché tale accordo nulla preclude agli utenti finali, come al contrario fa Apple (ma anche Microsoft, ecc.) che hai citato prima.

Poi, come ho già detto, le Amiga Parties possono vendere / distribuire sistemi operativi su prodotti a marchio Amiga, purché non siano presenti i 4 marchi di cui Hyperion ha licenza esclusiva oppure la frase "Amiga operating system".

Il tutto, ribadisco, rimanendo strettamente nell'ambito della legalità.

[Amiga Supremo]

@ cdimauro
I soggetti giuridici di quell'accordo sono esclusivamente AMIGA Inc., ITEC LLC, AMINO DEVELOPMNENT CORPORATION e HYPERION ; quel documento dunque ha il proprio merito nel business, ovvero si esprime nel contesto delle attività commerciali o remunerative di queste aziende e loro eventuali derivate/licenziatarie.
Saranno poi le parti, se decideranno di farlo, a decidere di limitare o meno l'utenza, come nel caso che hai citato di Microsoft, per esempio.

"AMIGA PARTIES" è soltanto il nome di CHI vantando la PROPRIETA' delle licenze erogate ad HYPERION, ha diritto a riprendersi tutto in caso HYPERION vada in malora.
Idem per HYPERION, qualora gli "AMIGA PARTIES" dovessero soccombere sul mercato.
Tutto questo per l'ovvio motivo di contenere le dispersioni ed evitare escamotage tecnici come via di uscita dai rispettivi rapporti di legame.

Per quanto riguarda le Amiga Parties NON possono vendere / distribuire sistemi operativi su prodotti a marchio Amiga se questi "sono o somigliano a THE SOFTWARE, come esposto e definito nei memoriali e negli allegati al contratto di accordo stipulato tra AMIGA Inc (ITEC LLC, AMINO DEVELOPMNENT CORPORATION) e HYPERION", a prescindere dal NON utilizzo dei marchi di cui Hyperion ha ottenuto una licenza esclusiva.
E la stessa cosa ribaltata vale per HYPERION.

[cdimauro]

D'accordissimo sulla prima parte, ma non su quella finale, perché vale anche questo:

"the Amiga Parties may develop, market, license and sell Operating Systems that do not exibit a Substantially Similar Software Architecture (including without limitation AmigaDE and AmigaAnyehere (under such trademarks)), so long as such Operating Systems do not use the Exclusive Licensed Marks (ad defined below) or the phrase "Amiga operating system"

che, tra l'altro, è scaturito come precisazione del punto che hai riportato tu. Dunque, a mio modesto avviso, ha forza maggiore.

[marmotta]

Miiii ho scatenato un caso giudiziario! interessante pero'

In pratica se Amiga Inc. chiude il marchio va ad Hyperion? Non vorrei essere nei panni di C-usa....

Vice versa se hyperion chiude va tutto (AmigaOne, AmigaOs4 ecc..) ad Amiga Inc?

[Amiga Supremo]

Vice versa se hyperion chiude va tutto (AmigaOne, AmigaOs4 ecc..) ad Amiga Inc?

HYPERION è in possesso di licenze che però sono e restano comunque PROPRIETA' esclusiva di AMIGA Inc.

[cdimauro]

Esatto. Amiga Inc. non li ha mai ceduti.

@marmotta. Sì, ma gli accordi che le due società possono aver stipulato nel frattempo mantengono i loro effetti. Quindi Commodore USA non rischia nulla, anche perché mi sembra che abbia acquisito una licenza perpetua per il marchio Amiga.

In particolare, gli accordi stipulati in precedenza dalle Amiga Parties valgono ugualmente, anche dopo l'accordo con Hyperion, pur infrangendo alcuni di essi i termini dell'accordo, e potrebbero anche essere sfruttati per aggirare i paletti posti da Hyperion.

[Amiga Supremo]

@ cdimauro
Il vincolo circa i S.O. che le "Parti Amiga" possono sviluppare, commercializzare, concedere in licenza e vendere sistemi è la DIVERSITA' della loro architettura software sostanzialmente simile [inclusi, senza limitazione anche AmigaDE e AmigaAnyehere (sotto tali marchi)].

La condizione che per tali sistemi operativi non devono essere usati i marchi dati in licenza esclusiva e in ogni caso definiti nominalmente con la frase "sistema operativo Amiga" scaturisce unicamente dal NON POTER LEGALMENTE utilizzare liberamente ciò che è stato girato in forma esclusiva ad HYPERION; dipende dunque da un'altra clausola contrattuale definita nell'accordo.