Slashdot Mirror
WinFS to be available in WinXP
ScooterMcGoo writes "According to a Microsoft Watch blog, WinFS is being back ported for Windows XP.
From TFA: WinFS isn't dead, Tom Rizzo, Microsoft's director of product management for SQL Server, recently told Microsoft Watch. In fact, Microsoft is planning to provide an update on the technology at this year's Professional Developers Conference (PDC) in September, he said.
Rizzo said that Microsoft is busily back-porting the WinFS file-system technology to Windows XP.
It's unclear if Microsoft also is porting WinFS to Windows Server 2003, but such a move would be likely, given that the Redmond software vendor is doing so with Avalon and Indigo."
It seems to me that every major component that Microsoft has promoted for Longhorn is eventually being backported to Windows XP. What's going to be new in Longhorn?
They STILL haven't figured out how to write to NTFS, they will never even figure out how to read now.
As the article states: "Microsoft decided to back-port both Avalon and Indigo to older versions of Windows -- Windows XP and Windows Server 2003 -- in order to maintain backward compatibility and help seed the application-development market, officials said. "
If Microsoft wants to make WinFS a fundamental part of their strategy, they must back port it. Forcing developers to upgrade before they can develop is foolhardy.
Simple... claim that Longhorn is *much* more secure (and actually deliver, by taking some advice and shutting off certain "features" in legacy windows). So if you *want* to keep using the insecure POS that is XP, sure go ahead... otherwise, pay up for Longhorn... oh, and btw, we have all these SW vendors that are releasing at the same time as we are!
Make sure everyone's vote counts: Verified Voting
WinFS is not actually a filesystem. It's basically NTFS+ (compare to HFS+). If a computer that only understands NTFS reads the disk, it'll look like an NTFS disk. If WinFS is enabled, the indexes become avaliable. Basically, it's the Indexing Service on steriods. Or, at least, that's how I'm understanding it. Correct me if I'm wrong.
And if I am right, this will be one feature I'm turning off. The Indexing Service already pisses me off.
That's not what they're saying. For one thing, WinFS won't even be in Longhorn but will apparently be avaiable for WinXP as well as Longhorn when they do finish it.
Longhorn won't come out until 2010 or so, and Microsoft will be able to charge for "Windows 98^K^KXP Special Edition".
Not a bad idea.
If you have the ability to put off the release of another OS for years, you can save loads of money on development, but still have a steady income stream from copies bundled with computers (every dell, etc from 2001 to 2006, and those of us who had beta copies of windows 97 all know how the 2006 date will work) and the occasional consumer retail purchase.
Look, I'm not saying that MS isn't innovating anything, but compared to everyone else, they move at a glacial pace.
Since there really isn't any competition (and I use this word as "an OS that could hurt significantly MS financially", so please, no flames), they can sit back and release stuff whenever they feel like, but still have a pretty much guaranteed income stream.
1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcf
I agree - WinFS scares me. I believe ext3 is sort of like WinFS, is it not? I was scared of ext3 but I heard that since it was "journaled", it would eliminate files going missing if your machine was hard powered off. I've had very good luck with ext3, and if WinFS is going to be similar, it might not be all that bad - but then again, look who's actually developing it.
I know, for instance, that in my company we'd have to develop a process for writing the metadata, reviewing the metadata, and that sort of thing. Adding more data to something isn't going to improve the ability to find it; it's just more information. It's trading off one set of memory for another; instead of remembering where a file was, you have to remember what metadata you gave it.
I'd classify the "metadata" approach to file storage as a cute technology that is just another side of the same coin that looks good because it's new but really doesn't solve the underlying problem of information management.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
BTW, it's not just MS, but all of their kind. For example, some might debate the usefulness of hyperthreading, but no one would deny that "hyperthreading technology" is a neat thing.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
One major problem with NTFS is the fact that it's still prone to fragmenting. Every so often I have to run a defragmenter or my system just starts churning when I need to do any disk access. I've never had to do this on a Linux box becaue the filesystem is designed to avoid that.
So, will WinFS finally get this figured out or are they just going to make something more complex and bug prone without fixing a fundamental design issue from their previous filesystem?
This sig has been temporarily disconnected or is no longer in service
Why? So that the first time you FTP a file, all the metadata is lost?
Metadata belongs into the file, nowhere else.
I don't think that Microsoft is concerned about users wanting to upgrade Win XP and Server 2003.
What Microsoft is concerned about, I think, is to evolve their product to remain competitive with the alternatives, such as Linux, so that the new desktop or server that someone buys, will run windows.
The days when people upgraded the OS on their servers and desktops because a new version was out are over.
So they don't need to motivate why a user should upgrade from XP to Longhorn, with the cost that that entails. What they need is a product that is sufficiently more attractive than Linux for most users.
So, assuming that they can keep the market share, their second priority comes to focus. Which I believe is to have features which are attractive, and will attract developers, but which won't work on Linux.
So, spending an enormous amount of money on a file system which is unique to windows. And lock in applications to Windows is very important.
The Internet is full. Go Away!!!
People don't just upgrade overnight. It's going to take longhorn several years to become as entrenched as XP now is. In fact, it probably won't be until the next version of Windows is about to be released that Longhorn may become the majority or Windows boxes.
That means, if they want people to develop for WinFS, Avalon, Indigo, etc.. they best make it available for XP and 2003.
My prediction is that Longhorn will be like Windows 2000. It will be adopted by the serious people, but most users will skip it, waiting for the next version.
If you need web hosting, you could do worse than here
If you had the opportunity to better define what each item was, that you would.
.. in the open dialog, it has the meta fields there for search..)
.. ever since I started using JuK, I have found myself utilizing the ID3 tags on my music a LOT more. For one thing, it is built into the interface and allows flexibility (ie when I record a live gig, I can go in and tag all of mp3's with the same artist/album/date/genre and then go back and add the title and change the filename) which is GREAT. Infact, when playing music, even though I do organize my files in folders (by genre), I tend to use the search in JuK much more often.
Assuming that it is _easy_ to do and doesn't require a significant departure from our current model (ie in the save dialog, it has the meta fields there for entry
I can see where it is useful
Just curious, how is this meta data stored in WinFS? Do you know? (I haven't kept up) -- is it built into the file a'la ID3 tags or is it a separate resource fork a'la Mac OS Classic? If I transfer a file to someone elses computer, is the meta data included? Is this an open standard so the meta data is cross platform compatiable?
Ahahahaha. Let's review.
1) Run a file search on Windows. Go get a coffee and then see the results. Realize that you can only search on basic attributes of the file, like name/dates/raw content.
2) Run a file search on OS X. Click your heels twice and then see the results. Still, you're limited to some basic attributes.
Some months (or years) from now...
3) Run a file search on WinFS. In theory you get hits pretty damn quickly, if they ever finish this technology. I'm not sure yet what extra file info you'll be able to search on.
4) Run a file search on OS X Tiger. Not only is your search blindingly fast, but you can search on arbitrary file metadata. Also, you can save stock searches which will automatically update when new matches appear in the FS. I believe this technology was brought over with BeOS coders.
I am so used to the OS X file search speed and Mail.app search speed that on my work Windows laptop I was forced to buy X1.com's search tool to get around the incredibly annoying (when you're not desensitized to it) delay when searching in either Windows Explorer or Outlook. The market for this utility should frankly not even exist. It should be the responsibility of the OS to help you find things as quickly as possible, and it should have been done YESTERDAY. I mean Jesus, it doesn't take a rocket scientist to embed something like a SQLite engine in your email client code.
I'm glad that Microsoft is finally getting around to this (someday) but in the meantime I will be quite happy when Apple's Tiger shows up on my doorstep early this summer.
what's the point of a search engine built into the filesystem? ... keeping files in a logical directory structure along with copious use of find and grep commands seems to be good enough.
Here is a fundamental basic of what's wrong with Linux:
Developer: "I use grope, pully, xtract, gunit, and other nonsensical named 3rd party tools AND I organize my files in a logical directory structure, which gives me everything I need!
User: "Where is my Word Document?"
Tech, life, family, faith: Give me a visit
Give an option for the metadata to be transmitted separately
There is no such option in FTP, or in most other protocols.
XML of course, cuz it's 2005, or tacked onto the end of the file, in some cases, ala id3 tags, or whatever.
Well, if you "tack it on", it's part of the file.
Second, corp intranets, which is what this is primarily aimed at, probably aren't doing a whole lot of FTPing of internal documents.
Corporate intranets are using CMS, document management systems, P2P, instant messaging, E-mail attachments, etc. None of those have provisions for transmitting, storing, or indexing separate metadata forks.
Third, the existance of FTP and the like haven't stopped Apple's file system, or NTFS itself, from having things like resource streams.
NTFS has resource streams, but they are rarely used and they are actually kind of a security problem (viruses like to hide there, and even AV products often don't look there).
Apple's resource streams have led to a decade of incompatibility and usability problems for no appreciable gain in functionality over single-file multi-stream solutions based on standards like ZIP.
Proponents of hacking up the file system to add all these complicated features have failed to make a sound engineering argument for why the functionality justifies the complexity or why it needs to be in the kernel. And they have failed to do so for several decades (because these ideas are not new). At this point, when Apple and Microsoft are pushing this sort of thing, it looks like they are doing it out of proprietary interests, not out of any engineering considerations.
The registry: hundred of applications forget to rmeove registry settings upon uninstall.
:-)
Which is the app's fault. I assume you're saying removing an app in WinFS deletes all assosciated config? If the apps don't delete the registry settings what makes you think they'll delete the schema definitions or whatever to delete the settings in WinFS? Besides, the clutter is small and you get your settings back if you re-install the app, so it's no big deal.
Temporary files: go into your temporary files directory and see the hundreds, if not thousands, of files and directories that are no longer in use, but eating hard disk space.
Sure, so people don't use the APIs properly. How's that going to change?
You can just delete them all anyway. Any app that doesn't lock its temporary files deserves to crash
Async file I/O: with a standard file system, we have to worry about file locking. With WinFS, there are no files to lock.
OK, then if it's modelled as a SQL database then you have to worry about updating in transactions. You can't just allow simultaneous readers and writers.
Making sure directories exist: developers have to worry about creating directories, with WinFS, there is no need for directories.
You probably need some schema definition instead, though?
Config files: no, users and other applications cannot touch your application's local allotment in WinFS, meaning your configurations and settings are safe.
Really? I can't see a reference for that. What if AppFooUpdater wants to read AppFoo's settings to see where it's installed, or what flags the user has set to know what to update?
One of the monumental problems organizations face today is aggregating information that's stored in disparate formats. Knowledge workers have long wanted to be able to search for content independent of format. WinFS allows the user to perform searches based on the metadata of the stored item, regardless of what type of file it is or which application created it.
Being a GNU/Linux user with a light well-organised Gentoo system at home, I often wondered about statements like this. But in the last few years I have had to use M$ Windoze systems at work, so I begin to understand the search requirement: it is because Windoze systems are horrendously organized! The directory structure resembles a junk yard. Writable system files, sloppy application installations, bizarre naming conventions, the scourge of the Windoze registery. It is no wonder M$ feels the need to add a search capability. Navigating a Windoze file system is next to impossible.
an ill wind that blows no good
If the entire fs is turned into a database by using indexes, what exactly is indexed?
Everything. You could search by every image file that would scale to a wallpaper. Every MP3 by some group with a bitrate of 128kbps. Every word file that was modified by Jane after February 2. You can index a large amount of information about the files themselves, the term is metadata. Right click a word or excel file and look at its properties, you could search by all that.
"I use a Mac because I'm just better than you are."
This is just a response to kill the buzz on Apple's Spotlight, which is actually shipping. When some competitor starts to make gains, Microsoft just lets loose that they're "working" on things sometime in the future to make the shareholders happy and to keep their name in the press.
WinGZ is being backported to WinQE using XYZ. WinGZ is not dead, IIRC GQRT FLRO JDF lfkhfh lhhdglksd...
I know it might make you seem a little less 1337, but could you give just a tiny bit of background so I know whether or not to read TFA? Like, WTF is WinFS?
I think the traditional concept of a filesystem with data organized within directories is beginning to show its age.
Why bolt on things like DB functionality and version control features (this is coming eventually...) to a traditional filesystem model when these features fit neatly with the concept of a more generalized persistent object store system?
"Orthodoxy means not thinking--not needing to think. Orthodoxy is unconsciousness." --Eric Blair
I think asking users to define metadata is a wasted effort. While users can tag data, it's a huge chore...
Spotlight I think has the best compromise. Modules that can define meta-data from document contents themselves. Most document formats that people would want to search already have a means of storing meta-data (like EXIF for pictures) so just let people modify this meta-data as appropriate with tools specific to the format, and encourage new app writers to generate documents with room for meta-data as well.
You don't need to store all files in a DB. Just make it easier for system services to have visibility to the meaningful data in documents across the system.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
At least, that's how it will be initially. Then people will be able to make simpler interfaces because of this metadata. As well as directories they can have searches with search results as a way of looking at their local files.
Then there'll be a demand for standards in representing arbitrary metadata, probably as part of the same file. Because right now every avi and mp3 has it's own way of representing it (id3 vs avi's metadata). This will involve extensions local file formats, so that older protocols can continue to use them as a whole "file", but with optional extensions to http and webdav for getting the metadata and just downloading a bit of it.
Then there'll be some consolidation of taxonomies, so they both refer to "author", "date" etc.
Then what we call a file will end up being a small wrapper that points to multiple binaries and strings and ints. Whether this is in the same "file" doesn't matter at this point.
There's my suggested evolution of file metadata, anyway. I completely agree that a revolution of file metadata won't happen because everyone won't switch over night. This basic plan I've outlined is how people will slowly move to it. It'll start off as a cache of metadata, because harddrive space is cheap.