Slashdot Mirror
CNet on WinFS
Weston writes "CNet has posted an article about WinFS, or more specifically, what Bob Muglia (a VP at Microsoft) said about it in a recent interview. According to Muglia, the new filesystem will not replace NTFS, but will incorporate feratures of NTFS, SQL, and XML all into a filesystem which, accoring to Microsoft, will open up a whole new world of information availability. He goes on to describe such a filesystem as the 'holy grail' that is sought by developers. WinFS is slated for release in 2005/06 as part of the Longhorn OS."
You don't need to buy oracle anymore! ...Just use the windows filesystem!
who like the filesystem the way it is. I can find any file in my system within 3 or 4 clicks of a mouse because I keep my files organized. How is the new system going to be faster than that? I don't understand how searching for files every time you need them is faster than a file system hierarchy.
...And when they came for me, there was no one left to speak out for me." - Martin Niemoeller (1892-1984)
Why not a little Java thrown in? Or DRM? or TCPA? Or (insert hot new technology here) ? /dev/null, all the while funding MS and driving them to an eventual 3.0 or 4.0 release, which will be Decent, Yet Still Subtly Lacking.
This seems classic MS-predictive-FUD, where people hold their breath for the Next Release, which is a 1.0 version that sucks. Meanwhile, support people and PHBs have committed to it, so its Too Important To Let Fail. Ultimately, it becomes a time and resource sink the likes of which is only matched by
All of this won't help the average user find files easier, and will be massively more bloated and complex (read: too many moving parts, read: Service Pack Hell), and probably REQUIRE that Athlon-64 system we've been drooling over.
I want to delete my account but Slashdot doesn't allow it.
that the NT and NTFS teams would allow the SQL Server group to take such a huge chunk of control from them? You've got to be kidding me! The filesystem will not be anything new. The SQL guys at MS have been trying to move to a DB FS for a while, but let's face it - the performance will absolutely SUCK. At most, this is SQL server for metadata slapped "on top of" NTFS, period.
The copper bosses killed you, Joe. 'I never died', said he.
if by efficiency, you mean "speed of read and write" then i don't think this is going to be an improvement. the article makes it sound (although it's short on details) like winfs is just a front-end for ntfs and sqlserver - another layer your read-and-or-write has to go through before it gets to the disk.
but, hey, it's got xml for buzzword compliance!
2 1337 4 u!
He goes on to describe such a filesystem as the 'holy grail' that is sought by developers... ...of high end processors, memory manufacturers, and name brand PC makers, who's sales have been down lately due to current software running well enough on previous generation hardware.
And of course WinFS will provide them with the ability to enforce DRM down to the file system level. Which is the Holy Grail of squeezing every last penny out of your customers, and making exclusive deals with evil associations.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
NTFS has been an excellent FS for years! It's fast, it supports massive drives and massive quantities of files and directories, and it's incredibly fault-tolerant. What's wrong with NTFS?
Now, admittedly, this would also add on some responsibility to tag keywords to the files, and I've thought of ways of doing that as well (for example, applying keywords associated with a directory automatically to files placed in the directory).
:-D ) are you going to be redoing all of your indexes and everything to support that move operation? (Considering right now all you'd have to do is rename and possible move the folder [maybe to the 'trash'] to get the job done.)
Of course you'd have to do that scut work for any of these FS's to be useful. Now if you've gone to the effort of making the directory meta-data useful and explanatory then wouldn't just walking the directory tree accomplish the same goal while being less complex and more compatible?
Suppose you go and move your files (say the 'photo me sophie' now needs to go to 'photo me annoying-ex' folder
DB backed file systems are only really necessary when you're dealing with document management and with documents being created by other people, not yourself. The one thing you learn with DM implementations is that those DB's containing "meta-data" are always stuffed with the data that is least annoying (not most helpful) to everyone using the system. Context is quite important when you're viewing data and what you may consider important for your search could be completely useless for the next person.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
And this is the point where it will fail. Look, the concept is nifty, that is true. However common users rarely bother to give a document a good name, so why would you think that they are going to fill in the metadata? (Which you can do by the way in Office documents)
Now imagine this: we are in 2006, you have your digital camera and come home from a long vacation. You want to upload the pics to your machine runninng Windows Longhorn with WinFS. Ah! Right now you get something like 00001.jpg, 00002.jpg etc. How will the camera know what metadata to put for the pictures? It won't... The only way to *enforce* it is to show each and every single picture and prompt for relevant metadata, which of course no sane user is going to fill in. (Imagine doing it for a couple of hundred pictures) It is that simple. Right now you would just create a folder "vacation to Florida May 2003", dump in all the files and be happy.
No, you won't find the files of you and Sophie the classic way.... but unless the metadata entry is correctly entered, you won't with WinFS either.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Filesystems are just inefficient, shitty databases.
And sometimes all I want is a shitty database.
What worries me is that Microsoft already overrides my wishes; if they think they've created the "holy grail", they'll be even more likely yo impose it on me even if I know it's not what I want.
Case in point: Windows 2000 and above has no problem reading FAT32 partitions greater than 32GB in size. But it refuses to create FAT32 partitions > 32GB in size. Why? Because at that size, Microsoft knows better, Microsoft knows you should be uses NTFS and get the benefits of meta-data and journaling.
Except, I don't want the overhead for my MP3 collection. The meta-data's already present in the ID3 tags, and I don't need journaling -- once the ID3 tags are written, they're essential read-only. I want low overhead storage for very large (several MB) files.
And I want something that is a mirror of my portable plaayer, which can only read FAT32, can only read the first partition, and is 60GB. Since my portable only reads FAT32 (but doesn't format), and since Microsoft, in its wisdom knew better than to allow me to format it as FAT32, instead I got to watch it run the drive for over an hour before telling me the partition was too big. Talk about a linux killer app: I nearly had to switch to linux if I wanted to be able to use my portable.
Fortunately for me that the open-source world exists: somebody had actually compiled the linux mkfs for cygwin, and I formatted the portable with it. I can't use Windows' chkdsk on it, of course, and I haven't yet looked at compiling fsck under cygwin to further work around Microsoft's collosal arrogance.
Given my experience, if Microsoft thinks they have the "holy grail" of filesystems, it, and Microsoft's arrogance, will once again be rammed down the throats of every Microsoft user. But by that time, I'm sure I'll have fully transitioned to linux.
Opinions on the Twiddler2 hand-held keyboard?
"Case in point: Windows 2000 and above has no problem reading FAT32 partitions greater than 32GB in size. But it refuses to create FAT32 partitions > 32GB in size. Why? Because at that size, Microsoft knows better, Microsoft knows you should be uses NTFS and get the benefits of meta-data and journaling."
There may be a far-less-nefarious reason why it won't let you create a FAT32 partition of size >32GB, namely that the FAT table would be ridiculously large and inefficient.
Now, you could argue that the Master File Table for NTFS is also large and inefficient, but at least you have some control there over cluster sizes. Don't like the default 512 byte size? It goes up to (I think) 16K in size. Sure, you end up getting some disk storage inefficiencies but you can get around this by either (a) picking a cluster size more in tune with your actual intended usage or (b) using file system compression which attempts to clean up a lot of hanging cluster wasted space in addition to its compression duties. The fact that you get security, journaling, and far better error recovery than FAT32 is just a bonus.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky