View Full Version : MacFuse & NTFS: a che punto siamo?
Mi piacerebbe poter leggere e scrivere HD in rete NTFS, quindi penso di aver bisogno di macfuse, ma a che punto siamo?Bisogna destreggiarsi tra opzioni di compilazione o è una cosa semplice?Funziona?Si bene, si a volte, no mai, insomma chi lo usa mi dica il punto della situazione :)
Dimenticavo, si lo sò che ci sono altri thread sull'argomento, ma volevo vedere un pò come andava ora :)
Ti dirò che io l'avevo installato senza fatica qualche mese fa e funzionava molto bene e soprattutto al primo colpo senza smanettere.
Ho formattato e riprovato la settimana scorsa ma non sono più riuscito a far nulla... e non ricordo più cos'avevo fatto la volta prima... :muro:
Ah, non avevo compilato niente di niente, forse avevo inserito solo qualche comando da terminale facendo direttamente copia-incolla da un sito.
comunque dopo che lo si installa funziona?Cioè non vorrei faticare per installarlo e poi ritrovarmi dopo una settimana a rifare tutto o a capire perchè non và :>
p.s. ho scoporto che in rete posso leggere/scrivere, ma mi serve comunque sapere se stop macfuse funziona :D
Si, se ci riesci funziona benissimo!
é un po lento in scrittura, quindi ad esempio non puoi fare montaggio video su un disco esterno ntfs.
Però cmq non dovrebbe mancare in un mac.
Non dovrebbe essere difficile installarlo, ci vorrà al massimo un quarto d'ora se trovi la procedura giusta. Io però non la trovo più...:(
p.s. ho scoporto che in rete posso leggere/scrivere, ma mi serve comunque sapere se stop macfuse funziona :D
Cosa intendi per stop macfuse?
Prova a guardare qui:
http://www.hwupgrade.it/forum/showthread.php?t=1498488
Scrivo qui perchè se trovi una soluzione mi interesserebbe!
stop = sto = questo :asd:
ho sbagliato scrivendo :)
cmq ho già visto :)
lorenzo999
16-09-2007, 13:01
sull'ibook ha funzionato al primo colpo, sull'imac non solo non funziona, ma ora il disco non mi viene montato nemmeno in lettura.
morale: non è ancora una scienza esatta.
ok figo :D
ma hai fatto le stesse identiche cose sia sull'ibook che sull'iMac ? :o
mi pare strano o.o
Più che altro mi sembra lento.
Secondo me l'HD esterno è meglio in HFS+ e per PC usi MacDrive.
Hai anche meno problemi con i nomi dei files (windows è molto più schizzinoso dei Mac a riguardo).
Indubbiamente se usi un disco esterno è meglio formattarlo in hfs+, qui non ci piove. Però succede di dover scrivere su dischi di amici oppure sul disco esterno in comune col pc windows. Insomma, adesso come adesso non posso neanche cancellare un misero file!
il disco esterno verrebbe utilizzato oltre che da me da altre 3 persone con windows e dovrebbe rimanere attaccato a un computer windows, che deve poterci scrivere sopra.
Sinceramente di macdrive ho solo sentito parlare, ma se lo mettessi me lo rileverebbe come disco normale? O.o
Da quello che so io si... però non l'ho mai provato.
Sempre per sentito dire le prestazioni di macdrive sono decisamente migliori di quelle di macfuse...
Solo che macdrive costa 50 dollaroni a licenza!! :sofico:
Economicamente ti conviene smanettare con macfuse!
Io c'ero riuscito... non so come! :ciapet:
il disco esterno verrebbe utilizzato oltre che da me da altre 3 persone con windows e dovrebbe rimanere attaccato a un computer windows, che deve poterci scrivere sopra.
Sinceramente di macdrive ho solo sentito parlare, ma se lo mettessi me lo rileverebbe come disco normale? O.o
Beh se è usato principalmente in ambito Windows forse non è il caso.
Comunque MacDrive rende l'HFS+ un filesystem nativo per windows, senza penalizzazione prestazionali (che io sappia) come Fuse (che è n driver scritto in user space, quindi non molto efficiente). Il disco lo vede come qualsiasi disco FAT32 o NTFS... ma sull'icona c'è la mela sopra ;)
il disco esterno verrebbe utilizzato oltre che da me da altre 3 persone con windows e dovrebbe rimanere attaccato a un computer windows, che deve poterci scrivere sopra.
Sinceramente di macdrive ho solo sentito parlare, ma se lo mettessi me lo rileverebbe come disco normale? O.o
Se il disco viene collegato sempre ad un PC Windows è molto più semplice abilitare la condivisione del disco ed utilizzare la rete per scrivere sul disco. ;)
Beh se è usato principalmente in ambito Windows forse non è il caso.
Comunque MacDrive rende l'HFS+ un filesystem nativo per windows, senza penalizzazione prestazionali (che io sappia) come Fuse (che è n driver scritto in user space, quindi non molto efficiente). Il disco lo vede come qualsiasi disco FAT32 o NTFS... ma sull'icona c'è la mela sopra ;)
Non è assolutamente detto che un driver user-space sia meno efficiente di un driver kernel-space, è solo più complesso da scrivere e va maggiormente ottimizzato per raggiungere prestazioni comparabili, tuttavia i vantaggi che derivano da un approccio user-space sono innumerevoli. :p
Se il disco viene collegato sempre ad un PC Windows è molto più semplice abilitare la condivisione del disco ed utilizzare la rete per scrivere sul disco. ;)
si però poi lo dovrei pure attaccare via usb a qualche mac :D
Non è assolutamente detto che un driver user-space sia meno efficiente di un driver kernel-space, è solo più complesso da scrivere e va maggiormente ottimizzato per raggiungere prestazioni comparabili, tuttavia i vantaggi che derivano da un approccio user-space sono innumerevoli. :p
Tipo ? O.o
si però poi lo dovrei pure attaccare via usb a qualche mac :D
In tal caso NTFS-3g è l'unica soluzione.
Tipo ? O.o
Stabilità?! Se un driver kernel-space esegue un'operazione scorretta c'è rischio che oltre a crashare si "porti dietro" l'intero sistema, questo non accade con i driver user-space che in seguito ad un crash vengono ricaricati e l'utente difficilmente si accorge dell'accaduto a meno che non vengano effettuate delle segnalazioni. ;)
EDIT: un esempio, Windows Vista è l'unico sistema operativo desktop a caricare i driver video in user-space. Al momento questa scelta ha causato un decremento delle prestazioni da parte della schede video (eccetto di quelle Intel che sembra già aver realizzato un ottimo driver). Ecco quello che succede in seguito ad un crash del driver video: link (http://imieiguaiconvista.blogspot.com/2007/08/vista-rock-solid.html), un crash simile di un driver kernel-space avrebbe portato al blocco dell'intero sistema o peggio ad un kernel panic, indipendentemente dal sistema operativo.
ok grazie della spiegazione ^_^
Non è assolutamente detto che un driver user-space sia meno efficiente di un driver kernel-space, è solo più complesso da scrivere e va maggiormente ottimizzato per raggiungere prestazioni comparabili, tuttavia i vantaggi che derivano da un approccio user-space sono innumerevoli. :p
Comunque quello che volevo dire è che Fuse non è il sistema per fare driver nativi su Mac. Avrà i suoi vantaggi su Linux perchè questo è un kernel monolitico e integrare driver nel kernel è problematico sotto molti punti di vista. Ma OS-X ha un microkernel, la maggior parte dei drivers sono già user-space, e ci sono le giuste API per farlo (IO kit). Fuse è un inutile doppione probabilmente mal-portato dall'ambiente Linux e a quanto pare le prestazioni ne risentono.
Comunque quello che volevo dire è che Fuse non è il sistema per fare driver nativi su Mac. Avrà i suoi vantaggi su Linux perchè questo è un kernel monolitico e integrare driver nel kernel è problematico sotto molti punti di vista. Ma OS-X ha un microkernel, la maggior parte dei drivers sono già user-space, e ci sono le giuste API per farlo (IO kit). Fuse è un inutile doppione probabilmente mal-portato dall'ambiente Linux e a quanto pare le prestazioni ne risentono.
OK, allora siamo d'accordo, FUSE è nato come supporto per il kernel Linux e neppure li da il meglio di se perché tanto dipende dal driver e non dall'interfaccia.
Non sono invece d'accordo sul fatto che XNU sia un microkernel, io lo definirei un macrokernel modulare (o ibrido come lo chiamano alcuni) dato che non ha le caratteristiche di un microkernel e neppure di un kernel monolitico... ma questo discorso si protrarrebbe troppo a lungo visto che neppure i guru in fatto di kernel riescono a dare delle definizioni sempre valide. :D
Non sono invece d'accordo sul fatto che XNU sia un microkernel, io lo definirei un macrokernel modulare (o ibrido come lo chiamano alcuni) dato che non ha le caratteristiche di un microkernel e neppure di un kernel monolitico... ma questo discorso si protrarrebbe troppo a lungo visto che neppure i guru in fatto di kernel riescono a dare delle definizioni sempre valide. :D
La mia opionione, dopo averne lette tante, è che OS-X è strutturalmente un microkernel nel quale sono stati aggiunte nel kernel alcune parti dell'OS BSD che potevano benissimo essere messe fuori.
Sono state messe nel kernel per motivi prestazionali e perchè è codice molto maturo e stabile: sono funzionalità standard di Unix che non richiedono di essere modificate o aggiornate e quindi non danno problemi di affidabilità.
Linux, invece, è strutturalmente un kernel monolitico dove con vari magheggi sono riusciti a mettere i drivers sotto forma di plug-in o addirittura in user-space con FUSE. Ma rimane monolitico.
Non sono invece d'accordo sul fatto che XNU sia un microkernel, io lo definirei un macrokernel modulare (o ibrido come lo chiamano alcuni) dato che non ha le caratteristiche di un microkernel e neppure di un kernel monolitico...
da questa descrizione sembra molto simile a quello di BeOS, funziona allo stesso modo?
La mia opionione, dopo averne lette tante, è che OS-X è strutturalmente un microkernel nel quale sono stati aggiunte nel kernel alcune parti dell'OS BSD che potevano benissimo essere messe fuori.
Sono state messe nel kernel per motivi prestazionali e perchè è codice molto maturo e stabile: sono funzionalità standard di Unix che non richiedono di essere modificate o aggiornate e quindi non danno problemi di affidabilità.
Strutturalmente XNU nasce come microkernel in quanto derivato da Mach 3.0; tuttavia l'introduzione dello stack di rete, del sistema di messaggistica tra i processi, la gestione dei file system POSIX-like, NFS (e altro) ereditati da BSD4.4, eseguiti in kernel-space rendono XNU un kernel molto differente dal concetto di microkernel. In più pur essendoci l'evoluto I/O kit molti driver (anche driver di stampa) sono di tipo kernel-space.
EDIT: VFAT, NTFS e gli altri file system integrati in Mac OS X sono tutti gestiti a livello di kernel, direi che siamo lontani dal microkernel. :D Al momento credo che solo Minix e forse il kernel di Windows CE siano microkernel a tutti gli effetti.
Linux, invece, è strutturalmente un kernel monolitico dove con vari magheggi sono riusciti a mettere i drivers sotto forma di plug-in o addirittura in user-space con FUSE. Ma rimane monolitico.
Su questo non si discute. Linux nasce (per volontà di Linux Torvalds) come kernel monolitico ma modulare ed adotta gli stessi concetti che sono stati alla base del kernel NT fino alla versione 5.2 (la 6.0 è molto più simile al concetto di macrokernel, come XNU). :)
da questa descrizione sembra molto simile a quello di BeOS, funziona allo stesso modo?
Effettivamente lo è dato che il concetto di kernel ibrido/macrokernel modulare è nato con BeOS (anche NeXTStep era interessata all'utilizzo del kernel di BeOS ma l'affare non andò in porto e ripiegò su Mach e BSD).
VFAT, NTFS e gli altri file system integrati in Mac OS X sono tutti gestiti a livello di kernel, direi che siamo lontani dal microkernel. :D Al momento credo che solo Minix e forse il kernel di Windows CE siano microkernel a tutti gli effetti.
Sicuro che i filesystem sono in kernel space su OSX?
Sì l'ultimo Minix (4) concettualmente è molto fico. Addirittura si "autoripara" in modo trasparente quando i processi vanno in crash.
Comunque secondo me al 90% l'NTFS su Leopard sarà supportato anche in scrittura. Ora c'è un progetto open-source che ha un'implementazione affidabile (quella utilizzata da Fuse) e pare che uno dei suoi sviluppatori lavorasse per Apple...
Effettivamente lo è dato che il concetto di kernel ibrido/macrokernel modulare è nato con BeOS (anche NeXTStep era interessata all'utilizzo del kernel di BeOS ma l'affare non andò in porto e ripiegò su Mach e BSD).
Fai confusione! :D
BeOS è molto successivo al NeXT-Step basato su Mach (microkernel).
Non era NeXT che voleva comprare il BeOS, ma Apple.
Solo che il boss della Be (ex dirigente Apple) pare appia chiesto troppo e la Apple ha comprato la NeXT. Anche se credo il motivo non siano stati i soldi perchè la NeXT è costata molto di più di quanto la Be aveva chiesto. E comunque la Apple ha fatto un affare: con la NeXT ha "comprato" anche Jobs e senza di lui ora probabilmente Apple sarebbe fallita.
Sicuro che i filesystem sono in kernel space su OSX?
I log di sistema mostrano il caricamento di un'estensione del kernel (quindi caricamento in kernel-space) quando viene utilizzato un file system VFAT o NTFS.
Se file system "secondari" come questi sono kernel-space immagino che anche HFS/HFS+ lo siano. :p
Sì l'ultimo Minix (4) concettualmente è molto fico. Addirittura si "autoripara" in modo trasparente quando i processi vanno in crash.
L'ho installato su macchina virtuale... :D veramente interessante, almeno per scopi didattici. Inoltro il tarball dei sorgenti è solod i 600 kB se non erro. :eek:
Comunque secondo me al 90% l'NTFS su Leopard sarà supportato anche in scrittura. Ora c'è un progetto open-source che ha un'implementazione affidabile (quella utilizzata da Fuse) e pare che uno dei suoi sviluppatori lavorasse per Apple...
Speriamo che Microsoft dia una mano, sarebbe un netto miglioramento dell'interoperabilità. Comunque quello che attendo con ansia è ZFS. :read:
Fai confusione! :D
BeOS è molto successivo al NeXT-Step basato su Mach (microkernel).
Non era NeXT che voleva comprare il BeOS, ma Apple.
Solo che il boss della Be (ex dirigente Apple) pare appia chiesto troppo e la Apple ha comprato la NeXT. Anche se credo il motivo non siano stati i soldi perchè la NeXT è costata molto di più di quanto la Be aveva chiesto. E comunque la Apple ha fatto un affare: con la NeXT ha "comprato" anche Jobs e senza di lui ora probabilmente Apple sarebbe fallita.
Non conoscevo i dettagli. :asd:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.