Newsgroup: it.comp.macintosh
Titolo: Domanda "cattiva" per una risposta sincera

Hello boys. Avrei una domanda da fare che richiederebbe una risposta
fuori dai denti. Uso il mac dal 1985 e ci sono affezionato moltissimo.
Con il tempo ha preso sempre piu' spazio il suo utilizzo con Internet,
ed ora come ora non sono soddisfatto della velocita' con cui il mio mac
(vecchiotto) visualizza i contenuti della rete.
Mi ha fatto molto pensare l'aver utilizzato dei PC di amici, neanche
troppo potenti, e di aver riscontrato dei tempi di risposta decisamente
piu' brillanti.
Mi sono detto "e' il mio catorcio (6100) a non farcela piu'", e cosi' ho
riprodotto le condizioni di connessione dei pc su mac piu' recenti (iMac
266, G3 Yosemite 300 Mhz), restando piuttosto perplesso. Sono si' piu'
veloci del mio, ma molto meno di un fetentissimo Celeron 350.
C'e' qualche ragione per la quale, utilizzando i piu' diffusi e recenti
browser, i Mac (sistema operativo aggiornato sino all'8.6) debbano
essere strutturalmente piu' lenti dei PC?
Sapete, devo comprare una macchina nuova e mi girerebbero piuttosto le
balle dovendo spendere parecchio di piu' per avere (in questo specifico
settore) decisamente di meno.
Che mi dite?
Roberto

essere strutturalmente piu' lenti dei PC?
Fuori dai denti: con Netscape il Mac e' piu' veloce, ma non in modo
eclatante. IE e' sempre piu' veloce su PC, e questo (a voler essere
buoni) perche' Win e' costruito intorno a IE, che la fa da padrone.
Se ti serve solo per i collegamenti ad internet, vuoi spendere poco e
te ne freghi della vulnerabilita'... meglio un fetentissimo Celeron.
------
bale...@dada.it
 
http://zap.to/balestra
  ICQ#:14303012
" Ora mai che i baci tuoi piu' non mi sazian
  cerchero' un'altra donna dentro ai sogni di Tarzan... "

Roberto
Allora...vediamo:
1. Il modem. Quanto e' veloce? Esterno o interno? Se e' esterno che
tipo di porta utilizzi?
2. Il provider. La differenza e' abissale. Per farti un esempio, la
connessione alla rete con TIN adoperando un modem isdn e' piu' lenta
rispetto alla connessione con provider come Enter o HomeGate
utilizzando un modem a 56K (provare per credere).
3. Software. Se utilizzi IE, in buona parte dei casi tutto il
contenuto, ad esclusione del protocollo JAVA, viene caricato piu'
velocemente rispetto a Netscape. 
Per il resto...non saprei cosa dirti. Ho provato a collegarmi in rete
sia con il Mac (G3 300mhz) che con il PC (PII 333mhz) con modem
identici (56K) e la velocita' di trasferimento era in media
leggermente superiore in favore del Mac (e comunque MOLTO veloce).
Ciao!
Nikola

 leggermente superiore in favore del Mac (e comunque MOLTO veloce).
Non posso che confermare il fatto che il rendering delle pagine web su
PC (ho provato un AMD 300) č anni luce piů veloce che su Mac...OS. 
Ma non č una questione di hardware.
Sulla stessa macchina installando BeOS il rendering delle pagine SKIZZA
come e piů che su PC. Quindi il problema diventa: č colpa del MacOS o č
colpa dei browser che girano su MacOS??
Ho paura che la risposta giusta sia la prima...
Alberto

