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."
easier and more irrevocably!
Yay!
They should have a look in the castle ARGGGHHHHHHHHHHHHH, then.
He tried to kill me with a forklift!
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.
I use XML quite a bit in my data-based programs. But I've seen it used WAY too often and in applications where XML just doesn't make any sense (like parsing 1GB files, for instance). XML is a nice tool, but isn't the fastest way to get to data.
That being said, does anyone else think using XML in a filesystem is a horrible way to go? Especially given the hard drive capacity we're seeing today... number of files that can be stored, folders/subfolders, etc...
Unless I misread the article, I just don't see this being a smart move.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
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!
According to sources close to industry experts, a new filing cabinet will be brought to market sometime in the next year or two. Instead of having files, labeled with what their contents are, you will have a master file cabinet, with thousands of records that will give you a map on how to open a drawer and decipher a complex set of instructions to find the paper you're looking for. The system will revolutionize the way papers are stored in folders. Previously, there was no large, cryptic system for shuffling papers around, now there is a standard way to misplace items. No longer will you have to look just in drawers, but you may not be able to even find the cryptic instructions to lead you to the drawer to start looking in. Details are sketchy, but some have eluded to possible bookworm attacks, that could corrupt the cryptography and therefore render your whole filing cabinet useless. Industry experts suggest that an anti-bookworm product could be available shortly to help protect from this.
-- Liberalism is a mental disorder.
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.
In 1997 Microsoft made a pledge to Internet Enable all of their tehcnologies - and true to their word, even their file-systems are now internet enabled.
It's really easy to administer. Just plug you Windows computer into the internet, wait for a few minuits for a helpfull worm - and PRESTO!!!
You file system is on the Internet Baby!!!
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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.
"...all into a filesystem which, accoring to Microsoft, will open up a whole new world of information availability."
:)
Seems like with all the worms and viruses out there that Microsoft has already achieved this goal
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?
Filesystems are just inefficient, shitty databases.
The fact that file systems are databases has been recognized since, oh, databases were invented. One of the first things IBM tried after inventing the relational database was to replace the file system with it. You can tell how far that went.
The choice to make the UNIX file system the kind of database that it is was deliberate. UNIX file systems are a highly efficient and robust database, with proven metadata, security, and data consistency models. They do almost exactly what people want databases to do with their unstructured data.
For anything else, they use other databases. By a stroke of genius (or maybe just historical inevitability), those more specialized databases can be stored and accessed inside the file system database.
A database file system is quite accurately described as "The Holy Grail": it's an ancient mythological object of no practical value, something that only insane people would pursue.
Easy:
It is really good at all of those things.
"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
One of the first things IBM tried after inventing the relational database was to replace the file system with it. You can tell how far that went.
What do you mean? To this day IBM uses a database AS the filesystem in the AS/400. Ever heard of DB/2?
LOAD "SIG",8,1
LOADING...
READY.
RUN
Ok, people were up in arms that NTFS would have SO much overhead that it would never be viable in desktop PCs(1992 Buzz). And here we are again...
However, even on the 486-33mhz 16mb Systems that NT 3.1 and 3.51 were released on showed that NTFS's performance was at the same level and sometimes much faster than less featured FS technologies like FAT, etc.
Ironically, Journaling is still seen as a major overhead on OSes like OSX - which baffles me, considering MS was able to offer great journaled performance on a 486 platform, and on modern systems is transparent and offset by the advanced MFT and data structuring in NTFS.
and I don't need journaling
You don't? Do you even know what it is? Journaling allows the OS FS to track and protect from read/write file corruption. Especially in cases of power loss or hardware failure.
This is why CHKDSK screens on NT running NTFS are very rare - the journaled NTFS takes care of these problems without letting the FS or the information on the FS get corrupted by an interrupted write for example.
File Systems are a database variant, whether people like it or not. Why not add the advanced indexing and heuristics of a database technology onto the basic NTFS structure (especially since NTFS was designed to be extended in this direction).
And no, a simple indexing server is not going to cut it, there are simple indexing systems in Win2k and XP already, they prove inefficient and do not expose non-FS storage data mechanisms to applications.
Also your Metadata example of the MP3s is already a moot point. NTFS using Metadata ALREADY, just because it is not that obvious to users, does not mean that NTFS is not ALREADY doing this. This is part of the design of NTFS, the ability to store more than name, date, and location of file structures. It can store virtually any amount of additional data about files on the volume, and already does with many files types. People just don't realize that this is already happening, and because NTFS was designed to do this, there is already NO performance degradation.
Put fast information retrieval technology that exists in Database servers behind this, and not only will you add functionality for users, but it could in theory also increase the file access performance of the NTFS file system itself.
Database server algorithms are very fast and efficient and offer relational constructs, something a modern OS just might be able to use - especially when you stop seeing files and documents on a volume as closed entities and instead realize that they are data constructs that often relate to other data on the system. (i.e. A very easy basic example would be Mail Folder Files)