Some people are absolutely gushing about the latest vaporware from Microsoft. Enjoy the fantasy while it lasts because it will be a very long time before any of this sees the light of day, and even then it will be years more before it's stable enough to use in a production environment.
Let's look at this diagram of Longhorn. Focus on the lower third of the diagram, the part in white labelled "Base Operating System Services", but excluding the part in "CLR". That part, which represents about 1/3 of the whole diagram, is what Windows NT is today. That means in the next three years the size of Windows is going to triple. This does not sound like a good idea. It's taken MS years just to beat the lower third into shape, and it's still less stable and more bug ridden than linux. Now they're going to triple it in size?
Now consider the other 2/3 of the diagram. The new stuff that is being added. On the right hand side is Indigo, a unified provider of services for security, identity and Web Services.
Taking it's lead from IBMs WebSphere - Indigo is one of those architectures that does everything for everybody. [ Marc Cantor]
Well, I'll agree with the part about following IBM's lead, but I was thinking more of SAA than WebSphere. Nuf said.
Now let's turn our attention to Avalon.
This is a whole new layer of Windowing and Media services layered
on top of .NET, which
itself is a layer on top COM, which is
layered on top of the Win32 API.
At each point in the evolution of Windows, each layer was supposed
to be "the cat's meow" and end all of our troubles and enable
"rich new interactions". First note that none of the new
layers has ever had that effect. Second, ask yourself, what does
this whole new layer add? To quote InfoWorld:
Emphasis mine. Why does it look the same? Because all the changes are aimed at the developers. Ole Eichhorn say's it best in his essay:
The most important thing is not how easy it is to build code, the most important thing is how well the code runs once it is built.
Yet again another new set of interfaces to learn for the programmers, which this time we really really promise will make you more productive. And even if it doesn't make you more productive, you'll have to use it anyway since you won't have a choice:
Longhorn will be the first operating system where ALL functionality is designed to be accessed through managed code. WIN32's reign as the Windows API has ended, replaced by managed .NET APIs.
Such a move is unique in the industry. No one, including Sun Microsystems, has made Java THE API for programming a particular OS, much less declared that, going forward, all new features would be offered through Java. Microsoft's decision to do that with .NET is an important advance, as it FORCES developers to write more secure code, simply because they can't make some of the coding errors (such as buffer overruns) that form the lion's share of security flaws.
Remember the last time we heard such breathless copy over a Microsoft technology? Maybe the same promises were made about COM? At the time they were already getting a little stale because they'd already been used in hyping MFC.
The last thing to ask when pondering Avalon is how many applications has Microsoft shipped that are pure .Net applications. After all, that's what they're telling their developers to do, and that's all of what Avalon is built upon. Last I knew, that count was still sitting at zero.
WinFS is the file system formerly called Cairo and has repeatedly not shipped since 1995. If it ever did ship it would be a complete failure because it does not solve a problem that anyone actually has. The whole idea revolves around attaching meta-data to all your files. Does this sound familiar? It should, and all of the same arguments about user supplied meta-data apply, see Doctorow, Shirky, and Pilgrim.
Now assume (incorrectly) that you were real careful and went back and entered meta-data for the 20GB of your special files. You know the ones, the same files that you have not been annotating with meta-data over the past 5 years. What are you going to use WinFS for? Why to search for pictures of granny or for old documents. That's it. Just search. Why all the fuss over meta-data? What you really want is Google for the desktop. All the meta-data in the world isn't going to find the mis-filed final revision of your marriage proposal titled "Untitled7.doc" sitting in "c:\Documents and Settings\Owner\Application Data\Microsoft\Office", yet a simple text search for "poem love marriage" will likely turn up all 7 revisions.
That basically covers it. Three major components, all useless in their own right, now stacked together on a shaky foundation to make an even more useless heap. Like I said at the beginning, don't expect to see any of this make it out the door and into a production environment for many many years, if ever.
Update: First I would like to clarify some things.
Mike Deem has a rather lengthy rebuttal which covers some good stuff. I believe most of the things he talks about are "solved" by having a search engine running over your files. The only thing I want to point out in particular is this:
But, WinFS does not stop there. When you put a file in WinFS, a property handler that knows the internal format of the file is executed to pull selected data out of the file to make it searchable.
My only response to that is, yeah, those proprietary file formats are a pain, aren't they?