This month's most interesting messages:

All from the SETI@home team members at Berkeley. Non-official statements but interesting anyway.

Eric Heien - 2000.10.01 in s.a.s., why v1.xx clients weren't retired when v2.xx became available:

I believe it was because we thought 3.0 would be just around the corner, so we didn't want to force people to upgrade only to force them again just a month or two later.

And as for stats on how many people are still running 1.xx clients, it comprises about 10% of results that we get now. Most of these are probably large computer labs whose admins don't want to change the software on hundreds of computers unless they really have to.

Matt Lebofsky - 2000.10.04 in s.a.s., SETI@home 3.0:

Version 3.0 is the official release - we are out of the beta test phase, having (finally) fixed everything we wanted to for the mandatory upgrade.
There may be 3.x versions in the future with small enhancements.

As of *right now* the versions have been made available on the berkeley.edu ftp sites. I put these out first so that cdrom.com can pick them up overnight (cdrom.com can handle a lot more ftp traffic than the three local ftp servers combined). I see that they are there already, so I'll make links sometime soon. One of the links will contain a page noting most of the interesting deltas between 2.0 and 3.0.

Mac people take note: Mac OS C Public Beta 3.0 is available (this is considered a public beta since OS X itself is a public beta).

The plan: Make these available without much fanfare (like I did yesterday by just plopping them into the ftp site). Let them simmer for up to a week. Barring major incident, formal announcement of its release will be made, with a warning about a "grace period" of some length (probably a couple of weeks) to allow previous versions to send back results. Then 3.0 will be mandatory for all users.
Hopefully we won't lose users in this process.

Come n' get it!

Matt Lebofsky - 2000.10.04 in s.a.s., when asked if 3.0 will be mandatory for all users and how it will be handled:

Yup. It's for real this time. When we released 2.x we didn't bother rejecting 1.x results since we believed that 3.x was around the corner. Making both 2.x and 3.x mandatory upgrades so close together would have bugged a lot of people, so we just let it slide.

[ >8 ] we know the version of the clients sending results back, and we can easily have the server behave in one of three ways:

1) Accept the result and send a new workunit, no questions asked
2) Accept the result, have the client present a warning message saying there's a new client available for download, and then send a new workunit
3) Do not accept the result and have the client present a warning message saying there's a new client available for download and the current client won't work until you get it.

Right now we're at (1) for all versions. Soon, we'll make the server behave like (2) for all versions before 3.x. After the "grace period" the server will behave like (3) for all versions before 3.x.

All this logic has been working all along in the client and server, we just haven't implemented it since the days of 0.x

Eric J. Korpela - 2000.10.06 in a.s.s., SETI@home Berkeley Team Status - job openings and career changes shake-up?

We're still here. We've just been incredibly busy. Eric Heien has gone back to classes, so he's pretty scarse. Dan is in Rio at a conference this week (poor guy). Matt's leaving town for a couple of weeks. David hasn't been around too much since joining United Devices. And I'm busy trying to put together a magazine article, in addition to my other major project getting busy (and being chosen for some NASA funding, yay!). I've also been working on a SERENDIP III paper. To top it all off, I've been put in charge of the science post-processing, so now it's my fault there hasn't been a science newsletter in way too long.

I still try to glance at the newsgroups occasionally, but I miss a lot of things. Hopefully, increasing the size of the team will free up some of my time by removing me from the DBA tasks and most of the programming part of my work.

Eric J. Korpela - 2000.10.11 in a.s.s., about re-processing old workunits with v3:

There's no intent to redo data that's already been done. Since the project has been extended, and it will be a while before we get an instrument on another telescope, the SETI@home system will likely continue operating at Arecibo. So we'll cover the same portions of the sky more times than was originally intended. So if there are any continuous sources of pulses in the sky, we'll still get find them without having to reanalyze the data.

The only scenario in which I think we'd end up reanalyzing would be if there is some interuption in our flow of new data.

Eric J. Korpela - 2000.10.13 in s.a.s./a.s.s./alt.info-science.seti, if we will see the last 10 workunits script back in action soon:

Probably not for a while. At this point any database effort given to this detracts from the effort to sift through the signals in the database for potential E.T.'s. Our hope was the we'd be getting another system to use for postprocessing, but that has fallen through for the time being.

Hiram Clawson - 2000.10.21 in s.a.s./a.s.s., upgrade warnings on?

I'm wondering if anyone has noticed upgrade warnings from clients that have been superceeded by 3.0 versions? I have attempted to turn on the upgrade warning mechanism and wondered if anyone has noticed?
If you have seen this, from which clients? Please display the output of './setiathome -version | head -4' if you have a client that is printing an upgrade warning when it connects to the server.