Most of the posts here are anti-this, anti-that. Consider for a moment the people who write the code for these games. They want, and deserve, some tall dollars for their efforts. Maintaining control of battle net is part of that.
Wake up.
If you spent years of your life developing a gaming property as valuable as battle net and the games that go with it, you would certainly be protective of anything that might destroy your ability to capitalize on it in the future.
In those cases you *can* tune your code to the number of available boxes and interconnect performance - perhaps by partitioning your problem space and cascading data exchanges across groups of nodes. Granted, not all problems can be executed asychronously, but in most cases you can rethink the problem in a way that avoids massive cross updates. The situation you describe leaves whatever interconnect in place idle for the majority of the time.
Of course, but you just have to tune your code to use the available interconnects efficiently. The worlds largest 'supercomputer' is Seti@home's NOW (network of workstations). You view their program as a huge cluster with massively slow interconnects - yet they still manage to process huge amounts of data. Code written for a 4gb/s backplane machine isn't optimized for a 1gb/s backplane, nor a 100mb ethernet 'backplane'.
- Josh Siler
A flat rate inevitably results in more high usage users than metered service - specifically, the people who enjoy the net, but can't or won't pay higher fees.
Heavy users fuel development, with online participation, advertising dollars, ecommerce activity, etc. Lowering the number of heavy users will lower the number of dollars in the industry, which in turn lowers the rate of progress.
Slashdot Mirror
Most of the posts here are anti-this, anti-that. Consider for a moment the people who write the code for these games. They want, and deserve, some tall dollars for their efforts. Maintaining control of battle net is part of that.
Wake up.
If you spent years of your life developing a gaming property as valuable as battle net and the games that go with it, you would certainly be protective of anything that might destroy your ability to capitalize on it in the future.
I know I would.
Er...'event handling', 'GUI' and 'object oriented' aren't exactly grandiose ideas or big buzzwords. More like standard platform features...
Now they can never be sure what represents what!
In those cases you *can* tune your code to the number of available boxes and interconnect performance - perhaps by partitioning your problem space and cascading data exchanges across groups of nodes. Granted, not all problems can be executed asychronously, but in most cases you can rethink the problem in a way that avoids massive cross updates. The situation you describe leaves whatever interconnect in place idle for the majority of the time.
Of course, but you just have to tune your code to use the available interconnects efficiently. The worlds largest 'supercomputer' is Seti@home's NOW (network of workstations). You view their program as a huge cluster with massively slow interconnects - yet they still manage to process huge amounts of data. Code written for a 4gb/s backplane machine isn't optimized for a 1gb/s backplane, nor a 100mb ethernet 'backplane'. - Josh Siler
A flat rate inevitably results in more high usage users than metered service - specifically, the people who enjoy the net, but can't or won't pay higher fees. Heavy users fuel development, with online participation, advertising dollars, ecommerce activity, etc. Lowering the number of heavy users will lower the number of dollars in the industry, which in turn lowers the rate of progress.
The last thing Linux needs is more installation and setup complexity.