Newsgroup: it.comp.macintosh
Titolo: nix rumori

su < 
http://www.macity.it/forum1/messages/4163/105227.shtml?1083189437
 >
qualcuno dice che nella prossima 10.4 o tigre che dir si voglia, Apple
potrebbe "passare da *nix a linux ... inserire la possibilità di eseuire
.exe (win$) ..." secondo quando direbbe < 
http://www.macosrumors.com
 >
(che mi risulta non accessibile).
che ci sarà di vero? [lo so bene che nessuno di noi è nella mente di
Steve]
Abbandonare Mach e BSD (e quanto rimane del glorioso NeXT) per linux? è
un vantaggio? uno svantaggio? debbo piangere? sorridere? star
tranquillo?
Non sarebbe meglio ampliare la compatibilità con linux e X11 (che
finalmente potrebbe essere "seamless") *senza* rinunciare alla stabilità
e alla potenza - nonché alla tradizione - di un *vero* *nix?
Lascio perdere la storia di eseguire programmi windows, che potrebbe
pure essere plausibile, ma il resto mi turba un po'.
ciao
Salvo
-- 
#!/usr/bin/perl
print "per scrivere a ~§alvomi©~ considerare Alfa e Omega \n";

 < 
http://www.macosrumors.com
 >
Occhio. E' inutile che metti i link tra <> se poi lasci lo spazio prima
e dopo.
-- 
Ve lo meritate Gil Amelio!

 e dopo.
sě, grazie.
-- 
sm

 nserire la possibilità di eseuire .exe (win$)
ma in questo modo i virus scritti per win potrebbero far danni anche su
Mac?

 Mac?
in effetti se venissero eseguiti "in emulazione" su Wine o robe del
genere non potrebbero far molti danni, visto che non hanno Registry e
porte "tipiche" da aprire.
Il punto č: i programmi eseguiti cosě saranno veloci, affidabili,
usabili?
ciao
Salvo

 potrebbe "passare da *nix a linux
Non mi pare si parlasse di un passaggio al kernel Linux (cosa su cui non
punterei nemmeno un centesimo), ma eventualmente dell'aggiunta di
librerie per facilitare il porting delle applicazioni.


 librerie per facilitare il porting delle applicazioni.
questo è auspicabile, e penso più che altro che sia questa la linea
seguita. L'equivoco nasce (ma sono rumors, appunto) con frasi tipo
"Apple vuol incorporare linux... ecc...), che potrebbero far pensare al
kernel.
Se così fosse, la Tigre si allontanerebbe un bel po' dalla Pantera.
Comunque, ho cercato riferimenti più precisi sui siti in inglese, ma
evidentemente non sono stato bravo nella ricerca questa sera...
ciao,
Salvo

 
Non penso che si andra' molto oltre la velocita' di VirtualPC, da quel
che leggo e' un ottimo emulatore (tanto che M$ si e' comprata tutta
Connectix per averlo) quindi a meno di grandi sorprese (poco plausibili)
la velocita' e' quella. 
Poi altro discorso la comodita' di averlo gia' integrato dentro l'os
tutto configurato con la cura di mamma Apple.
-- 
Ciao
Fabio

 
Un X11 integrato (e invisibile) nel sistema che ha un look aquoso ?
quella si che sarebbe una features gradita!
Quello che mi attira sono piu' le novita' a sorpresa che Steve tirera'
fuori dal cilindro, la classica cosa dall'utilita' abbastanza dubbia ma
che ti lascia senza fiato (do you know Backlit keyboard ? ;-)
-- 
Ciao
Fabio

 e' un ottimo emulatore
Ma Wine (cosě come Darwine) non č un emulatore. E' questo il vantaggio.


 Ma Wine (cosě come Darwine) non č un emulatore. E' questo il vantaggio.
Uh senza emulare una CPU x86 come fa a far girare il codice x86 ?
-- 
Ciao
un Fabio colto alla sprovvista

 che ti lascia senza fiato (do you know Backlit keyboard ? ;-)
già, è imprevedibile. Per fortuna :-))
ciao
salvo

 Uh senza emulare una CPU x86 come fa a far girare il codice x86 ?
