Slashdot Mirror
Gates Explains Longhorn Delay, Diet
An anonymous reader writes "Microsoft has set late 2006 as the deadline for shipping Longhorn, but to make that date, it had to delay the full implementation of WinFS, an ambitious file system geared at letting users search through all of their files at once. In this interview with Bill Gates, he provides a summary of why Microsoft decided to drop WinFS, saying: "WinFS, I'd be the first to say, is very ambitious. Nobody has ever brought together the world of documents, media and structured information in giving you one simple set of verbs that lets you richly find, move around and replicate those things." Meanwhile, MS Watch has published Longhorn head-honcho Jim Allchin's memo on why some Longhorn features had to be axed."
"WinFS, I'd be the first to say, is very ambitious. Nobody has ever brought together the world of documents, media and structured information in giving you one simple set of verbs that lets you richly find, move around and replicate those things."
Maybe Bill considered them nobodies...
It's not about finding files by filename, but about finding files by content.
It was always going to be NTFS, WinFS (Windows Future Storage) was a layer on top of NTFS used solely for items in "My Documents"
Don't be silly. What they're looking at is something like GNOME Storage where you can type in some search terms and semantically find the files.
Something like 1960s music or e-mails to Bruce, I'd guess. WinFS ties up all your documents, media, mails etc. into one database for indexing and searching, and beats the hell out of DIR C: /s/a.
So, what we have been shown in the next release of OSX Tiger that lets you search your documents, email and file system isn't anything like this. We have seen it in action and the set release date is 2005.
Come on Bill....Steve can pull this off and he doesn't have 50 billion in the bank.
Evolution or ID?
"...won't OSX actually have something like this even before Longhorn ships[?]"
Yes. Dominic Giampalo, one of the creators of the BeFS, now works for Apple.
No. updatedb and slocate find on the filename, not contents.
blah
According Allchin's unbiased memo, here's what's new.
* The highest quality OS we have ever shipped
* New information management tools to improve productivity, including fast desktop search and new, intuitive ways to organize files
* Major security advances that build on Windows XP SP2, such as new technologies to make clients more resilient to attack, viruses and malware
* Flexible and powerful tools to reduce deployment costs for enterprise customers, including technologies for image creation, editing and installation; and much simpler upgrades for consumers
* Significant improvements in reliability, including a robust diagnostic infrastructure to detect, analyze and fix problems quickly, and new backup tools to keep data safe
* A platform that creates Developer excitement with the availability of rich APIs [application programming interfaces]
Feel the developer excitement yet? Developers! Developers! Developers! Developers!
Wow. Sorry. I didn't realize that Allchin's memo was so hypnotic. I started channeling some fat, sweaty monkey man there for a moment.
Phiwum's law: anyone that names an obvious law after himself and then puts it in his own sig is just pathetic.
The Register interviewed Dominic and Benoit Schillings a couple of years ago and is a very good read.
Are you local? There's nothing for you here!
No, not the type of content, the ACTUAL content. Like searching for "pictures of houses" and the system going away and generating a list of all the jpeg images that are tagged with the "house" keyword.
Other useful examples might be "films starring Tom Hanks" or "music by The Red Hot Chilli Peppers"...
You're an idiot. You don't get it. On WinFS, when you search for something, *all of the results* are returned instantly. There is no delay. The filesystem is a database. When I say there is no delay, you need to think about *what that means* -- No delay.
The GNU find command is slow.
The problem with meta-tags is that they have to get populated somehow. Only the anal fill in meta-data, everyone else either blows it off or takes the defaults.
The real breakthrough happens when the system can decode and parse the file accurately to provide "automagic" meta-data. Otherwise meta-tags are a nice academic exercise that is either ignored or misused in practice.
A house divided against itself cannot stand.
I was going to post a draggable link, but it seems that slashdot filter does not allow javascript hrefs, so it will have to be done manually.
Create a bookmark with this location.Next time you are offended by the it color scheme, just click.
Pretty much untested, and has no failsafes (as in it will ruin other sites), for that open source look and feel.
In the next version I plan to add ability to remove any slashdot section as I think the apple theme is a bit overdone as well....
badness 10000
I didn't interpret it as an ad, either. I'm bemused by the whole Longhorn issue and will keep on converting people to Linux. I was just saying that it wouldn't necessarily be pointless to advertise here. MS actually did run actual ads on slashdot a while back.
~phil
Except for Microsoft themselves. They've already dumped PowerPC, MIPS and Alpha support to release solely on x86.
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Proper vector graphics would be cool though ... X has cairo (roughly display PDF) and gtk and qt are planning to switch. SVG for icon rendering is available now.
For me, a kind of "iTunes for files", including smart queries, would be fairly enough. And it doesn't require a brand new file system and its instability risks...
Here, watch this video. OS X has this in their developer previews right now, and is scheduled to be released to all users in either the first of second quarter of 2005.
Say you're a lawyer and you file your cases something like:
c:\year\case\client\outcome
Now you want to search these according to:
c:\client\year\case\outcome
This is not currently possible with directories without a huge PITA and this is one area where winFS can shine.
---
BeFS was the FS for BeOS. When introduced in ~1997, it was really extraordinary, with 64-bit addressing allowing file sizes many orders of magnitude larger than competitors (also much larger than physically possible), plus extensive support for metadata. BeOS implemented a great MIME-type system to identify file types using BeFS' metadata support, so the file type was cleanly split away from the file name, unlike the DOS/Windows hack of using the file name extension as a file type identifier. Furthermore, certain BeOS apps used BeFS metadata to allow extremely powerful query operations, including "live queries" that were updated every millisecond or so. BeFS was not really a database FS, but it did incorporate some cool indexing features that allowed database-level performance for certain filesystem operations. The earliest versions of BeOS really did use a true database as the filesystem. This idea was discarded due to excessive performance overhead, and BeFS was created as a compromise.
I have not used ReiserFS 4, but it sounds a lot more ambitious than BeFS. At any rate, the Linux BeFS driver is really a compatibility option that does not provide the same features as using BeFS natively under BeOS. fwiw, I would really love to see someone implement BeOS-like queries for Linux using one of the new metadata-enabled FSes.
You probably mean "avalon"...
a lon/default.aspx
http://msdn.microsoft.com/msdnmag/issues/04/01/Av
I think this is coming with Whidbey... But I haven't played with it yet - not sure.
Pax -- Ob
I probably shouldn't respond to a troll, but I'll bite on this one.
We have a sidebar that has significant more functionality than what MS intends to have two years from now. And our sidebar isn't vaporware: Dashboard
Lonhorn is going to have multiple desktops, tell MS not to copy Linux.
.Net is Java reincarnated, tell MS to give it back to Sun.
BeOS had BeFS in 1996, its everything that WinFS was going to be and then some, tell MS to not use WinFS.
While we are at it, The new windows versions are a bit like VMS, make sure you tell MS to scrap it all and start from scratch. Oh and this time also make sure you tell them not to include any BSD code again. I'll stop now, I wouldn't want to embarass you anymore.
Regards,
Steve
Actually, it takes kernel developers about a week to work through the implications of an extension to the behavior of filesystems, and they seem to be converging to a solution that will continue to behave in the expected way for programs that don't know about the new possibilities. (The flamefests were pretty brief, and then people got down to hashing out the new semantics)
Chances are that the reason WinFS is delayed is that, while it works great, it breaks half of MS's applications and all of everybody else's, because MS doesn't have a set of specifications which they are following, so they don't know what behavior people are depending on. Sure, they don't have to fight with people who don't want to change anything internally, but they do have to contend with legacy applications which depend on undocumented behavior (because important things weren't documented) and are all that are tying many users to Windows.
Go ahead, remove all the libraries that make up Internet Explorer, change the shell to cmd.exe and nothing outside of the shell will break. Delete shell32.dll, msi.dll, netshell.dll, shdocvw.dll, browseui.dll, explorer.exe, userenv.dll, urlmon.dll, shlwapi.dll, webcheck.dll, mshtml.dll and anything else you find that implements IE; nothing server-side will break.