Slashdot Mirror
WinFS' Spot on Back Burner Nothing New
osViews.com writes "Charles Arthur of Independant.co.uk has an interesting editorial which analyzes Microsoft's recently postponed 'WinFS,' the file system that Microsoft had been planning to implement in Longhorn. His editorial reminds us that this technology, previously referred to as the 'NT Object Filing System' was intended for a previous version of one of Microsoft's operating system's code named 'Cairo.' Microsoft first spoke of the 'NT Object Filing System' in 1992 and scheduled a beta release in 1996 and then a full release in 1997. But limitations cause it to continue being delayed."
...is a solution in search of a problem?
Or for that matter the ORIGINAL goal of the Gnu project?
What's your point here? Why are you trying to bash Microsoft just because they decided to delay or abandon something?
Best Buy can have you arrested
To how many of Mircrosoft's MILLIONS of consumers, is a filesystem like 'WinFS' (theoretically) a feature to be desired?
Most people I know want eye candy, and things to work as they're used too.
Microsoft doesn't _need_ WinFS, therefore it's not a prime concern
Error 407 - No creative sig found
People COULD just use naming conventions and name their files according to the content. But I guess that's just too hard.
IIRC, "Cairo" was what became NT 4... "Chicago" was Win95. Then there was the OS "Pink" by Taligent (IBM + Apple), but that never surfaced... And then there was BeOS and the BeBox... We can't forget the BeBox! It was... the precious. :^)
Slashdot's first reaction to VMware
Microsoft "solved" this problem for all intents and purposes by having every program save its files in the "My Documents" folder or a subfolder therein, and allowing for filenames that can be long and have spaces.
Sometimes I feel like Microsoft is rearranging the deck chairs while the ship is sinking. Anyone remember that cool "Tripping the Rift" movie? The ship is falling to pieces and the onboard repair robot repaired the machine that makes ice cubes first. The outraged captain smacked it with wrench and screamed "We're floating in space you decide to fix the stupid ice machine? Get to work on the fucking hyperdrive!!!"
Microsoft need a similar push.
Good point. Looking at their documentation, what they are trying is indeed isn't that simple. You raise a lot of the issues they deal with in adding extensible metadata and relationships while keeping backward compability with existing NTFS file system (Journaled b-tree).
Okay, take that and add a pretty comprehensive default set of metadata. The WinFS base schema is not small, and it covers a lot of stuff.
The next thing is that storing the data is one thing. The other part is storing functionality with the metadata, and allowing third-parties to do the same, and then providing a standard way to access that functionality.
One example is address data. Not that WinFS does this out of the box, but the idea is that if you had a mapping application or service, you could make an addin that would allow somebody to build a search or query like "Find all word documents that refer to people with addresses within 2 miles of this address"
The next part is that there is a whole set of APIs that allow for rule based management that allows developers (and maybe even users) a standard way of building complex actions when events in files occur.
By the way, the Semantic Web stuff is aimed at this kind of functionality as well. Of course, on the web, it's just nuts, but it doesn't mean that the effort can't have value.
Hate them or not, I do like that MS sometimes keeps trying to make something happen, rather than worrying if can be done. They may never get there, but from what I've seen of WinFS documentation, there is real power there.
Spotlight is close, but from what I can tell, the metadata is managed apart from the files, and the set of gathered metadata is by default smaller.
In think, a lot of what Spotlight can do the MS Search service can do already via indexing, but the interface leaves a ton to be desired (There are APIs for making search/index extensions. See the Adobe IFilter plug-in for example).
Where Spotlight really works well is the UI. That's important, and MS is lagging there, but I think they can catch up some.
And that the challenge for MS as well, is getting the technology to the point that it doesn't require lots of tech knowledge to use the stuff well.
ah, the old OS/2 can't do this filesystem from "Cairo".
it's lying in wait, waiting to lung out and kill penguins at just the right time...look out!
it's coming soon. really. no really. come on stop laughing!!!! it's going to come out any day now. yeah, in longhorn, that's the ticket.
There's a system that exists already and that's not vaporware. ReiserFS 4.
You can "cd" into a file like a directory and see the metadata. Things like bitrate for MP3, and all that stuff.
SQL doesn't fit that well with filesystems, btw. Relational databases work great with rigid categories. But beyond very rudimentary classification it won't work well because everybody has their own idea of what a good classification should look like.
Glomming two related services into one blob of unmaintainable code is not necessarily a benefit. A database mapping has the advantage of being able to catalog distributed file systems, including those which don't have any object tag extensions.
The other problem is that it's not uncommon in the database world to spend far more disk indexing complex data for access than it actually takes to store the raw information itself. Do you really want the possibility that your inseperable all-in-one file system is using more space for the equivalent of directory entries than for data itself?
Remember this isn't about special cases like a user too lazy to sort their home directory or documents folder, but applying that overhead to the entire system. With all the tweaks people do to improve general FS performance and reliability, why would anyone think adding overhead is a good idea unless you need, and I mean need those features?
If you do indeed need those features so badly, why not just buy or use one of dozens of existing document storage and search facilities?
WinFS was just trying to find a way to make people think the two ideas were inextricably bound together and in some way unique to Windows. In truth that honour goes to hundreds of document database and repository products and the long-toothed AS400 (or so my cohorts tell me that work on the platform.)
I do not fail; I succeed at finding out what does not work.
Right now, Reiser hasn't even conviced Linus and Viro to include Reiser4 into the stock kernel. Much less convince KDE/Gnome/Mozila/OpenOffice/etc/etc/etc to adapt their stuff to his interfaces. So, no, I don't think he's in the same position as Microsoft (who can coordinate this across the OS, the shell, and in many applicaitons at once) at all.
Business. Numbers. Money. People. Computer World.
First, anyone who seriously thinks that WinFS is truly vaporware has a significantly impared view of reality.
Second, by WinFS, these sites are not really talking about just a file system with metadata. That is not a difficult problem and has already been done in BeFS long before ReiserFS 4. The difficult problem is creating a fast and usefull interface for it. Thi is something which has NOT yet been done.
I have yet to see any proof that integrating database like features into the filesystem is any better than having a separate indexing system and then providing a transparent filesystem api for the combination. In fact, I'd think that the later more modular approach would be easier to maintain and manage. Properties you really want in filesystem code.
Since I have ended up being a SQL Monkey (again) at work, I assure you that I have no desire to use SQL to access my file system. I don't even want a middle layer that translates to SQL. Heck, I am not even sure I want a relational database for a file system.
I would rather they start, by looking at the speed of the file system and take some hints from the file system for Sprite and maybe some of the capabilities of Plan 9's filesystem / model.
Once, that is handled, look at all the trouble people have mapping our current batch of Object-Oriented Languages to SQL. Know, that you will write a natural language query engine for the end-users, so developers need an API / Object Hierarchy that works. Pick something that will be easy to program, allow decent, extendable meta-data, and fits nicely with objects.
You're right and I emphasized the wrong part of Reiser4. I know that NTFS has metadata. My point is that you don't need a WinFS type structure for Reiser4. Reiser4 is a lot further along than NTFS in implementing a WinFS type system because most of the features are built-in. Files that can be treated as directories and the plug-in nature of Reiser4 make it almost trivial to get WinFS functionality without the overhead of WinFS. The metadata is a small but important part of it. The real breakthrough is not the metadata itself but the structure around it and that allows it to be indexed in such a flexible way.
Time makes more converts than reason
WinFS, and any "filesystem" structured around the data, rather than the form of the data (eg. files), is more than just "content searching". An index of the content of the data is one metadata type. File event dates (create/update/last-read), access directories, archivablilty, MIME type, compression/encryption, application defaults, and data-specific pointers (packages, components, multidimensional scales, etc) are all even more useful data about the data than just some data contained in the dataset. Especially as human senses operate by association of related data, modelled as database schema relations.
The old "filesystem" leverages human experience with filing cabinets, fast becoming a lost art, into working with computers. It's a 1960s era hierarchical schema, long surpassed by the relational model for expressing human operations on data. Microsoft is so tied to the file metaphor that it can't produce anything but vaporware like "WinFS" (or OLEDB, or all the other pure marketsprach) to replace their legacy data tier. Linux isn't tied to such an albatross. We can get content searching, and all kinds of other human-sensible data operations, when we've moved to a modern data tier, and make Microsoft computing look as archaic as VAX/VMS. Let the good times roll!
--
make install -not war
You don't need an SQL database hiding inside your file system if you want to provide unified searching across disparate data sources (email, office, websites, SQL, etc). People have been doing it for years. Bill's just chosen the wrong means to the right end.
As far as i can see, there are two different concepts in that thing:
- The real FS part: ReiserFS-like storing of a file/dir architecture, which is nice, disk-space-savey and all, but has no consequences on the way people work. Furthermore it already exists: i'm using it right now.
- The self-organized document hierarchy and search capabilities, which might change the way people work for the best, as far as it's restrained to *very specific parts* of your data. Who would trade a well crafted UNIX dirs architecture for a key indexed FS? What about dirs related documents, like a hierarchy of Java packages? What about URL accessible documents? What about implicit (not already keyword-based) relations between documents? And so on... In most cases, this stuff would have to emulate a standard file hierarchy anyway, which would probably result in system resource overhead only, or would require that you specify explicit keywords (not really knowing how they would impact the search algorythm), which would result in user resource overhead only.
You get my point: this stuff must be an option, and it belongs to the user interface, as in DBFS or Google, with a standard lib/API for easy re-usability by tiers software. It would be of no use with MOST of the files, in my system anyway.
WinFS is not even a solution looking for a problem, it's a problem seeking naive clients for its solution, IMHO.
"Take away our PlayStations
And we're a third-world nation"
A.D.