I'd much rather see developers "waste" their time making things efficient than having 1000 cores on my machine trying to ray trace every scene. What it all comes down to is coherency between threads of execution, and all of the techniques that ray tracing makes possible (primarily high frequency lighting, since that's really the only thing that can't be done in a rasterization model) have terrible coherency.
This is super important because no matter how many cores you have, the bottleneck will still be going to memory and getting the data. In rasterization, the data accesses have pretty good spatial locality, but in areas with very high frequency lighting, there is just too much data, and every pixel is hitting a different part of it. Most of the really good ray tracers set up bundles of rays that have good locality, but this is really only trying to emulate rasterization with ray tracing in order to gain some of its performance characteristics.
In short, if rasterization can't do it, then it's going to be too slow to do in real time anyways. What ray tracing does give you is simplicity of writing code and freedom to do whatever you want, but it will never have the performance characteristics to be considered real-time. Even if you did have enough compute power to ray trace your scene at full resolution at full speed, it would be unconscionable to actually do it, because of the sheer amount of electricity wasted.
How can Office 2007 using someone else's indexer to search through your email be anything but a good thing? If every single application had its own indexer, every time your file system changed there would be a flurry of indexers jumping to see what's new, and your machine will come to a crawl.
Granted, they *could* have made it easy to drop in support for other search engines, but that adds a whole level of complexity because now you need to make sure these search engines are reliable (or people will blame Microsoft when it breaks). This involves a complicated test suite, signing (so people don't release trojan indexers that send them all your financial information), and in general is a ridiculous amount of work for them to do just to support someone else's product. Does GDS allow you to change the search engine used underneath? Sure, Microsoft is a convicted monopolist, but forcing them to implement a feature like this questionable.
Does it have merit? Sure, and perhaps it will get implemented someday. I think there are tons of applications that would prefer to have some system-provided indexer rather than having to build indices themselves. But you can't just build a system like this out of thin air, it takes time, and I think what Vista has is great for a V1.0.
In any case, you can disable the indexer fairly easily just by adding filters that turn it off for all the files you'd rather have GDS index (and Outlook should still use the indexer it wants to). This means shell-invoked searches will go slowly, since it will have to search the file system, but presumably GDS can hook that feature and provide its own results.
I wouldn't necessarily list DirectX with the likes of the other projects. DirectX has always tried to be the best at compatibility, with redists and backwards compatibility for OSes that the rest of Microsoft had written off already (it's only recently that the SDK stopped supporting Windows 98, primarily due to lack of demand, since older SDKs still work). You could say that DX10 only supports Vista, but the truth of the matter is that only Vista supports DX10.
It's fairly easy to adapt the API (as appears to have happened here) so that a certain class of applications will run on older hardware (and hence older operating systems), but those applications aren't interesting for DX10 right now, since DX9 already allows you to access the full feature set. As for running newer hardware on older operating systems, adding the required features to older operating systems would be a tremendous effort, since they go all the way up the stack, and would require changes to very old, very sensitive parts of the operating system.
This is something that has possibly severe security implications for Microsoft, but even worse implications for others involved, since it adds yet another version of a very complicated driver from the hardware vendors, and a whole slew of compatibility testing across the board from hardware vendors to software vendors, all to support a shrinking segment of the market (people running new video cards on old OSes). So for everyone involved, it's makes much more sense to continue using DX9 on the applications that need to support older OSes, and consider using DX10 to exploit new hardware and new features that can't be implemented on DX9.
I also attended the contest, but only placed 34th (well, officially tied for 29th). But it's not surprising that US colleges didn't do so well.
Have you seen last year's results? I don't think any US teams were in the top ten, so three ain't bad. Besides, you really have to give props to those teams in the top ten. Those guys were incredibly fast.
The winning team this year is from the same school, and includes some (all?) of the same players from last year's winners, so you know they've got skills in Petersburg. In fact, the past two years both teams from Petersburg were in the top 5. I'd hate to be in that regional competition =)
Slashdot Mirror
I'd much rather see developers "waste" their time making things efficient than having 1000 cores on my machine trying to ray trace every scene. What it all comes down to is coherency between threads of execution, and all of the techniques that ray tracing makes possible (primarily high frequency lighting, since that's really the only thing that can't be done in a rasterization model) have terrible coherency.
This is super important because no matter how many cores you have, the bottleneck will still be going to memory and getting the data. In rasterization, the data accesses have pretty good spatial locality, but in areas with very high frequency lighting, there is just too much data, and every pixel is hitting a different part of it. Most of the really good ray tracers set up bundles of rays that have good locality, but this is really only trying to emulate rasterization with ray tracing in order to gain some of its performance characteristics.
In short, if rasterization can't do it, then it's going to be too slow to do in real time anyways. What ray tracing does give you is simplicity of writing code and freedom to do whatever you want, but it will never have the performance characteristics to be considered real-time. Even if you did have enough compute power to ray trace your scene at full resolution at full speed, it would be unconscionable to actually do it, because of the sheer amount of electricity wasted.
How can Office 2007 using someone else's indexer to search through your email be anything but a good thing? If every single application had its own indexer, every time your file system changed there would be a flurry of indexers jumping to see what's new, and your machine will come to a crawl.
Granted, they *could* have made it easy to drop in support for other search engines, but that adds a whole level of complexity because now you need to make sure these search engines are reliable (or people will blame Microsoft when it breaks). This involves a complicated test suite, signing (so people don't release trojan indexers that send them all your financial information), and in general is a ridiculous amount of work for them to do just to support someone else's product. Does GDS allow you to change the search engine used underneath? Sure, Microsoft is a convicted monopolist, but forcing them to implement a feature like this questionable.
Does it have merit? Sure, and perhaps it will get implemented someday. I think there are tons of applications that would prefer to have some system-provided indexer rather than having to build indices themselves. But you can't just build a system like this out of thin air, it takes time, and I think what Vista has is great for a V1.0.
In any case, you can disable the indexer fairly easily just by adding filters that turn it off for all the files you'd rather have GDS index (and Outlook should still use the indexer it wants to). This means shell-invoked searches will go slowly, since it will have to search the file system, but presumably GDS can hook that feature and provide its own results.
I wouldn't necessarily list DirectX with the likes of the other projects. DirectX has always tried to be the best at compatibility, with redists and backwards compatibility for OSes that the rest of Microsoft had written off already (it's only recently that the SDK stopped supporting Windows 98, primarily due to lack of demand, since older SDKs still work). You could say that DX10 only supports Vista, but the truth of the matter is that only Vista supports DX10.
It's fairly easy to adapt the API (as appears to have happened here) so that a certain class of applications will run on older hardware (and hence older operating systems), but those applications aren't interesting for DX10 right now, since DX9 already allows you to access the full feature set. As for running newer hardware on older operating systems, adding the required features to older operating systems would be a tremendous effort, since they go all the way up the stack, and would require changes to very old, very sensitive parts of the operating system.
This is something that has possibly severe security implications for Microsoft, but even worse implications for others involved, since it adds yet another version of a very complicated driver from the hardware vendors, and a whole slew of compatibility testing across the board from hardware vendors to software vendors, all to support a shrinking segment of the market (people running new video cards on old OSes). So for everyone involved, it's makes much more sense to continue using DX9 on the applications that need to support older OSes, and consider using DX10 to exploit new hardware and new features that can't be implemented on DX9.
I also attended the contest, but only placed 34th (well, officially tied for 29th). But it's not surprising that US colleges didn't do so well.
Have you seen last year's results? I don't think any US teams were in the top ten, so three ain't bad. Besides, you really have to give props to those teams in the top ten. Those guys were incredibly fast.
The winning team this year is from the same school, and includes some (all?) of the same players from last year's winners, so you know they've got skills in Petersburg. In fact, the past two years both teams from Petersburg were in the top 5. I'd hate to be in that regional competition =)
Try changing it to:
/etc/dhcpc/hostinfo-eth0 to get the local IP, so it looks like:
/etc/dhcpc/hostinfo-eth0
ipmasqadm portfw -a -P tcp -L 47624 -R 192.168.0.3 47624
in my scripts, I source
.
ipmasqadm portfw -a -P tcp -L $IPADDR 47624 -R 192.168.0.3 47624
Good luck.