Map reduce is not a good candidate for this type of distribution. We are talking about huge amounts of data that would have to be sent to your browser. The data locality is very important to Google's success. If the computation to data set size is linear or better, and/or it a very large data set, transport of the data swamps any gains. If the computation is much higher than the ratio to the data set, as in folding, then you have a win.
Google's scalable approach to adding a another, cheap CPU along with another box full of storage scales nicely. Their real goal is adding redundant, replaceable storage on a massive scale, right-sized with the CPU power for computation and communication. If that CPU is not near the data, it won't work.
On another front, if you have ever done anything large in browser javascript, you might have noticed that memory management is not that great. Perhaps it is getting better.
Lastly, javascript is a great tool and easy to program. If you have a really intensive job, the expense of that job should justify the proper engineering resources to move the problem computationally as close to the hardware (CPU, main memory) as possible. This might suggest C, assembler, etc.
If I understood it correctly, then the point of the essay was to change the way we talk about the Internet. We have to explain it to the courts and others as though it was a commons or a marketplace rather than a collection of pipes viewed as property of SBC and Verizon.
The scenario described is possible and could have a bad effect on innovation and the economy in the US. Just look at how screwed up non-voice services are on cellular networks. It might not be as bad as Doc makes it out to be. Services that would have to pay too much would probably move offshore. Consumers outside of the US might pay less for these services. Innovation and GDP just shift away. The tech industry, including VCs would fight the innovation tax. Technologists would work around the existing pipes.
A better analogy for the Internet is the interstate highway system. It was built by the government and can be used by anybody for carrying just about anything. It separates us from other potential super powers (ex. USSR, current China) in that we can
make things anyplace and sell them anywhere else in the country. The contractors that built the interstates got paid, up front. They do not get to say what goods travels on them now or tax the value of those goods.
This analogy may spoil some of the magic of the commons for some readers, but it shouldn't. Those readers are still free to be as creative as they like as long as nothing is blocking them.
Oh, and I forgot to mention that with HTTP, you will have to poll for work and initiate another connection to submit a result.
Map reduce is not a good candidate for this type of distribution. We are talking about huge amounts of data that would have to be sent to your browser. The data locality is very important to Google's success. If the computation to data set size is linear or better, and/or it a very large data set, transport of the data swamps any gains. If the computation is much higher than the ratio to the data set, as in folding, then you have a win. Google's scalable approach to adding a another, cheap CPU along with another box full of storage scales nicely. Their real goal is adding redundant, replaceable storage on a massive scale, right-sized with the CPU power for computation and communication. If that CPU is not near the data, it won't work. On another front, if you have ever done anything large in browser javascript, you might have noticed that memory management is not that great. Perhaps it is getting better. Lastly, javascript is a great tool and easy to program. If you have a really intensive job, the expense of that job should justify the proper engineering resources to move the problem computationally as close to the hardware (CPU, main memory) as possible. This might suggest C, assembler, etc.
If I understood it correctly, then the point of the essay was to change the way we talk about the Internet. We have to explain it to the courts and others as though it was a commons or a marketplace rather than a collection of pipes viewed as property of SBC and Verizon.
The scenario described is possible and could have a bad effect on innovation and the economy in the US. Just look at how screwed up non-voice services are on cellular networks. It might not be as bad as Doc makes it out to be. Services that would have to pay too much would probably move offshore. Consumers outside of the US might pay less for these services. Innovation and GDP just shift away. The tech industry, including VCs would fight the innovation tax. Technologists would work around the existing pipes.
A better analogy for the Internet is the interstate highway system. It was built by the government and can be used by anybody for carrying just about anything. It separates us from other potential super powers (ex. USSR, current China) in that we can make things anyplace and sell them anywhere else in the country. The contractors that built the interstates got paid, up front. They do not get to say what goods travels on them now or tax the value of those goods.
This analogy may spoil some of the magic of the commons for some readers, but it shouldn't. Those readers are still free to be as creative as they like as long as nothing is blocking them.