Newsgroup: it.comp.os.amiga
Titolo: La faziosita' imperversaa fra i fan di Amiga...

 [snip]
by LjL
ljl...@tiscalinet.it

 Cos'aveva un Mac PPC a che vedere con un Mac 68k?
Cos'aveva un Mac 68k con un Mac68k di generazione successiva? A parte il 
processore, il paragone è praticamente lo stesso.
Solo per dire che l'esempio è sbagliato...
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

>> intera pagina con la recensione di AmigaOne.
Solo per precisare: si trattava di una news (per quanto "in primo piano",
rispetto a tutte le altre), non di una recensione. Per quella aspetto che
esca 'sto benedetto OS4 e che Virtual Works (o chi per lei) mi mandi un
esemplare in prova per qualche tempo, com'è prassi per tutte le recensioni
dell'hardware di PC Action.
--
p.bes
PC Action
vice caporedattore
deputy editor

 Bhč, un pň di propaganda non fa mai male...
ari-bhč.... diciamo che a quanto pare a qualcuno fa male ;-))
Fa male a chi sperava che Amiga Inc fallisse e che Amiga sparisse
completamente dal mondo informatico, a chi sperava che AmigaONE
non venisse mai commercializzato. Ormai a queste persone non gli resta
che "gufare" sperando che OS4 non esca mai, ma temo che avranno
un'altra brutta sorpresa ;-)))
-- 
bye bye
Claudio Marro Filosa

o e' faziosa appaio come il cattivo di turno... ;-)
Il crimine non paga....offre Ratman....
-- 
Giuseppe Gigante

Bhè, un pò di propaganda non fa mai male...
Oltretutto se e' apparsa la news su PC action non si puo' di certo
dire che Claudio menta. Non so quante siano le testate PC (di sicuro
se ne e' parlato nei forum Linux) ma almeno una c'e'.
Ah, che bello avere cosi' tanto tempo libero nelle proprie mani...
Luca
--
When Hell freezes over...
...I'll be snowboarding there too!!

nulla in comune, ne' per hw ne' per tipologia di prodotto.
No, però ha lo stesso OS. E rigirala come vuoi, ma per me AmigaOS4 *è*
lo stesso OS di quelli vecchi, almeno quanto MacOS 8 è lo stesso OS di
MacOS 7.
Intendiamoci, pure MorphOS dal mio punto di vista è lo "stesso OS"
(per quel che so di MorphOS), e idem per AROS.
Il mio ragionamento non implica che io "creda" in AmigaOS4 e non nelle
alternative. Credo in AmigaOS, che è quel sistema che ha un Workbench,
una shell che funziona con determinati comandi, un certo look and feel
(i menu *non* devono starmi tra i piedi quando non li voglio, per
dirne una), e tante altre cose pur soggettive quanto tu voglia
definirle soggettive.
by LjL
ljl...@tiscalinet.it

 Ah, che bello avere cosi' tanto tempo libero nelle proprie mani...
.... e di tempo ne deve avere molto, visto che riesce anche a
manipolare sapientemente attacchi nei miei confornti, arrivando ad
attribuirmi anche cose che non ho scritto io !! ;-)
Non c'è che dire, l'odio di certe persone non ha confini,
probabilmente con il killfile sperava di non essere scoperto, bha....


 di *tutte*) innovative rispetto anche agli OS mainstream di *adesso*.
Hai dimenticato arexx...
pur nei suoi limiti e difetti, e' una cosa di cui spesso sento la
mancanza  quando ho necessita' di integrazione fra applicazioni diverse
sui vari OS con cui lavoro giornalmente, senza dovermi imbarcare in
Visual Basic, Macro, OLE, ADO, e chi piu' standard ha piu' ne metta, per
risolvere piccoli ma fastidiosi problemi...

 wrote:

Non era mia intenzione elencare tutti i pregi di AmigaOS. Comunque,
ammetto che probabilmente non mi sarebbe venuto in mente, perché io
personalmente non l'ho mai usatomente...
Comunque sono d'accordo: *un* linguaggio di scripting "standard
enough" è un'ottima cosa.
A me piacerebbe anche un'altra cosa - forse è un po' un sogno.
Ci sono già un po' di interfacce grafiche "moderne" in cui il
programmatore non sta lì più di tanto a dire al computer che pixel
deve stare dove, ma si accontenta di spiegare la struttura
dell'interfaccia che vuole creare.
Io porterei questo concetto oltre. A me piacerebbe avere applicazioni
che funzionino sia da GUI sia da CLI, senza che il programmatore se ne
debba nemmeno accorgere. Il programmatore dovrebbe descrivere le
opzioni che mette a disposizione dell'utente, poi una engine (grafica
o testuale) dovrebbe preoccuparsi di dare a queste opzioni una "forma"
che sia adatta al mezzo di comunicazione adottato.
Il programmatore non dovrebbe dire cosa è una barra degli strumenti,
cosa è un menu e cosa una finestra di dialogo (o requester che dir si
voglia); dovrebbe dire "ci sono questi comandi possibili, tra cui
questo, questo e questo sono più importanti", e l'engine a questo
punto potrebbe decidere cosa mettere in un menu e cosa in una barra
degli strumenti, a seconda - ad esempio - della dimensione dello
schermo (abbiamo un 21" o lo schermo di un palmare?). Ovviamente
un'eventuale personalizzazione da parte dell'utente sarebbe la
benvenuta, ma anche qui, perché dev'essere l'applicazione a
implementare la logica di personalizzazione, e non un'engine del
sistema operativo?
Tra l'altro, riuscendo ad implementare efficacemente un sistema del
genere, si otterrebbe anche un linguaggio universale di scripting per
qualsiasi applicazione, senza averlo pagato (è sufficiente un'engine
pensata per "comunicare" con un file di testo).
by LjL
ljl...@tiscalinet.it


Tutto quello che hai detto, nei limiti del fattibile, sarà implementato 
in AROS tramite CABOOM, un component model correntemente in 
progettazione. Tra le varie cose sarà possibile impartire comandi alle 
applicazioni senza che le applicazioni debbano interessarsi minimamente 
di gestirli, semplicemente fornendo un'equivalente CLI della GUI, tutto 
a carico delle componenti dell'OS. Il programmatore si concentrerà sui 
cosa l'applicazione deve fare, il come farlo sarà quasi interamente a 
carico del SO, e tramite personalizzazioni anche a carico dell'utente.



wrote:

Questa notizia mi è benvenuta più o meno quanto quella dell'adozione
di Zune/MUI come interfaccia standard - andate avanti così :-)
La memoria protetta però... non ne volete sentir parlare proprio? =)
by LjL
ljl...@tiscalinet.it

 La memoria protetta però... non ne volete sentir parlare proprio? =)
Essendo AROS prima di tutto una reimplementazione di AmigaOS, la memoria 
protetta è un qualcosa che è _impossibile_ da implementare in maniera 
effettiva, a meno di non perdere compatibilità, sia binaria che a 
livello di sorgente, con AmigaOS. CABOOM e l'uso di sandbox, comunque, 
permettaranno l'adozione di forme più o meno evolute e più o meno 
effettive di memoria virtuale e protetta. Ad esempio applicazioni che 
sfruttassero interamente e solamente il layer posix potrebbero girare 
nel loro spazio di indirizzamento senza interferire con il resto delle 
applicazioni. Un esempio di tale applicazione è gcc, ed in generale 
tutti i porting da sistemi unix.
In ogni caso la MP e VM sono cose lasciate per un futuro più o meno 
prossimo...


