WinFS Beta 2 il prossimo mese

WinFS Beta 2 il prossimo mese

Al prossimo TechEd 2006 in Boston verrà presentata la seconda beta di WinFS

di pubblicata il , alle 09:09 nel canale Programmi
 
I migliori sconti su Amazon oggi
-37%

Amazfit Bip 5, 46 mm, Smartwatch, Schermo grande, chiamate Bluetooth, Alexa, GPS, durata della batteria di 10 giorni, fitness tracker con frequenza cardiaca, monitoraggio dell'ossigeno nel sangue

89.90 56.90€ Compra ora
-5%

TCL 55T6C 55'' QLED TV 4K HDR, FireTV (SmartTV con Dolby Vision e Atmos, HDR10+, Premi e Chiedi ad Alexa)

349.00 329.90€ Compra ora
-5%

TCL 43T6C 43'' QLED TV 4K HDR, Fire TV (Smart tv con Dolby Vision e Atmos, HDR10+, Premi e Chiedi ad Alexa)

259.90€ Compra ora
94 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
darkquasar26 Maggio 2006, 14:40 #71
Originariamente inviato da: Taym
In realtà, sebbene la cosa sia nota a pochi, NTFS supporta i symbolic links (o junction points) sin dalla versione introdotta con Windows 2000, e funzionano in modo analogo a quanto accade sui File Systems *nix.

"linkd" è il comando per creane e gestirli.

Mark Russinovic di Winternals ha fatto "junction" allo stesso scopo.

Che io sappia NTFS non ha alcuna feature in meno rispetto ai FS del mondo *nix; piuttosto una più raffinata struttura di permessi ed accessi.

ma il punto é: visto che NTFS é uno standard chiuso e crea problemi per la futura accessibilità dei dati nonché per la loro trasportabilità, cosa mi offre che non sia offerto anche da FS con standard aperti? Niente...
diabolik198126 Maggio 2006, 14:41 #72
Originariamente inviato da: darkquasar

+ che altro, cercare di provocare le altre persone é trollare...


Perchè con quello che ha scritto cosa pensi che stia facendo?
darkquasar26 Maggio 2006, 14:44 #73
Originariamente inviato da: diabolik1981
Perchè con quello che ha scritto cosa pensi che stia facendo?

ha espresso la sua opinione, che tra l'altro mi sembra anche abbastanza ragionevole....

La "provocazione" mica é costituita dal fare domande retoriche e da come si mettono gli accenti e le virgole, ma dal contenuto del messaggio...
Taym26 Maggio 2006, 16:04 #74
ma il punto é: visto che NTFS é uno standard chiuso e crea problemi per la futura accessibilità dei dati nonché per la loro trasportabilità, cosa mi offre che non sia offerto anche da FS con standard aperti? Niente...

Beh, il punto del mio messaggio era tecnico, riguardo le features di NTFS. Non vi erano implicazioni ulteriori.
Il punto del tuo mi sembra invece sessere: il rischio che qualche evento possa far scomparire dal mondo il know-how riguardo l'NTFS (e tutto ciò da cui esso è ricavabile) è più alto di un evento analogo che faccia sparire il know-how riguardo i vari FS *nix (e tutto ciò da cui esso è ricavabile), rendendo i dati su NTFS inaccessibili prima di una semplice migrazione ad altro.
Ho capito bene i problemi a cui ti riferisci?
E' un'opinione che, come tutte, rispetto, naturalmente, ma non credo di poterla condividere, sinceramente. Non riesco ad immaginare eventi che possano portare ad alcuno dei due scenari di cui sopra che non siano di proporzioni catastrofiche, ed ugualmente improbabili.
bist26 Maggio 2006, 17:11 #75
Originariamente inviato da: Criceto
L'XML è un formato testuale, notoriamente inefficiente da digerire per un computer. Meglio un dump binario della struttura dati dell'applicazione (quello che sono in genere i vari "formati" dei files).

