Adam Beberg (duncan) wrote: it has become apparent that the goals of DCTI have changed considerably over the years, and are no longer the same as what they were.
David McNett (nugget) wrote: It has also become clear to us that Adam's goals for Cosm and distributed.net's vision of its future differ enough to justify this parting of ways. Adam is very motivated about seeing the system he's designed, Cosm, implemented and put into production. True to its name, distributed.net is more focused on seeing what can result from a truly open and distributed continuing development effort. While each of these respective approaches is viable in its own right, attempting to co-mingle them has proven to be counterproductive.
What's the division about? It's clear from these carefully worded pieces that they've decided to split, and they've put an amiable face on it. However, the announcements are so vague I can't tell what the real issues are.
One of the problems I've always had with the d.net project was their closed decision-making style. On the one hand, they've build this wonderful thing for running the DES/rc contests, and made it fun to participate. I think that's really nifty. On the other hand, they've been advertising 'v3' for a over a year now, with its plug-in architecture promising a wide variety of clients to choose from, and an open interface so one may write one's own. But it never arrived, partly, it seemed, because Beberg wouldn't let anyone else work on it. Sometimes I felt like they didn't want to allow any other clients because they'd lose people from the rc effort, which is what they're really interested it. I think this might not be such a problem given rc5's microscopic bandwidth, footprint, and tolerance for latency compared to alot of other distributed computing projects If you think seti@home is bad, try cg rendering, or scientific simulations! Even the Mersenne prime client is more efficient with a large (>~16MB) memory allocation.
Nugget speaks of "a truly open and distributed continuing development effort." Their hot new client is the OGR project, and still closed source. Beberg is at least publishing a programming interface, but hasn't specified a license yet.
I've always been bothered by d.net's interest in using my processor for their particular project, paying only lip service to giving (control) back to the community they created. I've always been bothered by their failure to grok open source development.
I guess what all this boils down to is that I'd like to think that either Beberg or others at d.net have seen some light in this vein, but I can't tell which of them it might be. Comments?
cat > /dev/audio only works with raw data
on
SETI@Home For Linux
·
· Score: 1
/dev/audio isn't very smart about file formats--it's just a dumb device, so you pretty much have to give it raw audio data.
look at the work_unit.txt file. It's got a header, followed by some printable-coded binary data. One has to figure out how they've does the character encoding.
my guess is some sort of hacked uuencode. The faq says the portion out 0.25MB data blocks, and my work_unit.txt is 320K--about the right ratio for uuencodes 3->4 byte expasion.
Then, it's unlikely to be in 16-bit stereo, so one has to figure out what kind of samples they used. Probably single channel but 8-bit, 16-bit, what? Or, goddess help us, some kind of float--scientists seem fond of that datatype, despite the portability problems.
I responded to the initial call for developers back in july. I fact, I think I saw the announcement here, but looks like Rob's deselected that article.:(
Anyway, they did answer their emails in my experience, but it quickly became apparent they weren't interested in an Open Source development approach, so I told them I wasn't interested in contributing.
Mostly they cited fears of data-subversion by hacked clients. As has been mentioned in other comments, there are ways around this, and in the long run I think they're worth the extra effort. Security through obscurity only keeps the honest people out.
I think they still don't understand the benifits of open development. In my original contact with them, it didn't feel like a rational decision, and I've seen little evidence they've improved in this respect. This was something that always bugged me about d.net, too--they wanted my cpu, not my involvement.
Sad, since I'm sure it would have been finished sooner. The basic engine seemed to be complete at the time. I think server funding was part of what held them up, but still.
This is a serious advantage rc5 has over most of the other distributed computing projects--it's got a microscopic memory footprint.
d.net's only looking at 64bits at a time.
ok, that's facetious, but they're trying to decrypt a one-line message. Seti@Home is trying to analyse radio signals, and the unit of work is significantly bigger--350K on my machine. It's constantly doing fourier transforms of that and searching for peaks and trends. I don't think you could do that efficiently is much less memory.
So yes, until everybody's got 128MB of RAM, this will limit participation.
You could try the GIMPS project ( www.mersenne.org). It's not as sexy perhaps, but still new territory. My client weighs in at 1.6 MB.
Haven't actually checked that we can play this, but I've put up a mirror of the above motion jpeg for when it goes down.:) I'd try mtv if xanim doesn't work.
Slashdot Mirror
Adam Beberg (duncan) wrote:
it has become apparent that the goals of DCTI have changed considerably over the years, and are no longer the same as what they were.
David McNett (nugget) wrote:
It has also become clear to us that Adam's goals for Cosm and distributed.net's vision of its future differ enough to justify this parting of ways. Adam is very motivated about seeing the system he's designed, Cosm, implemented and put into production. True to its name, distributed.net is more focused on seeing what can result from a truly open and distributed continuing development effort. While each of these respective approaches is viable in its own right, attempting to co-mingle them has proven to be counterproductive.
What's the division about? It's clear from these carefully worded pieces that they've decided to split, and they've put an amiable face on it. However, the announcements are so vague I can't tell what the real issues are.
One of the problems I've always had with the d.net project was their closed decision-making style. On the one hand, they've build this wonderful thing for running the DES/rc contests, and made it fun to participate. I think that's really nifty. On the other hand, they've been advertising 'v3' for a over a year now, with its plug-in architecture promising a wide variety of clients to choose from, and an open interface so one may write one's own. But it never arrived, partly, it seemed, because Beberg wouldn't let anyone else work on it. Sometimes I felt like they didn't want to allow any other clients because they'd lose people from the rc effort, which is what they're really interested it. I think this might not be such a problem given rc5's microscopic bandwidth, footprint, and tolerance for latency compared to alot of other distributed computing projects If you think seti@home is bad, try cg rendering, or scientific simulations! Even the Mersenne prime client is more efficient with a large (>~16MB) memory allocation.
Nugget speaks of "a truly open and distributed continuing development effort." Their hot new client is the OGR project, and still closed source. Beberg is at least publishing a programming interface, but hasn't specified a license yet.
I've always been bothered by d.net's interest in using my processor for their particular project, paying only lip service to giving (control) back to the community they created. I've always been bothered by their failure to grok open source development.
I guess what all this boils down to is that I'd like to think that either Beberg or others at d.net have seen some light in this vein, but I can't tell which of them it might be. Comments?
raj.phys.sfu.ca/~giles/lego-probe/
only partial at the moment, but more going up as it comes across. poor thing.
Now if you'd said it was a lego scanning probe microscope, I would have been there alot sooner!
/dev/audio isn't very smart about file formats--it's just a dumb device, so you pretty much have to give it raw audio data.
look at the work_unit.txt file. It's got a header, followed by some printable-coded binary data. One has to figure out how they've does the character encoding.
my guess is some sort of hacked uuencode. The faq says the portion out 0.25MB data blocks, and my work_unit.txt is 320K--about the right ratio for uuencodes 3->4 byte expasion.
Then, it's unlikely to be in 16-bit stereo, so one has to figure out what kind of samples they used. Probably single channel but 8-bit, 16-bit, what? Or, goddess help us, some kind of float--scientists seem fond of that datatype, despite the portability problems.
Fabulous idea--too bad the data's encoded.
Looks sort of like uuencoding, but I've not managed to parse it yet. Any ideas?
I responded to the initial call for developers back in july. I fact, I think I saw the announcement here, but looks like Rob's deselected that article. :(
Anyway, they did answer their emails in my experience, but it quickly became apparent they weren't interested in an Open Source development approach, so I told them I wasn't interested in contributing.
Mostly they cited fears of data-subversion by hacked clients. As has been mentioned in other comments, there are ways around this, and in the long run I think they're worth the extra effort. Security through obscurity only keeps the honest people out.
I think they still don't understand the benifits of open development. In my original contact with them, it didn't feel like a rational decision, and I've seen little evidence they've improved in this respect.
This was something that always bugged me about d.net, too--they wanted my cpu, not my involvement.
Sad, since I'm sure it would have been finished sooner. The basic engine seemed to be complete at the time. I think server funding was part of what held them up, but still.
This is a serious advantage rc5 has over most of the other distributed computing projects--it's got a microscopic memory footprint.
d.net's only looking at 64bits at a time.
ok, that's facetious, but they're trying to decrypt a one-line message. Seti@Home is trying to analyse radio signals, and the unit of work is significantly bigger--350K on my machine. It's constantly doing fourier transforms of that and searching for peaks and trends. I don't think you could do that efficiently is much less memory.
So yes, until everybody's got 128MB of RAM, this will limit participation.
You could try the GIMPS project ( www.mersenne.org). It's not as sexy perhaps, but still new territory. My client weighs in at 1.6 MB.
Thanks!
Haven't actually checked that we can play this, but I've put up a mirror of the above motion jpeg for when it goes down. :) I'd try mtv if xanim doesn't work.
http://rain.ashlu.bc.ca/~giles/starwars/
Now, anybody want to do a real mpg conversion?
FWIW, here's the md5sum on the version I just pulled from ftp.aq.kernel.org:
:)
# md5sum linux-2.2.0.tar.bz2
f03f54fcb774751f68f13df80af91256 linux-2.2.0.tar.bz2
Mind you, I haven't verified the signature, but if you got it somewhere else and compared, we'd be doing better than nothing.