Eras don't end in a day, they slowly fade away. Yesterday marked another bittersweet milestone in SETI@home history. We cleaned out the lab. That meant sending the Sun Enterprise series servers that handled SETI@home's databases and web traffic down to the university's Excess and Salvage department. Here they are sitting in the hallway waiting to go.

We had hoped they would end up in a museum somewhere, but unfortunately interest in SETI@home's hardware has faded even faster than the project did.

What we have not (yet) discarded are a couple thousand DLT tapes containing the raw data from the first 6 years of SETI@home. We would like to have the data transferred to a more accessible medium, but we no longer have a functioning DLT IV tape drive, or the funding to pay for a commercial data recovery service. As the group's presence at the Space Science Lab shrinks, those tapes will probably also be discarded as well.

Times change and the world moves on.

The work units haven't "gone for ever", only the copies sent to you as tasks have gone. The work units will be copied again and sent on to someone else.
____________
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

The workunits people are receiving are re-sends of timed out workunits from other user's accounts. They are not fresh workunits.

i find it somewhat ironic that a guy with less than 2 million credits
can tell a guy with over 31 million off like that.

Can you imagine that some folk that really bust their butts to keep stuff running most of their time also have a LIFE at a weekend that enables them to wind down and put up with the other stuff which happens when they are not there?

Matt, tks for the information,

But in fact, there are U/D load problems !

I have about 2000 WU to report each week ! And this only into 1 hour time due to the Intranet security. I reveive from the RDM 1 hour, once a week , open gateway to Seti. But when Seti is very slow, or offline it became problems ! I want to help the research.
Perhaps is it better to close Seti for a few days or weeks to solve all the problems.
All what it sended during server problems are into " fixing missing results ". But this server is out since the big crash in august.
I have now about 8.000 WU waiting for assimilation !!!
Each WU about 50 credits, it become about 400,000 credits !!!

And of course , when I connect and can receive new WU, they are also calculated. The final result is when i start the U / D load, your server receive much more information than it is capable to proceed. Weare more than 1,000,000 with the same problem !!! Of course when the server receive at the same time so much request, it can not proceed because the overload !!!

It is a snowball effect !!! Only Seti team can solve it. Then DO IT !!!!!
Instead of trying to repair "broken arrows " !

I was going to get some programming done today but Dave needed php upgraded on the BOINC server, which was running Fedora Core 6. FC6 didn't have a sufficiently advanced php in its repositories, so this was as good a time as any to yum the system up to Fedora Core 7. This was slow, but worked like a charm.

Except I then realized the trac system (used for BOINC's web based public software development) was toasted due to the upgrade. It took over two hours of hair pulling, scouring log files, removing/reinstalling various software packages, poring through barely informative pages only found in Google's cache.. I don't really understand how what we ultimately did fixed the problem, but we seem to be out of the woods, more or less.

I hate to say it, but trac is written in python, and I've never had any positive experiences with this programming language. Every six months some random python program explodes as it is utterly sensitive to version upgrades, and tracing the problems is impossible as the code is difficult to read and scoured all over the system in vaguely named files. Others keep trying to convince me python is the bee's knees, but I just can't see it. I started out writing raw machine code on my Apple II+, so to me C is the pinnacle of programming languages (not C++). I'll shut up now before I further offend python programmers/developers.

- Matt