Guarda, se non ho capito male, Darwine non sarebbe in grado di far
girare un eseguibile Windows (a meno di un emulazione x86 come dici tu),
ma dovrebbe permettere di compilare un codice sorgente per Windows
(sfruttando la libreria WineLib) generando un eseguibile che possa
girare su Mac OS X.


 c'era questo:
"The Darwine project intends to port and develop Wine as well as other
supporting tools that will allow Darwin and Mac OS X users to run
Windows Applications. There are two major phases to this project.
 The first phase is the port of Wine to Darwin/PowerPC with X11
(XFree86).
 While the basic compatibility is there as Darwin is largely FreeBSD,
there is the hurdle of its Mach kernel which uses the Mach-O format
rather than ELF. This part has been achived with success. It means that
WineLib is now working on Mac OS X, and that developers should be able
to recompile their Win32 Apps using WineLib and make them work in Mac OS
X.
The second phase is to then integrate in WINE the QEMU binary
translator.
 Additional supporting tools for launching Windows applications from the
desktop and an integrated installer are desireable items for the package
(like OpenOffice is doing).
 This is distinguished from simply using QEMU to run Windows because
there is no Windows here. Just WINE and QEMU to run Windows applications
directly under X. That will enable vastly better performance, better
integration, and easier administration.
 For Mac OS X, the ideal would be to eventually use the native GUI.
 Further enhancements could include integrated support for things like
FAT32/NTFS volumes with Windows under via QEMU (or other PC emulator) so
that the same Windows applications could be run in either mode (Windows
or WINE)."
Il vantaggio principale, anche quando si fa girare direttamente
l'eseguibile compilato per Windows (una volta che avranno aggiunto
l'emulatore QEMU), č che comunque non c'č Windows di mezzo, quindi č
probabile che questo renda il tutto piů veloce. 


 
Mi sembra di capire che molti di voi sul discorso kernel preferiscono 
darwin a linux, sbaglio?
A parte il fatto che i miei rapporti con il kernel sono limitati ;-) , 
uso le applicazioni, se queste stanno sopra darwin o linux non mi 
importa molto (almeno credo) quali sono i motivi che vi fanno preferire 
l'uno piuttosto dell'altro?
Darwin ha un approccio microkernel (simile a Hurd?) mentre linux pur 
essendo di sostanza un monolitico ha introdotto da tempo i moduli.
Premetto che secondo me piu' diversita' abbiamo in campo informatico 
meglio e' per tutti gli utilizzatori e la liberta' di scelta se ne 
avvantaggia, il mio "mondo ideale" informaticamente parlando vede tanti 
kernel (Darwin, Linux, Hurd, e tanti altri presenti e futuri) e tanti 
ambienti desktop (Mac, KDE, Gnome, ecc.) con tutte le combinazioni 
possibili tutto open source o parzialmente open-proprietari. Non e' 
pero' un caso che non ho menzionato redmond nel mio "mondo ideale" ;-)
Sinceramente vedo anche io improbabile che dopo tutti i soldi spesi per 
sviluppare darwin (e acuisire le tecnologie Next) Apple usi linux come 
kernel per la prossima versione di Mac os X. pero' e' uno scenario 
fanta-informatico interessanta su cui  riflettere.

 probabile che questo renda il tutto più veloce. 
Si in effetti questo non l'avevo considerato. Penso anche io che in
questo modo avermo velocita' migliori. Questo Keynote si fa ghiotto :-)
-- 
Ciao
Fabio

 darwin a linux, sbaglio?
