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

 Ragioni storiche, finisce :-)
Se non ti piace lo puoi sempre cambiare... :)
Fabio Alemagna

 similia) sia tramite la seriale, senza nessunissimo tipo di problema.
Anche su un 500 con 512KB e floppy del Workbench basta aprire una
Shell e digitare "newshell AUX:" per aprire una sessione sulla
seriale.
-- 
 "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/

 filesystem adeguato c'è pure la multiutenza.
Non obietto, ma in remoto ti puoi collegare solo alla shell, a meno di non
usare robe tipo VNC... quello che volevo dire era semplicemente che
l'AmigaOS non era originariamente pensato per la multiutenza e il
collegamento remoto.
Che poi queste cose si riescano a fare, è soltanto perché l'AmigaOS è un
sistema duttile e ben progettato... yeah Hitman? ;)
A proposito, i filesystem multiutente *cosa* fanno esattamente?
by LjL
 
ljl...@tiscalinet.it

 A proposito, i filesystem multiutente *cosa* fanno esattamente?
Gestiscono l'accesso ai file sulla base di certi privilegi che l'utente
puo' o puo' non avere, proprio come tutti i filesystem multiutente :)
Fabio Alemagna

 puo' o puo' non avere, proprio come tutti i filesystem multiutente :)
Ok, ok, ma non farmi fare la figura dell'idiota per definizione... lo sarò
anche, ma porta pazienza :)
Intendevo, com'è che si stabilisce che utente sta usando il sistema? Viene
chiesto un nome e utente e una password al "login" (che normalmente non
c'è)?
E in ogni caso, più utenti possono usare *contemporaneamente* il sistema?
Non credo, no...? Senza la memoria protetta mi sembra un po' difficile,
anche se i miracoli possono sempre avvenire...
by LjL
 
ljl...@tiscalinet.it

 anche se i miracoli possono sempre avvenire...
Come detto la mancanza di memoria protetta restringe l'utilizzo della
multiutenza ad utenti fidati, ma non ci sono altre restrizioni.
Fabio Alemagna

 presenza del concetto di "schermo". Tale driver, pero', non esiste...
Il kit Siamese ha un driver per una scheda grafica fittizia.  L'output
va a finire, invece che ad una scheda vera, a un programma su un PC
collegato in rete. Il risultato e' che i programmi Amiga girano in una
finestra sul PC. Piu' o meno lo stessa cosa di X ridotto ai minimi
termini. Se proprio uno volesse X, puo' usare il port di GeekGadgets o
AmiWin o DaggeX. Ancora prima c'era il port di X11R4 di Dale Luck,
quello in uso sugli Amiga all'acceleratore di particelle di Stanford.
Una decina di anni fa esisteva anche ReMo, per controllare un Amiga
da un altro Amiga (non ricordo se usasse Envoy o TCP/IP). Da allora se
ne sono perse le tracce.


 Se non ti piace lo puoi sempre cambiare... :)
Anche l'assign L:? 
Si puo` rinominare in altra maniera? Non so, non lo credo possibile...
-- 
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

 Si puo` rinominare in altra maniera? Non so, non lo credo possibile...
Teoricamente no; essendo un assign standard, i programmi quando hanno
bisogno di qualcosa che dovrebbe stare in L: lo vanno a cercare in L:
Però, se vuoi puoi tranquillamente fare
Assign FileSystems: L:
e d'ora in poi l'assegnazione FileSystems si riferirà ad L.
Ripeto, tutti i vari programmi continueranno ad andare a cercare in L,
perché il nome standard è quello... ma tu-utente, a quel punto, potrai anche
dimenticarti completamente che "prima si chiamava L:" e chiamarlo
semplicemente FileSystems:
by LjL
 
ljl...@tiscalinet.it

 lo credo possibile...
Puoi fare tutto quello che vuoi. Basta un semplice "Assign L: remove" per
rimuovere l'assign dal sistema. Per ragioni di compatibilita' con il resto
del mondo, cmq, e' meglio creare un secondo assign, per esempio: "Assign
handlers: l:". Tu potrai far riferimento ad handler: mentre il resto del
mondo continuera' a far riferimento ad l:.
Fabio Alemagna

 mondo continuera' a far riferimento ad l:.
