A while back I wrote in response to Mark:
>>ok...just got a brainstorm here (thunder-boom) picture this for an
>>idea....a distributed computing "bank", where people can dump their spare
>>cpu cycles to, and "draw" some major friggin horsepower when we actually
>>need it. it may sound silly, but seriously, any of us just do a "vmstat"
>>on our systems after a day, and see that the thing is only really using a
>>few percent of the cpu over the day (since we sleep during nite on
>>occasion..that helps)
>Yes, all very nice. Myself I can see a sustained infrastructure forming
>once there is something like Digital's Millcent system to organize
>micropayments for the cycles (corporations want to make those $$ work), a
>suitable allocation broker to match bids and offers (research opportunity
>here), and Java with just-in-time compiling so nobody has to worry about
>architectural differences and Trojan horses.
The latter part of my mini-prediction is becoming reality. See
http://rc5.mit.edu , a new Java-based attack being mounted on RC5-64.
Besides using Java, they make the further simplification of discarding
the keyserver! Instead the client simply chooses random blocks, and
by probability theory (which I should have thought through myself but
didn't) the expected time to solution is twice that when a keyserver
is employed. Under Netscape 3, the Java client runs at about 1/250
the speed of the Bovine clients which use assembler portions tuned for
each architecture; I would expect JIT to narrow the gap to within a
factor of 10.
Received on Sun Dec 7 12:17:36 1997
This archive was generated by hypermail 2.1.8 : Sun Jan 09 2005 - 13:53:47 CST