i agree with you that linking all purchases to one account and the rumored "always-on" DRM are bad/strange ideas. if i had any influence i would push against these. i don't, though, they probably don't pay much attention to my armchair quarterbacking blog posts, any more than they used to pay attention to my more direct emails.
i never claimed to have run the army. at best i was a grunt-turned-sergeant-awkwardly-promoted-to-captain who had the ears of the generals because i knew what we could build, who could build it, and i could describe it to everybody - i was boots on the ground. i'm just pointing out that i think the current strategy is wrong and will likely fail, not that i was running it better back in the day.
all the more ironic buying Lookout since internally within microsoft in the mid-90's while we were dogfooding it against the still-being-developed exchange server, outlook (aka Ren, I think, as in Ren & Stimpy) was hatingly referred to as "lookout", as in "look out! it's about to hang again," or "look out! they're about to change the personal store format and you'll never see your old email again," or "look out! you've crashed again halfway through an email and drafts don't work".
Although it makes a nice tagline and dig in the ribs for Microsoft -- same delayed technology, different century, yuck, yuck -- the Cairo Object File System (OFS) and WinFS bear no resemblance to one another. Having worked in the Cairo/NT group at the tail end of the former and suffered through uncountable meetings about the goals/architecture/benefits of the latter prior to leaving MS, I can say this with some certainty. Saying they're the same internally or architecturally because both strive(d) to provide the ability to find any document by any properties or content (aka "information at your fingertips"... remember that?) is just vacuous -- you might as well talk about similarities between file-systems that support shell wildcard expansions * and ?.
OFS was about a lot of things, probably too many things. It was designed during the "object wars" and things like copeland and pink and opendoc were in the headlines. Document-centered work was the proposed user paradigm, where structured documents contained nested opaque data from many different applications, and so applications wouldn't need or want to know the difference between a top-level document or a sub-part of a document. This user paradigm did not entirely come to pass, and so an entire file and object-system architecture and shell user-experience premised on it was canned.
That said, a few features from "OFS" did survive into NT/XP, including:
* sub-streams on NTFS files. yep, look it up in msdn -- who knew!?
* link-tracking within a 'domain'. sadly not file-system style hard-/soft-links, but COM/moniker links, still can be useful.
* content-indexing. the CISVC service which runs COM-object filters over files and creates the "quickly-searchable" index in your "System Volume Information" per-volume hidden folder. this feature tops my list of missed opportunities. not enough filters early enough (hello PDF? hello JPG?), inadequate exposed UI, speed & resource issues, oh my.
* distributed file-system (DFS) features, mount-points, etc.
* file-/mime-/class-type associations and bindings to applications for different actions (edit vs open vs print, etc)
From what I saw to date, WinFS seemed to be about the data/XML paradigm of data format transparency, not about opaque nested/contained data like OFS. It seems to be pursuing a different usage paradigm. At least I think so.
It's a confusing thing, and it shouldn't be. The basic idea of fusing a DB and a FS is dead simple, and if every OS offered structured and unstructured data, a set of simple core schemas, federated query across the two forms of data, and transactional/ACID cross-references between them, you could build many applications more easily. Why WinFS keeps taking so many more bits to describe itself than this is beyond me.
i reuse old pc's like crazy, too, for myself and for nonprofits i work with. but think of the number of damn new machines you're talking about -- recent pc industry growth reports suggested that ~100M of the new PCs shipping this year will be replacing old ones!
it's just like recycling other materials: Reduce, Reuse, Recycle. The first word is Reduce for a reason -- it's the most important step, and the hardest to motivate people about.
yep, lack of tool-friendly reuse options on *nix beyond libs or recompiling the source (although that is quite a great thing to have for experienced developers!) -- this was my feedback to vinodv on his original halloween document, though he chose to include only references to tools and developer skills.
the number of OSS projects that have done language/lib bindings for perl, tcl, ruby, etc shows the usefulness of defining a language-neutral binding mechanism, especially one that supports late binding / scripting languages, but even c++ bindings are found out there.
it has always surprised me that the community has not even one common com-like thing, one with none of the windows-registry baggage, built along *nix principles -- files, pipes, file-oriented security, etc. i always expected 10 or 12 to emerge, then duke it out and consolidate into something common with just enough basic language support in gcc/etc to make it easy to use, something that people could use to add scripting, dynamic binding, etc at a lower cost to any project. a standard made by the community, for the community. something light enough that it's as easy to consider adding to your project as libc.
i can tell you, as nice a job as i think the mono guys are doing, that's not lightweight enough.
Yes it was ported, try googling "dcom unix", duh. two relevant links, software ag's entirex dcom on linux product and the Open Group's COMSource program.
Granted there's no GPL'd com/dcom out there, wish we could have done that, but we never had the resources or mgmnt buy-in to do so. sigh. Are the ports used? Probably a little. You likely don't hear Microsoft making hay about these because they arrived on-scene just as the big.NOT shift was happening, and this was off-message.
and no, it wasn't too hard to port except for sorting out threading, ld/.so, security, and process-model issues... haha, but actually pretty standard porting issues, esp back then when *nix threading was less settled.
Slashdot Mirror
i agree with you that linking all purchases to one account and the rumored "always-on" DRM are bad/strange ideas. if i had any influence i would push against these. i don't, though, they probably don't pay much attention to my armchair quarterbacking blog posts, any more than they used to pay attention to my more direct emails.
i never claimed to have run the army. at best i was a grunt-turned-sergeant-awkwardly-promoted-to-captain who had the ears of the generals because i knew what we could build, who could build it, and i could describe it to everybody - i was boots on the ground. i'm just pointing out that i think the current strategy is wrong and will likely fail, not that i was running it better back in the day.
all the more ironic buying Lookout since internally within microsoft in the mid-90's while we were dogfooding it against the still-being-developed exchange server, outlook (aka Ren, I think, as in Ren & Stimpy) was hatingly referred to as "lookout", as in "look out! it's about to hang again," or "look out! they're about to change the personal store format and you'll never see your old email again," or "look out! you've crashed again halfway through an email and drafts don't work".
Although it makes a nice tagline and dig in the ribs for Microsoft -- same delayed technology, different century, yuck, yuck -- the Cairo Object File System (OFS) and WinFS bear no resemblance to one another. Having worked in the Cairo/NT group at the tail end of the former and suffered through uncountable meetings about the goals/architecture/benefits of the latter prior to leaving MS, I can say this with some certainty. Saying they're the same internally or architecturally because both strive(d) to provide the ability to find any document by any properties or content (aka "information at your fingertips"... remember that?) is just vacuous -- you might as well talk about similarities between file-systems that support shell wildcard expansions * and ?.
OFS was about a lot of things, probably too many things. It was designed during the "object wars" and things like copeland and pink and opendoc were in the headlines. Document-centered work was the proposed user paradigm, where structured documents contained nested opaque data from many different applications, and so applications wouldn't need or want to know the difference between a top-level document or a sub-part of a document. This user paradigm did not entirely come to pass, and so an entire file and object-system architecture and shell user-experience premised on it was canned.
That said, a few features from "OFS" did survive into NT/XP, including:
From what I saw to date, WinFS seemed to be about the data/XML paradigm of data format transparency, not about opaque nested/contained data like OFS. It seems to be pursuing a different usage paradigm. At least I think so.
It's a confusing thing, and it shouldn't be. The basic idea of fusing a DB and a FS is dead simple, and if every OS offered structured and unstructured data, a set of simple core schemas, federated query across the two forms of data, and transactional/ACID cross-references between them, you could build many applications more easily. Why WinFS keeps taking so many more bits to describe itself than this is beyond me.
i reuse old pc's like crazy, too, for myself and for nonprofits i work with. but think of the number of damn new machines you're talking about -- recent pc industry growth reports suggested that ~100M of the new PCs shipping this year will be replacing old ones! it's just like recycling other materials: Reduce, Reuse, Recycle. The first word is Reduce for a reason -- it's the most important step, and the hardest to motivate people about.
yep, lack of tool-friendly reuse options on *nix beyond libs or recompiling the source (although that is quite a great thing to have for experienced developers!) -- this was my feedback to vinodv on his original halloween document, though he chose to include only references to tools and developer skills. the number of OSS projects that have done language/lib bindings for perl, tcl, ruby, etc shows the usefulness of defining a language-neutral binding mechanism, especially one that supports late binding / scripting languages, but even c++ bindings are found out there. it has always surprised me that the community has not even one common com-like thing, one with none of the windows-registry baggage, built along *nix principles -- files, pipes, file-oriented security, etc. i always expected 10 or 12 to emerge, then duke it out and consolidate into something common with just enough basic language support in gcc/etc to make it easy to use, something that people could use to add scripting, dynamic binding, etc at a lower cost to any project. a standard made by the community, for the community. something light enough that it's as easy to consider adding to your project as libc. i can tell you, as nice a job as i think the mono guys are doing, that's not lightweight enough.
Yes it was ported, try googling "dcom unix", duh. two relevant links, software ag's entirex dcom on linux product and the Open Group's COMSource program. Granted there's no GPL'd com/dcom out there, wish we could have done that, but we never had the resources or mgmnt buy-in to do so. sigh. Are the ports used? Probably a little. You likely don't hear Microsoft making hay about these because they arrived on-scene just as the big .NOT shift was happening, and this was off-message.
and no, it wasn't too hard to port except for sorting out threading, ld/.so, security, and process-model issues... haha, but actually pretty standard porting issues, esp back then when *nix threading was less settled.