E qui torniamo al discorso della "directory misteriosa" :)
Per grazia di Dio, Fabio, mi spiegheresti che *cosa* esattamente si suppone
che L: debba contenere? Mi vergogno della mia stupidità, ma non l'ho mai
capito... :)
Per quanto mi riguarda, contiene in filesystem, io sono contento così. Ma so
che non contiene solo quelli: contiene appunto gli "handler"... ma cosa
esattamente sono, gli handler?
(credo interessi anche a Hitman BTW)
by LjL
 
ljl...@tiscalinet.it

 (credo interessi anche a Hitman BTW)
Un filesystem e' un handler, ma un handler non e' necessariamene un
filesystem.
Lo gia' spiegato un questo NG qualche tempo fa: gli handlers sono dei
processi che dialogano con altri processi, di solito tramite
l'intermediazione della dos.library (ma non e' necessario), secondo un
protocollo stabilito e standardizzato. Si occupano di gestire (da cui il
nome handler) quelle "cose" che hanno un nome che finisce sempre con i due
punti ":". Ho scritto "cose" perche' non so come altro chiamarle, dato che
i filesystems sono solo un subset di quello che si puo' fare con gli
handlers.
Prendi ad esempio PAR:. PAR: e' il corrispettivo dos del device
parrallel.device, e permette di gestire la porta parallela dal dos. E' un
equivalende del /dev/lptx di linux. Poi  c'e' PRT:, che fa le stesse cose
di PAR:, ma prima di mandare l'output alla stampante lo processa con il
driver di stampa. Questi non sono filesystem, come puoi ben vedere, pero'
hanno il loro handler nella directory L:, chiamato port-handler. Poi
esiste PIPE:, CON:, AUX:, etc... L'env-handler menzionto da Rudi rimpiazza
l'assign ENV: con un filesystem virtuale chiamato sempre ENV:, il che
porta con se molti vantaggi.
Qualche tempo fa avevo iniziato a lavorare ad un handler che avrei
chiamato HTTP:, indovina a cosa doveva servire? :)
Fabio Alemagna

 (credo interessi anche a Hitman BTW)
Un filesystem e' un handler! Un handler, genericamente, e' il gestore
associato ad un dato dispositivo. I dispositivi SER: e PAR:, ad
esempio, sono gestiti entrambi da port-handler (AmigaOS crea un
processo con una istanza di port-handler per ciascuno di essi). Una
qualsiasi finestra testo e' una istanza di con-handler (tant'e' che
puoi aprirne di nuove in qualsiasi momento redirigendo l'output di un
comando su uno pseudo-file come CON:x/y/w/h/titolo/opzioni). SPEAK: e'
una istanza di speak-handler, PIPE: di pipe-handler, etc.
Un filesystem e' nient'altro che un handler che supporta un maggior
numero di pacchetti (operazioni) rispetto al solito. La tua partizione
di avvio, per esempio, e' un processo che istanzia l'handler
FastFileSytem (o qualsiasi altro, se lo hai aggiunto nell'RDB del
disco). La puoi formattare, crearvi directory o link, cambiarvi date,
ecc. Tutte cose che non hanno senso per l'handler della porta seriale,
per esempio, il quale infatti restituisce errore se provi a fare
altrettanto. Per entrambi resta comunque il fatto che l'I/O viene
effettuato allo stesso modo, ossia tramite scambi di messaggi
(pacchetti) tra applicazione e processo handler.


 chiamato HTTP:, indovina a cosa doveva servire? :)
Boh... ;)
No scusa, seriamente, ma non esisteva già una cosa del genere?
O mi confondo, esisteva solo per l'FTP?
In ogni caso, quindi, in generale è l'handler che "parla" col device, non le
applicazioni... giusto?
Comunque, ora mi rivolgo di nuovo a Hitman: quello che ha detto Favrin per
te non significa niente? A me personalmente, anche se lo sapevo già (pur
appunto non avendo chiaro che quello che fa tutto ciò è un handler), solo a
leggerlo mi sembra che mi si apra la mente -- vabbe' che non ci metto molto
ad aprirla un pochino.
L'handler per l'HTTP... che esista o no, fatto sta che è implementabile
credo quasi facilmente in un modo già standardizzato dal sistema operativo
(che probabilmente è stato scritto pensando a qualsiasi cosa meno che a
Internet). Esiste una cosa del genere per un altro sistema operativo?
In teoria, io faccio "Esegui" / "MultiView HTTP:
www.altavista.com
". Non mi
sembra male...
Oh già si può fare anche sotto Windows, tra parentesi... peccato che
l'ultima cosa al mondo che vorrei sapere è *come* questa caratteristica sia
stata implementata in Windows ;)
by LjL
 
