Slashdot Mirror
SETI@Home Says Client 'Upgrades' Are a Bad Idea
bgp4 writes "New Scientist has an article on how 'upgrades' to SETI@Home clients are causing some trouble. Even though the upgrades speed the client up, SETI reps don't want people using them because they may induce bad data. If SETI@home just open-sourced [the SETI@home client], they'd have better PR and a better client." Amen! SETI@home, are you listening?
so much for innovation and advancement of technology ... you'll never get where you're going if you're not moving forward.
I am, therefore you think.
The article seems to think that people modified the client in order to help out the SETI movement. I think it's pretty apparent that the only reason to do this is to be able to bust through data faster, increasing your score. duh! :)
See you, space cowboy...
This is a scientific experiment. It's not a race, it's not a demonstration of the power of computers or computer communities.
Comon people, think about this before you flame. Someone submitting invalid data can ruin this entire project for everyone. Open source software doesn't get tested until it's too late, and by time a calculation bug is found in the code, thousands and thousands of entries could be invalid. At least think about the project some before you randomly spew out "Free The Source!!"
Well, they forced you to update (otherwise the client wouldn't process any new units)
Yeah, I run seti@home. Yeah, I'd like it to be open source. But it's not.
If you agree to help out, you do so on seti@home's terms. They say they want you to use this software, so you use this software.
This is not about having the most units completed, or about being the one to find the signal, or about improving the software. It's about helping the project, and contributing to the body of scientific knowledge. If you want to help, use the sanctioned software. If you use anything else, then you're hindering. Go crack cyphers or calculate weather patterns or something.
But if they open source it, then we'll all find out that it's actually been a clever surveillance device used by the government to give them access to critical files on our computer and monitor our every move on the internet ;)
But give me a break. Stop antagonising Seti@Home because they're doing it in a traditional way. Who cares? They've come up with a great concept to advance their research, and a lot of people bought into it. It's not like they're making money out of it. It's not like the publicity they get fills the bank account of a rich CEO.
So stop picking at Seti@Home all the time until they become Open Source. Change is gradual, and we have to count or blessings and support Open Source initiatives when we see them, not declare a Jihad against everything non-OSS. Yes, most people including me would like to take a peek at the code. But let it be, for just a moment... Seti@Home remains a great project, whether it's Open Source or not.
You know, there *are* great software that don't need to be Open Source... And I think they're not hurt that much because of it. I don't think Seti@Home would get a whole lotta good from Open Sourcing their code, because everyone could figure out how to send false data claiming they not only got an E.T. signal, but it was singing Singing in the Rain in slow-motion.
"The wages of sin is death but so is the salary of virtue, and at least the evil get to go home early on Fridays."
SETI is listening, and your arguments are rejected.
This may sound odd to people participating in distributed.net, but SETI is not about processing data as quickly as possible. It's science. In science, you want to hold as many of the variables as similar as possible, so that you can be sure they didn't create a false result (false positive OR false negative). All else being equal, speed is nice, but it is not the goal.
Open source is not the answer for everything. Sure, if it was open source, some good patches might come out, but how many people would download the code, apply the patches that speed it up, and never have a clue that they just fatally broke the FFT result testing algorithm? Or for that matter, if they broke the FFT algorithm? Or would simply use it to easily learn how to send result blocks without processing them?
The fact of the matter is, even if you can improve the code, you cannot improve the code. (That's not a typo.) If you can improve the code, instead of helping SETI by processing keys faster, you bring yourself out of alignment with everybody else, create potential bugs in the experiment, and render all of your results suspect. SETI is science... distributed.net is engineering. There is a big difference, and science does things the way it does it for a reason. SETI needs the results to be as solid as possible. (If one of the hacked clients detects a signal, rest assured that even if SETI doesn't subject it to extra scrutiny as a result, some other scientist will.)
SETI can't stop people from modifying the executable on their own systems, but I think the people calling for SETI to make it even easier for people to modify the system (not just your code, SETI is part of a system and subject to the interactions thereof) have a fundamental misunderstanding of what SETI is about.
For another thing there is no advantage to
open sourcing the client since last I heard they had more people then they need to process the data and the bottleneck is from them receiving data from the telescope and not data back from the users.
If you open source the seti@home client you're going to have people hacking the code to boost their numbers, induce fake "sightings" and generally muck up the data.
In a scientific experiment like this you need more control -- open source is great, but it's not right for all projects.
These people have enough work to do with little resources, they don't need to have to try to kep out all the little hax0rs who want to hack with the code and look cool.
But, it *is* about finding the signal. It may not be about *you* finding the signal, but the *whole point* is to track down a signal.
To track down the signal, units must be processed. If we process signals faster it'll either let them eventually process more signals (larger spectrum, etc) or use less computers. Either is a worthy goal. One helps science, the other simply saves power and lets people run other distributed projects.
SETI@Home is hindering their own project by insisting on slow (They refused AMD's offer of help to speed the client up, doing more work, as carefully as before, in less time.) clients just to keep a large number of users helping is a bad PR move. You could help a project that wants to process data, or you could help SETI who wants a large number of users, who incidentally process some data.
The insistence with which some people clamor for open sourcing everything really annoys me (and a lot of other people). There are very good reasons not everything is open sourced, and sometimes they're not even due to stupid licensing restrictions imposed by third-party code.
For something like SETI@home (or distributed.net or whatever else you like), there's a very good reason to keep the clients binary-only. Namely, there is no oracle for verifying that a block of search space was actually searched by the client that claims to have searched it. Abuse of this was seen by the DES challenge and distributed.net before; open-sourcing SETI@home would lead to even worse abuses. Unethical people would modify the code to claim they had searched oodles of key blocks, ruining the results of the search -- and only so they could show off how "studly" their computer system is.
Of course, maybe this concept is too hard for bgp4 to grasp. But for goodness's sake, it's in the SETI@home FAQ. Whining about their policies on Slashdot isn't likely to change their minds.
(Beyond the malicious introduction of false reports, it's very easy to "optimize" something like this and introduce numerical or algorithmic errors. Unless you are familiar with advanced theories of signal processing -- the sort of thing you'd find in graduate classes at a good university -- you would be well over your head in looking at how the algorithms work. And there are enough bright grad students working on the average project to know how to optimize for all sorts of cases without the help of a bunch of open source zealots who think that the GPL is some magic potion that can be applied to anything to make it better.)
If this were a typical user program then id say open source it. The fact is this is a scientific experiment. The validity of the data collected is all that matters. If you open source the code then you will have a number of people who screwed up their version of the client because they didnt know how to do it right or because they just want higher stats and dont care about the data.
The benifit of an open source client is lost in a case such as this.
The only way they can be absolutely certain that clients aren't doing bad calculations is if they know that every client that goes out is from their own thoroughly checked source code. Open sourcing the client and letting anyone submit data with unchecked clients would defeat the entire point of the project. Seeing as a message from space is rare enough as it is, I wouldn't risk a buggy client destroying data that might never come again.
No CVS was ever set up (though it was repeatedly promised, those times any response could be elicted at all!), and the frustration of those volunteer developers taking part was very evident on the mailing lists.
There were a grand total of SIX snapshots ever made. SIX! At the very least they should have been daily!
I'm not the least bit surprised that the frustration with a slothful and (frankly) incompetent development team has burst out with "home improvements". That was only a matter of time.
As for SETI@Home's "reason" for not releasing the source - the need for a secure, validated connection - well, I think that's been blown out the water. If their connection was so secure and validated, rigged clients wouldn't be possible. The fact that SETI@Home are complaining at all shows that they're no better equipt to secure a connection than the movie industry with it's DVD encryption.
Let's all cut the pretense, and stop this nonsense. I want the very best SETI@Home clients that modern computer skills can create, looking for real data, using real analysis, not cheap junk that goes faster because half the tests are skipped. (Notice the gaussian stats vanished with the first official "faster client"?)
Now, SETI@Home obviously also wants genuine security. So put your source where your mouth is, SETI folks, and RELEASE THE CODE! Your attempts have failed, miserably, so let those who know what they're doing take over!
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)
SETI@Home is hindering their own project
There's no argument that it could be handled better. But my point remains: if you're not happy with what they're doing, don't help. There are plenty of other distributed projects out there that are worthy of your cycles.
I want to help seti@home. I realise there are faster clients that are probably as accurate, but seti@home don't want me to use them. So I won't.
While you will never get an argument from me that open source software is generally better, there are some things however for which Open Source is not appropiate. Even Eric Raymond would agree, after all, one of his presentations convinced me of this fact.
SETI@home is such software. It isn't some kind of disk system that just needs to run more quickly. It is a scientific endeavor. Unless it can be assured that the new algorithm being used in the patch produces EXACTLY the same results given the same input for ANY possible input, use of such altered packages could invalidate the experiment.
While it is nice to have such things open, in this case it just doesn't seem prudent given that the software is performing complex computations on the data. It is possible that some of the shortcuts used in the patch eliminate some calculation which almost never seems to produce any results, but could given certian inputs.
In a case such as SETI@home, such things would be a serious problem.
There is another reason the SETI@home team wants to keep things a little secret. There are groups who (for whatever reason) may want to either mask a possible signal, or create a false one. There are fanatics on both sides. If you read the FAQ on the home page, it states as much, and that steps have been taken to assure that such things are not possible. This may require some secrecy.
There is a civil war coming in the United States. Remember which side has most of the guns
Typical "official" Slashdot sentiment: ~(Open Source) == Bad. There are quite a few legitimate reasons to not open-source everything, most of which will likely be entered as comments while I'm typing this, so I'll spare the discussion but for one: security.
If people went through the considerable trouble of reverse-engineering and patching the client for speedups, wouldn't it make sense that they'd do even worse things to open code? And since most of these erstwhile hackers don't have any knowledge of astrophysics or the algorithms involved, they'd more than likely screw something up.
Do you just randomly comment out offending lines of code when compiling unfamiliar software, or do you try to fix the bug?
If you have the necessary knowledge to do something like this properly: then volunteer! And to Slashdot: get your head out of the sand! (Oh, and Hemos is a hamster.)
What we see here is just one more guy who simply cannot believe that open-sourced software is more secure then proprietary one (Just like the old argument of some people - mainly the less mathematically knowledgeable suits - who can't believe in the security of OS encryption software, after all the algorithm is readable by everyone and therefore unsecure).
In reality, the original patch from Olli was a good chance for moving in the bazaar scheme not only to processing power but also to client development, since it was a simple wrapper which didn't do anything special itself, but enabled other programmers to write their own Fat Fourier Transformation algorithms for special chips.
If S@h would have allowed patching the software (or had even made the client OS) we could now have dozens of different clients tuned for every imaginable Streaming Extension, DSP or multiprocessor enviroment. And the SETI@home project could have also been a starter for future similar projects which could have used all the power of the specialized out there.
Now for the defense of the project heads: There have been multiple malicious tries by individuals in the past who tried to get their rating up by cracking the protocol and sending bogus data to the server. This perhaps explains why they're this paranoid.
>To track down the signal, units must
>be processed. If we process signals
>faster it'll either let them eventually
>process more signals
They are already processing the signals at nearly twice the speed they can collect them.
By speeding up the client a small percent you hope for what? processing at 3 times the speed its collected? The client is good enough and nothing is gained by spending countless hours gaining a small speed increase, the time could be better spent somewhere else.
(this is like spending months of your spare time speeding up lilo or some other command. might learn something doing it but it is just a waste of time)
Is that they're going to patent intelligent alien life when they find it! This way they'll hold an exclusive patent on all intelligence in the galaxy and anyone who tries to think will be charged a license fee.
:-)
You know, I think it may be time to turn off the RC5 clients and let power savings mode kick in for the first time in months. It all seems so... silly somehow.
Science that isn't open source? What's next?
-- I'm omnipotent, I just don't care.
-- IANAEG - I am not an elder god.
I wanted to take a look to see exactly what the heck these patches do, but I'll be damned if I can find any. The best of search engines (several), and I can't find them anywhere. First time I've found myself unable to find something like this.
Any tips, anyone?
---
- 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'm seeing comments saying that SETI@home wants accurate results, not speed. Someone actually posted that "improving the code won't improve the code." That if you try to make it faster, you are out of line with the SETI@home's goals.
How can I say this? Well let's try this: what the HELL are you talking about?
Please, let's *think* here. Why are the goals of accuracy and speed mutual exclusive? Perhaps there are some methods that would reduce accuracy for speed. Fine. Let SETI@Home set there tolerance levels (i.e. how much significance to use on calculations, precicion, etc.). Then let people who are very, very good at making C programs run really fast and making programs run reliably and accurately take a crack at it.
Come on people. There is no reason that SETI@Home could not be improved by an open source approach. I agree that accuracy should not be sacrificed. But pardon me if I think the resources of the entire program world might not be able to produce a faster and more reliable/accurate client. It's just a matter of raw resources. More programmers, more peer review==better, more reliable code. And it just might happen that it comes out faster in the process
ranting ends ...
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
The reason is, as someone has noted, that I can FORGE the packets so that they will look like normaly processed data, whle they will be bogus. And I know already some people (by their nicknames) that have tried to do this, and get a high rank. I have seen people processing thousands of packets in an hour, while, with the official client, you can process a packet in 9 - 10 hours on a P III 400 MHz (running NT or Linux, no big difference).
Sigged!
SETI is science... distributed.net is engineering. There is a big difference, and science does things the way it does it for a reason. SETI needs the results to be as solid as possible.
The main thing with the SETI client _should_ be not to make sure it finds a signal, but to make sure it doesn't miss one. I agree with this part of it.
However, this is data analysis. Pure and simple. Run an algorithm on a lot of signals. Easy. No one questions the algorithm. What is questioned is the implementation. If I can take an algorithm and optimize it to run faster on a particular processor, then I must still get the same results. Otherwise, the algorithm is no longer the same.
And it's not a question of some hacked program finding a signal. ANY signal found will be subjected to the most intense scrutiny even before it's announced. Then it'll be scrutinized again afterward. And other signals from that sky area will be looked at, at various times going back years. No, a false signal will be eliminated pretty quickly. The thing to watch for is a false negative.
I don't think open source is the cure-all answer here, but I think the people running seti@home have not given thought to the fact that people running the client are the kind of people who really, really know computers. They know algorithms. They know the internet. They are smarter than the average bear. And they don't like people telling them you cannot know this, or you cannot know that. The SETI people need to explain their position better, or count on a lot of people leaving the project.
Just my $0.02
---
- 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.
but enabled other programmers to write their own Fat
:o)
Fourier Transformation algorithms for special chips.
I believe you meant Fast, of course, but this little typo is really cute
And who knows, maybe the good 'ol frenchman was actually fat and didn't mind it a bit!
To stay on topic, here is a link to clues about Fourier Transforms.
Sigged!
In the case of the SETI@Home project, the security is needed by the project, who don't get to see the modified versions. So it doesn't apply.
Of course, if people distribute their modified versions, other people will find the bugs. But how will the already-submitted results be retracted? And what about modified versions that people keep to themselves?
I suspect that future projects of this kind are going to have to include more dummy data to verify that incorrect algorithms are not being used.
Is everyone out there spouting off without reading the article, or am I the only one who can't get the link to work? I can't even get a ping response from www.newscientist.com...
Eric
SETI@Home is partially worried about people submitting unchecked data packets to boost their score, or not submitting a signal if found, simply to mess with the project.
But, they're also concerned with the project working too well. If their weekly allotment of data was processed in a day, users would either sit idle for the rest of the week, or recheck data. Either is likely to make people look for another project.
We need to have a general distributed processing client with modular cores. That way people can check for alien signals when the new SETI@Home client comes out, then evaluate various check opening moves, or try code keys, or any other project that needs users.
The basic shell of a distributed client is fairly simple, and in most cases is very similar. The system sends you data, tells you what to do with the data, and accepts processed data for return.
The same client could send out SETI@Home packets and DES keyspaces depending on which project had a more immediate need for help, and what the client computer was capable of.
Cracking code keys is a lightweight process. It takes very little RAM, and can be suspended instantly. Running FFTs on radio signals (SETI@Home) is a heavyweight process. It requires a lot of RAM, and isn't generally appropriate to run in the background while using the computer.
A multi-core client could deal with this beautifully. When you're using the computer, a lightweight process is selected based on your preferences and need, and runs in spare cycles, not being noticed. When the screensaver kicks in indicating an idle computer, the lightweight process is swapped out for a heavyweight process like SETI@Home or chess analysis, to be run when a performance deficit on the client won't be noticed.
The user could download processing cores for the projects they'd like to participate in, and list the jobs in order of preference. For instance, SETI@Home then chess analysis for the screen-saved modules, and Bovine code cracking for the spare-cycle modules.
Then the system would crack codes between keypresses, and switch to SETI@Home when there are data blocks available, but switch seamlessly to the less time-critical chess analysis when the SETI@Home blocks run out.
The system has the benefit that not every author of a distributed project would have to write a whole system, plus servers, and bug test it. You'd simply write a processing module and a server module to properly serve that data, and compile the client module for as many systems as possible, or distribute it as compilable code. Thus allowing SETI@Home to run on an SGI machine for instance, without the authors having to write a communication system that would run on that computer.
Mathematical tasks, like cracking keys, or recursively iterating chess moves, or FFT calculations are fairly easy to implement in a small program, and are fairly portable, usually not relying on the OS for much.
Currently, there are many ideas for distributed projects which never get explored because they don't have anybody capable of coding a client as stable/easy as the bovine, or of finding a large enough audience to make it worthwhile. Having one shell with multiple cores would allow anyone who can express their problem in code to reach a large audience of people ready to work on their distributed project.
Some people complain that open sourcing S@h would lead to more falsification of results. However, this is already occuring, and S@h will eventually be forced to do more and more redundancy checks anyway (i.e. sending the same packet to multiple people). Another interesting idea is that S@h will run out of packets to process sooner than expected and for this reason does not WANT to speed up the project. I think that overall, open sourcing the project, and then doing multiple redundancy checks will result in both faster and more accurate results.
Okay.. so the way they can be absolutly sure the client is working correctly to open source it.. but its not as if they're trusting the client completely. They will check the data that is reporting the signal (time and time again I suspect).
But what if they open source it? People will know how to fake the return data. You know someone will do it. So do they check the occasional block of data or the (most likely) more frequent block of data...
Its no choice to me.
May contain traces of nut.
>
:-)
mmmm... but the Alpha EV67 does it in 58 minutes! Man, I'd love to have one of those beasts...
As has been stated several times here, the importance in the seti@home project is in the validity of the data, not in the speed. In fact, since using the people on the net they are getting faster response than any existing super-computer, they are getting quite a bit of speed. Having custom clients floating all over the place would make that speed meaningless, though, if those clients are returning garbage data.
I'm a strong believer in the quality of open-source code... but there *are* reasons for maintaining control over the code... and this is one. Do you want results that you *know* are valid because the code is closed, or speed?
I don't think you really understand how to optimize code.
You optimize the sections of the code that take the most processor time, and the programs you use the most. If lilo completes in milliseconds, don't optimize it. If your whole office app is a pig, optimize the parts that the user spends the most time in. If your shell is fairly quick, yet you spend eight hours a day working in it, it might be worth optimizing those input routines even if it's only a 10% overall speed gain.
With SETI@Home, sure, they run out of data before they run out of time. But, they don't have to perfectly match. By your logic we should slow down the client so as not to waste any cycles on unimportant non-SETI@Home processing.
I'd prefer to optimize SETI@Home and either require less users, or process the week's signals faster and be able to run other distributed projects.
Because SETI@Home *is* a valid target for optimization. It sucks an incredible number of cycles. And now that we're used to running distributed projects, those aren't useless cycles anymore. You can see SETI@Home as competing directly with other projects for computer time.
It's much the same as a slow subroutine making the whole application slow. But in this case the subroutine is SETI@Home and it's making the application of providing computing resources to as many distributed projects as possible run poorly.
The only proven way to provide any kind of security to the project, is provide some kind of check as to the accuracy of the data sent. That involves checking every client's data once in a while, obviously the more often the better, of course, that will take some raw processing power off.
A way to do it: get every client to register, assign a certified key back to the client, with which it signs its responses, and send 1/10th (for example) of the results back to some OTHER client, check that the results match, if not, investigate and shoot them down, possibly try some legal action if possible. Also add some checks WRT IP addresses, so as to check that the same key does not originate from too many different IPs, etc ...
That can't be perfect, but it's almost impossible to defeat, at least compared to the current scheme. (Unless I missed something).
That's not a way to handle it. If everyone who has a problem with the specific implementation goes away you end up with SETI@Home being critically underpowered. And I like what SETI@Home is trying to do. I just wish they didn't make it an either-or choice of helping them or helping other projects. A well written client would allow people to participate in more computing projects with the same number of spare cycles.
The Seti people do not want anyone using new clients for one reason....their servers cannot record and split the data into packets quick enough. Right now they are recieving more completed packets than they know how to process. It seems that their little idea caught on a little more than they expected, and they just can't keep up.
Seems to me that the Seti@Home people are caught between a rock and a hard place. In order to attract lots of cycles, they've made a contest out of it. That's what posting team rankings on number of results returned amounts to, after all. And that inflames the folks who know they could rise in the rankings if only they could optimize their clients.
On the other hand, they prize uniformity of results over speed. Hmmmm.
Well, if they already have too many volunteers, the answer is simple: dump the contest and make it a lottery with one winner. No more rankings, no more teams. Just tap the guy who finds the aliens.
All the contesters will drop out and go back to cracking RC5. The hard core will remain, consisting of the ones who agree that uniformity is more important than speed, together with the ones who seriously want to mess with the project. There'll still be the need for security but at least most of the results will be consistent.
I bet you opened your computer and attacked the SIMM sockets with a butter-knife too? Or used vi in your /proc filesystem, right?
I'm not saying SETI should be open or not, but all of the arguments against open source are assuming that there will be 100 different versions of the software, or lots of different patches that will be installed in various combinations on the users machines.
Why couldn't the project be open but follow the same versioning as it currently does. i.e. open the source, let everybody put in their 2 cents, and release a single(or at least single for a particular OS) version of the software based on the best optimizations provided. I would like to have someone argue why open source would be bad in this case.
This is Slashdot, isn't it?
--
Interested in XFMail? New XFMail home page
Most everyone I talk to who runs this product says often that it is slowing their machine down. So often I hear "Let me shut down SETI@home and see if that helps" (it usually does).
If this program is really using idle tasks then why does it slow people machines down so much for eveything else.
The project says they "will not release the source". I say, why bother supporting them. Here you have a whole bunch of people who are brought together by the ideals of OpenSource and you're giving up your valuable processor time to a project which refuses to open the source. They're riding the "Cool Wave" of linux to get their work done.
Sure, finding life in outter space is cool. But not cool enough to let this program drag my machine down. By using the software, you contribute to their project, what are they contributing to the OpenSource comunity (not berkeley in general, the SETI people). OSS is a matter of give and give some more. SETI is only taking and giving very little in return.
Fish! LipHo
(quote)
... *grin* I know quite a few people who just download and run this program for the fun screensaver, and are pretty computer illiterate otherwise (at least compared to the majority of the people on this list).
I don't think open source is the cure-all answer here, but I think the people running seti@home have not given thought to the fact that people running the client are the kind of people who really, really know computers. They know algorithms. They know the internet. They are smarter than the average bear.
(/quote)
Unfortunately, that's not entirely correct. There are a lot of people who run SETI@home who haven't a clue what open source is, let alone the ability to code any improvements or whatever. Look at the number of people running the SETI client on Windoze boxes to see the truth of that statement
Seriously, though -- the scientific concerns of this project are substantial -- experiments need control, and that means that you can't let people go running off changing their little pieces of the experiment. And to think that just because somebody can write code means that they are now a qualified experimental scientist is a bit naive -- apologies to the list; I'm sure there are quite a few good programmers who ARE experimental experts.
One final point. You are quite right to point out that it's not false positives, but false negatives that we need to worry about. Unfortunately, while we can detect and discount false positives, we will never know about the false negatives -- and if it were I running SETI, I would not be willing to risk letting some random geek hack my code in such a way that he misses the real positive by inducing some error. I personally would count such an occurence as a tragedy of cosmic proportions (pardon the pun).
darkmagus
They are only making about 1/3 as many as are sent out. In addition, they only have a limited time (2 years?) of data gathering time allocated to them. If we go any faster, we will just get more repetition in the packets sent. We can't find ET any faster by speeding up the clients. The only way to go faster is to collect more data from the telescope. Unfortunately, the S@H site tells us why this is not possible. Maybe we should all read the info available from S@H before going on and on about the "inefficiency" of the clients.
Creepers, they are asking for our help with their project and we make it sound like they should be flogged for not being "perfect." If you don't like it, don't participate in it.
--
--
dman123 forever!
Filtering out the -1s and 0s since 1999.
I can't say that I agree at all with S@H's position on this subject. True, there are some right bastards out there who need to feed their egos so very much that they would falsify data, but that risk has already been taken. The important thing now is to find a way to minimize said risk.
S@H seems to think that this is best accomplished by keeping the source code to themselves. Not so. For instance, analyzing the communications protocol employed by S@H clients does not require the least bit of knowledge of how the client works internally. No, the solution to the bad-data problem that immediately occurs to me is redundancy -- having multiple independent computers run through the same dataset and compare their results. A mismatch would be handled by reissuing the same dataset to a different set of independent computers -- until one iteration produces agreement.
This would slow down traversal of the dataspace some, but that is far preferable to the introduction of rogue data -- which, I repeat, is already occuring.
Besides, S@H is running out of dataspace anyway.
Making the client sources available would almost certainly improve the efficiency of the client and would quiet those who object so strongly to running an unchecked program on their system. It would, it seems to me, make the entire effort more worthwhile and more interesting. Security through obscurity simply doesn't work.
Sic semper luseris.
or just send the same packet to two or more computers and check that the returned results agree with each other.
rather they should think about a way to do the distributed processing that could not produce false error even if open sourced. and then there would not be any reason anymore not top open source it. i do not think it is all to difficult to do:
greetings from vienna, austria.
dermond. (english is not my mother tongue and i have not spellchecked my post)
The SETI people have explained their position as well as they need to, IMHO. The post you are replying to explains it again. And as a person who has a Ph.D. in spectral estimation and 20 years in programming (ie, ``smarter than the average bear''), I have contributed 1500 results and have no intention of leaving.
While I agree with you, I think you, and a lot of the other "Open Source SETI now" zealots have missed the point. This has more to do with scientific method and the ability to convince other scientists and observers than it does technology, algorithms, open-scource and computers. Seti@home is an experiment, not a software package...it just happens to use software to do the experiment.
If a signal is found, your right, it will be analyzed to death before it is announced. False ones will be rejected. But with any experiment, you must be sure that ALL conditions are the same everytime it is repeated, to be sure the results are as accurate as possible. If the source is opened, they have just lost that control...they cannot be sure (100%) that the analysis is repeated under the same conditions. As we have already seen, some people have tried to boost their scores by sending the same packets over and over or by sending false packets. While these will get filtered out, the project can still say their results are trustworthy because all analysis is the same - same implementation, same algorithm. Imagine if it is opened up and a signal is found. It will be processed, double checked and checked again. But when they announce it, there will be a large number of people (and scientists) who, for whatever reason, will refuse to believe it. They will then point to the lack of control over the source as a place where the data was either " messed up to give a false positive" or deliberately faked. As they say in court, they will have a "reasonable doubt". This is too important to have that kind of possible outcome.
Put it in another context - a group is experimenting with an AIDS (or ebola or something like that)vaccine and testing it in petrie dishes (this is an example, so excuse me if this doesn't really happen). They set up a bunch of dishes they had control over (washed and prepared themselves). They get some help from people outside the experiment who can make the dishes clearer or easier to handle or what ever. They check and double check and find that in a lot of the dishes the virus is killed quickly and in some it is not. How do you interpret these results? You don't - the experiment is invalid because you cannot safely say which pertrie dishes are which and don't know wether the results are due to your drug or due to some bleach left in the dish by those who prepared it (by accident or on purpose). You can only be sure about your dishes but you can't tell which ones are yours. The solution is to only use your own dishes.
I'm sorry for being long winded but I'm trying to stress a point. So open source can make the client more efficient and faster, who cares? Being sure of the results is what matters.
The sad part is these patches may have already made the experiment invalid for thse same reasons...considering the size and reach of the net, who knows how many "enhanced" clients are out there. It is possible that, if a signal is found (or missed, in which case we may not realize it) that all the redundancy checks were done on clients with the same or similar patches with the same calculation flaw and all becasue the project doesn't have complete control...and because some 19 year old wanted to be #1 on the SETI@home list.
Hey, if you don't like it, don't use it. It's their experiment we must participate on thier terms.
Never by hatred has hatred been appeased, only by kindness - the Buddha
SETI has always had trouble creating enough work units to keep up with user demand. The project is more popular than anyone had ever dreamed.
One of the patches cause the clients to run 30% faster (at least on my clients). I've heard some reports of clients running 50%-70% faster.
SETI just can't generate that much data to munch. If they did speed up all the clients and they ran out of blocks, users would be very upset. Solution... SETI would start sending out the same blocks to be rechecked while waiting for new blocks to be created. And users would be upset because they were doing the same blocks twice.
In either case, they lose.
As for the open source discussion, that is meaningless in terms of SETI. Their problem isn't that the client it too slow, but that it has the potential to be too fast.
InitZero
Releasing the client as Open Source is not a good idea. SETI@Home is a real-time science experiment. Having an open client circulating around with some people using it, and others not, would invalidate any data being returned. The client needs to be STANDARDIZED, so that all results being returned are STANDARD. Having people modifying the client at will would really mess up the inner workings of the experiment. What if one person got the source, and somehow modified it to return data that "looked" like some intelligent transmission from ET?
Experiments need to have standards and controls, open sourcing the client would not work.
OPEN SOURCE IS NOT ALWAYS THE ANSWER.
Why are the goals of accuracy and speed mutual exclusive?
Well, here's a demonstration you can try at home. Find a recipe for, say, chocolate chip cookies. You want more speed? Double the heat setting on your oven, and cut the baking time by half. Watch what happens. Your output is no longer accurate, even though the input (yer ingredients, order in which you combined them, etc.) is the same as what was called for in the original "source".
Now open-sourcing recipes is a fine idea. Go ahead and experiment in the kitchen, and if you can come up with a faster way to make cookies that taste as good as the slow-cooking ones, more power to ya. But don't expect Betty Crocker to print your recipe in her next cookbook until she gets to test it out herself.
The folks at Seti@home might be better served if they open-sourced their code. It seems like a good way to improve it. But one programmer's improvement is another programmer's bug. And if someone's "improved" Seti@home code is fast but sloppy, and gives unacceptable results, the folks at Seti (and all of us who care about the project) lose out big-time.
It would be nice if the code were available to be tampered with, fine-tuned, and "improved". It would also be nice if only "real" improvements - not quick'n'dirty shortcuts - were used in crunching the data. But how to tell? We don't live in a perfect world. Open the source and big improvements - as well as tiny-but-devastating bugs - may follow.
There is supposed to be one accepted program for crunching Seti's data. Arrange it so several versions are running, and you introduce more variables into the experiment. Not good.
In a client-server system like this, there is no way to ensure that a client is actually doing what it's supposed to be doing. If you release the source code, it becomes much easier to make a fake client that pretends to process data blocks. Some groups may do this in order to get their names near the top of the list (or to sabotage the effort).
As it is now, it's a lot harder to make a fake client without source code. And before a few knee-jerk reactions get posted, like "Open source r00lz you Micro$oft whore!", for example (I use LINUX), just think about HOW you would verify the validity of the client results here from an open source program. Maybe there's a way. Please prove me wrong.
There's no point in arguing now about source vs. object code before appropriate authentication is adopted.
Which raises the issue that maybe this must be implememented outside the U.S. by foreign nationals, and that they should take care of distributing the client software, too.
[But any authentication server could still be in the U.S., of course]
Why must there be a scoring system of who does the most keys? I'm with the distributed.net just for the fun of it, and don't really care about my position in the top-100000.
Okay, if there were no scoring system, but instead simply individual statistics of how much you've done (ie. "you've done 1234 units. Project total is 1.234E20. Your share 0.1E-19 %." (numbers are not authoritative!)), then there wouldn't really be point in trying to make ones rating better.
Of course this could not prevent malicious people from simply messing the system up just for the assholity of the action, but it would stop those people who want to be famous for 15 minutes and see their name as high as impossible without cheating.
'nuff said.
The reason why they do not open source their project is very simple:
There are very good coders out there that believe that FFT means FAT Fourier Transform!
*Grin*
Angel
>SETI can't stop people from modifying the executable on their own systems,
:)
>but I think the people calling for SETI to make it even easier for people to modify the system
How can closing the source prevent me from spoofing a valid signal with a client I write and distribute? Nothing! In short you can't ensure that you are getting valid results back simply by saying no one can know HOW your client works because you can't control the source of the packets. I can write a bogus client that mimics your interface.
There is no inconsistency to having the client open, and then still ensuring that only valid clients be used-these are separate issues entirely.
According to your statement I quoted above, SETI's experiment is already blown if they can't stop people from modifying your executables, so why do they continue? Because they (I hope) have checks to see that the data is valid.
Point is, no one has to hack the closed client they can write their own. The only way to secure the client is to find other ways to validate the data. Thus validity has nothing to do with the openess, so open it and you gain the insight of the best programmers in the world both on performance, and probably security too.
This isn't about speed, or accuracy in the Scientifc processes that SETI is using, if it were, then no Scientific endevor ANYWHERE could use open source software. Guess all those universities will have to get rid of Linux
I don't think anyone is advocating that SETI release control of the project, just suggesting that we leave the astronomy to the astronomers, and the programming to the programmers.
>If you can improve the code, instead of helping SETI by processing keys faster,
>you bring yourself out of alignment with everybody else, create potential bugs in >the experiment,
No one is saying that giving any goofball the ability to screw with your algorithims will help you, but they ARE suggesting that you could get a lot of help with the valid client that YOU distribute/endorse. If you choose to abdicate that responsibility, well than you are no better than the suits who think that Open Source is a panacea that means they don't have to work anymore either.
Security through obscurity, you'd think the scientific community would know better.
We are agents of the free
Anyone else wonder if just maybe the NSA saw how fast the RC5 project could crack encryption, decided to write a client and fake a project (SETI@Home) to make use of all the computing power available on the very peoples systems they are monitoring?
That would certainly explain why the client was closed source. I for one will not waste my time, or my computers time, on RC5 (as it has long since stopped being useful) or on SETI@Home (Until I get some serious proof that my clock cycles are actually being used properly). This would mean opening up the SETI client so that I can be sure it is doing what it claims.
Sorry, but that is the way I feel.
-sirket
Yeah right. Lets open source the Space Shuttle software, MRI scanners, laser treatment machines, radiation treatment factilities. I know I want to strap my my ass in the chair and put my life on the line with code created and edited by someone who 'thought' they knew enough to make it better.
There are just some areas where a bunch of non-experts in a field are not the way to make things better. Mission critical specialty software is one of them.
Just adding my voice to the choir:
.01% chance that a given block is analyzed wrong would be unacceptable losses. Speeding the project up 10 times at the expense of a .0001% chance of getting a given block wrong is *still* unacceptable.
It is a *FEATURE* that this is closed-source.
It is *MUCH* more important that everyone run code which is *EXACTLY* equivalent, and has been tested to be equivalent, than that people be a few cycles faster.
Speeding the project up at the expense of a
Would I run Linux? Yes. Would I bet a few million dollars on a given patch working perfectly the first time? No.
So why is it that everyone's pressuring these guys to take that risk?
If you don't like the terms of the project, don't play. If you want to help them out, follow their instructions.
It may come as a shock to people, but the scientists running Seti@Home are *not* idiots; they are experienced professionals with substantial relevant training who have carefully examined their options and made rational choices.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
No! As I understand it, the goal of the SETI client isn't to prove a signal, only to attract attention to a slice of data.
Your own statement explains the flaw in your position that SETI shouldn't be opened. You said: Imagine if it is opened up and a signal is found. It will be processed, double checked and checked again. But when they announce it, there will be a large number of people (and scientists) who, for whatever reason, will refuse to believe it.
This is exactly why a faster (even possibly flawed) new algorithm might be helpful. The original data will always be preserved safely and re-examined with multiple algorithms once a signal is claimed to be found.
I can see two drawbacks to opening SETI:
1. The increased potential for a flood of malicious or honest-error false positives to overwhelm the process for reviewing the original data;
2. The possibility of false negatives, as discussed in another thread on this subject.
But false positives, at least in reasonable numbers, are hardly a reason not to open SETI.
-David.
Has anybody here ever taken a course in University (or High School, for that matter) Science?? You have to have control over your experiment to get valid results. People who modify the SETI@Home Client are basically destroying the results. Whether or not they intend to screw things up, that's what they're doing by not using the standard Client from SETI.
These people might also be the people who used to yell, "My dad can beat your dad!" when they were kids... I don't know.
What I do know is that I'm running two Seti work-unit as I type this (one each on 2 machines. A Windoze box and a linux box), and am more interested in precision and accuracy within my completed data, not speed.
Ignore Alien Orders
I was planning to make this point. Thank you! Whether or not it is open-sourced, SETI should not be a contest.
-David.
The SETI client isn't mission critical. Its job is only to attract attention to certain slices of the raw data.
-David.
RC5 has a known number of keys to check, and that number is truely enormous when compared to the number of keys per day that can be done. Thus, there is every incentive to optimize the hell out of the client.
By comparison Seti@Home is already processing data faster than it can be created. Optimizing the client won't make the analysis go any faster - maybe they would be able to check each work unit three times instead of two. But, where's the incentive to optimize?
S@H is a victum of its own success. What will probably happen is the number of users will start to drop off as people become bored. This isn't necessarily bad.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
- People are conditioned to want their computers to run faster. The amount of time and effort some people spend to overclock and benchmark their computers is often far out of proportion to the actual benefit they get from their computer's speed. It's not surprising that people treat their SETI@home processing speed as a benchmark.
- The fact that SETI@home puts up statistics that have turned this experiment into a competition to complete the most work units reinforces that behavior.
- At least one company (perhaps SGI, but I can't remember for sure) has mentioned their SETI@home crunching speed in some marketing literature, again emphasizing speed over quality of results.
- As several in this discussion have pointed out, making the clients faster won't help the project because the bottleneck is that SETI@home can't prepare the units fast enough. However...
- If the client software were improved, clients could potentially do more sophisticated processing in roughly the same time, improving the science. However...
- This could make the clients seem even slower than they already are, which wouldn't sit well with the kiddies who are more interested in their rank or how fast it makes their box seem than the science involved.
So what lessons could be learned if this or a similar experiment were to be done again?- Deemphasize the ranking of work units completed. Perhaps if the concept of a fixed work unit could be dropped altogether (i.e. make the "size" of a work unit something arbitrary so that they couldn't be compared). This would possibly prevent the client from being used more as a benchmark than for its true purpose.
- Plan for hacked clients and spoofed results by sending out enough test work units and by cross-checking results with multiple clients enough to have confidence in the results backed up by statistics.
- With enough cross-checking, you might as well Open Source the client.
I would be interested to hear if there is a (theoretically) foolproof way to use distributed clients to produce results with confidence if you accept that some clients will be spoofed.Point well taken.
Of course, what does this have to do with Open Source? If you don't like they way they do it, create your own version. I may not like Word, but I'm not demanding MS open source it, I'll use KOffice, StarOffice et al or create my own. Let them identify the slice their way first then check it out...don't mess with it midway through the experiment. Your proposal is to do the experiment a different way. Do it, but changing the experiment half-way through makes no sense.
And I say once again:
"Hey, if you don't like it, don't use it. It's their experiment we must participate on thier terms."
Never by hatred has hatred been appeased, only by kindness - the Buddha
Is there actually anyone out there doing weather simulations? I run seti@home because I like giving my computer something to do, and crypto projects seem like a total waste of time (what exactly are they proving? everyone already knows the results, and the public and the politicians don't care). Given that Arecibo wouldn't be able to detect our civilization from further than about a light year, I might want to try weather simulations.
One thing that I think that hasn't been brought forward is the paranoia that SETI must maintain. Think about it.. These scientists have been the butt of jokes about listening for little green men for years. They've had most of the radio astronomy community bitching at them for using up scope time on a "useless" pursuit. So if or when they get conclusive "proof" of ET Intelligence do you think they want to be in a position where they have to explain how they can be explicitly sure of their findings in the light of having 1000's of non-scientists and non-mathematians programming the code which "detected" their results? Granted, they could verify the packet(s) through a set of slower non-GPLed clients, but these guys are already behind the gun on the nature of their line of research. Give these guys a break! This is just one of those 5% cases where Open Source doesn't fit.
I had this idea that I'm hoping could get to one of the Cisco IOS engineers out there. If the source to the Seti@Home client were to be opened, wouldn't it be neat if someone would add a feature set for Cisco's IOS to function as a Seti@Home client. There are a lot of companies out there who have spare routers sitting idly by and a Motorola MC680x0 isn't that shabby. Of course, there isn't much memory to play with, but there are a LOT of idle routers out there.
Look the third entry in the Spain statistics: http://setiathome.ssl.berkeley.edu/stats/country_8 .html
This has everything to do with security. You're proposing that by not making the source code widely available, you can somehow guarantee the INTEGRITY of the results generated. And you continue to do this in the face of spoofed results, and claim your views are good for science. It boggles my mind.
This Seti@home code was written by aliens to not detect extraterrestrial signals. Do you honestly believe aliens have a clear concept of what open-source actually means? I think not!
--
Don't lead me into temptation... I can find it myself.
This is a rumor I heard, and I don't have any confirmation, but didn't SETI@home have big problems with people uploading fake data packets, just so they could have more data packets processed by Joe Schmuck down the street?
If that's so, that just undermines everything that SETI has worked for. Patching the client, that's one thing -- but fake data packets? SETI has not come this far to be undone by a bunch of code-happy jokers with nothing better to do than gratify their own fragile egos. I find that rather pathetic.
As far as the "client optimization" issue is concerned, it should be obvious that if SETI can't keep up with the data packet demand, "releasing the code" isn't going to do anyone a damn bit of good. What are they going to do? "Okay, we'll send you data packets -before- we have them?" (Again, SETI there's a chance that SETI has some reason to lie about this, but I'm going to take them at their word.)
And, really, whether or not someone thinks they "know better" than SETI or "know what they're doing," and are clamoring for the source so they can tweak it -- it's not yours to tweak. If you want to alter SETI's project, go work for SETI. Take some responsibility in the project and stop treating SETI@home like it's your personal toy. Certainly many people's intentions are good -- they just want to make the client "better" -- but that decision's not theirs to make. It's not their project.
If you truly want to help SETI, then use the @Home client the way the project's creators intended it, and don't sabotage it for the sake of your own ego.
Open-sourcing has the further advantage of becoming very, very portable, almost for free. I'm sure there are a few bored mainframers out there with a few underutilized MVS boxen that could contribute to the Cause.
<troll>But all of us know the real reason they won't publish the source--SETI@Home isn't sending us space noise at all; they're sending us heavily-encrypted high-level diplomatic radio transmissions from all over the world, letting us do the CIA / NSA / NRO's dirty work for them. Until we see the source, they can't prove it's false; therefore we must assume it's true until we see the source.</troll>.
Has anybody seen the latest DNRC office prank? Someone's co-worker was running SETI@Home on their office PC, so the DNRCie hacked him a screen saver that beeped and kept flashing the words SETI@Home: Possible extraterrestrial transmission found. Confidence 99.9893% over and over again. I can think of a half dozen people I'd like to do this to, only I'd make damned sure that on the next user input event, they'd get a dialogue saying "Please stand by: writing results to disk. DO NOT INTERRUPT THIS PROCESS" followed two seconds later by a dialogue box saying "Fatal exception error", because there's no point in being just a little bit cruel.
--
This is not my sandwich.
Anyone who has looked at the source for the patcher knows that S@H security is an oxymoron :) Anyway, they can fight windmills all they want and talk till they are blue in the face... let us deal with reality here though. Talking wont make the patches go away. They should stop spending effort on whining and either improve the security to a point where patches become very hard (wich would require frequent client updates probably) or remove most of the impetus to use them in the first place. (ie setup some resources to integrate community improvements, this does NOT mean open sourcing the entire project just the number crunching part) If you feel the second is not "scientifically sound" and you have no problem with the colossal waste of resources (including the natural resources, ie energy, belonging to us all) then you should push the S@H people to do something about security... anything else is futile. Futile can be fun, but not usefull :) And I would expect the S@H people to want to spend their time usefully. Ohhhh the big bad world doesnt play by my rules... Ill just start pouting and write scientific articles about it, that will teach them!!!
Anyone who has looked at the source for the patcher knows that S@H security is an oxymoron :)
:) And I would expect the S@H people to want to spend their time usefully.
Anyway, they can fight windmills all they want and talk till they are blue in the face... let us deal with reality here though. Talking wont make the patches go away. They should stop spending effort on whining and either improve the security to a point where patches become very hard (wich would require frequent client updates probably) or remove most of the impetus to use them in the first place. (ie setup some resources to integrate community improvements, this does NOT mean open sourcing the entire project just the number crunching part)
If you feel the second is not "scientifically sound" and you have no problem with the colossal waste of resources (including the natural resources, ie energy, belonging to us all) then you should push the S@H people to do something about security... anything else is futile. Futile can be fun, but not usefull
Ohhhh the big bad world doesnt play by my rules... Ill just start pouting and write scientific articles about it, that will teach them!!!
Is there actually anyone out there doing weather simulations?
Yes, here's the Slashdot story
...the subject line sez it all. =)
peer review, repeatability, they can't trust clients anyway
Yeah, I agree. The Seti@home client MUST be opensourced AT ONCE! I mean, we all know what we're doing, right? It's not like we can't figure out an obscure bit of code that does something we don't understand with data that we can't see and produces results that we can't check -- it's just drawring purty pitchurs, ain't it? And HOW DARE those scientists think that they can control the manner in which they analyze their data? Science isn't about control! It's about freedom! Freedom! Freedom! It doesn't matter if they just want to discover something that could change the world. If it ain't open source then it's E-VILLE! Control of data computing methods my ass. Just who do they think they are, rocket scientists?
BTW, for all the "why not Open Source" whiners out there, 18 months ago, this project WAS open sourced. You could volunteer, talk directly to the project leaders and hack the code all you wanted. This was during the DEVELOPMENT phase. When the development was finished, the client was closed. Where were the whiners when you could get the source? I got 2 different versions of it to play with (though I don't have them now, since I've nuked my hd a few times since then). The client is NOT a commercial product. Open source is great for commercial products because it continuously improves the quality of the code and design. A commercial product needs this improvement to stay competitive. The SETI@HOME client does not need this. It is doing what it was designed to do for this experiment just fine. There is no "competing product" to stay caught up to or surpass. In 2 years, when the experiment is over, so will the SETI@HOME client. Therefore, any of the benefits of OSS development have already been utilised by by SETI@HOME. It doesn't need to be tweaked or spead up or become more efficient. It simply needs to be used by 'volunteers' the way the project leaders have designed it. If you can't abide by their request, don't volunteer. If you don't like the way it works, don't use it.
If SETI@HOME didn't have their ranking scheme, would we be even having this discussion? I think that was their only mistake....
They already used the Open Source model...
Never by hatred has hatred been appeased, only by kindness - the Buddha
But, the "whole point" is essentialy a scientific experiment. When you do a scientific experiment you have to controll all the variables. When the experiment is over they have to be able to say "We looked Here,Here, and Here. On These Frequencies using Exactly these algorythms and we did[n't] find an alien signal"
It's wouldn't do to conclude the experiment by saying "We looked Here, Here, and Here. On These Frequencies useing some algotythms. Some data was check with this algorythem, Most of it with this one, and packets xxx through yyy we're not sure how they were checked but we're still prety sure we did[n't] recieve a signal. But we can't reproduce anything because we're not sure exactly what was going on"
I'm sorry but I have to disagree with you. Since the client is distribuited one can never be 100% sure that the results from one client are created by the same manner, even if the source is closed. Reverse engenering is possible and all one has to do is to figure out the exact protocol and packet format that the client uses (this could be hard, or not). Once this is done, one could create another client from the ground that could create valid or not packets.
Other cientists would not pay atention to results from clients on the internet. A result like that could only be accepted with results made with original data and with in-house computers. The seti@home just help to point out witch parts of the data the project manager should look at. This way even if a false packet is sended to seti@home they can be shure that a signal is real or not (analising their data, with their computer, and their software).
I don't know how much "damage" an open source client would make to the project it self, and I don't want to enter this "war". One thing is certain protocols can be hacked, and with closed source is usualy more easy to do it.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
In the case of SETI, there is a mismatch between the potential developers and users that is unique to a distributed system. The client user/developer wants a client that is faster, potentially at the expense of accuracy. The official SETI developers are not users primarily, but instead want to have great confidence in the client, potentially at the expence of speed.
This mismatch turns many of the benefits of open source on its head, from the perspective of the SETI developers, since their goals are different than the potential developer community. Note that the client user/developer would achieve his goals quite well if the client were open sourced, as per dogma.
Perhaps we need to tweak the dogma a bit to account for this bizarre bazaar. Instead of "open source is always better", try this on for size:
It does not necessarily make me happier with what you are running on your computer. If you are running a server I am happy that the server is open source because that means it has open interfaces. I'd be equally happy if you just opened your interfaces. If you are running my code for me in a distributed type of network, I want my goals to be preeminent in the code design. Open source only gaurantees this in the rare case that our goals completely coincide.
For open source to work reliably in a distributed network of users with varying goals, there has to be a central authority with approved clients for whom the cost of approving clients is less than the benefit of the potential innovation. In addition there must be a way to strongly authenticate that those clients have not been modified. Incidentally, an authentication method is what is really needed in a closed source case as well. I can't think of a foolproof method for doing this, the best bet is probably just random result comparison and some speed heuristics.
So the answer is that SETI could open source their client, and the people running it would benefit. But it might not be a benefit to them since the benefit of added speed (the most likely outcome) is not currently needed, and the potential for good faith bogus clients increases greatly. Bad faith bogus clients would likely stay at the same frequency.
--
"L'IT c'est moi!"
Having actually seen the code for seti@home,
I'd have to say that there are quite a few
ways this code could be cleaned up. I was able
to test a version using a much faster FFT from
a commercially available fft library that I had
my brother run. See his results!!!
"wahl@sgi.com" thats right _1:52_ baby!!
Now I understand that there is even a FASTER
version of an FFT out there as a public domain
algorithm. This would have saved even more
time.
da'fly
Hmm... I never looked at this SETI@Home thing before. So, I'm supposed to let some unexaminable program run lord-only-knows what while I'm not paying attention? No thanks. I won't even let Java in my browsers.
The current policies of SETI@Home are clearly wrongheaded; security-through-binary-obscurity is not the right way to protect the integrity of their project, and they're falling into the same close-minded trap the DVD Forum did. Obviously, they should open source the client (and the server!), but maintain an "official" binary distribution with an embedded signing key; their servers would only accept input from blessed binaries. (Yeah, it's possible to extract the key [though this can be made difficult]; you'd want to send a different key with each download, so you could easily revoke one. The point is that this policy would allow well-meaning contributors to play with the client source and submit optimizations for review.)
Furthermore, they'd get people making not only performance improvements, but bug fixes. Do they really think that by working alone they have better QC than if everyone could review the code?
That's not my point, though.
Normally, when the community at large is faced with someone taking a clearly broken licensing approach, we can react by making our own version free of encumbrance. Here, however, we're tied to SETI's data source -- few of us own large radio telescopes.
Is it possible to gain access to SETI's raw data feed? (Of course it is; they send data blocks to everyone for processing!) Is it possible to come up with our own code for analyzing that data and processing it elsewhere -- with or without the cooperation of the S@H administration? I don't think they'd be happy; but could they stop it? (Surely not without causing even more ill-will.)
...
Tangent: What if the ETs use ultra-wideband (UWB) techniques (see http://www.uwb.org/, http://www.time-domain.com/)? Won't FFT-based analysis totally miss such signals?
There are some side effects of open-sourcing the SETI client. As I understand things, the SETI client periodically transmits data to an outside machine. If SETI were open-sourced, it would be easier for rogue programmers to alter the source to send files (or whatever) to a programmer. Sure, we would all have the source. How many of us actually look at the source? Furthermore, a less than scrupulous programmer could publish source that didn't match the compiled binary.
I am somewhat concerned that the SETI project could be a front for the NSA and/or Echelon. How can the NSA keep up with analyzing all those voice lines they're monitoring? Why don't they just right a cute little screensaver that analyzes voice lines, and transmits the results back to home base? Hmmm. If that's the case, they really don't have anything to benefit from open-sourcing the code. It is this that prevents me from running SETI on my home machine...
--Be human.
Are you crazy? There would be too much chance of people doctoring data. Three guys get together, mess it up, and *BOOM* ET hoax. SETI would have to deal with possibly hundreds of hoaxes.
You want more speed? Double the heat setting on your oven, and cut the baking time by half. Watch what happens.
That's a great example, but it is also a straw man. That example works for cookies, but not necessarily for software. I agree that there might be a way to speed up the code at the cost of accuracy. But that is not what I am advocating. I'm advocating better written software--which will mostly likely be at least of of the following: more stable, more robust, faster. Better written, by definition, has to be at least one of those. And we already have a requirements for the project: no loss of accuracy. Fine. We work towards that goal. That's what software development and design review are all about. Open source just taps the resources of thousands for those tasks.
And just because they open source it doesn't mean they lose control. As these post evidence, many who do SETI are doing it for the right reasons. So if SETI realeses the code FreeBSD style--i.e. where they retain control of the "official" tree--then they gain all the benefits of opensourcing along with maintaining specific control of their research. The authentication problem could easily be solved by some public key system that is controlled by SETI. And before we start arguing about that, let's remember that they have already LOST that battle. So at this point, an open approach to how to improve the client would only help them.
Again, cookies are one thing. But software is another. I am sure you have worked on projects where someone wrote something accurate, but slow. Perhaps their memory management wasn't right, or they were using a slow method to get something done. The code worked. The code was accurate. But it could be improved and remain accurate just by having someone more experienced look at it.
And that is what I am advocating. Remember, that's the whole open source "thing". I think your confusing GPL, forking, and crab grass development techniques with a time honored scientific approach: peer review.
When it gets down to it, that is EXACTLY what open source is all about.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
I understand the merits of keeping the source to seti@home closed. It would be quite aweful if the project were invalidated by bogus results. However, I have a real problem in that the project maintainers seem to want their clients to run slowly. That's right! they seem to want to run inefficient code on your computer.
My chief example of this comes from some work that compaq has done on the client. They asked for the source to Seti@Home so they could get it to run on Alphas. the sent their version back to the maintainers and that is the alpha client that is being used now.
However, later they went back and tuned the client to run more efficiently. They linked the seti@home code against their Compaq Extended Math Library which contains a highly optimized FFT routine. The results are stunning. If you check out Compaq's stats, they have 21164 Alphas completing data blocks in under 3 hours. On my 21164 machine the best I've ever seen is 6. The speedup on the 21264 processor is even more dramatic. Check out their top users in the compaq team, they're flying through the data in under an hour per block!
Seti@Home has recieved that patch many months ago. (I found out about it from a compaq engineer on the now dwindling AlphaNT mailing list this summer) However the package maintainers have done nothing. This leads me to conclude that they either are technically incompetant and lack the skills to test this enhanced client (which I doubt because they are letting compaq use it) or simply want the clients to run slower.
So while I agree that open sourcing the client would be a very bad idea, I fail to see the logic behind refusing to distribute perfectly valid patches that could INCREASE the amount of science that seti@home does.
Having worked with the gcc compiler for many years I can say that math fluctuations are increadibly easy to introduce through optimization. Floating point operations, though rarely used in CS education, are rampant in the Seti code. The problem isn't in producing bad data but in differences in the output that most floating point optimizations produce. Floating point operations are much more prone to fluctuations due to optimization. The optimized seti clients are guaranteed to produce different results than the original clients.
Since they haven't been able to collect enough data by orders of magnitude to feed their clients, there's little use to optimized Seti clients outside of learning how the Seti client works.
I recently upgraded my OS from windows 95 to Linux. The windows 95 seti client pumped out work units in about 59 hours. The linux client cranks through units in about 22 hours. This is the same hardware! There is no way that windows introduces that much overhead compared to linux. The windows seti@home client must simply be *very* inefficient. I think this is the real reason "upgrade" patches are circulating. If the seti@home team would just release better-optimized clients, there would not be the incentive to install the rogue update patches. (Or people could just take this as a good reason to upgrade from windows to linux :^)
This is happening more and more often. The above was not a troll.
Instead of cross-checking a client's results with others, you can just send test units at random intervals. These test units would have bogus contents that indicate extraterrestrial signals.
Any client that returns the wrong results on a test packet is untrustworthy. All the work it's done can be re-sent to other clients, and it can be ignored in the future.
Well they can use a bit of redundancy to weed out erronous results. (both from patched clients, and simply the odd dud processor/cosmic-ray/whatever) And for the rest... they should the cycles be used on other projects. There is no good argument for waste, at least not unless its to keep the economy running smoothly :)
What if Seti used some sort of checking to verify data? Example:
Person A processes the data and checks the processed data into the server.
The data person A had is assigned to a (random) person B. If person B verifies what person A found, the data is accepted to be true.
If the data person B processed is different than the conclusion person A came to, the data is sent to person C and D for processing. C and D should verify what either A OR B got.
Of course, this could cause problems if abused, but it would allow for an open source client in that nobody can REALLY forge data because the data would be processed more than once. Of course, one may argue that this considerably slows down the effort .. but this is the best way to operate in a way that may lead to better efficiency.
But then again .. what do i know, and why are you reading this?
You're looking at it from the wrong angle. From the viewpoint of the overall project, yes, "we" are processing data faster than it can be created, and so, there is no reason to try to make the clients any faster. But from the _user's_ viewpoint, it's taking him hours to do one data block, it should be faster! Who cares if he has to wait a few days to get the next one so long as the one he's got finishes quickly? Once it's done, he can go do other things with his processor.
And making the client faster could benefit the project overall. Say by some miracle, the algorithm is tuned to be twice as fast. Horror of horrors, now we have to send out twice as much data, but we don't have it! So, send out the data you've already checked (and I don't mean like that bug early in the project). The more times a single block of data is checked, the more likely it hasn't been affected by a modified client or random errors.
But then again, I could be wrong.
NOT INVENTED HERE
Steve's Computer Service, Hobbs, NM
I would be interested to hear if there is a (theoretically) foolproof way to use distributed clients to produce results with confidence if you accept that some clients will be spoofed.
Send each packet out to three or more clients - those that return different results get suspended. Isn't good science about repeating the experiment and checking the results?
The world has changed and we all have become metal men.
Personally, I don't believe most people are running it that way. This one doesn't work like RC5, or the Mersienne Primes, where it can sit quietly in the background. Since the S@H client takes over so much of the machine, I believe most people only run it when they aren't using their computers. Thus, it's not a question of "doing other things with the computer". When the user is doing the other things, the client is basically shut down.
It's exactly the But from the _user's_ viewpoint, it's taking him hours to do one data block, it should be faster! viewpoint that leads to the race mentality and ultimately cheating to get higher in the rankings. The important thing is the science, not the race. I've got several machines running the S@H client, and I quit checking my rankings a long time ago.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
This is an impossible security quagmire. You can't give out software to be run on someone else's system (with or
without source code), and prevent them from modifying it.
The trick to better security may be to engage the help of those who might otherwise thwart it. Many of the people who
are cleverly optimizing SETI@Home would be good people to design sophisticated mechanisms to detect and prevent
program modifications.
The world will not get better through technology. We must seek to be better people.
It is probably not a good idea to make the SETI client open source. If it were made thus, people would be entirely free to make their own modifications to the client and do all sorts of nasty shit--in the name of their stats. By leaving it closed-source, the SETI@Home scientists can achieve at least a modicum of control over the types of clients that are used to connect to their networks. I mean give me a break. Open Source isn't the perfect solution for every piece of code on the planet!
This calculation is not some huge chain where if one part is broken they all are... they can (and will, probably hundreds of times and in with a hundred different methods) just check positive results themselves. The only real danger is a false negative.
That may be true on the Windows and the Mac clients. The Linux client runs happily backgrounded at a nice-level of 19 on my fiancee's dual PII-450 box. Even when she's busy running LaTeX or Nethack or WordPerfect. Running an RC5 client alongside would not be out of the picture at all, even though she has two SETI clients running (one for each CPU).
Greater optimization means that the SETI folks can do more analysis on the data they have and build more redundancy (and therefore more security) into the system. I don't understand why you would argue against faster clients when the problem is already infinite in scope.
--Joe--
Program Intellivision!
It seems to me that perhaps it would be better to just distribute a 'registration' client whose sole purpose is to give the user a unique digital ID and to download a (fingerprinted) latest release of the software or just the critical code each time the calculation was started, all subsequently packages could be signed with PGP or something. I imagine that this would hinder most attempts at tampering and would make it even safer to open source the code. Releasing binaries only, does give some form of lamer-protection, but as we have heard in this story and half a zillion other stories it offers no security at all. I am currently running setiathome at my box, and it would be very sad if the project got so f*** upped that the results of the investigations would have to be discarded as random lamer noise.
how can you people run software on your computers that retrieves & returns data w/o actually knowing what it is doing. i'm not bashing the project, it's a great idea. but what are these guys hiding by not opening the source. i'm a sys adm, & it makes me pretty nervous that all my developers are running that stuff w/o a 2nd thought.
What about the person who hacks the client, not realising he's broken something stopping potentially valid results from being sent back. Do we then check all negatives too? If so, why bother?
Yes, a few people who use S@H are "smarter than usual", the kind of backpatting people occasionally like to give themselves. I have a reasonably high IQ. I *don't* think I'm qualified to fiddle with algorithms people with PhD's in astrophysics have spent *years* on. "Thousands of eyes" don't help here.
Open Source. Closed Minds. We are Slashdot.
They dont have to open source everything, and even if they do clients could have to be blessed.
Somebody posted an old /. link to news about seti@home here... The Truth About SETI@Home I followed it's link and somehow visited www.3dnow.org. Upon viewing it's analysis, I deleted all traces of seti@home clients immediately. Why?
SETI isn't getting enough data. As so many data cruncher are finishing blocks more and more quickly, SETI simply want others to process more slowly... denying Intel's optimized build, and denying support of 3dnow (without giving reason!). So I think they want users to waste more cpu cycles without their knowledge. I'm so furious I stopped it immediately.
Hear, hear. Distributed.net's client is a fancy lottery machine. Yes, I admire the software engineering that went into it. The client can even work in 3 contests with cash prizes! But it appears that the OGR-enabled client has languished for lack of financial incentive. I for one have moved my mips to mersenne.org; the prize money is much greater, and the project has lasting scientific value with verifiable results. A fun part is that you can lower someone else's Lucas-Lehmer score by factoring one of their LL results (if you decide not to chase the prizes). That's still more fun than flying toasters.
[project scientist Eric] "Korpella says the project will not release its source code, and the program is being rewritten to make it harder to alter."
Now, all the arguments about needing consistent results, and not being able to generate units fast enough to keep up (but then why can't they optimize the splitters on the server, too??) and what could be characterized as a mistake by the project's race-horse results postings goes out the window with this statement. Project programmers are *actively* working against the people the need to help them. The lingering doubts I had about running the client on my systems have been iced -- I won't run it any more.
Because the problem, as defined by the Seti@Home team, is not infinite in scope. In fact, it's very finite. The are only generating about 30 gig of raw data per day, and the analysis capacity in place is way more than sufficient to analyze all that data.
Now, you might say "expand the project". That's a good idea, but it takes money and people that are not available. The S@H guys are running this thing on a relative shoestring. If you are going to tackle an infinite project, you have to throw infinite resources at it, and that's simply not available. They are doing what they can with what they have.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Te obligatory this isn't news reply:
SETI said the same thing about releasing the source to the 3Dnow team and they certainly aren't going to release it to the public now.
Personaly, I think its a major waste of computing power when other projects like GIMPS have 30,000 members while SETI is pushing half a MILLION.
The Spielbergesque lure of meeting ET keeps morons happy with their number crunching competitions while real science like GIMPS is mostly ignored.
Now the number crunching competition has gotten to the point where people with a lot of time to kill have written patches to have the fastest team on the net.
Its the geek equivilent of drag racing. SETI open source advocates should admit they're in a bloated project, swallow their BS techie pride and crunch slowly away for science or go do something else to show off.
Hehe. You weren't expecting common sense, were you? ;)
/. is to use the proper part of your brain..The stem!
The trick to understanding
Since SETI@Home can't process the amount of data being processed now, increasing it doesn't make it better.
(They refused AMD's offer of help to speed the client up, doing more work, as carefully as before, in less time.)
And AMD wanted to do this why?
1. Because the BODs, President, and CEO of AMD are all UFO buffs who wanted to help the search?
or
2. AMD wanted a misleading Benchmark to quote in their advertising to make their processors look good?
Everyone who answered 1, take the tin foil off your head and experience reality...
"Grab them by the pussy" -- President of the United States of America
The issue here is not speed at all -- it's the science. (As has been said many times.) For the experiment to be controlled, everything must be known about the processing. Even if changes that people make don't actually affect the result, in general, it is impossible to have a standardized experiment without absolute control over the analysis programs. And a standardized experiment is very necessary. For example, if an error is found in their code, they should be able to tell what specific blocks have been affected, and if there are half a million different copies of the code lying around, who knows?
This isn't distributed.net, where you can run a "check" to validate the client, and where the entire keyspace is known. This is also not the Linux kernel, where "This is known not to compile absolutely correctly on gcc 9.25.x" is acceptible. All parameters must be constrained as much as possible.
We are still trying to determine if there is any intelligent life on earth ;-)
Who cares why?
It's like, if they were willing to make Quake twice as fast on your computer with only a software patch, would you look the at the gift horses tonsils?
But with any experiment, you must be sure that ALL conditions are the same everytime it is repeated, to be sure the results are as accurate as possible.
"Oh, the reason you couldn't reproduce my experiment is that your conditions weren't the same. Jupiter was in Taurus when you did it."
Science isn't about making ALL conditions the same. Science is about deciding what conditions are important, and making them the same. (In that regard, your comments are very scientific: you've decided what's unimportant and actually completely forgotten about it.) So one of you is arguing "implementation is unimportant, algorithm is what matters", and the other one is arguing "who writes the implementation really is important, because there's a finite chance they'll screw it up, by mistake or on purpose". Guess what: you're both right.
So find a solution that solves both problems. Here's a hint: it's going to involve social engineering. The scientists and the hackers are going to have to actually listen to each other if they want to reach a good accomodation. It's not just a matter of the hackers shutting up and doing what they're told.
Preferential Voting: easy as 1-2-3