WinFS' Spot on Back Burner Nothing New 346
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."
maybe because WinFS... (Score:5, Insightful)
Re:maybe because WinFS... (Score:5, Funny)
Re:maybe because WinFS... (Score:5, Funny)
I was just thinking that if they get this thing going, they'll be able to find the problem. Most likely in their own filesystem. Or maybe that's the problem. Just not the one they wanted to find.
Re:maybe because WinFS is vapor... (Score:5, Funny)
Is there any project for a similiar file system in linux?
The idea itself is a good one.
Re:maybe because WinFS is vapor... (Score:5, Informative)
Re:maybe because WinFS is vapor... (Score:5, Informative)
True but Reiser4 is available now. Someone just needs to build a front-end into Gnome/KDE.
Other examples of vaporware in Linux:
- integrated NVidia or ATI drivers
This doesn't fit the definition of Vaporware because no one ever claimed it was going to happen. Besides, you have to download the drivers for Windows too.
- working USB 2 of Firewire support
Works for me, I don't know what problem you are having.
- fast boot-up times
25 seconds including init on a 700Mhz machine is fast enough for me.
What alternate reality are you living in?
Re:maybe because WinFS is vapor... (Score:4, Informative)
Linux won't display the login box until after everything is initialized, windows will half load itself, show the login and continue loading in the background.
Re:maybe because WinFS is vapor... (Score:2, Troll)
Re:maybe because WinFS is vapor... (Score:5, Informative)
Re:maybe because WinFS is vapor... (Score:5, Interesting)
One correction - filesystems (at least most UNIX filesystems) are not constrained to tree structure; the leaf nodes may have any number of parents, i.e. a file may be in any number of directories simultaneously. (Use the "ln" command). And using ln -s you can practically place a directory in any number of parent directories.
I use this to organize my music collection alphabetically by artist, by genre, and by the date I got the music simultaneously. (I tend to be most interested in music I got recently, because I'm not tired of it yet).
I know people tend to organize files and directories in a tree structure anyways. If you ask me that's because people are happy to maintain the analogy of a physical item that can only be in one place at a time - so what does that mean for WinFS?
Re:maybe because WinFS is vapor... (Score:5, Insightful)
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.)
Re:maybe because WinFS is vapor... (Score:3, Interesting)
I don't see it like this. File metadata andcontent are already tracked by journaling filesystems like XFS and Reiser and they do not result in "one blob of unmaintainable code." If implemented properly (and I am not proposing that WinFS would or will be), neither should this.
Re:maybe because WinFS is vapor... (Score:5, Informative)
http://www.namesys.com/whitepaper.html
Re:maybe because WinFS is vapor... (Score:4, Interesting)
The one tough thing WINFS aims to do that would be simple in user space is it hopes to be able to look in files and gleen some atributes form them. This is great if you can hook into some of the libraries form office or adobe et al, it saves you from having to implement parseing for all that stuff. I am not quite sure how you solve that one at the FS level. I just fear a user space system will get real crufty real fast and break when major changes occur to the files and their real attribes on disk that the DB can't know about. Like if a mount point gets moved or everything is resotored form a tarball and the dates get changed/permissions change a little because someone was careless. I think overall getting the neccecary info form the user when new files are created would be a fair compromise, the only issues is rule one of DATA "crap in crap out".
Then there are all the problems that you mostly have to deal with wether you do it in the FS or as some user space hack/bloatware thing:
Note that file creation would constitute just that you would want/need for efficency archives to contain all that info for the file in them, so the user does not have to enter it. Makefiles and the like would have to be update to do magic and fill in that data for the output files. Then you naturally have to fix all the gui tool kits so their fileIO dialogs support that info, any apps with custom dialogs will need to be patched as will console apps. Some sort of default values would be need for apps that just can't resonably support collecting that info as well. I don't want to have to fill in values everytime I "cat" somethig, I mean to unlink moments later.
I think its clear there are lots of differcult usability problems to solve. Some could probably extend and of the major OSS filesystems to include some extra attributes and add a crude query system, its all a question of what do you really do with it once you have it. I am sure R&D at Microsoft is just as perplexed on that point as I am. I feel sory for them since the marketing dept has been pushing this as the next big thing for almost a decade now, the pressure must be intense.
Re:maybe because WinFS is vapor... (Score:3, Interesting)
Anybody remember the Graduate keyboard for the 2600? How about the Mindlink?
The Atari 2700 with ergonomic wireless joysticks was ready for production then was killed. Let's see...what else? The 7800 keyboard was fully developed then killed. An advanced "Amy" soundchip for the 8-bit computers....yep! Oh yeah and then there was one of my favorites. They had an expansion cage ready to go t
BeFS? (Score:5, Informative)
It was a next generation file system, that afaik, is still superior to many modern filesystems. It even had methods for storing meta data from custom file types (ie- mp3), so you could search for an "artist" field with "Cibo Matto" in it, or whatever.
Also, it used a set block size (1, 2, or 4K) rather than a set # of blocks.
i miss BeOS...... *sniff*
Re:BeFS? (Score:3, Interesting)
Otherwise, you can take a look at Mac OS X.4 [apple.com] when it comes out next spring (or grab the beta now).
Re:BeFS? (Score:3, Funny)
Plus, where else do you have functions in the API like IsComputerOn() and IsComputerOnFire()?
Re:maybe because WinFS is vapor... (Score:5, Informative)
(I'm pretty sure Webster's Dictionary's trademark has long since passed into a more nebulous place.)
Re:maybe because WinFS is vapor... (Score:3, Interesting)
Fact-index.com not only puts up Wikipedia content with Google ads, it's actually started making substantial financial donations to Wikipedia!
Re:maybe because WinFS... (Score:5, Interesting)
Yeah, something like Tivo. Once you get it working and get used to it, you would feel like losing one hand without it.
Just my 2c
Re:maybe because WinFS... (Score:3, Interesting)
Is it possible that NTFS's meta-data was the first foray into actually implementing this? Like WinFS, they might have started wanting to categorise everything and link it together but settled on GUIs to change ID3 tags, as well as other meta-data (like Word), planning to implement the search engine and filesystem service layer (WinFS) later on.
However, NTFS works fine as it is. Like the parent, I too question the need for WinFS when some of its features have been implemented over several iterations of Wind
Or maybe... (Score:5, Interesting)
And that's why it's taking so long. Accessing filesystems as SQL data has always been a dream of anyone who has had many files. They just never knew about it.
WinFS is the 'real' solution IMO to all things like iTunes playlist managers, and expensive Content Management Systems yadi yada.
Sure, no consumer is expected to actually use SQL statements, but that doesn't mean that user mode programs should *implement* SQL features. User mode programs should only be the 'translation' layer between the user's point and click GUI, and the OS' internal implementation of the db. Surely, anyone can see that collecting meta data from the file system, and duplicating it in usermode so that you can have search capabilities on it is wasteful.
This article wasn't news to me, I've actually been waiting for this damn WinFS since just about 1996... And by god, is it ever turning into Duke Nukem Forever, but you know what, it's such a cool feature that I still can't wait for it to come out... (figuratively speaking)
Re:Or maybe... (Score:5, Interesting)
Notes basically gives you network-enabled document stores with indexed metadata and fulltext searching. The problem (other than the asstastic and totally broken UI) is that Notes doesn't integrate well with other software, either in exposing interfaces to users or pulling in random documents from the Internet or MS Office or whatever. Basically they pushed the hard problems back on the enduser, and Notes ended up as another island of data rather than a solution.
Anyway the idea was out there, and I think some people in MS understood it.
Microsoft, OTOH, is in the unique position to implement such an idea on the 'system' level and provide a transition plan for existing software. But it sounds like WinFS got beached because they still don't have real answers to the hard problems of pulling random data & metadata into such a system.
The other big issue for Microsoft is that they'd probably have to rewrite Outlook and Access for the thing to be effective. (I find it slightly funny that Outlook lacks even basic fulltext searching while MS was running their mouth off about WinFS.)
Re:Or maybe... (Score:5, Insightful)
Re:Or maybe... (Score:3, Interesting)
People said the same thing about XFS.
("Breaks POSIX", "Incompatible with Linux VFS", etc.) Which means it is probably a little premature to start planning World Domination for it.
That doesn't seem to be too much of a problem for Linus or Andrew. They even seem willing to accept Reiser4 now and work out the details later. The Posix/VFS issues can be fleshed out by moving some Reiser4 features into the VFS. The o
Re:Or maybe... (Score:3, Informative)
Re:Or maybe... (Score:5, Insightful)
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.
Re:Or maybe... (Score:5, Informative)
Oh, and, let us not forget that there is a definite lack of political support for our work in the kernel community (especially among the other FS developers, ahem), and implementing the semantics would take 3-5 years if we got the funding today.
But hey, we do have a really sweet storage layer that blows away the other filesystems, while MS has seemingly given up on the serious algorithm issues we solved, and MS is now talking about putting the metadata into a layer above the FS rather than getting their tree algorithms right. Also, their semantics are probably going to be a confused hodge-podge of search engine and SQL shaped by turf battles with no single architect behind the design.
So, I have to say that things are looking interesting. I wish we had the funding I need to focus more of my time on coding and design.
Re:maybe because WinFS... (Score:3)
Re:maybe because WinFS... (Score:5, Insightful)
WinFS and similar approaches seem to take the view of that directories are horribly complicated, so users have to be able to search for information to find it anywhere. Find a document from Joe, and so on.
Now, the problem with that is to do interesting searches such as "reports from joe" you need some kind of metadata that specifies the file's a report, and that it comes from Joe.
If we do this WinFS thing assuming users can't keep a good directory structure, why would they specify the correct metadata? After all, somebody has to mark it as a report. I know from experience that trying to make my mother type a decent filename is a problem.
Examples: She will write a document, and save it with a name like "letter", "invitation" or "invoice". Then later she'll open it, use it as a pattern for a different invoice, and save it back with the same name. In the best case, she'll call it invoice2. She will also keep two completely separate invoices in one document, one page for each.
So, would she even bother to provide some consistent information when asked to specify a subject, a person, keywords and stuff like that? I'm completely sure that no.
Re:maybe because WinFS... (Score:5, Insightful)
You can see this problem on any corporate network where the users have 10 shared drives, each with hundreds of subdirectories, and most of them don't have a clue whats out there.
In otherwords, some of the best metadata for searching would be folder structure. Problem is that most search tools don't understand "Q:\Reports\Joe\" in the same way humans do. I don't know how this helps your mother.
Re:maybe because WinFS... (Score:5, Interesting)
WinFS and masses of metadata assumes the stupid and not the lazy. The reason I don't want to have complicated trees of directories is that i am too damn lazy to do so and maintain it. Requiring me to add masses of metadata instead of a directory heirarchy does not address the problem: I am lazy!
Such a system will work well for limited uses - anything that has self populating metadata (such as music collections where files will either come with suitable metadata attached, or if I rip a CD I'll automatically attach suitable metadata via FreeDB or what have you. Similarly for a certain amount of video etc.
Such a system will work passingly well when you have a reasonable amount of attached metadata automatically, for instance email.
It won't work well for general user created documents and the like.
In the end a lot of data is purely user created - from speadsheets and letters to photos downloaded off digital cameras.
Find a way for me to be lazy and still have quick and easy access to all of those, and then you'll have my interest.
Jedidiah.
Re:maybe because WinFS... (Score:5, Insightful)
Such as
We already see all of this in many different types of apps. Either music managers, or disk information viewers, showing space taken up by this or that file.
We're seeing this in email clients too. Opera's M2 (which sucks otherwise) does a great job of this. Gmail does it too now, though not as well (IMO).
At least, assuming this WinFS is what it sounds like.
Re:maybe because WinFS... (Score:5, Insightful)
I disagree with your initial statement that storeing your files in nested directories is 'cute'.
It is a logical hierarchical structure that allows for easy sorting & finding of documents **If they are stored in any type of sane manner**.
iTunes is an excellent example of this. *(disclaimer: if all your ID3 tags are complete & accurate)*
iTunes allows you to search, play, and arrange your music very quickly.
This is perfect if your existing collection was not organized.
WinFS will be perfect for the millions of people who just dump every document that they come across into "My Documents". I work with a dozen of these idiots. The only way that they can "open" a file, is by opening word, clicking the open icon, and looking in the default location among the hundreds of files that they already have there.
Gnome's Spatial file/window system reminds me of the same concept.
Those people who already have their files well structured will only be annoyed at having to jump through the hoops that MS has placed before them. I don't want to have to work just to get at my files. Didn't MS try this already (in a very limited fasion) with the whole: "My Music", "My Photos", "my Downloads", My Gawd! Where are the files actually located?
C:\Documents and Settings\User\My Documents\more!
I much rather prefer:
c:\docs
c:\mp3
c:\pics
d:\download
etc....
By dumping everything into one directory, you make it impossible to easily find what you want, but your answer is: Just search it!
Why would I search it, if in 3 mouse-clicks I could find it the old-fasioned way.
MS strategy (I think) is to make using the compupter less like work (like it is for my above quoted co-workers), and less intimidating, but they do this at the risk of completely annoying it's existing 'power-user' base.
If MS could do it in a fasion that is 100% behind the scenes from the user, then they might have an idea. index all documents, songs (lyrics too), movies (scripts), _EVERYTHING_. Then IF you need to search, then the whole thing is at your fingertips.
I look forward to any opposing thought that you may have on this. I realise that I just might be a carmudgen old-fart who is stuck in his ways and afraid of change.
Re:maybe because WinFS... (Score:3, Insightful)
It fails though when I'm looking for Guns_N_Roses_-_Sweet_Child_O_Mine.mp3 but can't remember what genre it is. Did I file it under Rock, Hard Rock, Hair Rock? Did I file Fresh Prince music under Rap or Pop?
If I have folders by Artist and all I remember is part of an instrumental track, how am I going to find it unless I can search by genre?
Re:maybe because WinFS... (Score:3, Interesting)
If you have your music sorted by genre's the catch is to keep the folders general.
ie
From their there is no need to sub-classify the different types of Rock.
The key to this is Sane sorting. It is easy to over-classify your information. Any song should never be more then 4 levels deep.
This is an overly specific example. The same applies for any user-created files on the OS. (
Re:maybe because WinFS... (Score:3, Interesting)
My "My Documents" folder contains basically my entire life--papers dating back through high school, address book and email archive, all my pictures, music, save games, application backups, drivers & other updates, backup of my Palm files, scans of important life documents (birth certificate, etc.) All neatly sorted of course.
I sync my My Documents folder between my desktop, laptop, and an external drive, plu
Re:maybe because WinFS... (Score:3, Interesting)
Root music dir: "music" - I know, that's pretty counter-intuitive.
Under that:
hardcore
emo
punk
techno
jazz
80's
c e ltic
rock
orchestral
themes
Re:maybe because WinFS... (Score:3, Interesting)
You have some mp3s for a band called "Green Day" Do they go under emo, punk, rock (or even 'pop'). You may have strong feelings one way or the other as to which category they fall under, and therefore be able to save these files in one place and find them again at a later time. But will other people who use your computer/network have
Perhaps it's just a bad idea. (Score:5, Funny)
It reminds me of the old saying
Re:Perhaps it's just a bad idea. (Score:4, Funny)
Wha? That is most definitely not an 'old saying'
*covers head*
please don't hurt me!
Re:Perhaps it's just a bad idea. (Score:5, Funny)
Re:Perhaps it's just a bad idea. (Score:3, Interesting)
Who here remembers... (Score:5, Insightful)
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?
Re:Who here remembers... (Score:2)
Do I really have to lay it out for you? It is
Re:Who here remembers... (Score:5, Funny)
Remember it so well I even commented [slashdot.org] on it. Lame moderators only gave me a 3 though. Bastards.
Re:Who here remembers... (Score:3, Funny)
Re:Who here remembers... (Score:2)
Re:Who here remembers... (Score:5, Insightful)
The NT Object Filing System/WinFS, on the other hand, is now 12 years old, but Microsoft is still promising it's coming -- in a few years. Call me crazy, but I think twenty years is a pretty damn long product development cycle.
Re:Who here remembers... (Score:2, Informative)
Re:Who here remembers... (Score:3, Informative)
Re:Who here remembers... (Score:3, Informative)
Now, if you want to say HURD is the equivalent of WinFS, I'd be inclined to grant the point. But the original goals of the GNU Project are fulfilled by Linux. Except maybe the Chaosnet thing.
Re:Who here remembers... (Score:5, Interesting)
The nice thing about being slow in solving a hard problem is that others are also slow....
Re:Who here remembers... (Score:5, Funny)
Everyone knows that RMS wants Emacs to become self-aware.
Delayed as in 10 years.. (Score:2)
Basically same article. And yup, d-e-l-a-y-e-d.
right now its a race (Score:5, Funny)
Re:right now its a race (Score:4, Funny)
Of course its on the backburner (Score:5, Insightful)
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
Re:Of course its on the backburner (Score:2)
Re:Of course its on the backburner (Score:2)
a) When it finally does ship, most people, including Slashdotters in 3 months will be wondering how they did things before WinFS, or
b) When GNOME implements the same thing with PostgreSQL, most Slashdotters will think its the best thing since sliced bread, wonder how the did things before it and will laugh at MS for not thinking of it first, completely forgetting about WinFS.
WinFS is not a filesystem, but it could help a lot of people in how they organize and search for thei
Captain Obvious to the rescue (Score:3, Insightful)
Re:Captain Obvious to the rescue (Score:2)
Re:Captain Obvious to the rescue (Score:2, Insightful)
They can break anything.
Re:Captain Obvious to the rescue (Score:4, Funny)
Sounds like a good name for a band.
Re:Captain Obvious to the rescue (Score:3, Insightful)
WinFS uses keyworks. So where do they come from? Perhaps MS Word embeds the name of the user who wrote it, ok. But we can search for that already. The really useful information would have to be added manually.
Now, this may be useful in a huge company with thousands of documents, but for normal people this sounds pretty much useless. If your technophobic grandma can't properly name a document, she won't be able to introduce the proper keywords either.
*claps* (Score:4, Funny)
WinFS not really all that important... (Score:5, Interesting)
From what I know of WinFS, it really won't be all that important anyway. It is supposed to provide a way for all files to be treated the same by the OS (roughly) right? Thus making it easier for users to search, browse, or otherwise find these files?
Well, I don't know all of the juicy details of WinFS but I have played with the new Longhorn build. The search tool that is in the Alpha release (MSDN) is much improved over the current WinXP search. It was pretty cool, although some of it can be chalked up to eye candy. It still had a certain ease of use to it.
I doubt WinFS will ever be complete, personally. But I am sure some of the innovation and development benefits will still reach us as consumers. I know where I work, we spend time doing things the customers will never see. But they will still reap many of the benefits.
Re:WinFS not really all that important... (Score:3, Interesting)
With each new OS -- microsoft says its going to revolutionize everything. People get the OS, its exactly like normal, and life goes ON!
A long time (Score:2, Funny)
Not easy (Score:5, Interesting)
It's a simple concept:
Store on a standard journaled b-tree (or similar) filesystem the binary data, and store in a database all sorts of meta-information about the data. Also if you want, store a reverse index of the textual info and maybe another 'index' of image features if it's an image.
Then if you want to get anything, no need to go through the filesystem's tree, you can hit the DB indexes and get info instantly.
The real problem is keeping all of this in synch, with almost flawless atomic operations. (of course it's pretty much impossible to be flawlessly atomic, but one should come as close as the current journaled filesystems are).
So if you're using 2 components, let's say, a filesystem and a SQL database, then you need to open a SQL transaction, do your inserts/updates/deletes, then do the filesystem operation, then do the SQL transaction commit. If anything fails, you can revert the SQL modifications and everything goes back to normal. But if the filesystem has problems, then you can't keep the damn DB synchronized, and at some point you'll have to resynch both.
On 100k files, no problem. On 200MM files (what I'm aiming for), you're pretty much screwed. Then you have to start thinking of a self-healing system with a constantly-running checker that must ensure that it's very resource-efficient, etc...
It's just a huge problem. Supposedly Apple is solving this by Q1 2005, but I wouldn't be surprised if we see a massive increase in filesystem corruption bugs for a while on OS X (unless the DB indexing piece is just that, an indexer that runs x times a day and isn't atomically joined to the filesystem operations).
Re:Not easy (Score:3, Insightful)
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 th
Re:Not easy (Score:3, Interesting)
try reading practical file system design [nobius.org] (pdf) by be's chief fs implementor, it might give you some clues.
"Cairo" = NT 4? (Score:3, Insightful)
Re:"Cairo" = NT 4? (Score:3, Informative)
Not just vaporware. Infact Id software used it to create the textures in quake1.
Pink and risc got me all excited and scared my non nerd highschool friends back when I was 17. No I am excited about risci again and Unix when hopefully I get my powerbook next January. I had fantasies about owning my own hacking machine even at that age.
BUt was not Pink part of os/2?
IBM wanted OS/2 to beat windows and they planned something called CHIRP (powerpc reference plat
Re:"Cairo" = NT 4? (Score:3, Informative)
But exactly, how can you fork a feature list? I'm not sure yet, but it has been done, and repeatedly, by Microsoft(and also by Intel, among other manufacturers, whose roadmap featurelist are quite splittable) before, so I know it's possible, and not just in the software world. The quick and easy version seems to be
Blah, blah, blah... (Score:5, Interesting)
Let's put this in perspective. In '92 MS was looking at the Sybase source code and thinking about building a new filesystem around a database engine. Chicago AKA Win95 was almost out the door and it seemed reasonable to shoehorn this into Cairo (NT4). They were absolutely the dominant and fastest growing player.
I commented to a collegue in '93 (paraphrasing Robert Heinlein) that I did business with MS for the same reason I obeyed Newton's laws.
What happened around 1995? The internet became a commercial entity. Suddenly, MS needed to provide new applications (like IIS, IE, Outlook Express, an SMTP aware Exchange server, etc.) not just dork with cool OS technologies. A few years later, they are comfortable again after playing catch-up and start thinking about filesystems again, this time in "Longhorn". Again, they started talking about the capability two OS releases into the future.
However, this isn't a feature that is going to drive sales. MS needs to keep developers of home and office apps happy so they develop yet another new graphics system to replace DirectX. The perception of Windows security has never been lower and is starting to affect sales. IIS is losing ground again to Apache/Linux.
It's time to focus on revenue streams again and the revolutionary, expensive, difficult-to-build features get axed. It's probably not a bad idea. Think about the problems they've had with MS-SQL and ask yourself if you want a similar technology built into every teenager's game and grandmother's email box.
NT Flying Object System? (Score:2, Funny)
How many people read "NT Object Filing System" as "NT Flying Object System"? C'mon now, be honest.
God I must have dyslexia.
Re:NT Flying Object System? (Score:3, Funny)
BFS (Score:2)
A Delay for a Solution in Search of a Problem? So? (Score:4, Insightful)
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.
Re:A Delay for a Solution in Search of a Problem? (Score:3, Funny)
Chode: What the hell you been fixing these past few days?!?
Gus: The transdigital freon converter.
Chode: And what does that do?
Gus: It makes Ice Cubes.
Chode: Wuh... You mean to tell me, that with all the CRAP that's broken on this ship, you start with the fucking ICE MACHINE?
Gus: Now listen to ME, you fat purple dung pile... As the ship's engineer, I decide what gets fixed first. So if you don't like it, go screw yourself.
Chode: That does it! Come here... You've
Re:A Delay for a Solution in Search of a Problem? (Score:3)
In a perfect world, the user-side of what you're suggesting can be done without too much headache at all - and in fact is mostly done in larger shops via combinations of roaming profiles, policies and "h
Is he sure of his facts? (Score:4, Interesting)
WinFS is supposed to be based on SQL Server, when NTOFS was announced, MicroSoft hadn't yet acquired SQL Server.
I thought NTOFS was what morphed into the fast-find thingie that shipped with Office.
Re:Is he sure of his facts? (Score:3, Informative)
OS/2 killer stalks penguins (Score:3, Insightful)
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.
quite the coincidence (Score:3, Interesting)
My ex girlsfriends mother could use winFS (Score:4, Informative)
In her rolodex type phone number finder she had several of her friends listed under "H" for "Home number" with a sublist of name and numbers. She had a similar setup for "W" for "work numbers" and "M" for "mobile numbers" with a list of peoples numbers.
Obviously the cards for "H", "W", "M" where quite full as most people where listed there. Other cards where almost empty.
I asked her why she didn't organise people by first names or last names. She looked stunned that at the suggestion.
I would hate to see how this lady organises her computer files, but a search facility no mater how bad would help her alot.
Elivs
--
Sorry about any typoos in my post, Im having a busy day.
meta-/data rising (Score:3, Insightful)
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!
OFS != WinFS (Score:5, Informative)
Although it makes a nice tagline and dig in the ribs for Microsoft -- same delayed technology, different century, yuck, yuck -- the Cairo Object File System (OFS) and WinFS bear no resemblance to one another. Having worked in the Cairo/NT group at the tail end of the former and suffered through uncountable meetings about the goals/architecture/benefits of the latter prior to leaving MS, I can say this with some certainty. Saying they're the same internally or architecturally because both strive(d) to provide the ability to find any document by any properties or content (aka "information at your fingertips"... remember that?) is just vacuous -- you might as well talk about similarities between file-systems that support shell wildcard expansions * and ?.
OFS was about a lot of things, probably too many things. It was designed during the "object wars" and things like copeland and pink and opendoc were in the headlines. Document-centered work was the proposed user paradigm, where structured documents contained nested opaque data from many different applications, and so applications wouldn't need or want to know the difference between a top-level document or a sub-part of a document. This user paradigm did not entirely come to pass, and so an entire file and object-system architecture and shell user-experience premised on it was canned.
That said, a few features from "OFS" did survive into NT/XP, including:
From what I saw to date, WinFS seemed to be about the data/XML paradigm of data format transparency, not about opaque nested/contained data like OFS. It seems to be pursuing a different usage paradigm. At least I think so.
It's a confusing thing, and it shouldn't be. The basic idea of fusing a DB and a FS is dead simple, and if every OS offered structured and unstructured data, a set of simple core schemas, federated query across the two forms of data, and transactional/ACID cross-references between them, you could build many applications more easily. Why WinFS keeps taking so many more bits to describe itself than this is beyond me.
Why do it the hard way (Score:3, Insightful)
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.
WinFS might have been a good idea... (Score:3, Insightful)
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 [utwente.nl] 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.
Even older than Cairo: MS Access (Score:3, Interesting)
Problem is, MS Access (and MS SQL Server, and their engines Jet and...
Most probably MS will never come to push this until they get the relational theory right. But with the MS Access and MS SQL Server pushing the party line of 'SQL is relational, but objects are better', they most probably will never get there.
Perhaps Gnome Storage has a better chance, because PostgreSQL is such a nimble system. But it still is SQL. Rel looks like being a potentially conceptually better solution as far as the data language side goes, but it still needs a huge amount of work on the storage engine side.
Re:Maybe... (Score:2)
Re:Maybe... (Score:2)
I want to see... (Score:2)
Re:I want to see... (Score:2)
Re:Reiser4 (Score:5, Interesting)
Re:Reiser4 (Score:5, Interesting)
NTFS has always had metadata built in. That's not what WinFS provides.
Re:Reiser4 (Score:3, Insightful)