Premesso che non ne so quanto vorrei di kernel, non e' che preferiamo
uno all'altro, (molti qui usano sai OsX che Linux) ma da come la vedo io
darwin e' un progetto maturo, e' stabile, performante e sicuo. Un altra
transizione porterebbe le eventuali disfunzioni del caso, piccoi bug,
falle di sicurezza etc etc. Francamente non ne vedo i vantaggi.
Poi se sia meglio un microkernel o un kernel monolitico penso che non
sara' mai ben chiaro, tanto e' vero che Linux con i moduli va
snellendosi mentre i microkernel includono sempre piu' funzionalita'.
La mia obbiezione era molto poco tecnica, ad oggi il mond *BSD
rappresente una fetta motlo piccola e leggevo di recente su OSNews che
molte delle migliorie apportate a FreeBSD vengono proprio da Apple. Se
adesso apple abbandonasse questo kernel il mondo *BSD riceverebbe ancora
meno interesse. Non dico che scomparirebbe, ha comunque il suo folto
numero di sostenitori ma gli investimenti massicci si vedrebbero solo su
Win e Linux (oddio non che gli investimenti su darwin possano competere
con quelli di questi due colossi ma erano gia' qualcosa).
Come giustamente dici tu il mercato IT perfetto richiede un ampia
scelta.
-- 
Ciao
Fabio

Giusto un paio di considerazioni:
La sostituzione del kernel con quello di linux, la vedo potenzialmente una
buona idea. Sicuramente lo sviluppo del kernel di linux è supportato da un
numero di sviluppatori ben maggiore. Come tale ha un velocità di
introduzione di nuove feature e correzione di bug ben maggiore di quella
possibile con un kernel proprietario. Quanto alla potenziale superiorità di
un microkernel rispetto ad un kernel modulare, è una questione dibattuta. Un
vantaggio del microkernel è la possibilità di supportare più di una
personality. In tale ottica potrebbe introdursi il discorso della
compatibilità a livello di API con le API win32. Le api win32 potrebbero
essere implementate come una personality parimenti al sottosistema BSD.
Questa era +/- l'architettura originaria di NT, ove al posto di BSD vi era
un sottosistema Posix. Altri vantaggi rispetto ad un kernel modulare come
linux non se ne evincono. Altro discorso è la fattibilità della cosa,
sicuramente Darwin (quello non opensource) espone tutta una serie di system
call utilizzate dagli strati più alti di X (quartz, cocoa...). Si tratta di
vedere quanto tale interfaccia sia esportabile. In particolare bisognerebbe
trovare come sposare il modello Linux in cui i device driver sono
all'interno del x-server, con il modello di X in cui i device driver della
scheda grafica sono all'interno del kernel nel'I/O kit.
Per quanto riguarda la compatibilità a livello di API con win32 è un altro
bel film. Win32 espone migliaia di API (molte delle quali non documentate).
Pensare di riuscire ad emularne il comportamento mediante reverse
engineering è impresa titanica e probabilmente utopistica. Il tutto per
avere poi la sola compatibilità a livello di api, che richiede comunque la
ricompilazione delle applicazioni (ovviamente di quelle che non fanno uso di
algoritmi scritti direttamente in assembler). Poi non è affatto detto che il
comportamento delle API sia perfettamente mappabile con le API offerte da X,
è probabilissimo che non vi possa essere una corrispondenza uno-ad-uno.
Insomma è un gran casino...
Alex

 saggiamente approfittato
Quel che dici e' vero ma se io ti do linux e ti do i sorgenti insieme,
cosa mi vieta di installarci un windowsmanager proprietario (Quartz) e
tutto un corredo di software proprietari ? se non sbaglio la GPL vieta
il link (per questo c'e' la LGPL) ma non l'uso insieme a sw
proprietario.
Se no sopra linux non potrei usare nessun sw proprietario.
Sto dicendo un nuvolo di fesserie ?
-- 
Ciao
Fabio

 BSD, ma piu' che altro un x86 al posto di un PPC.
considerazioni che si possono tranquillamente quotare, mi
tranquillizzano :)
Del resto, comunicazioni ufficiali di Steve e soci non mi pare ce ne
siano, a parte i "rumors" rumorosi ;-)
Tra l'altro forse alcuni equivocano tra li*nux e un*x :)
Il discorso degli exe se da un lato puň sembrare interessante, vista la
mole di programmi (belli e brutti) per x86, dall'altro non č che poi
appassioni tanto, visto che oramai Mac OS X ha tutto quello che serve.
Basta "integrare" meglio altri porting *nix e X11 soprattutto per avere
di tutto e di piů.
ciao
salvo

 libero...ma non è il caso di osx).
Ok quello che dicevo e' che se prendi Linux e ci metti sopra una
struttura proprietaria non violi la GPL. Adesso Os x include sia la
parte grafica sia il kernel in un tutt'uno ma non penso che sia un gran
problema scorporarle (XFree ad esempio gira sopra linux senza esserne un
tutt'uno).
ovviamente siamo nel campo del puro immaginario perche' ribadisco
secondo me Apple non ci pensa proprio al passaggio di kernel.
-- 
Ciao
Fabio

 darwin a linux, sbaglio?
visto e considerato che siamo in un gruppo sul mac...
scherzi a parte... credo che senza troppa difficolta` in un paio di
giorni si riuscirebbe a racimolare due eserciti di persone disposte a
battagliare a sciabolate per quale sia migliore...
ma la questione e` abbastanza poco profonda a mio avviso. o meglio,
talmente profonda da essere sostanzialmente lana caprina. che si traduce
con:
-> per l'utente non cambia una mazza <-
scelgano quello che vogliono e che lo facciano bene ;)
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

 > saggiamente approfittato
