[rc5] V3 Questions and Concerns
root at jennifer-unix.dyn.ml.org
Sat Nov 1 11:47:44 EST 1997
On Tue, 28 Oct 1997, Marc Sissom wrote:
> Eric Gindrup wrote:
> I'm not going to bother cleaning this up this time...
But I shall...
(Note to Eric Gindrup: This is highly annoying.)
> > Although true that Java cores are not as high-performance as
> > native cores, the extra security is likely to draw in people who would
> > not be comfortable downloading "strange" software to run unsupervised.
> > This would increase the effectiveness of the Effort.
> > There are a whole bunch of reasons that this is a good thing and
> > the only reason I've really heard opposing it is that the Java
> > performance isn't good enough. I counter, though, that 0kps is
> > infinitely worse than 1kps.
> Nobody seems to want to combine the web page, java applets, easy
> download, and poor java performance into the obvious, a real,
> live, productive, DEMO!
Umm... I do. Look for my post "Re: [rc5] Best setup for infrequent dial-up
connection". If you can't find it, mail me, and I'll send you a copy.
> Sure, look here! Load this URL and watch your PC crunch keys,
> perform signal analysis on radio telescope signals, workout chess
> moves, or whatever. Then if the indi is interested, they can chase
> down the high performance core and let it run as an app and not an
> The object oriented forms of communication that the later JDK
> offers is also a plus. Download the 'object' which includes the
> data and the methods, execute the 'process' method and then send
> it back. For apps that are sensitive to easy sabotage, the object
> includes methods for authentication. If the app requires a 24/7
> connection, it drops itself out when the communications fail. If
> it requires a high performance platform, it drops out when the
> client fails to meet spec.
I was thinking of somthing like that with my recent "[rc5] An idea for the
v3 protocol" (Or somthing like that).
> The generic 'client' doesn't have to know about any of this. All
> it has to know is how to get objects from the servers, how to ID
> itself to the processing objects, how to run them, and how to
> return objects to the servers. Perhaps the objects can do this
> last part themselves.
> The user config can be simple or complex. The user can say:
> "I want to run SETI, or anything else that is heavy on flops".
> "I've got lots of mips"
> "I want to do the chess database, primes, or the current RC5
> in that order."
> Let the servers hold the intelligence to figure out what work
> is available and what to dispatch to which cpu. Let the objects
> decide for novices if they are running on an appropriate
I was planning on letting the client decide that, based on a simple
discription of the stresses and requirements for that core.
I love it when I see a "Me too" post that didn't know that it was a "Me too"
-=- James Mastros
When the annals of distributed computing are written, and the name 'Bovine'
appears in there, I can say "Hey, I was a part of that, I checked .0012% of
-=- Brian Wilson <wilsonb at mindspring.net>
Go to www.distributed.net before I come make you!
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5