ljl...@tiscalinet.it

 stata implementata in Windows ;)
Tramite estensioni di explorer (la shell, non il browser). Il che
significa anche che una cosa del genere la puoi fare solo con la gui e non
da linea di comando.
Fabio Alemagna

 da linea di comando.
Gia'... a suo tempo imparai a caro prezzo che le estensioni della shell,
per quanto comode, non sono visibili da molte (tutte?) applicazioni.
Per giunta, la flessibilita' dello scripting di Explorer era ben poca
(volevo fare una copia ricorsiva, FILE PER FILE, da una estensione al
disco locale).


 anni.
Ah... avevo scordato ftpmount...
Fabio Alemagna

preventivamente montato manualmente in un mount point. Se non esiste
E` una classica applicazione di esempio di un userfs.
Sono abbastanza sicuro che ce ne sono implementazioni che non richiedono
di montare ogni sito.
Conosco i datatype ma mi sembrano una cosa un po' troppo generica, che
senso ha gestire con la stessa interfaccia l'accesso a una immagine, a
un testo (magari multimediale) e a un suono?
Gnome da questo punto di vista ha sia un file system virtuale interno
(che permette appunto cose come accedere in modo trasparente a un file
scaricabile con ftp) che delle API generiche per fare cose come aprire e
mostrare una immagine.
Visto che si hanno i sorgenti non e` particolarmente utile usare
librerie esterne separate come i datatype, ma se fosse necessario
sarebbe banale aggiungere la possibilita` di caricare "moduli" per
gestire altri formati.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

 gestire altri formati.
A me non pare il massimo ricompilare codice o scaricare un intero
pacchetto di tutta una serie di caricatori solo per aggiungere un
nuovo formato (come faccio, tra l'altro, se voglio usare un caricatore
alternativo in luogo di quello standard?). Ma si sa che de gustibus
non est sputazzandum.


alternativo in luogo di quello standard?).
Beh, ho scoperto ora che debian ha spezzettato gdk-imlib e i modulini
vengono caricati con dlopen:
/usr/lib/libgdk_imlib.so.1.9.8
/usr/lib/libimlib-bmp.so
/usr/lib/libimlib-gif.so
/usr/lib/libimlib-jpeg.so
/usr/lib/libimlib-png.so
/usr/lib/libimlib-ppm.so
/usr/lib/libimlib-ps.so
/usr/lib/libimlib-tiff.so
/usr/lib/libimlib-xpm.so
E se il formato non e` tra quelli direttamente supportati prova
comunque a convertire il file con imagemagik.
Comunque considero assolutamente accettabile installare un pacchetto
aggiornato per supportare un nuovo tipo di immagine, non e` proprio che
nuovi formati grafici vengano inventati ogni giorno.
Se vuoi usare una libreria alternativa ovviamente basta installare un
pacchetto alternativo.


 [snip]
Però c'è una differenza tra una cosa "accettabile" e una "buona idea" o una
"soluzione elegante".
by LjL
 
ljl...@tiscalinet.it

 bisogno di qualcosa che dovrebbe stare in L: lo vanno a cercare in L:
Appunto, non lo puoi cambiare. 


 mentre il resto del mondo continuera' a far riferimento ad l:.
Questo  e` interessante.  Direi che  si puo`  fare lo  stesso anche  con
linux, cmq, e un paio di "ln -s".


 chiamato HTTP:, indovina a cosa doveva servire? :)
Buona idea ;)


 caratteristica sia stata implementata in Windows ;)
La shell  riconosce http: e  passa il  controllo a explorer...  nulla di
particolare.


 linux, cmq, e un paio di "ln -s".
E' vero. E se non ci fossero i link simbolici, Linux sarebbe imho una gran
schifezza.
Ma quello che io intendevo dire fin dall'inizio *non* è che, su Linux,
volendo non si possano dare altri nomi alle directory di sistema. Il
problema è che, comunque, i programmi e il sistema andranno a guardare in
delle directory.
Tu dici che secondo te il sistema degli assign di AmigaOS è un'accrocchio;
libero di pensarlo, ma imho le strutture duali hanno una potenza logica
molto maggiore di quelle singolari.
Pensa alla programmazione a oggetti: qual è il tratto che veramente la
distingue dalla programmazione tradizionale? Il fatto che è duale: c'è una
gerarchia di classi e una gerarchia di oggetti -- non semplicemente delle
sterili 'funzioni'.
Anche se il paragone è molto azzardato, prova a pensare agli assign come
alle classi, e alle directory assegnate come agli oggetti. O per dirla come
Platone, gli assign sono le idee -- Libs: è l'"idea" del cassetto delle
librerie -- e le directory assegnate sono l'incarnazione nel "mondo reale"
delle "idee".
Mettiamola un attimo sul pratico. Vuoi cercare, tra tutte le librerie che
hai, quella che contiene la stringa "imadummylibrary". Come fai, su Linux?
Devi cercare in tutte le directory che possono contenere librerie, suppongo.
Oppure puoi prendere ld.so.conf e fare uno script che cerchi automaticamente
nelle directory specificate lì.
Su AmigaOS, ti è sufficiente dire alla shell di cercare la stringa
"imadummylibrary" in Libs: .
by LjL
 
ljl...@tiscalinet.it

 pratica.
E' ovvio che ogni OS ha il suo sistema per razionalizzare le cose. Linux
essendo un kernel monolitico ha scelto la strada dei "moduli", che altro
non sono che delle librerie caricate dinamicamente il di cui codice gira
in kernel space. E' una scelta di manutenibilita' del sistema, piu' che
altro, che poco ha a che vedere con la flessibilita' di un microkernel.

 particolare.
E due: avevo detto di non dirmeloooooooooo! ;))
by LjL
 
ljl...@tiscalinet.it

 linux, cmq, e un paio di "ln -s".
In effetti gli assign di AmigaOS sono equivalenti -per certi versi- a dei
symbolic links -che AmigaOS supporta pure- creati nella directory /. Ho
detto "per certi versi" perche' con i symbolic links non puoi fare cose
del tipo:
Assign Libs: Sys:Libs
Assign Libs: Sys:UserLibs ADD
Oppure
Assign Fonts: Df0:Fonts PATH
Fabio Alemagna

 Appunto, non lo puoi cambiare.
Hai snippato il resto. Se fai quello che avevo detto, dopo non ti accorgerai
*mai* della doppia assegnazione, e potrai fare qualsiasi operazione usando
il nuovo assign che hai creato.
by LjL
 
ljl...@tiscalinet.it

 altro, che poco ha a che vedere con la flessibilita' di un microkernel.
... e suppongo quindi che la exec.library *sia* un microkernel, e non un
kernel modulare, giusto?
Penso che ci *sia* della differenza, dato che non ho mai sentito paragonare
prima il kernel di AmigaOS a quello di Linux.
by LjL
 
ljl...@tiscalinet.it

 prima il kernel di AmigaOS a quello di Linux.
Ovvio che c'č differenza. La prima differenza e' che solo exec gira in
modalita' supervisore, ed addirittura solo una piccolissima parte di exec.
Fabio Alemagna

 di un microkernel.
Si, e sinceramente non vedo vantaggi evidenti per l'uno o per l'altro.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 


 funziona proprio in questo modo... :)
Differenze minime di approccio. 
E` piu` semplice un unico filesystem ad albero o una foresta?
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 


 Assign Fonts: Df0:Fonts PATH
Un meccanismo un po` piu` flessibile, in effetti.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 


 operazione usando il nuovo assign che hai creato.
Ho letto la spiegazione di Alemagna, ti rimando li'.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 


 Altrimenti mi chiedo un handler di FS come possa lavorare.
Certo, tutti i processi utente possono accedere a tutte le risorse del
ssistema. Cosě avviene con TUTTI i microkernel, mica solo con AmigaOs..
Fabio Alemagna

 Saro` tardo, ma non riesco a vederne un uso :/