Come sempre non esiste una cosa migliore in assoluto, ma migliore per uno scopo. Se devi immagazzinare una mole enorme di informazioni con problemi di performance usi DBMS, ma se devi produrre file di medie dimensioni portabili e velocemente leggibili ormai dappertutto, XML è ottimo. Inutile dire che il definire un'entità "appuntamento" o "documento video" ricade nell'ultimo caso. L'inefficienza sarebbe usare un file binario per la sua illeggibilità.
Criceto26 Maggio 2006, 17:17 #76
Originariamente inviato da: bist
Come sempre non esiste una cosa migliore in assoluto, ma migliore per uno scopo. Se devi immagazzinare una mole enorme di informazioni con problemi di performance usi DBMS, ma se devi produrre file di medie dimensioni portabili e velocemente leggibili ormai dappertutto, XML è ottimo. Inutile dire che il definire un'entità "appuntamento" o "documento video" ricade nell'ultimo caso. L'inefficienza sarebbe usare un file binario per la sua illeggibilità.


L'XML va bene come formato di interscambio.
Non come formato nativo quando le prestazioni e l'efficienza (anche di ram) sono fondamentali, come in questo caso.
D'altra parte la leggibilità a che ti serve per un plug-in?
Ti sei mai spulciato con un editor un plug-in di photoshop?
bist26 Maggio 2006, 17:19 #77
Originariamente inviato da: darkquasar]Con Google Dekstop Search poi, visto che prima lo si é
Non so se innovativo ma lo reputo abbastanza brutto. Un po' meglio è MSN Search o come si chiama, ma anche lì ci sono i soliti problemi.

Ma l'ho scritto anch'io che WinFS é diverso: diverso come implementazione e modo di funzionare, infatti usa una logica abbastanza diversa e un server SQL tutto suo...
Mi riferivo al fatto che, con questa soluzione, sarà un accrocchio pesantissimo, ma i risultati ottenuti nell'organizzazione dei file degli utenti non é che siano chissà che cosa rispetto alle altre soluzioni esistenti.

Invece è diverso come scopo, non solo come implementazione. WinFS non serve a riorganizzare puramente i file o a cercarli, ma a riorganizzare il modo di accedere alle informazioni.
"Sarà un accrocchio pesantissimo" è un'ipotesi che ritengo campata in aria, a meno che non mi dici di averlo provato.

[QUOTE]Cioé con i software MS, il rapporto:
"risultati ottenuti"/"risorse hw usate"
é sempre bassissimo, molto minore che in altre soluzioni, così come lo é nel servizio di indicizzazione di XP: risorse mangiate: tante, risultati ottenuti: scarsini.

Luoghi comuni e pregiudizi si sprecano come al solito.
Per "risultati scarsi" del il servizio di indicizzazione di XP posso essere d'accordo. Ma dire che mangia tante risorse... mai provato Beagle?
bist26 Maggio 2006, 17:23 #78
Originariamente inviato da: Criceto
L'XML va bene come formato di interscambio.
Non come formato nativo quando le prestazioni e l'efficienza (anche di ram) sono fondamentali, come in questo caso.

Come in questo caso??? Se viene usato l'XML per definire un contatto, mi spieghi dove starebbero i problemi di performance? Visto che la Microsoft fa sempre male e il resto del mondo fa sempre bene, spiegami allora perché praticamente tutti i file di configurazione dei programmi open source (anzi, dei programmi per Linux) sono in formato testo e non binario. Se poi oltre che essere in formato testo sono in XML tanto meglio, ci sono fior di strumenti già pronti.

Per il resto... la leggibilità e la portabilità serve agli stessi sviluppatori.
sirus26 Maggio 2006, 18:21 #79
Originariamente inviato da: PeK]http://en.wikipedia.org/wiki/ZFS

non vedo nulla di simile a winfs qua dentro :\

cmq, XFS rulez [/QUOTE]
Infatti, ho detto che WinFS è
Già... poi salta la corrente e ti accorgi che tutto quello che hai fatto nelle 4 ore precedenti era stato solo cachato in memoria centrale

XFS fa un update di ciò che ha cacheto (se necessario) ogni n secondi con n < 60 se non vado errando

Originariamente inviato da: magilvia
...
Trovo inutili a priori i desktop search. Basta un po' di organizzazione nel salvare i file e di ricerche ne fai 1 al mese. Perchè sprecare risorse per indicizzare inutilmente i file?

sirus26 Maggio 2006, 18:56 #80
Originariamente inviato da: frankie
boh io mi sa che rimango su questo:

http://ilfrankie.supereva.it/ext2.png

... fosse almeno un file system journaled come EXT3 o ReiserFS, EXT2 è anche più insicuro di NTFS!
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^