Some points to ponder:

 * I occasionally check my stats in Team NetBSD on SETI@home (or, I did).
   The appearance is that many people moderately on the list have been
   relatively static.  Either the machines are no longer running 
   setiathome, or else they have too few spare CPU cycles to be useful.

 * It's not clear whether all NetBSD clients are being decomissioned.
   Some aren't listed as explicitly going out, though they seem to
   generally be older versions (so SETI@home may feel that the implication
   is strong enough).

 * i386-unknown-netbsd is on its way out, but not i386-unknown-openbsd.
   (On the other hand, the only OpenBSD binary listed is 1.1, which
    may make it implicitly on the way out.)

 * They claim that an Amiga client is in the works.  Much as I loved my
   dear old Amigas, I'm surprised that SETI@home still plans an Amiga
   port while dumping NetBSD/i386, NetBSD/Alpha, etc.

 * There is a ``Thanks to the following people for porting SETI@home...''
   A question arises in my mind: Did SETI@home contact them, or the other
   way around?  (Wes Peters is listed in there, I see; I believe that he
   is a FreeBSD-type, isn't he?)

 * I wouldn't count on being able to clarify the waters if by some chance
   it's your machine that finds the first definite sign of intelligence.
   Especially if you're running a LINUX binary, I'd not put much faith in
   the media managing to pick up anything more than ``LINUX''.  (Or, they
   might catch that you used a LINUX binary on your NetBSD machine, and
   may report something such as, ``...running LINUX on his/her NetBSD
   machine...'')

   If they can't support our OS, they could provide a legitimately patched
   version that gets the correct OS version.  (Or do the binaries use
   uname(1) to figure out the machine?)

 * Team NetBSD has ~60 years and ~34,000 results logged.  In proportion to
   the ~186,000 years and ~74,000,000 results that's not much.  On the
   other hand, if it's just a matter of compling & storing a few more
   binaries...how much more might they get over the next 6..12 months?
   In absolute terms, 60 years and 34,000 results is a lot of computation
   to get for the trouble of compiling a binary or few.

With those points in mind, one can continue to run clients because it's
doing some theoretical good.  But, there's a reason why SETI@home doesn't
tell FreeBSD users to use the same client as LINUX users.  And, even if
MS-WINDOWS' setiathome ran under WINE (it might, for all I know), I
wouldn't expect SETI@home to tell i386 LINUX users to use the MS-WINDOWS
client.  There is a certain amount of respect involved, and there is a
difference (IMHO) between running a FreeBSD or LINUX client because there
never has been a NetBSD client, vs. running a FreeBSD/LINUX client because
SETI@home stopped supporting NetBSD.

Alternatively, someone could offer to port SETI@home to one or more NetBSD
platforms.  I assume that the SETI@home folks would want to scrutinize any
substantive source code changes, but it is conceivable that they'd
rubber-stamp it if changes could be contained to Makefile type stuff (or
if it ``just works (compiles)'').  Given the number of (presumably
volunteer) people listed as helping port SETI@home, I assume that they
wouldn't mind going this route, if they had a reputable person and the net
changes were minimal.  This might also be helped if there were some
unified voice, ``I will not run LINUX/FreeBSD SETI@home clients under
emulation, but would run a native NetBSD client[, for platform-X].''

A third option might be to start a more immediately useful/productive
distributed computation.  Is anyone doing en masse POV-Ray rendering, for
example?  Or, perhaps with some kind of agreement, and ssh, we could
distribute the work of building kernels & packages?  (After a new release,
binary packages will probably need a lot of CPU time to recompile.  And,
in general, it might be nice if people could connect to the website,
specify some kernel options, and get a fresh kernel---especially if one
needs a custom install kernel, or if one's system is too short on
memory/CPU-cycles to build a custom kernel.)  Distributed building of
binaries probably should require ssh connections. POV-Ray isn't such a
problem if one of the ``renderers'' is misbehaving.


Do these ideas strike people as being worthwhile and practical (and novel
enough to be worth _our_ doing it)?


For myself:

  I don't intend to run setiathome under emulation.  I would resume
  running it if my NetBSD box were supported (~3000 hours, ~150 results
  to date).

  If I had more expertise in network & X programming (and/or more time
  to spare for it), I'd offer to sign a reasonable NDA and attempt to do
  the port if no one else did & if SETI@home wanted it.  (I might yet be
  willing to try---setiathome runs on so many UNIX-like platforms already,
  and FORMERLY supported NetBSD, so it might be as simple as typing
  ``make''.  But, I'd rather someone with more expertise, and perhaps a
  little spare time, step forward first.  *grin*)

  As I reflect, I'd rather help people get software that they want or need
  by helping compile packages & custom [install] kernels.

  Barring the above, a distributed render-farm intrigues me quite a bit.
  I wouldn't have many tasks for it, right now, but I do have spare
  cycles...


Well, that's enough of my rambling.  Maybe it will spark a neuron out
there...(^&


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com