Newsgroup: it.comp.os.dibattiti
Titolo: Linux (era: Re: Collegarsi a Internet da WinUAE 0.8.16r2)

 Quello no, e li` c'entra poco linux :-)
Non ne dubito, ho abbastanza neuroni per rendermi conto che la questione
dell'"user support" è separata completamente da quella del sistema
operativo.
Era solo una piccola polemica senza scopo pratico.
Ora fammi aprire un altro piccolo paragone.
Sempre sul file system, sono un po' fissato.
Metti che io ho avviato AmigaOS da un disco (facciamo floppy, o CD) che si
chiama Workbench3.1.
Se il disco è inserito, da shell posso scrivere
SYS:        e la directory corrente diventerà la root del disco, dato che
SYS è assegnato automaticamente al disco di avvio
Workbench3.1:        idem, perché è il nome del disco
DF0:        idem, supponendo che il disco stia nel drive DF0 (prima unità
floppy)
Se il disco non è inserito (a parte il fatto che il Workbench se ne accorge
subito e toglie o rimette l'icona a seconda)
SYS:        apparirà un requester che dice "Please replace volume
Workbench3.1 in any drive"; ovviamente, se metto un altro disco il sistema
se ne accorge (e non mi dà un BSOD... vedi un certo sistema operativo) e me
lo chiede di nuovo. Mi dice "replace", ovviamente, perché sa che SYS
equivale a Workbench3.1
Workbench3.1:        requester che dice "Please insert volume Workbench3.1
in any drive", notare l'"insert" invece di "replace"
DF0:        requester che dice "No disk present in device DF0"; in questo
caso, qualunque disco metto andrà bene
La superiorità di tutto questo è particolarmente evidente rispetto a
DOS/Windows.
Ma anche rispetto a Linux mi pare che abbia dei vantaggi. Se non sbaglio,
non c'è modo di chiamare un disco col suo nome; l'unica cosa che conta è la
directory dove va montato secondo la fstab.
Se tolgo un floppy (un CD no perché non me lo lascia fare) senza prima
umount'arlo, cosa succede? (credo di non aver mai fatto una cosa del genere,
ma penso che non mi piacerebbe provare, sbaglio?)
So che sotto DOS e Windows succedono delle cose incredibili se si toglie o
si cambia un disco senza spiegare esattamente il tutto al sistema.
Una nota di colore: se per caso si toglie un disco mentre il sistema lo sta
*usando*, nel senso ci sta scrivendo o leggendo, l'amichevole "Please
insert..." diventa un "You MUST replace volume Workbench3.1 in device DF0!"
:-)
by LjL
 
ljl...@tiscalinet.it

 Workbench3.1 in any drive"; ovviamente, se metto un altro disco il sistema
C'e' anche un'altra cosa che AmigaOS fa da piu' di quindici anni coi
dispositivi rimovibili che NESSUN altro sistema operativo che io
conosca sappia fare a tutt'oggi (eventuali smentite sono sempre
accette). Non e' di fondamentale importanza, ma fa sempre un certo
effetto.
Prendi un Amiga con due drive per floppy (o due CDROM o due hard disk
rimovibili... ci siamo capiti). Apri una shell e, supponendo di avere
un volume con tanti file, digita "list DF0: all" (piu' o meno
equivalente a "ls -lR /mnt/floppy") o "list Pippo: all" (se il disco
ha etichetta "Pippo"). Mentre List mostra i file e le directory
presenti, metti in pausa l'output sulla shell, estrai il disco dal
drive in cui si trova, inseriscilo nell'altro e sblocca l'output.
Senza battere ciglio, List riprende a mostrare i contenuti del disco
leggendoli dal nuovo drive. Touche'.
-- 
 "The first thing we do, let's kill all the lawyers"    (W. Shakespeare)
 Rudi Chiarito         SGML/XML, user interface, i18n         Amiga Inc.
 
ru...@amiga.com
 
http://amiga.com/

 leggendoli dal nuovo drive. Touche'.
Ahah questa non la sapevo, mai avuto due drive :)
Per quanto -- credo -- fondamentalmente inutile, anche questo dimostra la
precisione e la coerenza con cui è stato scritto AmigaOS.
Mi sembra però che un'incongruenza ci sia: mentre non ho nessuna obiezione
su "list Pippo: all", mi pare che il sistema *non* dovrebbe continuare a
leggere tranquillamente il disco con "list DF0: all".
DF0 identifica *quel* particolare drive, e se il disco che viene letto non è
più in quel drive, non dovrebbe più esistere un "list df0:".
In questo caso, mi sembrerebbe più logico un "No disk present in device
DF0", se non un "Please replace volume X in device DF0".
by LjL
 
ljl...@tiscalinet.it

 leggere tranquillamente il disco con "list DF0: all".
Perche' no? Nella scansione (magari ricorsiva) della directory,
"Pippo:" o "DF0:" *NON* vengono risolti ad ogni accesso. Normalmente,
prima ottieni un lock in lettura su "Pippo:" o "DF0:" (operazione che
risolve i nomi), dopodiche' chiami Examine() o la piu' efficiente
ExAll() su tale lock e, ricorsivamente, su eventuali sottodirectory
(operazione che non risolve nomi di volume).
Se metti in pausa List mentre mostra i contenuti di "DF0:a/b/c/", lo
stai facendo dopo che il programma ha chiamato Examine() passando il
lock sulla directory (non il percorso completo). Se togli il disco
dall'unita' e lo reinserisci in un'altra, il sistema se ne accorge e
automaticamente passa tutti i lock del volume "Pippo:" (non importa se
hai ottenuto il lock usando "Pippo:" o "DF0:", alla fine il volume
usato e' sempre lo stesso) alla nuova unita'.
In soldoni, un lock e' sempre associato ad un volume. Puoi accedere
al lock da qualsiasi unita' in cui il volume sia inserito, non solo
da quella in cui si trovava al momento della chiamata a Lock().


 configurazione media.
Era più o meno quello che sospettavo.
[snippo] su tutta la parte sui lock, mi hai quasi ucciso... non mi
permetterò più :)
Hitman mi aveva anche detto che AmigaOS, al contrario di Linux, riguardo
alle librerie probabilmente non ha il versioneering e il collegamento
dinamico trasparente (o quello che era, Hitman correggimi).
Siccome io non so cosa siano, mi piacerebbe se gli rispondessi tu.
by LjL
 
ljl...@tiscalinet.it

 Siccome io non so cosa siano, mi piacerebbe se gli rispondessi tu.
Se si riferisce al fatto di chiamare le funzioni di libreria come se
fossero funzioni locali, senza dover cercarne prima il puntatore
manualmente per nome, con le librerie Exec le chiamate vengono
effettuate mediante salto ad un offset specifico in una jump table,
non per nome. Ogni libreria ha i suoi prototipi, che definiscono per
ognuna di esse anche l'offset. Quindi all'interno del mio programma
posso usare tranquillamente "RectFill(blah blah blah);" per riempire un
rettangolo usando la graphics.library.
L'unica cosa che in teoria non sarebbe trasparente e' l'apertura e la
chiusura delle librerie, ma e' una vita che compilatori C come quello
della SAS lo fanno automaticamente (si compila staticamente con una
mini-libreria che contiene costruttore e distruttore; per le librerie
Commodore tali costruttori e distruttori sono nella stessa libreria
del codice di startup).


 (operazione che non risolve nomi di volume).
Nella scansione ricorsiva delle directory, pero', all'atto di scendere di
un livello viene creato un nuovo lock, per cui il disco deve comunque
risiedere in DF0:, altrimenti appare un requester che chiede di inserirlo.
Fabio Alemagna

 risiedere in DF0:, altrimenti appare un requester che chiede di inserirlo.
Se cambi directory corrente ogni volta che ti muovi nell'albero e
chiami Lock() usando solo il nome della directory (cioe' il percorso
relativo), il nuovo lock viene creato relativo al vecchio, quindi non
c'e' bisogno del disco in DF0:. Del resto il pacchetto
ACTION_LOCATE_OBJECT richiede sempre un nome e un lock rispetto al
quale il primo viene interpretato (Lock(), tramite GetDeviceProc(),
passa all'handler la directory corrente per percorsi relativi). Ci
sarebbe bisogno di DF0: solo se tu chiamassi ogni volta Lock() col
percorso assoluto, cosa che pero' ti costringerebbe
a) a mantenere un buffer temporaneo col percorso (domanda da un
milione di dollari: quanto grande?)
b) ad essere vulnerabile a comportamenti bizzarri (fai una scansione
ricorsiva di LOCALE: e qualcuno ti cambia l'assegnamento nel
frattempo... non serve a nulla, anzi crea solo piu' confusione)


 frattempo... non serve a nulla, anzi crea solo piu' confusione)
Be'... List funziona cosi' :) Prova pure... Segnalo sul taccuino delle
cose da correggere nell'OS4.x :)
Fabio Alemagna

 del codice di startup).
Mi riferivo appunto al fatto che  i programmi non devono preoccuparsi di
come gestire l'allocazione in RAM della libreria, a quella pensa il SO.
Da quello che  dici AmigaOS non ha questa capacita`,  ma ci deve pensare
il codice del programma.
E in  effetti si  accorda con il  fatto che AmigaOS  non ha  (per quanto
so)  un gestore  di  memoria protetta  (manca anche  la  VM, forse?  Non
saprei...).
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Xena:TWP fan
Webdesigner / indegno sysadmin di 
www.italservicesnc.it
 