La BSD e` stata *volutamente* fatta in quel modo. E ne hanno
approfittato sostanzialmente *tutti*. Perfino qualche pezzo di Linux
viene da li... (pezzi che SCO peraltro aveva provato a sostenere fossero
sotto il loro copyright, sputtanati, ma tant'e`...)


 sotto il loro copyright, sputtanati, ma tant'e`...)
Si rumoreggia che anche lo stack TCP di windows odori fortemente di BSD
.... i soliti maligni ;-)
-- 
Ciao
Fabio

 .... i soliti maligni ;-)
no, e` un fatto per quanto ne so io vero e riconosciuto, nonche`
perfettamente legale.
anzi, una delle ragioni per cui BSD fece lo stack TCP IP (credo fosse
una delle prime cose sviluppate a Berkeley, quando era solo un'aggiunta
a'Unix'), era proprio che tutti potessero averne una buona
implementazione da usare (per diffondere il protocollo)...
io per lo meno la sapevo cosi` :)


 
A memoria mi sembra di ricordare  (ovviamente di cose lette, all'epoca
non ero stato neanche concepito) che tra quelli che avevano messo mano
al tcp e inventato i socket c'era anche il cofounde di sun Bill Joey.
-- 
Ciao
Fabio

 .... i soliti maligni ;-)
Tutti gli stack non stream based si basano sul codice dell'originaria
implementazione BSD. Che all'epoca non era affatto opensource (è opensource
net ed open bsd).
Alex

 e alla potenza - nonché alla tradizione - di un *vero* *nix?
Si`, sarebbe meglio.  E` anche fattibilissimo, in termini di
compatibilita` Linux -- FreeBSD lo fa, persino OpenBSD in qualche
misura.  Cosa intendi per X11 "seamless" non so, quello immagino che
potrebbe essere tecnicamente impossibile a seconda di quel che intendi.
Alex

 potrebbe essere tecnicamente impossibile a seconda di quel che intendi.
ciao Alex,
solo il fatto che sinora X11 e le sue applicazioni bisogna pur sempre
lanciarle da un xterm, attendere che questo si carichi se già non è
attivo, ecc...
Insomma non dà l'impressione di essere del tutto integrato nel sistema.
Se voglio lanciare xclock - tanto per essere banali - devo prima
lanciare xterm. Invece xcalc dovrebbe essere gestito come una normale
applicazione.
A questo punto tutte le applicazioni X11 sarebbero davvero un plus per
Mac OS. Ora sono ancora "un'aggiunta".
ciao
Salvo

 lanciarle da un xterm
Mica vero.
Io ho X11 fra i login item, e, a parte questo, non ho alcuna necessita
di usare xterm o del terminale per lanciare le applicazioni (anzi, io
xterm non lo apro neanche, per come mi sono impostato lo .xinitrc):
vanno bene il menu' in alto o degli Applescript da mettere in
/Applicazioni.
Daniele
-- 
"Shine, shine on, through the darkness and the pain.
 Shine, shine on, through the wind and the rain." (Riot - 1977)
STARGAZER: 
www.stargazer.it
 - Le stelle della scena Hard & Heavy!

 vanno bene il menu' in alto o degli Applescript 
Tanto per fare un esempio con xclock, che tu citi.
Salva come applicazione questa semplice linea:
do shell script "/usr/X11R6/bin/xclock -display :0.0"
e avrai xclock a portata di click.


.


 Io ho X11 fra i login item, 
e infatti può essere utile, ma, appunto, dovrebbe essere "attivo" già
con il SO stesso, in qualche modo...
l'integrazione non è ancora quella che dovrebbe essere. Di sicuro lo
sarà, o almeno io lo spero :)
ciao
Salvo

 con il SO stesso,