On Thu, 17 Jun 1999 12:42:29 GMT, 
bale...@antispam.dada.it
 (Marco
Balestra) wrote:
| Fuori dai denti: con Netscape il Mac e' piu' veloce, ma non in modo
| eclatante. IE e' sempre piu' veloce su PC, e questo (a voler essere
vade retro. satana :)))))
ed ora, molti web developer, usano IE per i test e snobbano netscape.
io mi sa' che sono l'unico a fare il contrario, ancora.. :(
non ho mai approfondito, ma... iCab assomiglia negli errori di layout
piu' a netscappo o a IE?
oha


Per la mia esperienza, pur limitata, le prestazioni di rete dei Mac sono
tristemente basse: in una rete Ethernet prestazioni decenti le si raggiunge
solo se connessi a un server tipo AS IP, o a server che "simulino" AS IP
(linux p.e.). Il limite, IMHO, e' intrinseco in MacOS: tra due mac (non
verso AS IP ma in peer to peer) anche passando da 10 a 100 Mbit si ottiene
un passaggio da circa 250 a 270 Kbyte/sec (un incremento ridicolo); le due
prestazioni in altri ambienti (p.e. PC) sono di circa 800 KB/sec e 2-3
MB/sec. C'e' qualcosa nel MacOS che blocca l'ingresso di informazioni
(utenti piu' esperti potrebbero spiegarti meglio perche').
La stessa cosa si riflette nella connessione PPP (che e' una connessione di
rete).
La colpa non e' dell'hw che e' ottimo, ma di MacOS. Stando alle promesse,
l'8.5 doveva migliorare in questo campo, ma fatti contingenti mi lasciano
dei dubbi...
Essendo conscio di quanto ti ho detto (fioriranno le smentite...) ho trovato
ridicolo lo sbandieramento che si e' fatto dell'iMac come della "macchina
per Internet": io credo che il problema sia proprio il SO. Chiaro che un 486
verra' battuto in ogni situazione, ma un pentium, con abbastanza memoria
(diciamo 24MB) sara' migliore per la pura navigazione.
Certo anche i browser fanno la loro parte (vedi gli altri post).
Verz!!!

piu' a netscappo o a IE?
Non saprei dirtelo, l'ho preso ma non ho ancora avuto il tempo di
provarlo.


(diciamo 24MB) sara' migliore per la pura navigazione.
Solo per un problema di browser. Gia' mettendo la cache su un disco
RAM le cose migliorano, e di parecchio.
La piu' grossa fregatura del MacOS e' sempre la stessa, ed e' stata
anche un bel vantaggio: la duplice struttura (datafork/resourcefork)
dei file... l'HFS, insomma, plus o meno che sia, e' meno performante
della becerissima (ma veloce) FAT.



(Rimuovere il trattino antispam per rispondere)

 essere strutturalmente piu' lenti dei PC?
Ci sono vari motivi per cui il tuo Mac sembra più lento del PC nel
collegamento ad internet: a partire dal provider che fornisce il servizio,
passando per il modem utilizzato, il browser utilizzato e infine (ma non
meno importante) gli eventuali disturbi sulla tua linea telefonica.
Il collegamento ad internet non é un compito molto impegnativo per il
computer vista la bassa velocità massima alla quale vengono trasmessi i
dati.
Quindi la causa del collegamento lento non é di sicuro da addebitarsi al Mac.
Dando per scontato che non puoi, nel giro di un giorno, cambiare provider,
modem e linea telefonica, ti consiglio di provare iCab (se non l'hai già
fatto): é un nuovo browser per Mac molto leggero e veloce ad interpretare
l'HTML.
Lo puoi trovare su 
www.icab.de
Ciao ciao
*********************************************************************
Il mio vero indirizzo é 
pu...@intercom.it
, ICQ#20390352
*********************************************************************
La Tariffa Urbana a Tempo diminuisce la liberta' di tutti gli utenti
Internet. Anche la tua.
http://notut.videonet.it/
*********************************************************************

 
(Remove the hyphen! Spambusters at work!)
*** Early bird gets the worm, 
   but the second mouse gets the cheese ***