Powered by Debian 2.x (Woody) on a K6/2 box - 100% Wintel free

 saprei...).
La memoria virtuale c'era tramite programmi aggiuntivi e col 4.0 e' di
serie. La memoria protetta arrivera' col 5.0 (solo di recente stanno
iniziando ad avvicinarsi al pubblico CPU con MMU decenti... era ora,
visto che ad AmigaOS avrebbero fatto comodo vent'anni fa, ma pazienza).


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

 ... *è* ? ;-)
Be', ricorda che deve uscire tra un paio di mesi, quindi mi aspetto che
esista gia' :)
Fabio Alemagna

 serie. La memoria protetta arrivera' col 5.0
ma non avevano scelto di non metterla?
mi pare di ricordare dei messaggi di Alemagna in questo gruppo che litigava
col resto del mondo perche' sosteneva che era una decisione in
controtendenza ma giusta.
Oppure l'ho sognato?
Saluti
Marco

 Oppure l'ho sognato?
No, non l'hai sognato, ma non hai chiara la differenza tra AmigaDE e
AmigaOS.
Fabio Alemagna

 AmigaOS.
Infatti ;-)
Mi fai un sunto delle differenze e di cosa e' oggi Amiga?
grazie
Marco

 controtendenza ma giusta.
Il discorso era che, per quanto indiscutibilmente utile, nei casi di
software bacato la memoria protetta e' solo un palliativo, che limita
i danni quando il peggio e' successo. E' un po' come una assicurazione
sulla vita: se da un lato riduce i problemi causati a tua moglie e i
tuoi figli quando passi a miglior vita (uso il "tu" in senso generico,
non ti sto gufando), il succo del discorso purtroppo non cambia, cioe'
che sei morto.
Non aiuta nemmeno il fatto che per via di hardware primitivo le
implementazioni attuali della memoria protetta sono giocoforza
artificiose, macchinose e fragili (non vedo perche', semplicemente
bucando il server di posta o altro, uno debba automaticamente avere
pieno controllo sull'intera macchina). Per fortuna le cose stanno
cambiando ultimamente, si incomincia finalmente a vedere hardware 
decente.


 decente.
tipo?
Saluti
Marco

controtendenza ma giusta.
Pare anche a me.
-- 
Davide Inglima, limaCAT

 tipo?
IA-64? PPC A30/A50/RS64?
Senza contare, poi, la (relativa) facilita' con cui oggi e' possibile
usare blocchi funzionali gia' pronti che implementano architetture
comuni (ARM, PPC, MIPS), ai quali possono essere poi aggiunte le
estensioni piu' disparate.


 IA-64? PPC A30/A50/RS64?
Grazie per la risposta: purtroppo sono troppo utonto per capirti ;-)
Si tratta di hw gia' in commercio? e destinato a quale uso?
Saluti
Marco

 Si tratta di hw gia' in commercio? e destinato a quale uso?
Beh, per ora le CPU che ho elencato sono solo per server, ma e'
risaputo che prima o poi funzionalita' presenti in prodotti di fascia
alta finiscono in prodotti di massa (lo Zaurus qui ha un SH3 a 120MHz
e 16MB di RAM... dieci anni fa qualcosa di paragonabile costava un
occhio della testa, ammesso di trovarlo).
Dimenticavo una cosa importante: dall'ARM6 in poi (quindi da una
decina di anni) anche gli ARM hanno funzionalita' simili, sebbene
siano un po' piu' limitati. E uno StrongARM 1110 a 206MHz richiede meno
di 400 milliwatt (picco).  Gnam gnam...


 pazienza).
Infatti, rimane  sempre un difetto  di AmigaOS... meglio tardi  che mai,
cmq.
