Slashdot Mirror
The Truth About SETI@Home
zealot writes "According to this article, the SETI@Home project is not using the most optimized clients available "just to brake the unit turn around" so that they can continue to recieve various contributions. The authors are also demanding access to the client source (and asking to GPL it if possible), so the greatest performance may be obtained. " It's an interesting point: They didn't figure on getting the reponse they did, and will sooner rather then later run out of blocks to be crunched. Yep: What happens if hold a war and /everyone/ comes? Or a distributed program, I guess.
I would rather see that they not GPL the client. It would be far too valuable under a BSD license or an X Consortium license. Whereas if the software were placed under the GPL the code becomes useless for general use.
I would think it would be good for project morale to say, "Look how good we're doing! We can process the data blocks faster than we receive them!" Seems to me that the purpose of this project is to get something done, to make some progress...Not to keep everybody busy for as long as possible.
Anyone else find that final sentence difficult to understand?
;)
Da grammmur on dis syte is atroshus.
All of the evidence points to exactly the problem that the author describes. Seti@home needs to write a second client to handle the division of work and "graduate" some of the reliable, high performing volunteers into producing the units of work for others.
Their fundamental problem is that they only distributed the analysis portion. Now that the overall load has become unbalanced, they need to distribute one more piece of the workload.
Geeky modern art T-shirts
Opening up the source code to the world will increase the block counts in two ways:
1) Optimisation
2) Hacked clients returning blocks unchecked, as previously seen with distributed.net
By using a hacked client and _lots_ of different
e-mail addresses to report completed blocks with, any hacked-client-antics could go undetected....
I'm not saying that this is unbelievable, just that it would be nice to have some evidence to back these claims up... or else state them as conjecture, not fact.
--
Let's not get too wound up because SETI@HOME is getting overwhelmed. It means that the idea is successful. Why do people participate in these kind of distributed processing projects? With the exception of those who want to show off their machine, most of us do it because we feel that instead of our computer downloading Warez or porn all night, we can do something useful.
If SETI@HOME is having some troubles, helpful advice, not scathing criticism is what is needed.
I would much rather see more of this kind of thing, even if it was occasionally bungled, than other groups being scared off because of how hostile the online community is
Maybe I'll find ET...
-------------------------------END--COMMUNICATION
The article in 3DNOW is way off base... If you check the seti@home home page (http://www.setiathome.ssl.berkeley.edu) they explain why the code is not released to the public. Additionally, the code improvements they discuss are limited to Intel chips, and I, for one, am not running the bulk of my setiathome clients on Intel chips (too slow...), although I realize that a good portion of the clients being run are Windoze clients.
I'm sure everyone is already aware of this, but there are 2 clients for windows - one gui based, one console based. The console based one goes about 2 or 3 times faster than the gui based one so anyone interested in drastically increasing their block processing speed can do so immediately by using the console based client. Also, I've seen some really odd stuff over the last month in the seti@home stats ... first MS is substantially behind Team Slashdot, then they suddenly surge ahead, then their numbers *decrease*, then they surge ahead again, then they disappear from the stats page entirely [!], then the return with low numbers, then (today) they're 20K blocks ahead of Team Slashdot - what in the world is going on here?
there are two kinds of people in this world - those who divide people into two groups and those who don't
We're distributing encryption cracking and alien detection. What else can we distribute? We need something that can be broken down into small parts, worked on in parallel, and isn't overly time-sensitve.
We could get some writers, artists, and 3d animators together and make 'the great Net movie', and render it on the largest rendering farm ever.
Maybe some sort of distributed neural network? Dunno.
Ideas?
From the Yahoo page:
Looks like anyone interested can find out the real scoop from the horses mouth.
The article seemed to be flame bait to me. They never said that Seti@home said anything other detailing the performance critical routine in the seti@home software. Then the way I read it seti@home did not want to give up their source. The article said:
Is this what they said or more likely an interpertation of what they said?
Lets check the facts before slamming Seti@Home.
Check out the Lance Armstrong Foundation
kayaking
damn it people, isn't the philosophy behind coding very similar to sentence diagramming? shouldn't we be the people who speak correctly? sorry for ranting, but it irritates me to see a group of people so incapable of expressing themselves. not that i'm trashing hemos here... it just comes to a head with him because he posts.
if we're serious about this "revolution" thing, we need to give people a reason to take us seriously. communication is essential... yes, even with the outside world.
i don't really know where this came from, and i beg the moderators to regulate the hell out of it for being off topic.
It sounds like academia is just as fraught with Dilbertisms and idiotic management as industry. With the type of response SETI@Home has received from the world it seems that their problems could be solved with a simple call for help to the community. But it appears that they have not learned anything about community development success open source efforts have had, and are ego-inflated by their monopoly on SETI data and insist on being control freaks. The sad thing about this is that their attitude will eventually affect their ability to get funding, as skeptics can easily point out the fact that when they were donated millions (anyone care to really estimate?) in free computational power they wasted most of it.
/leading/ contributor to the effort, but I am in the top 0.3%-tile overall, and in the top 30 in "team slashdot", having spent a decent amount of time to get the software running autonomously on a handful of SPARCs. But I think now I'm going to look more closely at distributed.net despite the fact that SETI engages the imagination (and fantasy) much more. Anything we can do to improve this process?
I'm by no means a
I chose AMD because I fancied not tossing my motherboard and case. I run on a 450 MHz AMD-K6-2, with the 3d-now! extensions (of course). I can tell you from experience that the FFT that Seti@Home uses routine on an AMD SUCKS. It takes forever to do a single block of data, and I calculated it would eventually take something like 70 hours to complete the block. I was disappointed. Granted the floating-point on AMD's aren't great, but they aren't THAT bad. That was part of AMD's purpose to include 3D-NOW!, to handle floating-point better. The fact that they are unwilling to optimize the code just plain makes me angry. It puts those with alternative processors at a disadvantage, when the users themselves are willing and able to fix it. That is the reason I love RC5: it runs well no moatter what processor you use, it's optimized for almost every one, and if you want to optimize it further, distributed.net allows you too. Just because Seti@Home claims they will run out of blocks of data, it does not matter. If they do, perhaps other programs will see the need to contribute.. perhaps the ACTUAL SETI program.... (this is not actually run by SETI, but by an affiliated group). We could all get a lot more done if we simply all did our best to get what 'needs' to be done done, and worry about the next source for our work when we get there (a la RC5).
(Joke! :))
www.HearMySoulSpeak.com
They're worried about running out of blocks to process? Isn't that the idea?
The problem is that the data they want to process doesn't come in blocks, it comes in one big chunk (or several), and they can't break it up fast enough to keep up with the blocks being finished.
---
END OF LINE
1.5 hours per work unit!!!!!
Deleted
The problem is that the work units are created from the Arecibo Radio Observatory, and not many people have their own radio observatory...
/El Niño
I've been recieving ancient Seti@home units for weeks. They keep sending out the same units over and over, from January 1999 through March 1999. When you work on it, you notice that it just keeps looping. You hit a February unit, then a March unit, then a January unit, etc.
:)
Maybe they've set it up to analyse the units in that strange order, but I doubt it seeing as they have enough computing power to encode several thousand years of MP3's per day... using BLADEENC!
What the Seti@home project needs is a way to better manage the data that they're being sent. It would also be nice if they'd optimize their client so we could run it for the same amount of time, but have it take up less CPU. It really is intrusive when it's not running in screensaver-only mode under windows, and without -nice 19 in Unix.
They can't distribute the splitting project because the data blocks are HUGE. I'm guessing that the data comes in large chunks, maybe just one large chunk, even. If they could distribute that, they wouldn't need to, because the blocks would be small enough to send on their own.
---
END OF LINE
There is.
Go to the Display Properties, Screen Saver, Hit the settings button, check the go to blank box, and put 0 minutes in for time. It will show no pretty pictures, and give your speed a shot in the arm.
Saw it written and I saw it say, pink moon is on its way. None of you will stand so tall, pink moon is gonna get ye al
Never attribute to malice that which can be adequately explained by stupidity.
Look, this code is unoptimized. We all knew that. No news there. Now, they say they're not currently interested in optimizing it, probably for a couple of reasons. I mean they're having problems keeping up with the current load as is. What's wrong with them wanting to sort that out before they add in the problem of different code bases for various chipsets?
Look, these guys aren't experts in distributed technologies like the guys over at d.net.. Hell, no one's as expert as the guys over at d.net. You can't run d.net for as long as it's been going on and not be experts.
So the seti@home guys can't split the bits up fast enough to avoid duplicates? Well hell, there's hundreds of corporate sponsors falling all over each other to donate stuff, right? Use that!
Frankly, I thought seti@home should've teamed up with d.net from the beginning, instead of trying to setup an entirely new system. Why not use an existing infrastructure? Quite a hell of a lot of people (myself included) killed the rc5 client in order to run the seti@home client. I don't want to go back to rc5, but I don't want to duplicate work either.
Seti@home should just hand the codebase over to the d.net guys and see what they can make of it. If the setup is anything like d.net's, then they surely can help with getting more bits split, as it were. So you got too many people to help? Well, that's what you get for not doing your homework, no cookie for you. Now admit defeat, and get some FREE help.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Oh damn, the Seti@HOME people are "making" me run my computer all night (at "full throtle", no less !
My opinion of his opinion: he should "get over it". The only thing driving that dude is competition with others, not the altruistic donation of *spare* computing power towards (an arguably) good cause.
If I ever write an article like that, remind me to switch to decaffinated coke.
-adam a
*removes Seti@Home off of the three linux boxes, the one OpenBSD box, and the UltraSPARC he had it running on, installs RC5*
--
Dave Brooks (db@amorphous.org)
http://www.amorphous.org
But when my computer is MY work, my, hobby, i don't like it when a program doesn't use it and makes it look like crap....
Hey! Get all your freakin monster machines out of the project. It's not a competetion.
I have a crappy little Cyrix P200 running in screen saver mode a few hours a day. I'm still working on my first block - which all of you power hogs have undoubtedly reworked 3 or 4 times by now.
Give us little guys who are actually interested in the SETI project a chance to really participate.
You never really know how close to the edge you can go until you fall off.
Is there anything out there in the Open Source realm that does this kind of distributed processing stuff. I know that each project is different and needs customized stuff, but a general program would work. Something like the following: :).
Server - program to keep track of all stats send blocks, recieve answers, redundancy checks, a blank area for your own backend stuff, and maybe some HTML reports (cuz everyone wants to see this on the web
Client - basic framework of how to receive problems, send answers. Then have an blank area in the code where people can add in there own stuff as a module.
Licensing might be a problem, but I'd suggest that you leave the individual code as a sperate program thus the cutomized part wouldn't need to be under the GPL if the general part was GPL'd and a company wanted to use it. Maybe the LGPL?
I don't know enough about all this stuff, but everybody seems to like playing with the distributed projects, it would make sense if there was a free version. I know there are arguments against opening the code (easier to fake answers), but couldn't redundant checks help that?
-cpd
is anyone else getting tired of /hemo's/ way of emphazing /stuff/?
Run 8 of them under linux AMD 300 178MB ram with -nice 20, it takes about a week for it to process all units, this is good if you have a dial up line, only have to connect on saturday to upload the results and download some more work units.
Make that, oh, around 20 million entire CDs per day. One CD takes me 15 minutes to rip and encode. They've got 290 kiloclients or so. Work it out. My estimate assumes they aren't working for the entire day. Anyone know how many unique CDs there are total in the world?
---
END OF LINE
Am I the only one sick of seeing this argument used against SETI@Home? This is totally STUPID. My computers would run the same hours with or without SETI@Home on them. I also don't think that I'm pulling *that* much electricity to make a large impact on the atmosphere - and my area uses hydroelectric power anywayz.
I think it's funny though when people hear this argument and then use it to advocate d.net.
Err, distributed.net is not open. The fact that the distributed.net client was hacked demonstrates, once again, that security through obscurity does not work. In other words, trying to make it more difficult to hack the client by only publishing the object code rather than the source code as well is a much worse solution than figuring out some way to guarantee that bad blocks cannot be submitted, regardless of the functionality of the client.
BTW, unless this seems normal, it seems the client may have already been hacked:
62) polle 3975 1193 hr 28 min 43.0 sec 0 hr 18 min 00.9 sec
straight off the top 100 lists just now..
Notice, 18 MINUTES to complete a work unit.. Umm.. no.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I always thought it would be cool if someone was doing an animated movie like "a bug's life" on a shoestring budget using the net as their render farm. That would be way cooler than encryption cracking or SETI. Of course, the rendering is the easy part, coming up with a decent script, doing all the 3d modelling (coming up with all the frames that need to be rendered), and then there's the audio...It would be tough, but man it would sure be cool...
Bang the head that doesn't bang!
I like to think of distributed net in the same context as the NASA Deep Space 1 mission that just flew by comet Braille.
-DN (distributed.net) has had it's share of glitches and trouble, but now it represents a technology that we can apply to other problems.
-DS1 has had a few glitches of its own. The ION engine wouldn't start properly, and then it mysteriously started working after a while. Of course, we figured out what was wrong, and that seems to be a normal characteristic of brand new ION engines. Overall, the DS1 ION engine has operated for 1800 hours, vindicating the original concept.
-DN tackles a current political issue, but the problem is technically boring. Cryptology is hot in the news today, but we all know the outcome of the DN problem. We'll find the key. But along the way we will learn a great deal about how to build vastly distributed programs running with donated computer time.
-DS1 also tackeled a current political issue, but it was essentially boring. DS1 flew by astroid Braille. Asteroids are in the news, but DS1 was so far away from it that the asteroid occupied only 4 pixels in the CCD. It also appears that there was a problem with the tracking system, so there might not be any better photos. Boring! But we're learning a tremendous amount about how to build spacecraft that can automatically perform their own navigation.
SETI at Home's biggest mistake is that they re-invented the wheel and made all the mistakes they would have avoided if they'd had some help. They have the right problem. We're all interested in finding alien life. But they could learned something from the distributed net people.
If tits were wings it'd be flying around.
Come on guys, now that we know Seti@home is just a bunch of no-good, no-good-dooers, lets all stop wasting CPU time on aliens that we aren't going to find (come on, they are out there, but too far) and break some encryption! That is something we can use right now!
Don't get mad about what I called seti@home. I run both (on diff computers) although I am thinking of changing to both RC5.
Corndog
Look at the awful job most of the search engines are doing keeping up with the web. Why not a distributed spidering project? Hand out a base of URLs to spider, then let remotes spider from there. As the ever pessimistic Rob has already pointed out to me, the load on the host end would be huge, but I still think if it were done right, the whole net could be cataloged in a few months, then kept updated.
It seems like a distributed spidering project with a search engine front end like Google on different hardware/net could make a search engine useful again. There are probably a few interesting things that sites could do to streamline the workload--I haven't thought of them, but my spidie senses are tingling.
slashdot broke my sig
Perhaps, instead of trying to distribute the cracking of some cypher, or finding ET, people need to sign up for "distributed computing." What I mean is, people sign up to use some client software to do any project someone needs more than one or two computers to solve, even if they only need one CPU-year, if they provide the client-side software to do the number-crunching, it gets downloaded and executed.
Of course, the software would need to be small, and there would probably have to be some semi-centralized agent for everyone to get it from, and there would have to be a "validation" process to make sure someone wasn't just trying to find all the combinations of the letters in the alphabet that make cool names for their EverQuest character.
Thil promises to get big. I mean, they had a measurable backlog on their calculations at SETI, but it's dwindling quickly. This shouldn't make us upset, we should be glad that we have proven this can work. Not only that, but we've proven there are more people than they expected would be willing to participate.
What if they figured out a way to distribute the calcs on Pi or the solution to the human genome? We could probably find a cure for cancer in a month if they could figure out how to distribute the work. If it can be calculated, we could probably cut the calculation time down to virtually nothing. Not only that, but we've proven we can by laying the smack down on this whole ET-search.
So, what we need is an agency (/.@home?) to organize and distribute the plethora of projects out there that have one year project times or greater. Of course, one of the distributed projects could be the assignment and distribution of the projects. Maybe give that job to people who have proven dedicated to "the cause," a time-served promotion schedule, of sorts, like in a business.
Or something.
-Ristoril
One of the major problems they've had from the begining is that Aricebo doesn't have any sort of reliably fast connection. They actually snail mail the data on DAT tape from the observatory to Berkeley.
Seems to me the simple answer is to process all blocks twice and compare the results. This would then solve/detect the problem where a hacked client was sending back "untrue" results. Anything that comes back with "different" results gets sent to a third "validated" respondent and the differing on of the initial pair gets demoted from validated. This also solves the workload bottleneck for the time being.
The 3DNow! advocacy guy's got it all wrong. It is a conspiracy from the NSA, FBI and CIA to make people stop donating their spare CPU time to Distributed.net.
- Da Lawn
't used to be LawnMOWER, really...
(there are only 4 "letters" in DNA)
<Counts./>
<Counts again./>
Wait a second!
<Counts one more time./>it sure seems to me that there are only three letters in DNA!
</JOKE>
Why is this article called "The Truth About SETI@HOME"? It's not more the truth than any of the usual Slashdot postings.
(Same for this flood of articles from osOpinion. Anybody, knowledgeable or not, can get his stuff published there, and all of Slashdot, LinuxToday and LWN will start a big fuss about it. It's just a waste of time.)
solving the "hacked client" problem when giving away client source would be easy: the server would need to keep track on who processed what data and send out some packets (maybe 5% or 2%) to different people and compare the results. i am sure the extra performance of tuned clients will outwight the checking overhead. once someone is found cheatings they are out.. comparing would work for the seti test. with the RC5 contest or finding primes it would not be that easy: the result of the 2% double packets would be in most cases "not a hit" and it would be unlikely to find someone who cheats that way. one way to solve that problem would be to demand that clients send a hash value of some intermediate results back that make shure the client has completed most of the processing steps.. and that values can be double checked..
mond.
A quote taken from the Seti@home page;9
http://setiathome.ssl.berkeley.edu/faq.html#q1.
"We decided not to make source code available for security reasons and for science reasons as well. We have to have everyone do the exact same analysis, or we can't have any control over our research and be confident in our results.We were also worried that there may be a few people that want to deliberately try to screw up our database and server."
As I read this above, the reason they are not distributing source, is to keep the data taint to the minimum. For a scientific analasys you would want as few unknown variables as possible. Keeping a contiguous software base from start to end on the project, ( at least the core computation part ) assures that the data is processed via the exact same instructions. By allowing anyone to construct a more efficient client, you're adding(potentially) small changes into the math. The amount of calculations over that minor 320~k block of data is staggering. Similar to the "Butterfly" example in chaos theory, a minor warble in a single math calculation may have no noticeable effect a dozen times.. but a million?
Yes, I may be blowing this out of proportion. Yes, I know that there does not need to be a contiguous analasys scheme from start to end in the case of seti@home, Yes, I feel that they should consider (as in the 3dnow article) NDA's for faster clients. But I feel that the above quoted statement says things clear enough to me.
Yes. They should not trust a valuable data block to a single computer. I'm assuming that there is a very robust system of checks and balances installed to check and re-check, and re-check every number crunched by passing the same block to multiple machines.
As for the second half of that statement, it's to prevent people who -don't- care about the project to get their jollies in raising their stats. Look at all the todger waving that goes along with the rankings... "_MY_ team is #1..." Yes it is still possible to fake packets, as has been evidinced, but with open source clients, it's trivial.
Yes. I believe in Open Source. However I know there is a time and place for it, scientific analasys, to me, is not one of them. RC5? Sure.. crack keys by brute force.. no analasys needed there. But SETI@home? This is science... This is for a more worthy cause than bragging to your mates about how your machine crunched more than theirs and you're cooler than them...
Seti@home definitely needs to ramp up their block construction process if what is in the 3dnow article is true. File "Running out of blocks to process" under 'Problems we -want- to have' How many scientists would -kill- to have too much processing power available?
Hell.. make a "variable" scientific analysis engine for distributed computing, give the science labs of the planet access to all the crunching they could ever dream of..
As always, my own opinion.
I don't like this guys attitude at all. He's angry because SETI@home has limited resources? They spend a fortune to use that radio telescope and distribute the work units, but thats not good enough for dude, he wants more. He is angry because he's "sacrificing" his idle cpu cycles. Its almost as if he feels its his RIGHT to help out when in fact its a privilege. They have every right to make the client as slow as they want. They have absolutely no obligation to open source it or improve the speed. Its their toy, and they are only letting us play with it.
I'm happy for SETI@home. I think its great that they've got 8 million volunteers and have managed to (almost) process all the data they've acquired. I hope they aren't completely overwhelmed, though. It must cost to server up all those work units. Something like 40 gigs a day, I think it is. Thankfully they have all them corporate sponsors.
I think it would be interesting if they open sourced it, but I understand why they haven't.
The author claim that if he have faster code, he will shutdown his computer at night.
...
I don't think it's gonna happen. People will still make their seti@home software run at night. Having fatser code will only enable them to do even more workunits.
Also the number of people who have 3dnow pr P3 is a lot smaller than the number of people who have P2, Pentium, PowerPC, Alpha, Sparc,
Optimizing for 3dnow will only enable a small amount of people to get faster performance.
I'm in favor of opening the source code for seti@home, they should not fear having code out there that produce false result because they could easily recompute the workunit with their version to see if it's true. And if too many bad result came from one person, they could easily cancel his account.
Opening the source will enable other people to correct bugs (the windows version is really not stable enough to run 24hrs/day) and optimize the code (again the window version is more than 2 times slower than the linux version - ok the gfx take more time to compute, but it should not be more than 2 timer slower - I've tested the 2 versions on my laptop).
Opening the source will also enable other scientist (with computer programming knowledge) to check the source to make sure that the computation are done right.
It's kind of contreversial for scientist to release closed thing. Science it about peer-review, all their work whould be peer-reviewable including the source code of their programs.
Note that they should not only open the source of the client but of all the other part of the system. This would enable other people to adapt the application to work with other projects and to enable amateur radio-astronomer to analise theire own observation with well-know algorithm and maybe to set-up their own distributed system to analyse the data they collect.
Okay, I don't want to hear any more about SETI@Home not releasing the source code. Here is the real deal on all of this. Do any of you wonder why SGI is blowing the doors off of everybody else? Do you wonder why they crank blocks in under 3 hours? It's not because they have superior hardware, it's because they have the all-powerful SETI@Home client source code. They've gone in and tweaked it so that the FFT (fast fourier transforms) routines use the optimized math libraries (they didn't previously). Bam, instant boost for SGI. Sun has done the same thing, you just can't notice since their average block rate hasn't dropped down yet (they've only been using the optimized client for about 2 weeks now). Both the SGI and the Sun clients had to pass certain SETI@Home tests to be allowed by SETI@Home (they had to crank a block and return results within a certain amount of precision and accuracy).
Both Sun and SGI have offered the optimized clients to SETI@Home to distribute on their home page, but SETI@Home doesn't want them (they don't want forks in the code base or something like that).
That's funny. They are, indeed, blatantly wasting their computer power. It is unreasonable that anyone would send out CD data to encode, but the idea that in a single day, we could've encoded a great portion, if not all, of the CD's ever produced.
Someone made a good comment when they said that the main problem with SETI@home is their unwillingness to call on the community, just like the legendary PHB's of every major corporation. They manage out of fear, rather than by communicating with the people.
What should SETI@Home do about it? Limit the submission of units to one machine per email address. Disallow the transfer of units between accounts. Retire the Top 20 teams and accounts of all categories every 2 months, that will make it less appealing to push so hard to the top.
But, above all, let people have the fastest client software possible, that is the least they deserve if you want them to support the project. Put the code into open source and let the best coders of the planet tackle it!
Cynical translation: "Kick off all those darned RISC users with their really fast floating point units and their farms of multiprocessor servers! Let us recode your client so our favorite processor looks better!"
Now I remember why we're looking for intelligence Out There....
Stupid job ads, weird spam, occasional insight at
n optimizations != n different source trees
He was especially talking about optimizing the FFT routine using special instructions from the 3dnow instruction set. Since this function plays a big role in overall computing time, this would have speeded up the whole process noticeable.
You can maintain portability and `speed hacks' for special platforms in one tree. Look at PostgreSQL, GNU libc, strace, MySQL. They all contain assembler code for improving speed on certain setups while supporting various platforms.
I want to ditch the GUI client and start using the CLI one, but I need a graceful transition. I mean, what does the system do if it sends out a block and it never gets the work back? I guess I could leave a little hole in the sky! Thanks,
Blar.
...the fact that when they first started having problems, they blamed it on the linux community, saying that we modified the clients to report more packets completed than actually were for the purpose of getting higher rankings. As a community, we did not do this. Perhaps a few linux users did, but they blamrd the Linuc community as a WHOLE. Till I can get an apology to the Linuc Community from them, no SETI@Home packets will ever pass through my computer.
-- Wiccan Army, 13th Airborne Division "We will not fly silently into the night"
Wow...Simple but smart. It also offloads some of the verification processes and would allow them to concentrate on making those faster clients.
I for one just thought that they should increase the range of signals that they are capturing.
Who knows...
Your rank out of 916986 total users is: 146354th place.
Thats up 40,000 places since last week!
so a distributed computing experiment succeeds past its own expectations, and an article manages to put a negative spin on it because some AMD fans don't get to optimize the code for 3dnow while there's talk of Intel doing it for MMX or its successor. colour me unimpressed about the complaint, and congrats to the Seti@Home people for managing to get their work done!
It's just like Linux vs. BSD.. Each side has something they excel at, and something that they lag behind at. Just use whichever one makes you happy.
They're definitely short of data to be processed by an order of magnitude. It shows how everyone wants to find life on other planets but no-one wants to pay for more telescopes.
Of course I'm a hypocrite! I even know how to spell it. What where you thinking?
And, thanks for caring. I have no doubt that some very seriously interested people are using fast machines. It's also clear that some people with a lot of horsepower are in a big race to see who can do the most.
Insane speed doesn't really buy much in this case. The SETI project can only collect data during a limited time each year. At the current rate it will be used up a long time before the next session. In the meantime, the handful of people on the other end have to deal with all the stuff that comes back. The client is just doing the front-end work. Any interesting signals have to be handled individually. If all the homework gets done this week then most of the good stuff will just sit around waiting for someone to look at it.
On the other hand, if they were able to do some more programming to expand the search using the available data we might have a different story.
You never really know how close to the edge you can go until you fall off.
I still maintain that the SETI@Home folks need to be doing a much better job of letting people know about how much work is going wasted, and what they can do about it, if anything.
A long time ago, they indicated that if they had enough people, they might try to increase the depth of analysis performed, or to add more frequency bands to their Areceibo receiver rig so that they'd have more data. I really hope they do this.. they have obviously proven that they can get an enormous amount of computer time for it. (And not 700 years like the 3dnow! article said.. more like 38,000 years so far).
On the positive side, they are increasing the amount of graphs and data available to track the project, but without the context of how much of that work is being repeated, it means nothing at all.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
SETI@home is about donating your (spare) processor time to a (in my opinion) good cause.
If a big company with lots of processor power wants to donate some processor time, so be it. The point is to find ET! It is not to get to the top of the rankings.
If SETI@home runs out of data, well, they can either start recycling through the blocks that they havn't heard from (You know, the people who run it thinking it may be nice, and then give up seeing how long it takes), or just stop for a few weeks until they get the data to send out.
Insert wit here.
Phew, I'm not used to waddling around in asbestos underwear anymore .. anyway, I made an update to the disputed editorial at the former location that replies to some of the comments made here and in other forums, check it out if you really care.
Armin Lenz
I like the distributed movie rendering... but the distributed spider concept...wow.
That's something that could be *used* by anyone, every day. The big problem, of course, is the load on the on the host end. Unless someone had a boatload of cash to spork over, it would almost have to be done by someone established...
(Anyone at AltaVista listening??)
I'd sign up for this one.
If you want, you can join in with one or both of the groups I know that are trying to do just this sort of thing. I posted the URLs in the reply just prior to this, and don't want to start getting redundant, here.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I think that the seti@home folks have to choose
some linux guru, anyone well know. And ask him
to make an optimized version of the program.
I seems that the code works with large amount
of memory and makes the cache incoherent. So you
get more speed with more bus speed.
My two cents.
OverLord
Both of these problems can be dealt with if you have massive redundancy. SETI now has about 900,000 participants, about three times as many as projected initially. There's plenty of room for redundancy there.
SETI works like this: you get a block of data, and then your client is supposed to apply several transformations followed by Fast Fourier Transforms. If any of these Fourier results look significant, the client is supposed to tell the server.
To turn this into an open protocol, we simply should require clients to compute an MD5 signature of each of their Fourier transformed data, then compute a single signature of all those signatures, and send that back to the server, in addition to the regular notification of significant results.
The server keeps a database of these signatures, and in fact sends every batch of data to at least three different machines, preferably running different versions of the client on different hardware at different times in different parts of the world. If the received results coincide, everything is ok; if not, the server does the calculation itself and blacklists the bogus clients. Bogus clients should still be fed bogus data, just to keep them busy.
A public access library of data packets and associated correct MD5 result signatures should be available so that people can check their hacked version of the client against it.
--
I'm quite sure some knucklehead out there will hack a client to deaht and mess with their heads a little. Its not as if not using an OSS solution is circumventing hacking of any sorts.
-
ping -f 255.255.255.255 # if only
I guess I don't completely understand this situation, but let me try to pick my words correctly: the Fullon3d web site is labeling Seti@Home an enemy, they want optimized software, and they keep saying Seti@Home is trying to stall. Ok...I still don't get it.
1) I guess we could start by saying the Seti@Home Project is not a video game; it is a distributed computing project connecting hundreds of thousands of computers actively working on the same task. All of this optimization stuff doesn't mean a thing for this project and it's goals. Fullon3d is also reporting that the Seti@Home Project has a lot of competition, which is entirely true. And, as a way to curb this growing *obsession* with work units, they propose the following:
-----
"Limit the submission of units to one machine per email address.
Disallow the transfer of units between accounts.
Retire the Top 20 teams and accounts of all categories every 2 months, that will make it less appealing to push so hard to the top."
-----
Of course, they want to stigmatize competition, but yet, they want to optimize the client to make processing units faster!! Seems a bit contradicting doesn't it? Also, I'm fine running the client software on my P166 comp with 88mb of memory. IMHO, the project is running fine. What need will making the client run *a little* faster fill?
*
2) Everyone has already seen the negative aspects of opening the source, so I don't have to refresh your minds. But, let's think about this situation with some common sense; there is no need to label Seti the enemy.
*
3) Oh yeah one more thing: fullon3d was comparing the Seti@Home project to this:
-----
"How would you feel building a road to the hungry people of the world with your bare hands while the initiator of the project doesn't want you to have shovels because they didn't think to buy trucks and groceries yet?"
-----
What? They are two unrelated situations that deal with different varibles and have no relevance on either of them! The fact is, if you don't want to help Seti, don't download the program.
Rajiv Varma
Well I guess my Windows 98 partition running the win*NT* ahahah (win32 poopie) CLI client isnt really working must be a figment of my imagination that I have 51 units done.
Such childishness.
Besides RC5 is boring!
A generic architecture for distributed computing projects.
SETI searching, RC5 cracking, CGI Movie rendering... Whatever.
Deleted
Their "hardware" is cheap (internet access, zillions of cheap computers), and their raw data is expensive (radio telescope time, real-time data). What's so suprising about SETI fussing over the data and not the software/hardware? Efficient code saves hardware, and that's not their bottleneck.
This article is asinine, moderation is all well and good, but what can we do when editors post truly idiotic stories?
Having tested on many machines, it is clear that there are optimization issues, especially with graphics. You pay a lot for those pretty graphs.
Here are some of the average times I've gotten:
(WU = Work Unit)
Windows NT 4, Pentium II 350 Mhz: ~25 hours/WU
Windows NT 4, Pentium II 350 Mhz, no graphics: ~12 hours/WU
Linux, Pentium 75 Mhz: 65 hours/WU
Windows NT 4, Pentium 150 Mhz (laptop): ~150 hours/WU
Windows NT 4, Pentium 150 Mhz (laptop), no graphics: ~50 hours/WU.
(All NT boxes had "run in background" set.)
With these numbers, it is clear that the graph greatly effect performance. I suspect that the relatively superior performance on the Linux box is because NT degrades the priority of any non-foreground process.
I do wish that Seti would make this more clear at their site. It isn't immediately obvious, and I probably wouldn't have noticed myself if I hadn't wondered why my Linux box (no graphic version) seemed to do so much better than the NT PII boxes.
Still, what a lot of people miss is that this is an experiment. We shouldn't expect perfection immediately.
As for the source, well, I agree with Seti on this. The danger of muddying the results is far too great. In essence, we are donating CPU time. In doing so, it is basically theirs to do as they see fit. It is not us running a program for ourselves. It is them running a program using us as helpers. If you don't like that, don't participate.
The cake is a pie
It's inefficient to use more processing power than you have to.
Personally, I hold efficient use of resources to be a higher value than whatever's prompting people to defend the status quo here. It's one of the best features of hacker culture.
I had a friend once who said, "Why should I conserve paper? The trees are already cut down."
Of course this doesn't help if you've got a slower PC (like my old P5/100) as it eats enough CPU time that the system becomes unusable. Chalk it up to 95's 'crap scheduling' as another poster put it =^)
--
God damn, these people are doing the best they can with the money they have, there is no point in making faster clients. Nobody cares about their wasted 'cpu cycles'. You leave the program on when you want, if doing twice as many work units isnt accomplishing anything then there is no point. Find something else to write code for in your spare time.
damn anal retentive geeks.
-I go to Rice, so figure out my email address
I didn't think of that possibility. However, if you use sufficient redundancy, then not all of the people processing that block will be running a hacked client. As long as there is one legitimate client which records a positive result back at d.net, then you can demonstrate that anybody else who said that block was a negative is running a broken (hacked) client. It would be necessary to send the redundant blocks to different clients simultaneously in order to make sure that any hacked clients are discovered before the user of the hacked client has an opportunity to cash in on their ill-gotten gains.
You could also seed the work units with positives and check to see which clients record those as negative results, and then ban those clients before they cause you to miss a real positive result. Seeding the work units like this means you have to be able to generate more than one positive result, which would be doable in SETI because a number of different results could be the pattern we're looking for. In other words, there are many possible positive results. Seeded positives might be impossible to use in key cracking because there should only be one key to the puzzle and if we already knew the key, we wouldn't need a contest to find it. The only solution that I can see for d.net would be for the client to not return a positive/negative result but just return the processed block for final interpretation as positive or negative back at the d.net server. Unfortunately this moves back into the "security through obscurity" model.
Your right to not believe: Americans United for Separation of Church and
Well, that's a good point and it would carry more weight (for me) if you ran out of valid work units and your machine powered down. But it looks like seti may be just sending old wu's again to keep people running it, which I agree is a waste.
So, I don't disagree that efficiency is a good thing and that un-optimized clients is a bad thing. I didn't mean to (and I don't think I did) imply otherwise.
I guess I'm just thick because I still don't see how that article hopes to accomplish that. If a 3dnow optimized client appears tomorrow, everyone would still leave their machines on the same amount of time, no? If seti ran out of work units they would likely send out January again. What did I miss?
Since one of the biggest optimization problems seems to be in the graphics, and since only Windows (and Mac) boxes have graphics versions, I'd think a Linux advocate would be tickled about this. It certainly makes that OS look better than Windows. (I suspect it is also one reason why Team Slashdot is currently number one.)
The cake is a pie
I received a mudslide of emails and read several forum submissions here on Full On 3D, over at 3DNow.Org, Anandtech and Slashdot (which, ironically, chose to post this ragtag editorial but turned down the opportunity to get the word about 3DNow.Org, the 3DNow! coding workshop or Linux3D.Net out - go figure how much that makes them a gossippy place over one that cares for Linux and coders).
Ouch
They already compile on different compilers to support the different operating systems. Why can't they pass different optimization flags for the same source code? Right now this client uses only 486 code optimized by an obsolete egcs. With the latest egcs and Pentium II optimization I could get at least 33% faster.
Ok... I *JUST* got out my ammeter, and my computer takes in .5A. At least in America, we have 120 Volts, so thats 60 watts (if i am thinking correctly here, P=VI, right?) Now, in most parts of the country, energy is about 8-10 cents a kilowatt hour. According to my calculuations (correct me if im wrong here), but thats like 6 cents a night? I'd also like to point out that if a computer puts out any NOTICABLE heat of noise, you probably need a new computer, perferably not an intel *hint*
I am beta-testing the Intel hacked client. Here are some interesting tidbits:
1) My PPro 200 can process a unit with the hacked client in about 7.5 hours (compared to ~23 hrs before).
2) The hacked client is way too unstable for release and it crashes on my NT systems all the time.
I think the SETI@home people are doing a great job. I run web sites and it is hard enough to run one that gets a few hundred hits per day, much less million+ hits/day that the seti site must be getting.
The complainers seem to forget the fact that running a scientific experiment requires great control over the parameters. A bunch of barely tested hacked clients are the last thing these guys want.
Each different CPU may yeild slightly different results due to roundng, precision, and different Run Time Libraries. Especially with a FFT, these differences can accumulate faster than you think. So, if people run even more versions on more chips, 3d-now, SIMD, and so on, the number of variants explodes. Accuracy (& consistancy) is more important than speed in some cases.
That said, I'll kick some ASS if they are deliberatly sandbagging their code.
rbb (Yes, I've written FFT code in commercial software.)
The GPL is based on a philosophy. It's not a philosophy that everyone appreciates and like all philosophies, it has it's proponents and it's opponents. If you happen to like the BSD licenses better, feel free to use them for your program. It's up to the author of the program to choose which license suits their particular code-philosophy and really, it's nobody else's business. Just as your religion is not my business, and mine isn't your concern. One is not better than the other.
Also,
I agree that some good comments get moderated down just because they are anti-GPL but that is the fault of a few moderators, not all of them (us, I should say sometimes). All moderators have the power to remoderate comments that they feel have been unfairly downgraded and to tell Rob and Co. about any perceived misuse. Labeling all moderators is stupid since it's not one group, the roster rotates between all people with accounts who haven't checked the box saying they don't want to moderate. If you see moderators seemingly misusing their power to further their beliefs and not helping the discussion, please, for Pete's sake, email Rob and tell him about it. Don't just sit and complain.
Unlike prior distributed computing projects, the sole purpose of DIESP is to give nerds with flashy computers bragging rights over their friends. The compute task is still to be chosen, but will be something that exercises a good mix of integer and floating-point ops, and is highly optimizable to take advantage of the most arcane instruction-set extensions. The actual task will be meaningless, but who cares? (Our beta progam searches for Bible Code-type messages in the works of Nostradamus, and ray-traces the results.) It will be open source so that everyone can tweak it to their heart's content. We'll put up all kinds of statistics on the DIESP web site, and we're actively exploring logo partnerships with various hardware vendors and co-branded clients for major ISP's.
Another major innovation of DIESP is our unique Virtual Result Computation which eliminates the annoyances of other projects, like requiring you to leave your computer on all the time. Submit just one work unit, and, for a small fee, our VRC program will pretend that you're running at that speed on a virtual CPU(TM)(Patent Pending) and your statistics will be continuously updated! You may purchase as many virtual CPU's as you wish. We'll also be introducing our Premium program, where, for an extra fee, we'll assume that you're optimizing your client software and/or upgrading your hardware over time, so your virtual compute rate will gradually be increased.
Exactly. After all, they say up front that this is a "two year project". I'm sure that after two years, they'll have lots of ideas on things to improve. But thinking like scientists, they don't want to change things midstream.
(BTW: was that 23 hours for the graphics version?)
The cake is a pie
My semi-random thought:
Some MS people get it in their heads that MS should have a good showing in the S@H results. So they get approval from the company to set up a small server farm (so that they don't get a visit and an escort out of the building from corporate security, as is the custom for independent thinkers at MS).
They get a hold of a bunch of systems left over from the last major group upgrade. They are all the same speed & memory, all running NT with the same security hol...patch level. They started them all at the same time. So is it any surprise that they process blocks roughly in sync? Compound this with multiple clients per system, and periodic usage of the systems for other tasks, and you would have a wave-like effect as you've noticed. They turn in X000 blocks in a big hurry, then aren't heard from for a while.
That's my story, and I'm stickin' to it.
I think not...(*poof*)
I don't understand why we cuold possibly be doing the same blocks over and over on purpose. Why can't they just grab more data. Point radio telescope outwards. Record. Process to the SETI block format. Distribute.
I just don't get it.
"...and Slashdot (which, ironically, chose to post this ragtag editorial but turned down the opportunity to get the word about 3DNow.Org, the 3DNow! coding workshop or Linux3D.Net out - go figure how much that makes them a gossippy place over one that cares for Linux and coders)."
Did this guy ever think that we (slashdotters) care about computing, not just alternative computing? Hey I resent being called gossippy! Did you all here what this guy said about us, he called us gossippy. We need to tell everyone quickly to no pay attention to his mindless garble
You so see the sarcasm there right?
..they/we/whomever found out that Seti@Home really
*is*
running a rendering farm, cleverly disguised as a distributed-alien-detecting-bit'o'software..
CN
So gcc, the gimp, gnome, and emacs are all useless for real work? Aside from the fact that there's gnu.misc.discuss for this, what is your definition of real work?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Well there is one point that the author is not correct. Yeah it would be pretty cool for SETI@Home to be more open for the community. But if anyone remembers the last pitfalls in distributed.net and specially that hacker breaking all records in RC5 then there could be some ground for not being so open.
However I don't like how SETI@Home presently goes. Apart of being quite critical on the usefulness of such venture, I also tried to overcome my acidity and give a hand to these guys. However...
Yes the client is a terrible dumbiness. Sometimes I get the terrible feeling that I inserted some piece of Visual Basic in my hardware (Nooooo God! Nooooo! Oh it was just a nightmare...) No matter that you can control its niceties and some other stuff the thing is clearly raw. And it is quite weird that they hold such way for so long. Well let's face the facts. This thing may not happen in our lifetimes. But it is stupid to keep it running 5km/h when we can get it a little bit faster. Specially if we consider the amount of info we need to analyse.
I wonder why SETI@Home does not take an attitude neighboring BSD licensing styles. Something like this: you get some specifications, bla-bla-bla and send us any code you think useful on it. However We determine what goes and does not. It would really improve things a lot. Anyway even if the keep this enclosement this will not avoid them to face serious cracks in the future.
Meanwhile the author revolves some ideas about the possible "disconfort" SETI@Home has for having so many people on it. Well that could be quite true. In fact SETI on the whole has shown such behaviour in several places. It has grown from an elitist view of the project when it started. Some protocols of meeting "alien civilizations" transpire a behaviour that was quite typical on the 60's. Champagne, elite, jet-sets and a few dodos with enough money in their pockets to pay the first seats. Funny to see their faces in front of some mastodon half-brained being with tentacles in his face and only capable of saying the words: "tasty!". Just a joke sent by our friends from the other side of the Galaxy.
Why not? Clinton said we would go to Mars to "get them before us" in a "jokingly" reference to Independence Day film. If really there was someone in Mars (speculate about it) that would be a very disgusting joke... Martians could feel themselves offended enough to take some retribution.
Nobody is saying the GPL is more popular. I didn't see anyone saying that n% of unixes were open source...
The reason GPL is better is because it keeps people from closing the source again. If I write open source software to benefit my fellow computer users, I don't want someone turning around and closing that source later.
You would say that the GPL handles this by restricting freedom. But, I'd say that the freedom to plagarize code isn't one that I particularly care if I withhold from somebody whose only use of it would be to deny any benefits of open source to future users.
ie: BSD helps microsoft. Evidence: Win95(etc) TCP/IP based on BSD code, almost a direct ripoff. This is known because the attacks that work on BSD derivatives also worked identically on MS products.
GPL hurts companies like Microsoft. Not only can they not (legally) take a complete application like Apache, steal all the good innovations, close the source, and stick an MS label on it, but they have to compete with a project that they can't kill by forking to death.
If you can give me an example of how the GPL hurts users, the people who will run potential code that I may write, by guaranteeing that it will stay open source, well... I'd like to hear it.
Well, it doesn't even matter if it's released with a license that allows any derivative work to be made for non-private (testing, etc) uses.
Ideally it would be open source to help people run future projects like this, etc.
But, the current task is only to waste as few cycles as possible while cranking out SETI blocks. To do this they don't need to allow derivative forked projects or anything. All they need to do is let people read the code (or even parts of it ala d.net's RC5) so that we can suggest improvements.
A GPL or BSDL-ish license would only be icing on the cake.
This article is a good example of the typical GPL tripe that comes out any time one of these self-proclaimed h4x0rs wants to work on a particular project but doesn't get to. They find a project, demand open-source, and when they don't get it, they demonize the entire project. They accuse them of being "Afraid of the truth." They're threatened by real coders. What garbage. They just don't want to release the source -- some claim they could do a better job of writing it.. they don't care, nor should they. This is SETIs project, it's their code; if they wanted your help, they'd ask for it. In the meantime, it's not like they're taking food out of our mouths. Those of us who use the program choose to use the program. I'd never hesitate to turn my computer off when I want to just because I owe SETI that time. If you want to volunteer your time for SETI, volunteer it in the ways they're asking you to. If that rubs you the wrong way, don't freakin volunteer! Go find your own project to work on. Seems a lot more reasonable than smearing the project and putting this rabid spin on it just because they didn't let you help in the way you wanted to.
Oh, and I love the offhand and offtopic stab at slashdot, too. Perhaps it's gossipy, but that's alright. That's the point behind it. It's a news site, not a church for your particular brand of activism. I guess if they put a bigger spin on their stories, hyped them more in tune with your own ideology, they'd then become a more "caring" resource for "linux and coders." Of course I, for one, would stop visiting it. Thankfully, they aren't so limited in scope.
Come to think of it, how do we know that SETI@Home deals with radiotelescope data at all? It could be anything. For all we know, SETI@Home contributors could unwittingly be nodes in a vast NSA cryptanalysis machine.
Insane speed would by a lot here. I cannot believe that the FFTs and doppler shift we are doing now are the only useful analyses that can be run on the data. SETI should be more flexible. If they see that they have (orders of magnitude) more processing power available to them then anticipated, they could broaden the project to include those other analyses that are were considered too cpu-intensive (or too farfetched ?) to be included in the first place.
Why not release a second set of clients that go over the same data, but in different ways ?
There may have been slight doubts about wether people would be allowed to know about the Deschall
;)
results. The problem is that its VERY hard for the govt to really shut down or stop deschall, because the knowledge of how it works is widespread, and so is the equipment to see if it was crackable - and crack we did. It was just an organizational challenge. It had a tangible result with a political repercussion. That was the real daddy of all cracks because it was the first succesful very wide distributed crack (at least to my knowledge).
Seti seems like a HUGE shot in the dark. If you read the FAQ, the chances of finding another IET civ out there is vanishingly small based on the sample set and other factors. They admit it themselves. So:
1) we dont even know if there will be a result. And when there's no result, we cant chalk it up to
just a bad set of client software or a bent Arciebo dish. There just might not be anyone there - and we cant even be sure, because the data sample is from an extremely narrow bandwidth of a small section of the sky.
2) SHOULD we find something, how the hell are we going to be sure we're allowed to know? I mean, ya this is sounding all X files and all - but its really not easy for someone to go home and figure out if someone stepped in and fudged the "no" results. There are no competing seti's like there was for Deschall - other groups could verify the efforts of Deschall (some dropped out, but I think SGI had its own internall effort, for eg).
The govertnments (probably those of Nato in this case) probably has some reason for not letting any concrete evidence of ETI getting out. Either we wont hear about it at all, or it will be accompanied by so much hype and other fuzzy claims or denials or what not, we wont know whats true and whats not (like area51 and other encounters nowadays, tho I personally dont believe in the astronomically improbable likelyhood of aliens having a symilar physiology to us, never mind having to be based on carbon like we are).
Couple those two things together, throw in SETI screaming for help wehn they reach loads that are equivalent to a 1/10th of what CDROM.COM handles constantly, make big parades and press releases of how Top level Sun Engineers have to walk in and help them because this is SOOOO cutting edge (and not that its a bad design), and you end up with a project that has TOTALLY lost all my faith.
Rc5's stats are way better, the foster competition and actually finding EVERY machine in your house and your friends' house and his workplace and everywhere that you can (and many places you SHOULDNT) and throw them into your team's stats. We eagerly await client updates, which, for DES at least, showed HUGE improvements over, say, Deschall (I remember 600Kk/s on my P133 in DESchall - with the RC5 client I think its 3-4 times that now!)
Not to mention SETI repeated keys for weeks, and is now trying to keep the load down (they admitted themselves they had problem with load months ago).
Lame.
Not that rc5's result is that interesting to me right now, I am actually trying to help setup an independent research team with some cycles and clients to calculate protein/enzyme interactions in human cells - something thats apparently much overlooked in North America (I dont know much about the org.chemistry in this effort, Im the unix guy
THAT would be a far more interesting and useful project than just cracking more keys to convince some entrenched non-science-educated politicians something we've been pounding over their heads for years (really, the mersenne prime search is more interesting to me than rc5 - I might switch soon, unless rc5 actually does some work on the Golomb Rulers project).
If you want more info on the computational chemistry shit, email rutile at home dotte com (decode that yerself) and he will explain what they're trying to do.