prossimo...
Basta che non ve ne dimentichiate nel frattempo. "La storia insegna"
che non è "tanto facile" aggiungere la MP a un OS che non era pensato
per averla... hai presente esempi? ;-)
E sono sicuro che sarai d'accordo che al giorno d'oggi un OS senza
memoria protetta *non* è usabile per production work.
Se lo era ieri, perché non può esserlo oggi? Be', ad esempio perché
ieri non c'era la necessità di far girare browser Web che *di sicuro*
sono destinati a crashare.
E poi diciamo la verità, si sentiva la mancanza della MP anche "ieri".
by LjL
ljl...@tiscalinet.it

 
Ed il resource tracking? Io penso sarebbe interessante iniziarci a 
lavorare prima possibile, capisco che in AmigaOS e' legale passarsi tra 
processi puntatori ad aree di memoria e finestre, ma lavorando su alberi 
di processi dovrebbe esser possibile gestire questi casi. Sarebbe anche 
interessante aggiungere un api apposita per la creazione dei thread 
(perche' no, equivalente alla API pthread per compatibilita') che 
faciliti anche la futura implementazione di memoria protetta 
(all'interno del processo).
Scrivo qui e non in ML AROS perche' probabilmente avete parlato di ste 
cose alla nausea prima che mi iscrivessi un annetto fa e non vorrei 
ripetere cose gia' dette :)
Bye,
  Gabry

 (all'interno del processo).
Una qualche forma di RT è già implementata, ma richiede collaborazione 
da parte del programmatore, come avviene su AmigaOS4. Purtroppo se si 
vuole usare l'API di AmigaOS non si hanno molte altre possibilità: 
immagina di aprire un file in un processo e di passare l'handle ad 
un'altro processo; ora, se un processo muore, in un sistema con RT 
effettivo, tutti i file vengono chiusi, ma come faccio a chiudere tutti 
i file, nell'esempio che ho dato prima? Se lo faccio rischio di far 
lavorare il secondo processo su un file tramite un handle che ormai non 
vale più, con tutte le conseguenze del caso. Il fatto è che non c'è modo 
di sapere chi possiede cosa, in AmigaOS, a meno che non sia il programa 
stesso a dirlo all'OS...
Con CABOOM, cmq, e NON usando l'API di AmigaOS, il RT sarà incorporato.


 stesso a dirlo all'OS...
Tempo fa mi ero creato un sistema di RT su AmigaOS che funzionava anche 
abbastanza bene, ovviamente c'erano alcuni casi in cui falliva, ma in 
genere era sufficiente.
In pratica partivo dalla supposizione che i processi potessero nascere 
da shell o da workbench e costruivo degli alberi di conseguenza. Ogni 
risorsa creata ovviamente veniva etichettata con il processo che l'aveva 
creata, ma veniva rimossa SOLO se veniva richiesta la rimozione del nodo 
radice dell'albero.
Il sistema di rt era in pratica implementato come una serie di patch a 
DOS, Intuition, Exec, Graphics e disponeva dei due comandi unixlike kill 
e pstree (quest'ultimo stampava anche tutto l'albero delle risorse).
Purtroppo non ho portato avanti il progetto (si parla probabilmente del 
1997) in quanto sebbene funzionasse bene con molte applicazioni NON 
poteva gestire in modo adeguato al 100% i casi limite da te descritti 
(mentre funzionava bene se io passavo tra sottoprocessi della stessa 
applicazione il puntatore ad una finestra o un BPTR).
Ovviamente il 3.x e' solo il punto di partenza di AROS, e siccome ci si 
avvicina sempre di piu' al completamento mi chiedevo appunto se si era 
gia' pianificato qualcosa per andare oltre ed aggiungere quello che 
oggigiorno e' un must di un sistema moderno :)
Io auspicavo una soluzione piu' friendly, cioe' modificare le API, o 
aggiungere API estese per far questo tipo di cose, ma se ci sono 
vantaggi aggiuntivi, come mi sembra di capire da un altro messaggio, con 
questo CABOOM (di cui non ho sentito parlare in ML stranamente) ben venga :)
Bye,
  Gabry

 MacOS 7.
Mmmm, posso essere parzialmente d'accordo. AmigaOS 4 è un port trans-CPU
ma pare essere un patchone per modernizzare. MacOS 8 fu un vero e
proprio salto generazionale che vide forti alterazioni del Toolbox,
l'introduzione di elementi standard based e l'avvio verso il sistema di
passaggio, MacOS 9.
Per chi sui Mac ci programma, l'8 fu se non proprio un anno zero,
comunque una pietra miliare.
Marco

Marco
by LjL
ljl...@tiscalinet.it

 no?
Parzialmente sì, ne abbiamo ben pochi. Per quanto riguarda quel che è
stato scritto (e la discussione che l'ha preceduto) direi che la maggior
parte degli interventi (numericamente) ha avuto questo scopo.
 
Marco