Appena dimostrato... ENV: e' un assign a RAM:env. Le variabili ambiente,
in AmigaOS, sono dei comuni files residenti in ENV:. I programmi accedono
ad ENV:, non ad ENVARC:, a meno che non si voglia *salvare* la
configurazione, e non semplicemente usarla.

 E` piu` semplice un unico filesystem ad albero o una foresta?
Boh... tanto ad AmigaOs non interessa, visto che se vuoi puoi avere anche
l'albero :) Proprio in questi ultimi giorni sto scrivendo un filesystem
per AROS (Amiga Research OS - 
http://www.aros.org
) che simula la directory
root di unix. In pratica du scrivi "dir root:" ed ottieni tutta la lista
dei filesystems. dare un "cd root:sys" equivale a dare un "cd sys:" e via
di seguito...
Sto facendo questo perche' sto implementando da capo a piedi una completa
libc per AROS, il cui goal finale e' fornire ad AROS uno strato posix il
piu' completo possibile. Quel root filesystem mi servira' per translare
nella maniera piu' trasparente e pulita possibile i path in stile unix nei
path in stile amiga.
Ad esempio, un path del tipo /sys/ciao verrebbe translato in
root:sys/ciao. In realta' un root filesystem non sarebbe necessario per
fare questo, basterebbe infatti translare /sys/ciao in sys:ciao, ma in
questo modo non potrei "listare" la directory root, non potrei farla
diventare directory corrente, etc...
Fabio Alemagna

 variabili conservati in RAM ed eventualmente settati in un file di boot?
