[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: intent of package seti@home



I am a strong believer in free software.  Your arguments are good, but 
not perfect.

John Hasler <john@dhh.gt.org> writes:

> Kevin Dalley writes:
> It occurs to me that your test packets could require the client to compute
> an md5sum on itself and send it in along with its version data.  This would
> pretty much require that everyone runs a binary issued or registered by
> SETI, though.

The algorithm would need to be a bit more complicated than that to
protect against malicious attacks.  The malicious cracker could just
return an md5sum of the approved binary, which is kept nearby for
occasions like this.  For the non-malicious hacker, this algorithm
would work fine.

> A common myth about free software.  "If I release my source there will be
> hordes of buggy, incompatible versions!"  Doesn't happen.  How many buggy,
> incompatible unofficial modified versions of the Linux kernel are there in
> circulation?  Gcc?  Perl?  How many people are going to install a variant
> SETI client hacked up by somebody they never heard of instead of getting
> one from your site or installing it from their Debian CD?  (The latter will
> only be possible if you free your software, of course.)

There are subtle differences between most free software and a
distributed program.  There are many buggy versions of the Linux
kernel around.  (2.2.1, for example).  The potato upgrade has
introduced many more bugs in software.  The only people affected by
the bugs are the people downloading and using the bad software.  A bug 
in one copy of a distributed system could affect the final results.

> > False data would only help a little, depending upon the bug introduced in
> > the changed code.
> 
> You seem to be assuming that all changes will introduce bugs.  Some will,
> of course, but most will eliminate bugs (you do know that there are bugs in
> the code, I hope).  

Not at all.  But there may be advantages of knowing which data was
analyzed with which bugs.

If I were directly involved in this project and the decision were up
to me, I would try to find an excuse for as much of the source code as 
possible.

Disclaimer:  While my company funds some of the research for
SETI@Home, we are not directly involved in the research.  Furthermore, 
I have no affiliation with SETI@Home.

-- 
Kevin Dalley
SETI Institute
kevin@seti.org


Reply to: