Billionaire baron Bill Gates still mourns Vista's stillborn WinFS Five years after he stepped down from day-to-day involvement in Microsoft, co-founder and chairman Bill Gates has revealed his frustration that Windows Vista's database-like file system never saw daylight. In a question'n'answers session on the wildly popular cat'n'chat board Reddit, the world's richest geek was asked: “What …
What is the point of a having a Database as the OS's filing system.
Databases are for related information. The OS's FS just stores files of various types and names. The XP Search function along with indexing is sufficient.
Unless you are going to allow end users to tag their files (e.g. photos) with custom tags (e.g. London, Business Trip, Taken By: ...) then I don't see the point.
Nice in theory but collapses when presented with visual data or even music. Then a human has to arrange for the meta data to be input in some way and it never gets done. With music it's not too hard to get artist/track/year info but even getting sensible genre metadata is not simple and anything like "find me all the instrumental work with pianos" isn't going to happen unless you type it in yourself.
Basically, WinFS and similar systems need to come with a butler.
My personal experience of ripping CDs is that the online databases have incomplete coverage and enough errors to make me want to disable automatic updating. (One I've gone to the trouble of fixing all the errors, I don't want the next "system update" to automatically screw them up again.)
Everyone (BG included) needs to recognise that WinFS was pulled because it didn't actually deliver end-user benefits in real life. The idea was not new (IBM having deployed several filesystems that are significantly more structured than the UNIX-oid byte stream model) and the implementation not difficult (MS had and still have SQL Server, and NTFS had and still has streams that you can pack with metadata and shell support for reading those streams). This idea is neither new nor technically difficult. It just isn't very good.
> WinFS was pulled because it didn't actually deliver end-user benefits in real life
WinFS would have delivered several really nice benefits that users would have loved once they'd discovered them.
Trouble is, WinFS suffered from exactly the same problems that many other implementations of this idea have had - it was dog slow. And that kills it stone dead.
Vic.
Not a windows guy and I didn't see any MS presentations on it, but the way one of the windows admins pitched it to me back in the day; was less on metadata stuff and more of a transaction based filesystem where you have equivalent of redo logs, etc than would allow you to roll a filesystem forward/backward in time and be able to replicate a filesystem by doing log shipping. As a storage guy that part seemed rather interesting to me.
All modern file-systems are “database” in that they use btree indexes for directories and i-node/f-node is a special index for blocks. When you add in symbolic links you also have alternate indexes. Add replication, duplication and caching, you pickup much of complexity of a DBMS.
File-system as a database is not even a particularly modern idea either, both the IBM System/38 & AS/400 were build around a relational database.. what was new was doing on a distributed system with disconnected nodes. It was the distributed bit that killed WinFS.. and that was only in the mix because Windows Server could not scale-up like an AS/400.
{zfs, ResFS, HDFS, GFS, etc} are the heirs to WinFS without many of the features and no MS control.. so yes, culling WinFS is bound to hurt..
The OS's FS just stores files of various types and names.
Congratulations on completely missing the point, or indeed what the basic premise of WinFS was. Your argument goes that since the OS has historically provided only unstructured flat files this is all applications have been written to use and hence their is no reason to support anything else regardless of the benefits available to applications designed to use a richer OS persistent store.
WinFS was not some kind of glorified extended attribute scheme for simply tagging files but something altogether more substantial. The essential idea was that any file holding useful information generally has some form of internal structure: instead of each application needing to process a raw byte stream and parse that structure for itself the OS can keep track of that structure for any application once for all applications using that file. This has potentially huge benefits for efficiency and resource and code sharing: if you read up even a little on what was really involved you may begin to see the real benefits of the actual model as opposed to basing misinformed criticism on a wildly inaccurate guess.
In a very, very generalized sense, current file systems are databases, just without schema and the rest of the things we associate with databases in the way we use them.
As I see it, the key problem for MS (even if they had overcome the internal problems they had developing and implementing the code) is that outside of the types of file systems we currently use, all of the Windows based software which has done something similar lost the whole db whenever a part of it became corrupted. I'm not sure even Linux has completely solved that problem, although they seem to be much further along than MS is.
I just tried it and it does work for simple queries.
What I cant understand is the association of Database technologies with Text Searching.
With a DB all the Tokens are already there and querying is done over a small number of Tokens.
Information systems are vastly different form search engines.
No, no-one has ever used the word/phrase inside file search option. I say this as someone who has tried, and failed repeatedly to get it to work.
Agent Ransack should work nicely, but more, I use NotePad++ with their "Find in Files", which works quite well. Sometimes I will open Notepad++ just to use it's search, which allows regEx and "expanded" (C-esq escaped characters) search strings
<-- 'Cause inside file search always does.
@ Swarthy
Actually, it does work. For DOS style text files, maybe RTF, maybe Word.
But looking for function in bunch of C sources, you're out of luck. But rather than saying the .c files were not indexed, or bothering to look, it will tell you no matches, even when you are looking at one in an editor...
Vista was pretty much missing from Vista. So I'm not convinced anyone noticed the absence of a relational file system.
Problem is, no one wants to deal with metadata or schemas in a consumer OS - especially not one made by MS, which would be all-but guaranteed to lose/break files and have a UI made of distilled clown pants.
Vista appears to have been all about a "we need a Windows upgrade and we need it now, for revenue" type scenario, with no real direction other than increased security and graphical eye candy. It's a pity. It's not like Microsoft is without ideas but it suffered a few lost years due to execution.
WinFS was a good idea but (see what other commentards have written above) hardly original, stemming from ideas from the 90s (and before that, on big computers) that were too far ahead of their time for the desktop tech of the time.
Mostly yes, but MS was also well aware that they managed to grab the network/server crown away from Novell because Novell lagged too long between 3.12 and 4.x for Netware. During that time MS released NT 4.0 and ate Novell's lunch before start work on their dinner. If MS didn't get out a release with incentives to upgrade they feared the same thing would happen. And that might have been the case. Without Vista, we might all be running Linux systems now. Or be still stuck on XP with IE6.
This was the only feature of Windows 7 that I was interested in, a true differentiator over XP. However the Balmer rot had already set in, and the rush to release something took over (hmm, Xbox360 all over again...)
There is little to save Microsoft right now. They have destroyed all their products (Windows), or they already are too overspec and previous versions offering more than enough functionality (Office), or simply crap (Xbox, Surface, Zune, Windows Phone).
What a waste of time it is to read these comments. "Destroyed all their products (Windows)". Uh huh...
And the idea that the X-Box is crap? Yea, sure. I'll be playing on mine shortly, as will several million people.
And despite my issues with Windows Phone 7, I expect that my girlfriend is tired of how many times that I say I like my HTC HD7 (now with 7.8). I like it much more than either of my two other Android phones....
The Xbox *is* crap. Slowly but surely, it finally slid into 3rd place last year, though realistically speaking, that happened earlier. Of course, you'll see more Xboxes in the US but that's because the US just has bad taste. Same goes for the iPhone (hit in the US, losing ground to Android brethren elsewhere).
Yeah, because why would you want to store your settings in a versioned, journaled database in a hierarchical manner which allows complex ACLs to be set on each individual setting or tree, rather than just at a file level as ini/conf files do?
Oh, all of those are the reasons that you'd want to do it.
You mean like the way most linux distros do it? Works fine...
Try moving the settings of a ton of apps to a new PC... I know you can export from the registry and then import, but if you've done it a few times, you should know what a PITA it is.
And versioning or backup of settings works fine if stored in a file...
@petur - I can't change the permissions on a single setting of a Linux conf file, or is it ini, or is it a file in a directory called conf all seem to be used, a user can either have access to all the settings for a particular application or none at all. If a conf file corrupts on linux, that's it, it's gone, whereas there is logging of the registry database. The registry is much more granular than a conf file can ever be and if you find "regedt32 /e <key>" too much of a PITA, you can always try <right click>-<export> from regedt32.
The registry has come a long way, in particular with the move to NT based OSes. You shouldn't compare the registry from Win 3.11 with an underlying FAT filesystem to the Registry from Win 2012 under journaled NTFS, they're entirely different things. I certainly wouldn't compare linux from 1993 with linux from today, it's a senseless comparison, but everything has to come from somewhere.
I've personally not seen a registry corruption, but I've been using NT based Windows since the mid 90s. I'd also contend that if people backed up properly occasional corruption (which happens on all systems) be it file or database (registry) there wouldn't be a problem because they could recover their systems. The people who seem to make the most noise about Windows being prone to corruption are the people who don't back up. Which is odd, considering they are also the people who claim to know about IT.
Not sure it's the monolithic registry per se that is the problem, more the lack of adequate tools to work with it after the fact, including but not limited to:
- an efficient editor
- a consistency/integrity checker
- a workable solution to ensuring third parties correctly implement the monolithic solution on both installation and removal*
- trust the MS have f*&^$*! it up again on the odd numbered rev.
*insert I hate Java and it's inability to update OR uninstall if a dll gets clobbered rant here.
Just like there's a Unix philosophy which mandates small single function programs and file formats in very simple text formats, the Windows philosophy wants to have everything in complex binary formats. Both has its own beauty, though you may find one more usable.
The Art of Unix Programming summarizes this quite nicely. It contrasts the simple file API of Unix, where you can essentially read and write text to files, with the more complex APIs you have on Windows which allow you to create complex file formats. The big problem with those APIs is, that they have a certain learning curve. If you wanted to create software writing into a database-like file system, you'd need to learn the APIs and write your structures in a way the rest of the system can handle them. That's something few Windows software developers care to do, so even with such a file system, they would still write their files themselves.
If it works like OSX Spotlight I'd find it useful, I never quite found something for Windows that didn't work without either a noticeable overhead or without shipping my index data elsewhere (too long ago, can't quite remember what it was called) - it's very useful to quickly dig up data quickly so to have it under Windows would be helpful.
This post has been deleted by its author
It's a pity really. WinFS is one of the few promising things to come out of Redmond around that time. Had it not been tied to the nightmare that was Vista it would have been hailed as a revolutionary idea. Unfortunately it was all wrapped up with a bunch of bad ideas that Microsoft THOUGHT were revolutionary.
Oh, I'd put 98ME up against Vista. People are always forgetting about 98ME, which pretty much paved the way for Windows 2000. Had one system for a VIP that needed to be rebuilt every 3 months because he insisted on 98ME. Could not talk him into using 98SE even though for MS, it was about as solid as 3.12 was for Novell. At least Vista had the good graces to fail miserably on install if it was going to blow itself up.
Boy was I glad when 2000 came out.
Back in the day, BeOS implemented a filesystem (called, natch, BeFS), which did all the things WinFS was supposed to do. It used metadata extensively with a database-like filesystem which allowed applications to access and store various data types in the filesystem without an intermediate store. It was also blazing fast due to the filesystem index being a built-in feature instead of an add-on.
Unfortunately, Be took on Microsoft at the height of its power and never really had a compelling story about why one might want to run BeOS instead of Windows, so it has vanished into the dustbin of history.
Well, that and there were no apps for BeOS and even if there were, it was before broadband so getting anything more than a few megs in size would be a pain - I installed it, thought "this looks nice", then had to realise that I was never going to be able to do anything meaningful with it. Windows didn't win, MS didn't crush BeOS, there was no competition, a shame really, because it looked pretty good. Still if we're talking about OSes that had a chance and got crushed, my loyalties lie with RISCOS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