Io questi valori li ho misurati sia con AT che con Tcp. Sicuramente il Tcp
e' piu' veloce, ma non astronomicamente (al piu' ho notato un 10% di
miglioramento), e rimane al di sotto di quanto realizzano altre piattaforme.
Anche degli Ftp (puramente Tcp) su rete locale non sono cosi' esaltanti.
Su una connessione PPP (generalmente al di sotto dei 64Kbit/sec) le
differenze con le altre piattaforme non possono essere cosi' evidenti
(altrimenti dovremmo spararci).
Adesso provero' a configurare il "mio" 7500 come dici tu. Trovo pero' strano
che il problema sia di rendering.
Non uso dei prodotti di misurazione delle velocita' di rete. Uso un metodo
empirico: un grosso file (o tanti file piccoli) e orologio alla mano. E i
dati che ho fornito sono stati ricavati cosi'.
In effetti sembra esserci un grosso overhead nella apertura/creazione di un
nuovo file, piu' che nel trasferimento puro. Credo che l'8.5 abbia
migliorato proprio questa pecca (ma queste sono tutte _impressioni_).
In passato ho provato anche a usare Dave per il trasferimento Mac to Mac
(via Tcp). Cio' che ho visto e' che il transfer rate aumenta, ma l'overhead
"esplode": andrebbe bene per grossi file mentre sui piccoli diventa una
palla al piede.
Verz!!!
Allora: ho appena provato a copiarmi da un server NT un file di 91milioni di
bytes; il Mac (appletalk of course) l'ha scaricato in 5' 17"; il Pc (tcp) in
3'02". (rispett. 280 KB/sec e 488 KB/sec, in genere va piu' veloce, strano).
Non sto a fare le prove inverse, un'altra volta magari.  La rete e' tutta
10Mbit e non c'e' traffico spurio a quest'ora..

 PC, ma ho provider diversi e questo conta.
La differenza si nota soprattutto offline: il problema è il rendering
delle pagine, non tanto la velocità di collegamento.
Se apri una pagina complessa su Exporer di Windoze la cosa è istantanea,
su Mac ci può mettere DIVERSI secondi, anche minuti. Non ho mai fatto
test di velocità specifici, però siamo sul 'diverse volte più veloce'...
Certo per l'utilizzo on-line la velocità di qualsiasi G3 è più che
sufficiente.
Alberto

