No, I agree with you. You're completely correct that WinFS's scope was far beyond desktop search, but in reality, this is all the end user really cared about, and "plug-ins" to a desktop search that understands various database formats seems to solve the problem (in it's current state) better than the monstrosity of WinFS. Like you say, it would probably be 10 years before apps fully supported it anyways. It would likely be at least another 2-3 years before Office and other MS apps supported it, so it really had no use in Vista other than as a "Here it is, it's done, now start using it" approach.
I don't think the developer world is ready for it. And the users can only benefit if the developers accept it.
While you essentially have a somewhat correct position, all your facts and deductions are wrong.
1) Longhorns original schedule was mid-2003 (Whistler Server (eventaully called Windows 2003) had been scheduled for 2002 for almost a year before XP Shipped).
2) Longhorn started with the XP codebase.
3) The Longhorn reset started with the Windows 2003 SP1 codebase.
4) The "Reset" happend in 2004, not 2003.
5) It was not "add-on" development, it was essentially re-architecting the entire OS to be.NET based, something which nothing was really ready for, and was far too large of a job.
6) They didn't have problems "getting the features to play well with each other", they simply weren't ready, and wouldn't be ready for the OS ship. In the case of WinFS, it was simply an over-architected solution to a simple problem that was much better solved by simple indexing.
7) Not "all" of the exciting features were removed. As I said above, WinFS turned out to be something that wasn't really needed or wanted. Monad was relagated to ship post launch, EFI turned out to be useless because no computers were using it in consumer PC's, and NGSCB (Palladium) was so highly criticised that nobody wanted it anyways.
The features that were dropped were largely irrelevant, or unwanted, meanwhile the list of things that are new in Vista is huge. Check out the wikipedia entry:
Now, that may still not be enough for a lot of people to upgrade, or they may not be features a lot of people really care about, but to claim that "all the exciting new OS features had been removed" is simply bogus.
Yes, since the user having the keys solves the problem. Not.
Surveys have shown that users are willing to give out their passwords for a piece of chocolate. Cars are Hijacked every day, and the user just gets out of the car leaving the keys to the attacker. I'm not saying that a TPM chip is the best way to solve the problem, but merely putting it in the users hands doesn't solve much of anything.
I think that, like many things, the reasons behind these ideas are well intentioned, but can be used for evil if not policed.
There are a lot of good reasons to do the things Microsoft proposes. Stolen laptops, Malware, Leaked confidential information (think patient records, social security numbers, etc..). The problem is, of course, that most such technologies cut both ways.
My point was that Vista had nothing to do with this. The methods are being used only in the Patterns & Practices group, as such your comment that Vista was delayed because of these methods was not only off base, but just didn't apply.
If you had actually gone to the link and watched the video, you'd realize that you just made yourself look like an idiot. But since you're blissfully ignorant, I'll just laugh at you. I'll leave it as an exercise for you to figure out why.
Actually, Microsoft has done a lot of work in this area. They have a model they claim works very well for creative teams, consisting of a "common" open work area with reconfigurable moving walls you can write on, surrounded by shared offices, plus "escape pods" where people can go be alone with their project. You can see a channel 9 video on this here: http://channel9.msdn.com/ShowPost.aspx?PostID=2383 21
Gamers aren't the only ones driving the market. You'll want a fast dual core processor for Vista, for instance. Software will always expand to fill all available CPU Cycles. I just see software becoming more powerful, not just games. Thinks like more AI in real-world apps, star trek level stuff.
That really makes no sense. Why put it on the CPU unless you were interested in high performance, low latency gaming? I could see it being used in a console, sure, where you don't upgrade the equipment. Possibly Laptops, too, but not Desktops. What's wrong with being on the chipset? Oh, right, AMD doesn't make chipsets anymore, but I guess ATI does...
I'm not entirely sure I agree. MMU's or FPU's are central processor functions. People didn't typically upgrade these regularly, though sometimes they would buy machines without them and want to add them later.
The video, on the other hand, is something that is in constant flux and is an incredibly competitive market. Sound is ok on the motherboard, as is video for "typical" users, because they don't have high demands. Putting it in the CPU, on the other hand, seems kind of silly, since the CPU is the single most expensive component in the computer in most cases.
If we're talking about a substandard "onboard" kind of graphics, then I suppose it's not a big deal. You know, like Intel onboard graphics or whatever. But if we're talking about high end video, which is what I would suppose it would be, otherwise there would be no purpose in trying to make it "ultra efficient", then that changes far too fast.
I don't want to pay $500 premium on my CPU for something that will be outdated in 6 months. I mean, I can sell off my old high end video card in 6 months and buy the latest stuff, I can't sell off the integrated GPU.
Am I the only that thinks this is a bad idea? Either I change video cards more often than CPU's or CPU's more than graphics cards, but in either case I seldom want to upgrade both at the same time. Although I suppose I wouldn't mind a better GPU "for free" with my CPU, I suspect it won't be "for free".
No, I meant that whether a project is open source or closed, you still have project management to deal with. I know full well how open source projects work. Take the Linux kernel, for example. Much of the project management is done on the linux kernel mailing lists, but it's sitll project management. Linus (or one of his selected managers) has to review all code and decide if it's right for the core kernel, roadmaps are discussed and drawn up, etc... Volunteer developers does add certain wrinkles to the problem, but it's still got a huge amount of overlap with typical commercial development.
Open source does not simply happen in a vacuum, it's not order that magically materializes out of chaos. Read the C&B.
That's simply ridiculous. Theming is not a tradeoff with the kernel. Open source or not, a project is a project, and requires project management. The same overhead is there regardless.
You're making a totally different argument. I won't disagree that market forces have a definite impact on the quality of software, but the point I was addressing was the implication that Microsoft simply didn't hire enough competant developers, and instead hired superfluous musicians and graphics artists.
My point was that Microsoft has likely hired all the developers it can get and/or manage efficiently, cutting "cosmetic" staff won't do anything to improve software quality.
You're talking a totally different model there. Even so, you're not throwing bodies at the problem, bodies voluntarily go looking at the problem, then if they find something, present it to the benevolent dictator to cherry pick patches. There's no real project management involved (except for the core project developers). Many of the changes just fall in their lap when someone submits them, without anyone knowing the work was even being done.
The car manufacturer could hire competent mechanical engineers and cut costs in the fabric design department instead.
Do you really think it's a lack of money to pay engineers that prevents a company like GM or Microsoft from creating bug-free products? That's amazingly clueless.
Don't you think that Microsoft wouldn't pay whatever it took to hire people to make Windows the best product they could? Yes, they would. The problem is not money. The problem is logistics and resources. There are a finite number of skilled developers, especially those with skills in a particular area. There are also a finite number of people that can work on the same project without stepping on each others toes.
You can't just throw more bodies at the problem. That just makes matters worse. So, no. It's highly unlikely that cutting the budget for fabric design would do anything to improve the engineering staff.
While I agree that any tom, dick or sally shouldn't be able to just make up stuff and have it appear on Wikipedia (it's not a source of fiction), I think that there's a lot of people that make value judgements about things they disagree with on Wikipedia. Many articles are, essentaially, "Don't believe any of this crap, they're shysters" kind of deal. I personally believe that an encyclopedia should give facts, and the end user should make their own judgements about them.
Uhhh.. I'm sorry, but we seem to have read entirely different interviews. Nowhere did he say "developers don't want that", what he said was that Developers wanted fixes to the existing CSS support more than adding new CSS features, but even so they did add a number of new CSS features, again based largely upon developer demand (stuff like min/max-width, etc..)
Also, IE (even IE6) and FF treat margins and padding exactly the same way in standards mode. So I don't know what you're trying to say.
Slashdot Mirror
Try reading the whole thing.
Yes, Monad has been released for non-Vista OS's, but they're still working on all the cool new Vista related features of it.
No, I agree with you. You're completely correct that WinFS's scope was far beyond desktop search, but in reality, this is all the end user really cared about, and "plug-ins" to a desktop search that understands various database formats seems to solve the problem (in it's current state) better than the monstrosity of WinFS. Like you say, it would probably be 10 years before apps fully supported it anyways. It would likely be at least another 2-3 years before Office and other MS apps supported it, so it really had no use in Vista other than as a "Here it is, it's done, now start using it" approach.
I don't think the developer world is ready for it. And the users can only benefit if the developers accept it.
While you essentially have a somewhat correct position, all your facts and deductions are wrong.
.NET based, something which nothing was really ready for, and was far too large of a job.
o ws_Vista
1) Longhorns original schedule was mid-2003 (Whistler Server (eventaully called Windows 2003) had been scheduled for 2002 for almost a year before XP Shipped).
2) Longhorn started with the XP codebase.
3) The Longhorn reset started with the Windows 2003 SP1 codebase.
4) The "Reset" happend in 2004, not 2003.
5) It was not "add-on" development, it was essentially re-architecting the entire OS to be
6) They didn't have problems "getting the features to play well with each other", they simply weren't ready, and wouldn't be ready for the OS ship. In the case of WinFS, it was simply an over-architected solution to a simple problem that was much better solved by simple indexing.
7) Not "all" of the exciting features were removed. As I said above, WinFS turned out to be something that wasn't really needed or wanted. Monad was relagated to ship post launch, EFI turned out to be useless because no computers were using it in consumer PC's, and NGSCB (Palladium) was so highly criticised that nobody wanted it anyways.
The features that were dropped were largely irrelevant, or unwanted, meanwhile the list of things that are new in Vista is huge. Check out the wikipedia entry:
http://en.wikipedia.org/wiki/Features_new_to_Wind
Now, that may still not be enough for a lot of people to upgrade, or they may not be features a lot of people really care about, but to claim that "all the exciting new OS features had been removed" is simply bogus.
Yes, since the user having the keys solves the problem. Not.
Surveys have shown that users are willing to give out their passwords for a piece of chocolate. Cars are Hijacked every day, and the user just gets out of the car leaving the keys to the attacker. I'm not saying that a TPM chip is the best way to solve the problem, but merely putting it in the users hands doesn't solve much of anything.
Those situations would fall under the jurisdiction of law enforcement, not Microsoft.
Law Enforcement almost never solves them.
I think that, like many things, the reasons behind these ideas are well intentioned, but can be used for evil if not policed.
There are a lot of good reasons to do the things Microsoft proposes. Stolen laptops, Malware, Leaked confidential information (think patient records, social security numbers, etc..). The problem is, of course, that most such technologies cut both ways.
My point was that Vista had nothing to do with this. The methods are being used only in the Patterns & Practices group, as such your comment that Vista was delayed because of these methods was not only off base, but just didn't apply.
If you had actually gone to the link and watched the video, you'd realize that you just made yourself look like an idiot. But since you're blissfully ignorant, I'll just laugh at you. I'll leave it as an exercise for you to figure out why.
Actually, Microsoft has done a lot of work in this area. They have a model they claim works very well for creative teams, consisting of a "common" open work area with reconfigurable moving walls you can write on, surrounded by shared offices, plus "escape pods" where people can go be alone with their project. You can see a channel 9 video on this here: http://channel9.msdn.com/ShowPost.aspx?PostID=2383 21
It's very interesting.
Gamers aren't the only ones driving the market. You'll want a fast dual core processor for Vista, for instance. Software will always expand to fill all available CPU Cycles. I just see software becoming more powerful, not just games. Thinks like more AI in real-world apps, star trek level stuff.
That really makes no sense. Why put it on the CPU unless you were interested in high performance, low latency gaming? I could see it being used in a console, sure, where you don't upgrade the equipment. Possibly Laptops, too, but not Desktops. What's wrong with being on the chipset? Oh, right, AMD doesn't make chipsets anymore, but I guess ATI does...
I'm not entirely sure I agree. MMU's or FPU's are central processor functions. People didn't typically upgrade these regularly, though sometimes they would buy machines without them and want to add them later.
The video, on the other hand, is something that is in constant flux and is an incredibly competitive market. Sound is ok on the motherboard, as is video for "typical" users, because they don't have high demands. Putting it in the CPU, on the other hand, seems kind of silly, since the CPU is the single most expensive component in the computer in most cases.
If we're talking about a substandard "onboard" kind of graphics, then I suppose it's not a big deal. You know, like Intel onboard graphics or whatever. But if we're talking about high end video, which is what I would suppose it would be, otherwise there would be no purpose in trying to make it "ultra efficient", then that changes far too fast.
I don't want to pay $500 premium on my CPU for something that will be outdated in 6 months. I mean, I can sell off my old high end video card in 6 months and buy the latest stuff, I can't sell off the integrated GPU.
Am I the only that thinks this is a bad idea? Either I change video cards more often than CPU's or CPU's more than graphics cards, but in either case I seldom want to upgrade both at the same time. Although I suppose I wouldn't mind a better GPU "for free" with my CPU, I suspect it won't be "for free".
No, I meant that whether a project is open source or closed, you still have project management to deal with. I know full well how open source projects work. Take the Linux kernel, for example. Much of the project management is done on the linux kernel mailing lists, but it's sitll project management. Linus (or one of his selected managers) has to review all code and decide if it's right for the core kernel, roadmaps are discussed and drawn up, etc... Volunteer developers does add certain wrinkles to the problem, but it's still got a huge amount of overlap with typical commercial development.
Open source does not simply happen in a vacuum, it's not order that magically materializes out of chaos. Read the C&B.
That's simply ridiculous. Theming is not a tradeoff with the kernel. Open source or not, a project is a project, and requires project management. The same overhead is there regardless.
Where, exactly, did you come up with this opinion?
What you're saying is that Linux developers shouldn't be working on XGL and Beryl because doing so harms the kernel development.
That's just silly.
You're making a totally different argument. I won't disagree that market forces have a definite impact on the quality of software, but the point I was addressing was the implication that Microsoft simply didn't hire enough competant developers, and instead hired superfluous musicians and graphics artists.
My point was that Microsoft has likely hired all the developers it can get and/or manage efficiently, cutting "cosmetic" staff won't do anything to improve software quality.
You're talking a totally different model there. Even so, you're not throwing bodies at the problem, bodies voluntarily go looking at the problem, then if they find something, present it to the benevolent dictator to cherry pick patches. There's no real project management involved (except for the core project developers). Many of the changes just fall in their lap when someone submits them, without anyone knowing the work was even being done.
Most corporate development can't work that way.
The car manufacturer could hire competent mechanical engineers and cut costs in the fabric design department instead.
Do you really think it's a lack of money to pay engineers that prevents a company like GM or Microsoft from creating bug-free products? That's amazingly clueless.
Don't you think that Microsoft wouldn't pay whatever it took to hire people to make Windows the best product they could? Yes, they would. The problem is not money. The problem is logistics and resources. There are a finite number of skilled developers, especially those with skills in a particular area. There are also a finite number of people that can work on the same project without stepping on each others toes.
You can't just throw more bodies at the problem. That just makes matters worse. So, no. It's highly unlikely that cutting the budget for fabric design would do anything to improve the engineering staff.
Yes, I'm sure the car manufacturer would put all their fabric designers on the brake problem. That's a good use of their time.
Because it's an intel chipset?
While I agree that any tom, dick or sally shouldn't be able to just make up stuff and have it appear on Wikipedia (it's not a source of fiction), I think that there's a lot of people that make value judgements about things they disagree with on Wikipedia. Many articles are, essentaially, "Don't believe any of this crap, they're shysters" kind of deal. I personally believe that an encyclopedia should give facts, and the end user should make their own judgements about them.
Uhhh.. I'm sorry, but we seem to have read entirely different interviews. Nowhere did he say "developers don't want that", what he said was that Developers wanted fixes to the existing CSS support more than adding new CSS features, but even so they did add a number of new CSS features, again based largely upon developer demand (stuff like min/max-width, etc..)
Also, IE (even IE6) and FF treat margins and padding exactly the same way in standards mode. So I don't know what you're trying to say.
As for cacheing, try ctrl-f5.