Si, no, non so.
- se a qualcuno non serve, farglielo caricare e' inutile.
- se lo integrano in maniera radicale nel sistema, puo' diventare piu'
difficile personalizzarlo (.xinitrc), gestirlo a piacere, etc.
Forse preferisco cosi' come e ora.
Non dimentichiamo che X11 serve a gestire applicazioni che lavorano in
maniera diversa da quelle tipiche di Aqua. Perche' sono state studiate
per lavorare in quella maniera, hanno un'interfaccia diversa
(finestro-centrica e non applicazione-centrica), regole di funzionamento
diverse, etc etc. 
Forzarle a funzionare come Aqua sarebbe appunto questo: una forzatura. 
Io sono abbastanza soddisfatto di come funziona X11 al momento: l'unica
ulteriore integrazione che probabilmente aggiungerei e' una migliore
gestione delle finestre, con il sistema in grado di riconoscere quelle
che sono figlie dello stesso processo e dividerle quindi in famiglie.
In questo modo sarebbe possibile utilizzare Mela-Tab per muoversi fra
tutte le applicazioni e non solo fra il resto del mondo ed X11 (stesso
discorso per Command + < per muoversi fra le finestre di una stessa
applicazione X11).



WWDC 2004, OS Foundation mission: «At the core of Mac OS X is Darwin, an
open source UNIX-based foundation incorporating operating system
services based on the popular BSD standard, high-performance networking
facilities, and support for multiple integrated file systems. Sessions
in this track will cover Darwin, advanced networking features integrated
into the core OS, and system-level security, authentication, and
cryptographic services as well as topics such as file systems, I/O Kit,
and Apple's highly-optimized X11 implementation.»
Nella pagina c'e` anche un iCal per seguire gli sviluppi e la
discussione.
(dal 28 giugno al 2 luglio, se non ho capito male)
Un tema trattato sarà il porting di applicazioni Unix e Linux,
ovviamente:
«Porting Linux and Unix applications to Mac OS X is easy. This session
will discuss tools and APIs designed to make it even easier. We will
cover all the basic concepts in bringing Unix applications to Mac OS X.»
ciao
Salvo

 applicazione X11).
Ecco, infatti, dici bene; questa è una delle cose che vorrei cambiare
anch'io. Per questo parlavo di maggiore integrazione.
ciao
Salvo

 > libero...ma non è il caso di osx).
Scusa... ma quale sarebbe l' 'interfaccia' grafica di Linux?


 di MarcoS?
non sei mica il solo: anche da appaiono grigi in Zuppon.
Ma perché?
ciao
Salvo

 Ma perché?
quasi ho il dubbio che mandi dei cancel...


 quasi ho il dubbio che mandi dei cancel...
e, di grazia, why isso doveresse farlo?
:)
Salvo

 e, di grazia, why isso doveresse farlo?
non so nemmeno se lo faccia, quindi :)


 wrote:
Wezzy, tu che lo vedi, che user agent usa MarcoS, che da noi genera
questi strani effetti per cui i suoi post sono "grigi"?
ciao,
Salvo

 wrote:

User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502)
Strana cosa, l'agent mi sembra al quanto standard, o che siamo entrambi
utenti fw e al solito fanno loro qualche casino?
-- 
Ciao
Fabio

 Mac OS. Ora sono ancora "un'aggiunta".
Penso che sicuramente Mac OS potrebbe "intercettare" la partenza di
un'app X11, se X11 non e` ancora attivo, e fare partire anzitutto X11 e
poi l'applicazione -- invece di demandare questo compito all'app stessa
o altre app ausiliarie come ora.  L'attesa supplementare pero` rimane a
meno che X11 non venga fatto partire in fase di startup (cosa che, se
vuoi, puoi anche fare gia` ora, penso).
Quello che secondo me resta "non seamless" e` che le app X11 non hanno
UI progettate secondo i parametri Aqua, soprattutto per gli shortcut (ma
non solo quelli) e` un problema (che so, per il paste devi fare ctrl-V
[o magari qualcosa d'altro ancora...] invece di Mela-V, e` proprio una
pizza...).  Rimediare _questo_ problema lo vedo molto molto difficile.
Alex

 utenti fw e al solito fanno loro qualche casino?
potrebbe essere, ma chi può dirlo?
Sta il fatto che i tuoi messaggi e reply appaiono, i suoi qui no. E
neppure da Enrico.
ciao
Salvo

 pizza...).  Rimediare _questo_ problema lo vedo molto molto difficile.
