Re: intent of package seti@home
Stephane Bortzmeyer <bortzmeyer@debian.org> writes:
> On Thursday 22 April 1999, at 13 h 30, the keyboard of Kevin Dalley
> <kevin@seti.org> wrote:
> The concern is reasonable but John Hasler explained very well why
> hiding the source code does not protect you against such a
> sabotage. The problem of saboteurs is real but the solution of
> concealing the source code is not serious. Pretending that this is a
> case where the free software model fails is not true.
Hiding source code doesn't absolutely protect against sabotage, but it
does reduce bad analysis, whether accidental or purposeful. I don't
like the solution of hiding source code, but it is not a ridiculous
measure.
To protect against breakins, stronger protection is desirable. Any
entry is bad. Given a choice, completely removing the possibility of
sabotage from SETI@Home would be good. However, reducing the amount
of sabotage is another step.
> "Useless" is too strong. There are several simple heuristics to
> limit false negatives:
>
> - assigning each block to two machines (requiring different network
> addresses). It divides by two the speed but it is quite safe,
> specially if the blocks are assigned randomly.
The usefulness of this technique depends upon the frequency of bad
executables. Distributing one bad executable may still cause problems.
> - barring machines to send too many results in a too short time
> (difficult with proxies).
Actually, difficult in all cases SETI@Home allows machines which are
connected occasionally. Any machine may run for hours or days before
connecting to the network, followed by an upload of a large amount of
analyzed data.
Reply to: