Slashdot Mirror
WinFS' Demise Not a Bang Or a Whimper
Shadowruni writes "The Seattle-PI confirms with Mircosoft what MS bloggers and pundits have been saying all along. WinFS simply isn't going to happen. Some of its features have been 'merged' with other projects." From the article: "WinFS was dropped from Vista in what company executives described at the time as a trade-off to get the operating system completed in a timely manner. The release of Vista has since been delayed again and is now scheduled for November for large customers and January 2007 for the general public, though some observers say it may be out even later." Final confirmation of a story from last month.
> And how often have we heard rumours of WinFS appearing in the next Windows OS?
Ever since Jim Allchin Microsoft announced Project Cairo in 1991. It was scheduled for release in 1994, and it was to include an object oriented file system similar to what is now referred to as WinFS. Now, 15 years later, these capabilities are STILL missing in action. Here's a chart showing Microsoft scheduled and actual ship dates.
Of course, in the mean time Microsoft has been chasing other innovations and their ever expanding appetites ever since that announcement...Internet connectivity and its related clients (www, mail, ftp, nntp...), security, improving stability, not to mention all the kinds of new hardware devices that had to be supported. Many of them were first supported by Windows.
Nonetheless, WinFS is one of the most obvious cases of Microsoft having "dropped the ball."
I've been running on Vista, and most programs I've tried (Photoshop, Dreamweaver, Opera, WoW, Guild Wars, Trillian) run perfectly fine. Some I've had to run with admin access (WoW, utorrent), others just worked. The only program I've had trouble with is Nero. Nero 6.whatever doesn't load Nero Express, but the actual Nero Burning ROM program works. I tried installing the Nero 7 demo, but it won't run for some reason. I haven't tried MS WOrks.
After 10 years working to create a suitable storage layer for implementing semi-structured data queries in the FS for Linux, I gotta tell you, this stuff is harder than I ever thought it would be. :-/
(See Reiser4 for our storage layer, and our Future Vision paper for what semantics we are going to add.)
5 years to do the first draft (ReiserFS V3), and then another 5 years to get it finally right (Reiser4).
To do enhanced semantics cleanly, you want keywords to be just another kind of file (see our Future Vision paper for why. That means you need to store files that contain phone number sized objects and keywords reasonably efficiently. Because of network effect economics creating a barrier to entry, you have to at the same time make traditional file system usage patterns at least as fast. That is hard. How hard? Oracle tried to do it without deeply changing their tree algorithms, amd implemented an FS on top of their database engine, and found that it was half the speed of a traditional filesystem. Others also found it hard. I tried to do it with V3, and found that for files in the 0-10k size range, I had many of the performance problems that FFS had when they created fragments. Thing was, I never knew they had performance problems, because it was not in their paper.... The problem was that when you combined fragments from multiple files, you add seeks, and one added seek is deadly to performance. The approach used in most databases, BLOBS, suffers from the same problem as FFS combining fragments, and yet more, because BLOBs unbalance the tree (see our website for details and nice diagrams). The usual transaction technology employed for databases, it is just wrong for filesystems, what you need in an FS is to fuse multiple transactions together into batches. And more....
There are so many different areas where if you take a wrong step, performance goes through the floor. You cannot imagine how depressing it is to work on a project where the performance is terrible until the very end, after 5% to rarely 20% at a time you've dragged it into something decent over years of time. I look back on it, and I see that we were incredibly lucky, because all the mistakes I made, were mistakes that took days or weeks to fix, and except for one thing (BLOBs), all the major things that would take years to fix, I got right. There is no reason for this other than luck. And BLOBS cost us years.
So we have for Linux the storage layer that MS could not develop because they quit before 10 years had passed, and perhaps weren't lucky enough at. Now, with technology working, and balance trees that can emulate file system semantics at twice the speed of the real thing (see our benchmarks ), sigh, if only we can overcome the politics. Yup, the WinFS team had to deal with corporate managers that quit before 10 years are past, but we have to deal with..... better unfinished as a sentence.
The only consolation in this field is that everyone else seems to find it just as hard. Probably that includes even the politics.
That's a often-debunked myth. Research over the past 10-15 years shows that Mach is slow because it's bloated. Newer microkernels are much smaller (for example, L4 can apparently fit entirely inside your CPU cache), and don't incur anywhere near as much of a performance hit.
Instead of drawing conclusions based on an old flamewar, go read some of what Andrew S. Tanenbaum and others have written on the subject.
http://outcampaign.org/
Actually I disagree that OSX is ahead of its competition. In some areas you might be right but in general I think that KDE is a lot more advanced. The IOSlave system and the kparts are both highly integrated into the rest of the system and used to great effect.
Anywhere in kde that you want to use a file you can use an IOSlave. This gives you url transparency for reading and writing in every app very easily. For example you can send a file in kmail and then use sftp to load an attachment from a remote server and hit send. It will grab the file and attach it just fine. You can go to a form on a webpage that expects a file say for uploading an image and give it an http, ftp, sftp, etc url to an image and just hit submit to upload it. These IOSlaves are integral to the system and I would say on average they save me several hours per week.
The other major thing is the kpart system. Other systems seem to just pay lipservice to reusing components. In kde there is one address book system, one spellchecking system, one terminal window system, one proxy configuration system etc. I can configure those things in just one palce and they are reused everywhere. Actually for text editors there is a good example of this take kate. Kate actually is two pieces one is an application called kate and the other is the actual kpart called kate. By default the kate text editor, kwrite, kdevelop3, embedded text views etc all use kate. So you can configure syntax highlighting for example and no matter where you look at the code it will be shown the same way. I have not seen anything remotely close to this in any other system.
For what I do kde is more advanced then pretty much any other gui system out there and it saves a lot more time them osx, windows etc do.
Also as a note you can write kde apps in python and ruby. Those are definitely flexible yet safe programming langauges and you can get apps up and running very quickly with those.
Computer modeling for biotech drug manufacturing is HARD!
"Or management, who de-prioritized it as a "nobody will ever do that" feature."
So let me get this straight.
There you are coding the bulk importing tool for SQL server. You have written all this code to try and determine data types, matching the columns to commas, etc. You wrote the loop that iterates through the file. And then the manager came along and told you not to add any eception handling to the code inside the loop? I don't think so.
Instead I think you are stupid and lazy coder who decided not add any exception handling to the loop instead letting the exception bubble somewhere up the chain where it pops up as "overflow" instead of "unable to convert 05/05/206 into a date on line 129,456".
BTW here is a helpful hint for all SQL server DBAs. When you are trying to import very large CSV files import them first into postgres, that way if there is an error postgres will tell you exactly what line the error occured in and what field. You can then open up the file in emacs or vi and fix it (don't use notepad your windows will crash with a file that big).
evil is as evil does
It was probably recoverable, if you had contacted support@namesys.com, and if it was not an extensive hardware error. Most ReiserFS V3 corruptions (and most ext3 and XFS corruptions) occur due to hardware errors. The ones that cause only a block or two to be bad are usually recoverable. The ones that lose the whole drive, well, no FS will save you from that....
Source
No, I don't work for Microsoft, and I have no documentation to show that this is the 'fix'. I simply work at a computer store, and always find computers whose owners have found new and exciting ways to break them. This was discovered simply with a comparison of the two associations for directories/folders between a broken machine and a functional system.
I used up all my sick days, so I'm calling in dead.