Slashdot Mirror
Longhorn to be Released in 2006, Sans WinFS
skillio writes "Everyone's favorite OS maven, Bill Gates, announced a release date for Longhorn on Friday. He confirms what many had suspected - Microsoft will attempt to complete this release in calendar year 2006. The most notable element of this announcement was Gates' admission that WinFS, Microsoft's next-generation file system, would not be complete in time for this release - surprising, since this was the most hyped component of the next iteration of Windows."
since that file system will probably break compatibility with everything non-windows it's delay is good for everyone.
I wonder if they will decide to use it to lock out any third party application providers they dont like.
Likely each component will be rolled out seperately... and then it'll all be bundled (without the new file system) for the official longhorn release.
Of course, they will package the new release with new bells and whistles to give people a reason to upgrade... but most function will be able to be obtained before the official "longhorn" release.
SP2, for example, contains several aspects of longhorn that were forced to the users sooner. Examples are the pop-up blocker and the protected memory to prevent buffer overruns.
What was it - Cairo? Chicago? They ended up dumping them, and putting the "doable" stuff into their next "mainstream" product.
My guess is that WinFS was turning out to be one of those grand and glorious ideas that was falling short of "doable" - at least any time short of 2041.
Teen Angel - a Ghost Story
Allchin: Don't call it 'Shorthorn'
Well, now that you mention it. It seems like an apt moniker.
In the land of the blind, the one-eyed man is king.
So, in real life we'll see it in 2007? Or 2008? I guess we have an issue for a poll here :-)
WinFS is an interesting, bold, and novel take on a file system, but I'm not sure why it's taking so long for them to implement. They've been working on it for a very long time. It's complicated, but it doesn't seem ten-years-by-a-dedicated-team complicated. I can't help but think that once Microsoft comes out with a reference model, there will be an open source reimplementation in months.
Microsoft has higher demands on it, and it's harder to develop it the first time, and presumably their implementation is optimized to within in an inch of its life, but I still don't see why a project they're working on now won't be ready for 2006.
Could it be that they want to adapt their applications to use the new features before they release it? That I could see taking forever, since everything from Word down to the format Spider Solitaire saves its games in would be affected. But I assume that they've implemented a Win32 filesystem API on top of it, and presumably with tolerable performance, so why not release it and adapt the apps later?
Microsoft, and in particular Bill Gates, have stated numerous times that Longhorn is the most expensive and time intensive project MS has embarked on and would be as complicated as the Apollo space program. With that in mind, WinFS was really the cornerstone and pride of the Longhorn project as MS would like to say it. With that in mind, this is akin to cutting the goals of the Apollo space program drastically ... like not landing on the moon at all!
Granted a system like WinFS can be extremely complicated but it is not a "selling" point to me for Longhorn. I will compare it against other features it offers and decide to buy it or continue to use XP.
Actually, I think this is a case of RTOFA (O for other). At least currently, though likely to change soon, the last article on the main slashdot site is about how Windows XP and 2003 are slated to get Avalon and Indigo as part of interim releases, since Longhorn is now not slated til 2006.
A feature that solves no problem. An interesting idea placed in the wrong location. And I'm glad its shelved.
On paper, this sounds neat kind of in a thesis paper sort of way. But the practicality of it was way beyond what any desktop user would need. I had problems figuring out how to use it efficiently (after all you have to have meta data lined up). I couldn't even begin to figure out how to explain how WinFS would help grandma and grandpa.
I do see WinFS as an interesting tool for server applications but for a desktop it isn't feasible without a whole heck of a lot more tools. On a server I can see this being a powerful tool to help keep your web app file data sane because you can force metadata and relationships there. On a desktop it would have been a feature with cumbersome tools used once a month. This is the very definition of bloat. I am very glad it was shelved since the cost vs benifit of WinFS on the desktop was completely off.
Doesn't this all sound a lot like whistler (released as Windows XP)?
A lot of these features were also announced to be part of that OS but were removed in the beta versions. Some did not even make it to any beta version. WinFS was even announces to be part of Win NT 4.0, so they should have a lot of time to complete it.
If all these stuff will be removed in longhorn, will it just be 'Windows XP Second Edition'?
...wich is not a surprise. Making those available in all the relevant windows platforms they'll tempt developers to *use* them (the same binary using avalon features may work without modifications in longhorn *and* XP SP$SOMETHING - compare that to avalon only being available for longhorn. Everyone would use just XP features and no longhorn features because fo the extra work needed). It looks to me like they though that everyone would jumpo to Longhorn because of their coolness, but they realized that they would lost what they call "the api wars". Now that they realized that Longhorn can't be 100% true they need to retain people in their new APIs - putting them available for XP is a good way to do that. I'd call that "conserving upwards compatibility" a different version of one of the reasons they're everywhere: "conserving backwards compatibility"
Fuck it! If you're going to burn plastic, I'm gonna be there trying to stop you. As much as I hate Microsoft, the nature itself didn't do you any wrong. There's no need for dioxine in the environment.
:)
Yes, I'm part of the ecologist nazis.
I'll do the stupid thing first and then you shy people follow...
This is yet another proof of how hard it has become for them to upgrage Internet Explorer. Adding just one feature requires an entire new operating system. Fortunatly, for SP2, Bill has outsourced the job. I'm sure 99% sure that the pop-up blocker in SP2 is stolen from Mozilla. Horray for open source!
(Just joking)
The idea of the popup blocker and the tabbed browsing were not their own idea. Competitors like opera and mozilla based browsers (mozilla, firefox and others) had those, so IE must have it to keep up.
Round of applause please. M$ have just made an engineering decision that works for users at the expense of their own image and revenue stream.
If WinFS was in late beta at the time for the Longhorn release there would be a massive urge in MS to release it anyway, bugs and all so as to get dosh out of the upgrades. That would be disasterous!
The FS needs to be just about indistinguishable from perfect and bug free; bleeding edge doesn't cut it. M$ seems to have grown up enough to realize that.
I thought the buffer overrun protection was AMD's idea, with the NX page flag.
I think MS is going about this a bit more complicated than necessary. Mac OS 10.4 is said to have similar features. It's not as complicated as you think: simply attach XML metadata to every file (similar to how .NET and a host of other systems do now) and organize based on that.
The problem with MS's implementation is that they want to tie SQL to it. Noble (it'd vastly improve performance) but unnecessary.
It still remains to be seen how well Apple pulls this off (my guess: ok, but not perfect). While the implementation is easy, getting it to work as expected will be hard.
I'd personally be satisfied with just a "spokewheel" system: have every person and event as the axle of a spokewheel and have the files branching off it (business contacts, vacation photos, etc). Not too complicated: just define a person schema in XML, make each person the top key and work off that. I think MS originally wanted to take that approach (based on the MS research projects) but overdeveloped its complexity.
I dropped of those years ago, as microsoft wasnt putting out product often enough to make it cost effective. ( they go along with the MOLP agreements.. )
.. Then you have no software... Its a perpetual lease..
The other hidden problem that few people think about is that if you drop off the plan, ever, you loose the license to use what you have
Going retail prevents this problem.. Yes it costs more, and you don't get their 'enterprise support', but at least you are in control.
---- Booth was a patriot ----
Prediction.. In a year and a half, Microsoft announces the real name of Longhorn:
Windows XP SP3
If XP is going to get Longhorn Technologies, and Longhorn isn't going to get the rest (best?) of the "Longhorn Technologies", then thats all it is. A new service pack, just like XP was.
This vaporware evaporation is a good example of how Microsoft inhibits innovation. Not due to some malicious plot by Bill Gates. Rather the inability of his giant, complicated organization to nimbly publish new technologies, because of the ramifications of any change to their monolithic system. If their architecture were simpler or more elegant, they could point their billions of dollars and thousands of programmers at any new tech, armed with the inside expertise of the other Windows systems with which it must interoperate, and roll out something new in a few months. WinFS has been announced so many times, and would do so much good for Microsoft, that it's obvious Microsoft's execs want to put it out. The captain of the Titanic wanted to turn away from the iceberg, too, but his ponderous state-of-the-art craft couldn't avoid the sudden obstacle. Let's just hope there are enough lifeboats to save the hundreds of millions of Windows users, and the rest of us don't get sucked down in the whirlpool.
"Never ascribe to malice what can be explained by incompetence."
- Unix fortune teller
--
make install -not war
I think what we're seeing is MS beginning to adapt to the release schedules of their OSS competitors.
.NET 2.0 Longhorn will have a two years beforehand, Indigo a year in advance, the free Yukon embeddable data engine two years beforehand and now a substantial slice of Avalon, not to mention at least 1 more media framework and substantially increased device support - XP is a completely different beast. Hopefully we'll get a new version of IE that isn't the equivelant of shoving a rod of Uranium 235 down your shorts too (and for those who don't think its important when you're using Firefox anyway... have you looked at how many apps mshtml.dll is embedded in?).
If you think of new paid MS desktop releases as whole number releases of Gnome/KDE (substantial changes, new environment), MS is in pickle trying to compete with the "minor" even numbered releases the Linux desktop teams are pushing out. Every six months, Gnome users get a little more - that's hard to fight when you only release new OS changes every 4 years.
Whenever people asked me why they should upgrade from Win2k to WinXP Pro, I always said "You'll get a new annoying cartoon interface and a couple nice internal things, but mainly, you go with XP because of the periodic updates that become available to it". I think if you look at XP that was released and compare that to the XP users have now (with journal tablet support, two new versions of the windows media framework, three revisions of built in wireless support, and now native bluetooth support all the other stuff tossed into SP2), I think that everyone has to agree (whether they like XP or not is a different story) that its a substantially changed product. This is ignoring the products that were pushed to all previous versions of windows (.NET Framework, IE and OE, DirectX 9, etc). Its also not just cosmetic features - The windows userland driver model is being deployed mid-XP release as opposed to in a new Windows version.
From the look of it, the changes keep coming - by the time Longhorn rolls out, XP users will also have the same major version of
It looks like WinFS follows the same strategy - don't buy Longhorn because its completely different from XP - buy it because its slightly different than XP at release, but also because you'll be eligible for a four years update cycle that will end with Longhorn being substantially different than XP's resting place.
Tell me about it. The sad part is that this filesystem sounds like IBM's jfs/jfs2, which has been around for eternity. It's being hyped up to the cazillion degree like it's something special. It's NOT. So the order goes...
FAT16
FAT32
NTFS
NTFS5
WINFS
I agree with you that putting everything in the same basket and rely just on metadata to extract info is quite stupid (probably we'll end with a "folder" and "subfolder" metadata anyways, so what's the point?). But relying exclusively on directory trees to classify data has definitively limits, in that a certain file may belong to at most one category (if you are thinking that symlinks and hardlinks solve that problem nicely, please consider that symlinks break if you rename/move the original file, and hard links are limited to the same volume, and there is high inconvenience in making a proper backup of them - in that you end with multiple copies of the same data).
That being said, one could say there's no real need for special filesystem support to store/search metadata: let's do a periodic collection of metadata from files, just like locatedb does, and we are all happy, right? Well, for one there is the latency between updates, and there are also are issues in a multi-user environment (one should see results just for files which he may access at the instant of the query).
The right answer is probably somewhere in the middle, I'd say that ReiserFS 4 with its plugin architecture is a great tool to experiment with this (idea: each time a file that was opened for writing/appending is closed, notify an userspace daemon to extract its metadata and put a copy of it somewhere: metadata is still in the file, and its copy is kept up-to-date in a form which is easier to perform searches on using an uniform API, but you need some kernel support to do this efficiently).
The only Microsoft 3d desktop demonstration I can recall seeing was some obscure handycam video of some guy moving 2d windows around inside a WindowsXP mod called SphereXP. Not to bash the guy's efforts but by comparison it looked hacked together and confusing (especially for "Aunt Tillie"). I'm looking at research.microsoft.com right now and the video of Microsoft guys talking about a 3d desktop... Then they show their implementation of one. It. Is. A. Mess. It is beyond description. You really have to see it for yourself. Nobody would want this. If you thought people's Windows desktops now were cluttered, organizational trainwrecks, you should see this thing. It would make Aunt Tillie's head spin--if it didn't give her motion sickness first.
I'm inclined to agree with you that Microsoft may already have lost its position of leadership. Listening to the guys in the research.microsoft.com video, it sounds like MSFT is mostly populated by PHB's now.
ReiserFS and WinFS are two competing philosophies.
WinFS is a data store. It's a separate, monolithic database which stores meta-information about files on the traditional filing system.
ReiserFS is about extending existing filing system technology such that data becomes transparent and self describing allowing any kind of querying facility to be layered on top.
Let me try an explain. Let's say you have a hard disk of OpenOffice Writer documents, which you wish to query. This is hard, because the SXW format is a complex beast. To the operating system it's an opaque series of bytes. Let's see how you'd query photos embedded in these documents:
Firstly you need to locate and open the file using the POSIX fs apis. Next, use a zip library to navigate the compressed filing-system-within-a-file that zip files are, to locate one of the XML files contained within. Now load up an XML parser and navigate the XML to one of the image nodes. Unfortunately not all information is easily represented using XML: this is one such piece, so it's actually stored as a JPEG encoded binary file ... decode that, and now navigate the structures in memory to arrive at the data you want.
Word documents are not much better.
This is an extreme example, but hopefully you see my point. Look at how many APIs were required to get to the wanted information, yet they are all fundamentally the same. ZIP files are miniature filing systems which add a compression feature (and performance!). XML is a tree of nodes: hmm, kind of like a filing system. Binary structures in memory tend to be trees or graphs of information: a bit like a filing system that supports linking.
What if we could unify these APIs? What if the underlying operating systems filing system was powerful enough to be the superset of all the features these disparate APIs provided? ZIP files are used for compression, for fast access to the contents and because it makes it easy to send them via the internet and manipulate them with modern file managers. XML is used because it's an efficient way to represent a complex tree with many nodes. Binary structures are used because some stuff just can't be easily encoded as text.
But we have a problem - there are sound technical reasons why openoffice documents are not a sparse collection of files. For one, most filing systems are not fast enough: a file is an expensive thing, opening and reading them even moreso. You don't want a file for every cell in a spreadsheet, or every paragraph in a word processor document. The overhead is too high. There is another problem: files cannot be directories and vice-versa. Having each paragraph as a file may be convenient for search engines but it's not so convenient for users.
What if files could simultaneously be directories, and what if we used a filing system designed so that a 3 byte file is not an unacceptably inefficient design? What if we could decompose our elaborate file formats with our chunks and headers and streams and DIRENTs into a tree of files all accessed via the POSIX APIs: open(), read(), close() ?
No longer would the structure of an image embedded in a word processor document be a mysterious and opaque bytestream to other programs. Now it's trivial to trawl the content of files and index them.
You see, this is the genius of Hans Reiser. He realised that writing indexer plugins for every file format under the sun would never work, it'd never scale, it'd never give users consistently good results. The right way is to make the foundations powerful enough that the concept of file formats itself falls away: by minimizing primitives, by unifiying interfaces, the system becomes more powerful.
The technical challenges of such an approach are enormous, it can only be done because ReiserFS is not a "bet the company" move, as