Che e' piu' semplice da gestire, non devo avere nessun file di
configurazione scritto a mano nel quale non faccio altro che settare
valori di variabili, e siccome le variabili ambiente non sono altro che
files posso gestirle in una maniere piu' semplice e razionale.
Fabio Alemagna

 che files posso gestirle in una maniere piu' semplice e razionale.
In effetti e` una soluzione piu` elegante, questo si.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 
"I've seen SPAMs you people wouldn't believe.
                  Time to shutdown.           "

 Non capisco cosa intendi...
Non essendo file  in formato standard non puoi montare  la partizione da
un'altro SO e editarne i file da li, credo.
Con linux, volendo, lo puoi fare.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 


 via di seguito...
Beh, avendo  gli handler (o  i userfs  o comunque un  qualche meccanismo
simile) si puo` fare di tutto: tutto sta a scrivere il codice giusto.
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 


 Con linux, volendo, lo puoi fare.
Questo e' vero, ma a che serve? In caso di errori puoi sempre partire con
un sistema minimale che ti consente di aggiustare il guasto. Nel caso,
invece, la modifica tu la voglia fare da remoto non c'è bisogno di montare
la partizione, basta connettersi all'Amiga da remoto e cambiarla
sirettamente sull'amiga.
Fabio Alemagna

 Questo e' vero, ma a che serve?
Non saprei, io non l'ho mai usato :-)
-- 
Renato "Hitman" Salzano - 
http://spazioweb.inwind.it/hitman/
 
e-posta : sonicblast (at) 
inwind.it
 / Fan di Helena Velena 
Powered by AMD K6/II-350, Debian Linux 2.x (Woody) and WindowMaker
---> Le risposte usualmente sono nelle FAQ <--- 

 Quindi a volte _non_ puoi imporre un'altro widget?
Non capisco cosa vuoi dire... Ci sono alcuni framework che hanno tutti i
widgets in una unica libreria ed implementano un unico stile di disegno,
che puo- essere o meno configurabile, ce ne sono altri, tipo MUI, che
lasciano ai widget libera scelta, tant'e' che ogni widget sta in un file a
se', pur "esportando" degli stili ai quali il widget dovrebbe attenersi,
in quanto scelta dell'utente. In generale, cmq, BOOPSI, al quale TUTTI
questi framework si appoggiano, lascia libera scelta al programmatore, il
quale DEVE implementare un metodo per il disegno del widget.
Fabio Alemagna