Sicuramente. Il compito è arduo, effettivamente, non lo metto in dubbio.
E a questo riguardo non è che - ipoteticamente - preferendo linux a BSD
si otterrebbe di meglio.
ciao
Salvo

 pizza...).  Rimediare _questo_ problema lo vedo molto molto difficile.
beh, pero` quando compili un'applicazione con QT mac invece che con
QT/X11 per esempio i vari Ctrl-V vengono rimappati in Mela-V...
magari....
al limite farlo proprio a livello di keyboard, e mappare la Mela sul
Ctrl... chissa` :)


 io non sono fastweb e non li vedo manco io.
Appunto: lui che invece usa il server news di FastWeb li vede. Forse il
server news di FastWeb ha avuto problemi a sincronizzarsi con gli altri?
Comunque questi sono gli ID dei messaggi di questo ramo che ha mandato
MarcoS: <eXlqc.3316$lk.2123@tornado.> <R1oqc.3512$lk.290@tornado.> e
effettivamente c'è qualcosa di strano. Il dominio è incompleto.


 rispetto al TCP/IP che pure ha i suoi begli annetti.
Oddio non era molto dissimile dall'appletalk ed altre tecnologie di rete
locale disponibili all'epoca. Il paragone con tcp/ip è molto improprio. Col
nome di SMB o CIFS è oggi il più efficiente protocollo di file sharing
disponibile.
Alex

 disponibile.
puoi dimostrare questa affermazione? e definire piu` precisamente
efficiente, ovvero il 'piu` veloce a parita` di connessione fisica',
'quello che impiega meno risorse a parita` di velocita', etc?


 si otterrebbe di meglio.
Certamente no, il problema e` praticamente separato dal kernel.
Alex

 insomma.
si, dal punto dell'utente certo. direi ben meno legate che classic
addirittura...
dal punto di vista dell'os invece le applicazioni unix sono processi a
tutti gli effetti con tutti i diritti del caso...
divertente questa ambivalenza...


 poco...) e` certo una cosa che potrebbero fare in due righe di codice...
sarebbe il minimo, per fare in modo che l'utente non debba preoccuparsi
di X11. 
In generale velocizzare tutti i rallentamenti che fanno presumere che il
sistema sta caricando "qualcosa d'altro", e in definitiva occorrerebbe
cliccare su un'app X11 senza chiedersi se è "aqua" o meno, se è "cocoa"
o "carbon" ecc. Comincia già ad essere così, e se vanno per questa
strada è un bene.
I messaggi dei forum che citavo facevano capire (speravano?) che si
potesse anche fare una svolta abbandonando BSD per un ipotetico linux, e
la mia preoccupazione (per così dire) era (è) che invece di migliorare
l'esistente (già solido e sicuro) si preferisse "sperimentare" soluzioni
incerte, tornando indietro: all'incompatibilità tra applicazioni "mac" e
"unix".
Dai titoli delle giornate della conferenza WWDC 2004 pare invece - per
fortuna - che si tratti di continuare, e di integrare quanto più
possibile nel *nix che già c'è, ovvero Mach, Darwin, BSD, NeXT ecc...:
"we will cover all the basic concepts in bringing Unix applications to
Mac OS X" ... "...all the core of Mac OS X is Darwin, an open source
UNIX-based foundation incorporating operating system services based on
the popular BSD standard... and Apple's highly-optimized X11
implementation".
Se questi sono i principi, le mie perplessità vengono a cadere.
ciao :)
Salvo

 'quello che impiega meno risorse a parita` di velocita', etc?
In effetti č dibattuto se sia "migliore" il CIFS o NFS in un certo ambito.
Quale sia la soluzione piů efficiente nel complesso dipende da tante
variabili oltre il protocollo. AFS mi pare confinato ad ambienti di ricerca
e comunque non ha avuto un grande seguito. WebDAV mi pare assai poco
efficiente. Gli darei un pari con NFS.
Alex

 posti esotici, ecc ecc.
Oddio, bisogna sempre vedere cosa altro è disponibile. L'NFS basato su RPC
ha storicamente avuto grossissimi problemi di sicurezza. Ancora oggi per la
gestione dinamica delle porte da parte dell'RPC pone grossi vincoli in
presenza di firewall.
Alex