[rc5] V3 Questions and Concerns

Ivo Janssen ivo at ricardis.tudelft.nl
Sat Nov 1 18:21:04 EST 1997


On Sat, 1 Nov 1997, James Mastros wrote:

> 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.
> > <chop>
> > >         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
> > applet.
> > 
> > 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.
> 
> Exactly.
> 
> > 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".
> > or
> >  "I've got lots of mips"
> > or
> >  "I want to do the chess database, primes, or the current RC5
> >  in that order."
> 
> Righto.
> 
> > 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
> > platform.
> 
> 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"
> post.

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
> the keyspace".
> 	-=- 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.
> 

Sorry! :) (this is a joke, no reason to start flaming or so!)

Ivo

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list