Preferisco cosi' piuttosto che avere le estensioni.
In realta' la questione estensioni e' poco significativa... basterebbe
che il nostro gruppetto 4+4 fosse codificato diversamente nella
struttura ad albero invece che nel file, non e' a questo che servono
le doppie forche. Per capirci: un file non sa quale sia il suo nome,
in quanto e' contenuto nella struttura di gerarchia logica del disco
(la DIR, ovvero le cartelle). Le risorse, invece, rappresentano il
vero "problema": sono codificate in un secondo file parallelo che
viagga appaiato al primo. Ogni volta che accedi ad un file (ovvero che
chiedi all'OS di accedere ad un file) in realta' ne stai aprendo due,
se non devi pure sciropparti la ricerca nel Desktop Database.


On Thu, 17 Jun 1999 18:02:27 GMT, 
bale...@antispam.dada.it
 (Marco
Balestra) wrote:
| >io mi sa' che sono l'unico a fare il contrario, ancora.. :(
| Per testare le pagine finite uso IE3/Mac, IE4/mac, NN4/Mac, IE3/NT,
| IE4/95 e NN4/95... Anche se solo per poco, sono *tutti* diversi :-(
io ho rinunciato al java. cosi' non ho piu' tutte le grane se non
qualche problema di layout sulle table. IAW, cosi', mi basta un test
su exploder e uno su netscappo :)

On Fri, 18 Jun 1999 06:56:02 GMT, 
bale...@antispam.dada.it
 (Marco
Balestra) wrote:
| On Thu, 17 Jun 1999 21:17:03 +0200, 
ma...@info-sys.it
 (Maki) wrote:
| >Preferisco cosi' piuttosto che avere le estensioni.
| In realta' la questione estensioni e' poco significativa... basterebbe
| che il nostro gruppetto 4+4 fosse codificato diversamente nella
| struttura ad albero invece che nel file, non e' a questo che servono
| le doppie forche. Per capirci: un file non sa quale sia il suo nome,
| in quanto e' contenuto nella struttura di gerarchia logica del disco
e sommando questo ai problemi di frammentazione dell'hfs lo rendono
poco performante. mi piace pero' sottolineare che hfs e' piu'
stabile... nel lavoro di ufficio, IMHO, HFS e' piu' performante di
VFAT... se io perdo un disco, perdo mediamente 4 ore di lavoro.
| (la DIR, ovvero le cartelle). Le risorse, invece, rappresentano il
| vero "problema": sono codificate in un secondo file parallelo che
| viagga appaiato al primo. Ogni volta che accedi ad un file (ovvero che
| chiedi all'OS di accedere ad un file) in realta' ne stai aprendo due,
| se non devi pure sciropparti la ricerca nel Desktop Database.
non ho mai capito il vantaggio... soprattutto perche' ci sono altre
formattazioni (ext2) che funzionano molto bene e risolvono
(addirittura) il problema della frammentazione che tanto assilla gli
utenti di basso livello. (*ss*)
oha

 wrote:
| > >(linux p.e.). Il limite, IMHO, e' intrinseco in MacOS: tra due mac (non
| > >verso AS IP ma in peer to peer) anche passando da 10 a 100 Mbit si ottiene
| > >un passaggio da circa 250 a 270 Kbyte/sec (un incremento ridicolo); le due
| > Non siamo a questi livelli, ma la sostanza rimane.
| Scusate, ma io tiro circa un mega al secondo su
| una 10 (G3), sia tra Mac e Mac che tra Mac e PC.
| Sono fortunato?
IMHO e' impossibile. 10Mbit/sec => 1,25Mbyte/sec teorici. mettigli gli
headers dei pacchetti dei vari layer, poi i tempi impiegati per la
connessione... 
non e' che hai usato FTP? :)
| > La piu' grossa fregatura del MacOS e' sempre la stessa, ed e' stata
| > anche un bel vantaggio: la duplice struttura (datafork/resourcefork)
| > dei file... l'HFS, insomma, plus o meno che sia, e' meno performante
| > della becerissima (ma veloce) FAT.
| 
| Per la velocita' in rete, mi chiedo: non e' che
| semplicemente, come in altri casi, il MacOS e' piu'
| "prudente" di altri SO? Cioe' fa una paccata di
| controlli e lavora al risparmio per evitarsi rogne?
non so quanto, ma qualcosina in piu' la _deve_ fare, avendo le
resource separate.
| Non ci ho mai perso del gran tempo, ma mi sa che
| smanettando con OT Tuner si potrebbero migliorare
| un po' le prestazioni, tipo escludere a priori certe
| possibilita' a seconda dell'hardware usato. Un po'
| come trovare la stringa giusta per il modem...
no... l'HFS non lo cambi.. poi cambiare i settaggi della SCSI.. ma io
non lo farei mai. :)
oha

utenti di basso livello. (*ss*)
Il vantaggio della forca risorse e' lampante aprendo un file con
ResEdit: quella forca e' strutturata, per cui l'accesso alle singole
risorse nel file e' velocissimo.
Se provi ad aprire con VB su Win un file di programma avrai anche li'
delle pseudo-risorse, ma noti immediatamente il tempo che ci metti a
caricarle una per una, dovendo ragionare su una spalmatura lineare e
non strutturata di byte per ricavare delle pseudorisorse strutturate.
Quindi l'accesso di un prg ad una sua risorsa diventa + veloce con la
resfork, cosa che era ancora piu' importante quando non ti caricavi in
RAM tutto il programma (perche' la RAM era poca).
Per ovviare a questa lentezza sotto Win distribuisci le risorse in
varie DLL, ottenendo cosi' un applicativo grafico le cui risorse sono
distribuite su decine (se non centinaia) di file la cui funzione
risulta difficilmente comprensibile: ricostruisci in pratica una
strutturazione delle risorse avvalendoti del filesystem.


 se non devi pure sciropparti la ricerca nel Desktop Database.
Ok, volevo dire che preferivo il Mac quando se le prendeva di santa
ragione dai PC, figurati ora. E' una cosa generale: quando scorro
velocemente in "esplora risorse" la cartella windows vedo un sacco di
icone generiche che dopo qualche secondo vanno a posto. Su un p200mmx.
Su un LC non capita niente di tutto cio'. Ci metta il tempo che ci
vuole, ma la finestra si apre dove e come l'avevo lasciata sei mesi fa.
Non me ne faccio niente della velocita' se poi devo perdere il tempo
guadagnato a fare il lavoro che non fa lui. (leggi: ho il tasto F5
consumato a furia di usarlo...)


 come trovare la stringa giusta per il modem...
Mah, tutti i torti non li hai. Ho sentito parlare di RunShare, o
qualcosa del genere. Mi hanno detto che velocizza parecchio, soprattutto
i collegamenti a 100Mbit.


 test di velocità specifici, però siamo sul 'diverse volte più veloce'...
Sul G3 una pagina da 400k con tabellona si apre in qualche secondo con
NS e praticamente all'istante con iCab.


 
(Remove the hyphen! Spambusters at work!)
*** "Energizer Bunny arrested, charged with battery." ***

On Fri, 18 Jun 1999 09:36:43 GMT, 
bale...@antispam.dada.it
 (Marco
Balestra) wrote:
[...]
| Quindi l'accesso di un prg ad una sua risorsa diventa + veloce con la
| resfork, cosa che era ancora piu' importante quando non ti caricavi in
| RAM tutto il programma (perche' la RAM era poca).
| Per ovviare a questa lentezza sotto Win distribuisci le risorse in
| varie DLL, ottenendo cosi' un applicativo grafico le cui risorse sono
| distribuite su decine (se non centinaia) di file la cui funzione
| risulta difficilmente comprensibile: ricostruisci in pratica una
| strutturazione delle risorse avvalendoti del filesystem.
si. ma non lo trovo sbagliato ne' sconveniente. unix e' stato lodato
fin dall'inizio per diverse ragioni, una di queste era la versatilita'
del sistema che rende comodo l'interscambio di dati fra una
applicazione e l'altra.
effettivamente, i "comandi" unix non sono sempre molto performanti, ma
si combinano facilemte insieme (anche con shell scripts) ed e' molto
semplice fare applicazioni complesse.
oha

 wrote:
| Sicuro che no. Per l'ftp non ci vuole Appleshare IP?
questa e' grossa :)
ftp sta per file trasnfert protocol, della suite tcp/ip 
esiste da prima degli home computer.
| Io metto in condivisione (con DAVE o fra Mac e Mac)
| i dischi che mi servono, lancio appletalk e passo i
| files che mi servono. L'ultima volta che ho usato il
| PC (Pentium 133, una ciofeca) era per passare tutto
| l'Hard Disk su Mac, per poi usare il tutto su VPC.
| Beh, mi dico, attacco le due macchine, accendo la rete
| e via. Poi mi viene un'idea balzana: perche' non
| farmi direttamente un CD? 
| Preso dalla frenesia tecnologica collego, apro Toast,
| ci trascino il disco del PC, elimino dalla copia i vari
| files di sistema tipo win386.swp e tutta la cartella
| di DAVE (che si tiene i vari logfiles aperti, quindi
| non e' copiabile), lancio la scrittura e mi faccio un
| backup via ethernet da hard disk PC a CDR Mac.
| Teoricamente, 300K/sec bastano e avanzano per scrivere
| un CD a 2x, ma in pratica sappiamo benissimo che non
| e' mai abbastanza veloce :-)
se hai 32 Mb o piu' di cache in scrittura su toast, ci riesci
tranquillamente.
con il 9600, qui in ufficio, scrivo le tracce leggendole in ram e
scrivendole in seguito, con immenso spreoco di tempo ma godimento
surreale.
non vedo l'ora di bruciare i cd da ramdisk, :)
| Beh, cmq, a parte questa bullata della quale non smettero'
| mai di vantarmi, le copie in ethernet girano tra i 700K
| e il mega/secondo (che, sigh, e' piu' o meno la velocita'
| del Jaz-2!)
| > no... l'HFS non lo cambi.. poi cambiare i settaggi della SCSI.. ma io
| > non lo farei mai. :)
| 
| Ah, no, io intendevo dire (e l'ho detto): per le copie in rete.
| E' Open Transport che secondo me gira col freno a mano
| tirato. Si fa delle mene tipo "ma, e se sto lavorando
| su un modem a 9600, con una tempesta magnetica in corso,
| e il server va momentaneamente in crash ma si riprende
| subito? Meglio stare li' un po' ad aspettare..."
| Cioe', piuttosto che darci dei problemi preferisce andare
| coi piedi di piombo. In questo caso, invece, a me piacerebbe
| un OT che mi dicesse immediatamente "nessuna risposta".
non e' nella filosofia mac. diciamo che sarebbe non male ridurre i
timeout. capitano degli errori sulla rete. forse sono quelli?
| Preferirei che mi crashasse la macchina 2 volte al giorno
| per scarsita' di controlli, ma almeno per il resto della
| giornata girerei al doppio della velocita'.
non dirlo nemmeno per scherzo. :-<
| OT Tuner permette l'accesso a parametri di Open Transport
| dei quali nemmeno conosco il nome, figurarsi la funzione :-)
| ma sono sicuro che smanettando li' dentro (IM alla mano)
| qualche risultato si puo' ottenere...
puo' essere. io, d'altra parte, ho notato migliorie (anche di
stabilita del sistema) passando da thin.ethernet a rj45 e poi con
switch.
cya
oha

 
(Remove the hyphen! Spambusters at work!)
*** when free speech is outlawed, 
    only outlaws will be able to speak freely. ***

 wrote:
| Ok. Adesso mettiamo insieme i pezzi: per poter fare
| una rete TCP/IP via ethernet da un mac all'altro, non
| ci vuole Appleshare IP? No? Ok. Comunque, io accendo
penso di si.
| la rete come ho sempre fatto, con "Sharing" da una
| parte e il Chooser dall'altra.
si. ma se sei su un segmento di rete che "porta" solo tcp/ip, devi
usare quello.
con appleshare IP lo fai comodamente, altrimenti devi installare un
software di tunneling su IP. in pratica il tcp/ip e' un protocollo a
packettizzazione, quindi gli puoi montare "dentro" altri protocolli,
come l'AT.
| <snip>
| > se hai 32 Mb o piu' di cache in scrittura su toast, ci riesci
| > tranquillamente.
| Mima. Cioe', 32 Mb di cache? Ho i 4 mega "standard"...
| Nono, e' proprio che scheggia. Il calcolo dei quasi-1MB/sec
| e' fatto un po' a occhio (cioe', copia un file grosso e
| guarda quanto ci mette), pero' la velocita' e' quella.
non e' che sei in full duplex?
| > | Preferirei che mi crashasse la macchina 2 volte al giorno
| > | per scarsita' di controlli, ma almeno per il resto della
| > | giornata girerei al doppio della velocita'.
| > non dirlo nemmeno per scherzo. :-<
| 
| Lo ripeto: mi piacerebbe poter dire al computer "Senti,
| non sto facendo niente di importante, solo girare un po'
| in rete e guardarmi le donnine nudeAAAAAANONONONO i siti
| culturali sulla fisica quantistica. Se ti sembra che magari
| forse puo' darsi che i dati stiano arrivando cosi' cosi',
| fregatene, che a fare un reload ci metto meno che aspettare
| te che ti metti d'accordo col server". Ecco. Non voglio
| una rete perennemente instabile, ma una rete alla quale
| posso dire quando sono disposto a perdere tempo e quando
| sono disposto a perdere dati.
onestamente, non mi sembra il caso. :)
IAW, non ci guadagneresti, poi, cosi' tanto.
cya
Oha

applicazione e l'altra.
Si, ma la path dependancy spesso pesa... Non su un sistema
"monolitico", ma certamente per lo "iuser".


 
(Remove the hyphen! Spambusters at work!)
"Windows 95: A 32 bit extension and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company, that can't stand
1 bit of competition."

SNIP
Il problema è che un ragazzino che studia informatica alle superiori è
perfettamente in grado di scrivere un programnma che gestisca un
database per controllare quali DLL sono installate, da quali programmi
sono usate e che versioni servono al dato programma.
La soluzione migliore sarebbe quella di includere le varie DLL nella
cartella della applicazione (il che permetterebbe la reinstallazione
solo sel sistema operativo e anon anche delle varie applicazioni)
anche perchè non è detto che se una applicazione ti installa la DLL
1.0.0.1 l'applicazione che ti ha installato la 1.0.0.0 sia contenta.
Ma si sa, da uno che ha detto che 640k sarebbero stati sufficienti per
tutti...
Saluuuuuuuto
Freddy
Togli il punto per la reply.

On Tue, 22 Jun 1999 00:11:47 GMT, 
gensuke.@flashmail.com
 (Freddy
Krueger) wrote:
| La soluzione migliore sarebbe quella di includere le varie DLL nella
| cartella della applicazione (il che permetterebbe la reinstallazione
| solo sel sistema operativo e anon anche delle varie applicazioni)
| anche perchè non è detto che se una applicazione ti installa la DLL
| 1.0.0.1 l'applicazione che ti ha installato la 1.0.0.0 sia contenta.
questo e' un'altro discorso. 
se le libs cambiassero nome quando cambiano funzionalita', uno
potrebbe sempre trovare la vecchia e la nuova. non dipende questo
dalla partizione, pero' :o)
cya
oha

 wrote:
| > non e' che sei in full duplex?
| 
| Snort. Sono a fetentissimi 2x sul mio writer preistorico.
| Mi attacco in Appletalk via ethernet, di piu' non so.
| Nel caso specifico della "bullata", ero collegato tra Mac
| e PC come descritto sopra. PC per terra, cavo xover, Mac
| sul tavolo. Full duplex? Mi sa di roba telefonica :-)
se usi un cavo cross rj45 sei in full-duplex. se ti colleghi ad un hub
sei (usualmente) in halfduplex.
in pratica, il full va' quasi al doppio per trasferimenti "in pari".
| Ribadisco che non sto tenendo in piedi un network
| aziendale. Chemmi frega se mi crasha il computer
| mentre vado a spasso per i siti web? Anche RaiUno
| salta ogni tanto, mica mi sveno...
| Siccome sono l'unico utente della "mia" rete, cioe'
| anche l'amministratore e l'unico che potrebbe avere
| conseguenze dal fatto di avere un client instabile,
| la situaz di cui sopra non mi dispiacerebbe. Oh, del
| resto Jaz e Zip permettono di spegnere la verifica
| dei dati in scrittura. Il Jaz e' abbastanza veloce,
| e ci metto roba VITALE per il mio lavoro (solo per
| il trasporto, mica per il backup), quindi la verifica
| resta accesa. Ma sugli Zip ci faccio il backup del
| backup di roba che boh magari una volta o l'altra
| gli do' un'occhiata. Se resta giu', bene. Se no,
| pazienza. Quelle rare volte che uso lo Zip per roba
| seria, accendo la verifica e ci dormo su...
| Che c'e' di male?
che progettare un sistema piu' configurabile significa esporsi spesso
a problemi.
la apple ha sempre optato, IMHO, per sistemi di facile configurazione
(configurare uno switch e un router per un segmento di una rete
aziendale in tcp/ip non e' una cazzata, anzi).
appletalk e' lentissimo, ma e' molto comodo per configurazioni
"volanti" e semplici
cya
oha

 oha
Perché con l'hub si va half duplex? (forse sono un pò OT :) )
In fondo colleghi sempre TX ed RX, anche se non li incroci? O non
c'entra niente?
Ciao,
Joshua
-- 
Outside of a dog a book is a man's best friend.
Inside of a dog is too dark to read
                                Groucho Marx

 in pratica, il full va' quasi al doppio per trasferimenti "in pari".
Argh!!!!!!!!
Il full duplex deve essere gestito dalla scheda di rete, ed e'
indipendente dal tipo di collegamento (diretto con cavo incrociato) o
tramite hub.
-- 
Sergio Aletta
nyr...@thebrain.net
Note: 
the address at the left of the @ is ROT13 encoded

 wrote:
| 
| > 
| > se usi un cavo cross rj45 sei in full-duplex. se ti colleghi ad un hub
| > sei (usualmente) in halfduplex.
| > 
| > in pratica, il full va' quasi al doppio per trasferimenti "in pari".
| Argh!!!!!!!!
| 
| Il full duplex deve essere gestito dalla scheda di rete, ed e'
| indipendente dal tipo di collegamento (diretto con cavo incrociato) o
| tramite hub.
tutti gli hub che ho visto sono half.
alcune schede (tutte le 100) sono full
quindi _spesso_ se ci si collega ad un'hub si va' in half_duplex
mentre succede spesso che collegando due computer direttamente si vada
in full_duplex
ho semplificato troppo, prima, eh? :)
oha