Subject: Re: no more seti for NetBSD...
To: None <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 02/14/2000 23:23:31
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
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)?
I don't intend to run setiathome under emulation. I would resume
running it if my NetBSD box were supported (~3000 hours, ~150 results
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
Well, that's enough of my rambling. Maybe it will spark a neuron out
"I probably don't know what I'm talking about." --email@example.com