Slashdot Mirror

come out with a CSC client which is 250% faster than distributed (on x86, at least).

Yes, that's 2.5 times as fast.

had stats which (gasp!) don't break or have new bugs in them every couple days and (gasp!) don't have a 2 hour scheduled downtime to update every night and even (gasp!) update in real time, almost like real databases do!

started the Gamma Flux project which, while not personally my cup of tea, is certainly the first distributed computing project which is actually useful (it helps calculate ideal containment solutions for nuclear waste).

promised to pass on the entire share of the CSC winnings to the person who wins, as opposed to distributed.net's 20% (10% if you join a team).

But what finally pissed me off the most was reading this post earlier in this thread from Decibel at distributed.net, in response to an admittedly pretty hostile post from Armin Lenz at dcypher.net, in which he has the gall to imply that dcypher shouldn't have done CSC at all because distributed had "announced" that they intended to work on it soon after the contest was announced, way back in May. Of course, Decibel doesn't mention the fact that they didn't launch the project until November 17, 2 weeks *after* dcypher.net, and only then with a broken client (yes, a brute force program that's 2.5 times slower than it should be is certainly broken), and that they haven't even *released* a finished client for the Mac!

And furthermore, he doesn't even understand that making the argument that "we announced first" isn't likely to garner too much respect at /. Guess what, Decibel--there's a word for preannouncing programs months before you plan to release them so as to scare off any potential competitors. It's called "FUD", and it's a particularly disgusting kind; in fact, even Microsoft's backed off a bit from that sort of thing lately.

And despite all that, he still says "we did CSC because it was relatively easy to add". Well I'd hate to see how badly they can screw up a project that's a little "hard".

I'm hoping I won't get the chance with OGR. Despite everything, I think OGR is a pretty cool project, and I just might be persuaded to stick with distributed.net if they (finally) come out with their OGR client, and it works, and isn't orders of magnitude slower than competing clients, and they fix their stats and get their act together. I suppose in the end I was always a sucker for the moo.

But distributed has a lot of lost trust to earn back.

distributed.net announcements don't kill other projects. It's too bad that the existing OGR project decided to pack their bags... but laying blame on someone else?

I'd think slashdotters are used to holding strong to an underdog. Like someone's just going to quit working on some app for Linux just because some other company announces they are going to make it for Windows?

You get the anology.

Secondly, distributed.net supports distributed computing efforts as a whole, not just their own. See their Mission Statement where they say "...we will advocate distributed computing..." implying as a whole, not just themselves. Their mission is to do things "...in the advancement of distributed computing..." not just distributed.net.

Thirdly, distributed.net even credits the Origional Effort on their OGR Page... and in no way told the origional effort to stop what they were doing.

-Saxton


_________

distributed.net announcements don't kill other projects. It's too bad that the existing OGR project decided to pack their bags... but laying blame on someone else?

I'd think slashdotters are used to holding strong to an underdog. Like someone's just going to quit working on some app for Linux just because some other company announces they are going to make it for Windows?

You get the anology.

Secondly, distributed.net supports distributed computing efforts as a whole, not just their own. See their Mission Statement where they say "...we will advocate distributed computing..." implying as a whole, not just themselves. Their mission is to do things "...in the advancement of distributed computing..." not just distributed.net.

Thirdly, distributed.net even credits the Origional Effort on their OGR Page... and in no way told the origional effort to stop what they were doing.

-Saxton


_________

To take your comments one at a time...

because it was supposed to add stability and scalability that was not available in the NT/SQL config they had before.

Statsbox II is more stable and scalable than Statsbox I. sbI was having more and more hardware issues. It was also a single Pentium 166 that was OC'd to 200MHz. sbII is currently a dual PII-300, and the motherboard should support any Slot 1 CPU. This mobo will also support up to 1G of RAM and currently has 1/2G installed. sbI was maxed out with 256M, iirc.

Well, it's no faster. Crashes and corrupts just as often,

Based on what measure? The RC5 statsrun dropped from over 6 hours with stats turned off to under 4 hours with stats left on. Even with the ever increasing RC5 statsrun time (it will keep getting longer until the project is done) and CSC stats, we're still finishing stats in less time than on sbI, and we're leaving HTTP access enabled durring the run.

We've also had far less unexpected downtime with this setup than with sbI. In fact, I can't think of any hardware issues that have affected sbII. The current problem was caused by human error, read my .plan for more info.

they have failed misserably at putting the functionality back into the stats pages.

This is the only argument yake that holds any weight, as far as I can see, but I'd like to know what is missing other than all of the CPU/OS info that the old site had? Also please note that there is CPU/OS info available for CSC (see here and here).

Since I do d.net more 'cause stats are cool than any other reason, it kinda pisses me off...

You're certainly not the only participant who is a stats-junkie (I'm one myself). We do try and take stats very seriously, but unfortunately, there's only so much time in our days. Nugget, Bruce, and I are working on our next version of stats, which will be far more robust (and hopefully will include cross-project stats). Sometime in the future, we will also be looking to bring some more PHP and SQL folks on-board.

I hope you can undertand how discouraging a post that is full of misinformation can be to those of us who are working to improve stats.

To take your comments one at a time...

because it was supposed to add stability and scalability that was not available in the NT/SQL config they had before.

Statsbox II is more stable and scalable than Statsbox I. sbI was having more and more hardware issues. It was also a single Pentium 166 that was OC'd to 200MHz. sbII is currently a dual PII-300, and the motherboard should support any Slot 1 CPU. This mobo will also support up to 1G of RAM and currently has 1/2G installed. sbI was maxed out with 256M, iirc.

Well, it's no faster. Crashes and corrupts just as often,

Based on what measure? The RC5 statsrun dropped from over 6 hours with stats turned off to under 4 hours with stats left on. Even with the ever increasing RC5 statsrun time (it will keep getting longer until the project is done) and CSC stats, we're still finishing stats in less time than on sbI, and we're leaving HTTP access enabled durring the run.

We've also had far less unexpected downtime with this setup than with sbI. In fact, I can't think of any hardware issues that have affected sbII. The current problem was caused by human error, read my .plan for more info.

they have failed misserably at putting the functionality back into the stats pages.

This is the only argument yake that holds any weight, as far as I can see, but I'd like to know what is missing other than all of the CPU/OS info that the old site had? Also please note that there is CPU/OS info available for CSC (see here and here).

Since I do d.net more 'cause stats are cool than any other reason, it kinda pisses me off...

You're certainly not the only participant who is a stats-junkie (I'm one myself). We do try and take stats very seriously, but unfortunately, there's only so much time in our days. Nugget, Bruce, and I are working on our next version of stats, which will be far more robust (and hopefully will include cross-project stats). Sometime in the future, we will also be looking to bring some more PHP and SQL folks on-board.

I hope you can undertand how discouraging a post that is full of misinformation can be to those of us who are working to improve stats.

To take your comments one at a time...

because it was supposed to add stability and scalability that was not available in the NT/SQL config they had before.

Statsbox II is more stable and scalable than Statsbox I. sbI was having more and more hardware issues. It was also a single Pentium 166 that was OC'd to 200MHz. sbII is currently a dual PII-300, and the motherboard should support any Slot 1 CPU. This mobo will also support up to 1G of RAM and currently has 1/2G installed. sbI was maxed out with 256M, iirc.

Well, it's no faster. Crashes and corrupts just as often,

Based on what measure? The RC5 statsrun dropped from over 6 hours with stats turned off to under 4 hours with stats left on. Even with the ever increasing RC5 statsrun time (it will keep getting longer until the project is done) and CSC stats, we're still finishing stats in less time than on sbI, and we're leaving HTTP access enabled durring the run.

We've also had far less unexpected downtime with this setup than with sbI. In fact, I can't think of any hardware issues that have affected sbII. The current problem was caused by human error, read my .plan for more info.

they have failed misserably at putting the functionality back into the stats pages.

This is the only argument yake that holds any weight, as far as I can see, but I'd like to know what is missing other than all of the CPU/OS info that the old site had? Also please note that there is CPU/OS info available for CSC (see here and here).

Since I do d.net more 'cause stats are cool than any other reason, it kinda pisses me off...

You're certainly not the only participant who is a stats-junkie (I'm one myself). We do try and take stats very seriously, but unfortunately, there's only so much time in our days. Nugget, Bruce, and I are working on our next version of stats, which will be far more robust (and hopefully will include cross-project stats). Sometime in the future, we will also be looking to bring some more PHP and SQL folks on-board.

I hope you can undertand how discouraging a post that is full of misinformation can be to those of us who are working to improve stats.

Our true purpose is to promote wide-area distributed computing... encryption contests just happen to be the vehicle we've used to do that so far. OGR will be the first contest that breaks that mold.

For those who are interested, I would suggest taking a peek at our mission statement.

Not quite, if you go to http://stats.distributed.net/csc/os.html, you will see that while windows is indeed first, linux is #2, with the Mac at #5. But this is just the CSC contest--and csc cores have only really come out rather recently for the Mac (I think), so the numbers may be skewed. But the fact that the Mac is on there at all doesn't lend too much credence to that argument, especially given the margin between them.

Now if only they would run the Platform/OS analysis for RC5... :-)

distributed.net has an Optimal Goulomb Ruler (OGR) project. It hasn't started yet, and there are no prizes, but the results of this project could actually be useful. See this page for an introduction ("Golomb rulers refer to a spacing technique that is used in a variety of areas such as astronomy (placement of antennas), xray sensing devices (placement of sensors), and myriad other fields such as data encryption.").

Distributed net has a new project in the works, OGR

can be found at:
distributed.net OGR todo list

and some good information can be found at:
distributed.net Project OGR

Tournesol

Distributed net has a new project in the works, OGR

can be found at:
distributed.net OGR todo list

and some good information can be found at:
distributed.net Project OGR

Tournesol

I'm sure a few of the readers on Slashdot have heard of a wacky little experiment called Distributed.net?

Nipok Nek

Yes, once the processor hits the HALT instruction, the gates stop transistioning between the on and off states, where the power is consumed. When these logic gates stop, they just act like capacitors and sit with its charge. When the keyboard, timer, etc., or other interrupt is activated, the processor starts executing instructions until the end of the interrupt routine and executes another HALT at the end.

My laptop consumes 33 watts at full throttle, but consumes about 12 watts throttling the HALT instruction due to other electronics. You can watch how much your laptop consumes by splicing an ammeter and voltmeter from the power supply. Power in watts is voltage multiplied by current.

If you have the wattage, you can express this as kilowatt hours and calculate the cost of running your laptop each month for nonstop use. Its usually 8 cents per kilowatt hour or 2 cents for the industrial rates. Running my laptop while chewing on CSC keys in the background cost me $1.90 a month.

Moore's law is that computing power doubles every eighteen months. At the same time, parallel processing and distributed computation ( Cosm & Distributed.net) are becoming increasingly common. This leads to an abundance of cheap computing power, enabling brute force attacks on secure systems. In light of these developments, do you see username/password pairs being replaced by anything more resistant to such brute computing force?

He might be poking fun at the popular and heavily marketed software coming from the USA. Russia may have a different computer culture than the consumers here in the states. Look at what they are doing to the CSC effort lately.

Funny guy, but there are those who might not have a sense of humor and take him most seriously.

I saw somewhere a few months ago (don't you love it when people really back up their information like that?) that the growth of the web vs. the available indexing technology meant that only about 4% of the web was being indexed. Goodness, that's a surprisingly low number, isn't it? I've heard it mentioned, and have often mulled over the idea myself, that some sort of distributed indexing is probably the next logical step. With the apparent successes of distributed.net and SETI@home, this is at the very least intriguing. So let's just say, for the sake of discussion, that I had some time on my hands and the motivation to see a monster search database project through (these are both very hypothetical points). I could create the central database and write some client code. My dedicated AOV (Army of Volunteers) could come in veritable droves to download the client code and join the team (which they certainly would, right? Right?!?!?) Anyway, their client would initialize and get one of the starting URLs from the root database and go to down indexing and spidering. Shouldn't be too much of a bandwidth hog, since it will be just text, but it would be constant. Maybe not a good idea to do this with an analog modem. When the client has "eaten it's fill", or once a day, or something like that, it would slam it's content my way.... ah, there's a potential problem. That's a lot of content. Well, it's all text, so my client could maybe get some decent compression out of it by gzipping it up. Still, it wouldn't exactly be trivial. Thinking on about this, why will it help me to have my AOV doing these HTTP transactions for me when my server could do them it's own damn self. Surely my server would have a big enough pipe that the bandwidth wouldn't be a problem, and I could start any number of processes. What's the big difference between web indexing sites like distributed.net and SETI@home? Ah, it's processing power. That's what's required for the "traditional" distributed application. That kind of number crunching isn't helped by bandwidth... you need such a honkin' processor to do all that chewing that it's not cost-effective to create the system... it makes a whole lot more sense to distribute the work to any number of "normal" machines, thereby simulating a "super computer". That's right... it's all coming back to me now. So, what would be helped by distributing the web indexing process? And wouldn't the smart fellas at Google or AltaVista or have thought this through by now and come out with some sort of beta? Hmmmmmmmmmmm...... What? You actually read this whole thing? Sheesh. That's impressive. Oh well, might as well moderate me up :) RP

Yes sorry, that wasn't the reason. I should have checked before posting. This is the reason.
An extract:

Databases, by definition, mean dealing with huge amounts of data. They also often contain very small computational requirements (although this is not always the case). This means that the bottleneck for database operations usually isn't CPU horsepower, but disk bandwidth. This means that distributed.net would be ill suited to help.

The distributed.net network is currently crunching keys 8 times faster than dcypher.

That's because the distributed.net network currently has over 15 times as many computers working on it than dcypher.net. (Compare here and here; I compared the number of clients which reported in the last day, since I figure that's the most relevent number to compare to current keyrate.) Furthmore, I'd guess that since dcypher.net is so new, distributed has an even higher proportion of the big-iron/large subnets working for it.

I waited, patiently, for over 6 months for distributed to come out with a new project--and when they release OGR, I'll probably come back. But after seeing my dismal keyrate running their CSC core, I decided to give dcypher.net a try.

On my machine (PII-350), the dcypher.net client is roughly 250% faster than distributed's CSC core. It's CSC keyrate is even about 10% faster than my rc-5 keyrate was with distributed.

Furthermore, their stats engine updates in real time, instead of distributed's absurd daily updates during which stats are completely down for an hour and a half. While both web sites are pretty poorly designed, distributed.net has been at times nearly unnavigable (this is getting a bit better).

But the important thing is, dcypher has accomplished all this and they've been around for a month! I can't imagine how you guys can complain about the fact that it took dcypher an extra 3 weeks to come out with a Linux client when it's taken distributed, a much larger organization with presumably much larger resources, months and months to build any clients at all for CSC or OGR (and the one they came up with is infernally slow).

At the time of this writing, d.net is the only network which seems to be able to solve this contest in time (remember that CSC is time-limited, any solution found after March 17, 2000 is void).

Obviously, that's just because 15 times as many people are going with the much more poorly coded, less efficient solution. It's more than a bit ironic to find people on /. advocating the use of a particular program even though it's demonstrably substandard, just because a majority of the ignorant masses are using it.

What's worse is that distributed takes the position that since they have so many loyal lemmings, they can release an unoptimized core and it won't matter because enough people will still run it. It's that arrogant attitude that turned me (and, I'd guess, many others) off of SETI@home.

Oh well; to each his own. Happy cracking!

There's a link right on the front page:

http://24.141.28.12/cscstats/speed.html

So DCypher clients are approximately 2x faster. The figures (which you can of course verify) are actually a bit on the low side, with the MMX core my K6-200 gets around 280 kkeys/s (compared to the 218 kkeys/s listed).

The way I see it, thanks to distributed.net's greater total horsepower the contest will be finished on time, so that's no reason to select them. With DCypher I get more money (and yes, should I win I will donate some to a charity of my own choosing -- right now d.net's top charity is d.net itself!) and, thanks to faster clients, my computing power is maximized.

Cheers,
-j.

Distributed.net and dcypher both try to solve the CSC contest.

The distributed.net network is currently crunching keys 8 times faster than dcypher.

At the time of this writing, d.net is the only network which seems to be able to solve this contest in time (remember that CSC is time-limited, any solution found after March 17, 2000 is void)

D.net source code is available to anyone who wants to improve or just review it : http://www.distributed.net/source/

Right now, d.net have clients for :
- Linux x86
- Linux Alpha
- Linux Sparc
- FreeBSD x86
- NetBSD Alpha
- DOS
- Netware
- Win16
- Win32 x86
- Win32 Alpha
- HPUX 10.20 (HP-PA 1.1)
- IRIX 5
- Solaris Sparc

Distributed.net and dcypher both try to solve the CSC contest.

The distributed.net network is currently crunching keys 8 times faster than dcypher.

At the time of this writing, d.net is the only network which seems to be able to solve this contest in time (remember that CSC is time-limited, any solution found after March 17, 2000 is void)

D.net source code is available to anyone who wants to improve or just review it : http://www.distributed.net/source/

Right now, d.net have clients for :
- Linux x86
- Linux Alpha
- Linux Sparc
- FreeBSD x86
- NetBSD Alpha
- DOS
- Netware
- Win16
- Win32 x86
- Win32 Alpha
- HPUX 10.20 (HP-PA 1.1)
- IRIX 5
- Solaris Sparc

You have to check out Adam Beberg's Cosm.
It was going to be distributed.net's v3 client until "Cosm" split from dn in April. I still don't have a clue why that happened but would love to see Adam's project succeed and replace S@H, d.n, etc.

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.

You're right. Distributed.net had that exact problem. They found a way to fix it. The client is STILL open-source. See? Simple, huh?

Check out http://www.distributed.net/source/...

Not entirely open source, they left out the part you would need to report results back. But that's the part we really don't care about. Everyone wants the algorithms optimized. I just think the SETI@home people should get a clue.

---

DeepCrack can process DES information in a few days, but they spent months designing it to be fast. It takes a matter of seconds to transfer a block and then hours to process them. The hour long process is the one I'd work on optimizing.

Yes, DCTI is "slow", but no one is getting paid to do anything, so unless you've donated something, I'd say everyone is getting what they paid for *grin*

OGR? I'm the one who did the very first work on OGR -- taking garsp32(?) and breaking it down into something that could be stoped and restarted. OGR doesn't have any discrete "blocks", so it's taken a long time (over a year) to get it working. Granted, this is no small task, but how much grief did people give Duncan over "v3"? People don't care about how complicated things are; they just want results. ("v3" became Cosm and is coming along nicely.)

"normal day-to-day operational work"? Would you outline some of this work? Maybe things have changed dramatically in the past 8 months, but I don't remember any consuming "operational work." I hosted a full proxy -- hell, it was the keymaster for a week or two -- and it took very little overhead from me or dbaker. The ever present stats problems are the only thing that I would say qualifies, but only a handful of people manage(d) stats -- and nugget ignored the work I did on speeding up stats. The most consuming "work" was babeling in #dcti :-)

Note: I'm not bitter. Despite all of my contributions to the effort (beyond cracking keys), the only mention of my existance is in the ledger as having donated a motherboard and two NICs -- one NIC burned out and DCTI never used the brand-new motherboard (that I know of.)

DeepCrack can process DES information in a few days, but they spent months designing it to be fast. It takes a matter of seconds to transfer a block and then hours to process them. The hour long process is the one I'd work on optimizing.

Yes, DCTI is "slow", but no one is getting paid to do anything, so unless you've donated something, I'd say everyone is getting what they paid for *grin*

OGR? I'm the one who did the very first work on OGR -- taking garsp32(?) and breaking it down into something that could be stoped and restarted. OGR doesn't have any discrete "blocks", so it's taken a long time (over a year) to get it working. Granted, this is no small task, but how much grief did people give Duncan over "v3"? People don't care about how complicated things are; they just want results. ("v3" became Cosm and is coming along nicely.)

"normal day-to-day operational work"? Would you outline some of this work? Maybe things have changed dramatically in the past 8 months, but I don't remember any consuming "operational work." I hosted a full proxy -- hell, it was the keymaster for a week or two -- and it took very little overhead from me or dbaker. The ever present stats problems are the only thing that I would say qualifies, but only a handful of people manage(d) stats -- and nugget ignored the work I did on speeding up stats. The most consuming "work" was babeling in #dcti :-)

Note: I'm not bitter. Despite all of my contributions to the effort (beyond cracking keys), the only mention of my existance is in the ledger as having donated a motherboard and two NICs -- one NIC burned out and DCTI never used the brand-new motherboard (that I know of.)

DeepCrack can process DES information in a few days, but they spent months designing it to be fast. It takes a matter of seconds to transfer a block and then hours to process them. The hour long process is the one I'd work on optimizing.

Yes, DCTI is "slow", but no one is getting paid to do anything, so unless you've donated something, I'd say everyone is getting what they paid for *grin*

OGR? I'm the one who did the very first work on OGR -- taking garsp32(?) and breaking it down into something that could be stoped and restarted. OGR doesn't have any discrete "blocks", so it's taken a long time (over a year) to get it working. Granted, this is no small task, but how much grief did people give Duncan over "v3"? People don't care about how complicated things are; they just want results. ("v3" became Cosm and is coming along nicely.)

"normal day-to-day operational work"? Would you outline some of this work? Maybe things have changed dramatically in the past 8 months, but I don't remember any consuming "operational work." I hosted a full proxy -- hell, it was the keymaster for a week or two -- and it took very little overhead from me or dbaker. The ever present stats problems are the only thing that I would say qualifies, but only a handful of people manage(d) stats -- and nugget ignored the work I did on speeding up stats. The most consuming "work" was babeling in #dcti :-)

Note: I'm not bitter. Despite all of my contributions to the effort (beyond cracking keys), the only mention of my existance is in the ledger as having donated a motherboard and two NICs -- one NIC burned out and DCTI never used the brand-new motherboard (that I know of.)

> I've lost track of the number of nights I've pondered porting the RC5 client to Mac OS X, or AltiVec

-sigh-

http://www.distributed.net/source/

Download it, and "putz" with it when you have 5 minutes.

The strange thing is, this is my second post on this and Daa and dbaker have also pointed this out. Some wanker even pasted parts of that page here.

How long do we have to hear "I would port it, but those d.net people wont release the cores!"

The only thing we don't release is the buffer and networkprotocol, for reasons stated in this post.

This isn't cast in stone, but we would most likely convert it to US$, since there would most likely be a 10kEuro check made out to us, and then we would split the prize 60/20/10/10 to the charity voted for by the participants/distributed.net itself/the user who finds the key/that users team (if the user is not on a team, they get 20%).

If the winning user or team were located in Europe, we might ask CS if they'd be willing to send checks directly to them.

Decibel
distributed.net Controller
decibel@distributed.net

I'm only going to comment on the first point, as you've brought up precisely what I am now responsible for at distributed.net.

You're absolutely right. And we're working to fix it.

We've finalized a redesign of our web site and are beginning a complete rewrite of nearly all of our web content. After the major pages are finished, we'll go to work on the documentation, which is very lacking, often in some extremely important areas. The site will have a new hierarchial structure, with simple URLs for news, help, and downloads. Deep information will be even more readily accessible for those diehards who want it.

The changes will be rolling out in stages over the next thirty days.

Come back to distributed.net in a month's time. I promise, you won't be disappointed.

Client core source - the source that does the actual crunching - is entirely open and available at our web site.

We have good reasons for not releasing our network's source. One is that we would become instantly vulnerable to block spoofing, threatening the integrity of the effort.

See also here for most of the source which IS open.

If you can port these sources/cores to your platform, we'll be happy to make a client wrapper around it!

Oh, on that page is also an explanation why we still are not open source...

I've put a rate clock up for this contest. It refreshes every two minutes and is continually updated by the master keyserver. Stats don't get any more accurate than this...

• http://nodezero.distributed.n et/~vetere/csc-rate.html

Feel free to hop on over and check it out.

Daniel
--
Daniel Baker - dbaker@cuckoo.com - dbaker@distributed.net

Don't automatically call me people as though I somehow represented all of Slashdot. I see this happen a lot. Read my User Info page and see what I've posted.

I don't claim that competition is necessary. In fact, if Microsoft actually valued its customers and technology as much as it does its money, it would be quite plausible for me to "like" Microsoft because they would be making better software. As it is, I think competition is good in that circumstance because they aren't attempting to innovate and move quickly with technology but are falling behind (often) what hardware can do and aiming for the lowest common denominator.

Distributed.net does a very good job of what they do and if they released their source code at all to the public (maybe not the part that does the network interaction), it would be very easy to add to it. Modularity would be even better. But why not communicate with them about it in the first place? On a more personal note, I help program GICQ. There are about a dozen Linux ICQ clients, all based on each others' source code to some degree. Sure, lots is good ... to some extent ... but when everyone just starts their own project instead of helping someone else's, they all move slowly.

Just my $0.02 worth.

- Michael T. Babcock <homepage>

We sucessfully completed RSA rc5-56 challange October 22, 1997 (See our full history at http://www.distributed.net/history.html ), over two years ago. We are currently working on rc5-64, which is 256 times harder than rc5-56. Were we to tackle rc5-56 again, we could crack it in a matter of days.

dB!
decibel@distributed.net

it lists Linux glib2, FreeBSD, and solris clients.

Moo!

Although some competition would be great among the distributed computing projects, dcypher.net seems to have picked a bad contest to try and get off the ground with. Perhaps more of a "marathon" challenge would be optimal, instead of the "sprint" that CSC provides.

We had already announced our intent to do CSC, and have an enormous amount of computing power in comparison to the newly-formed dcypher. Dcypher really can't expect to beat us to the CSC key, and after one unsuccessful challenge, their users will likely be unmotivated to stay around.

At this point, our CSC/OGR clients are only in a beta testing phase; however, based on the few hours that we've been running this public beta, our key-checking rate is at least twice that of dcypher. We'll probably be releasing the final clients in the next week or two, and at that point, our rate will be large enough that we should be able to exhaust the entire keyspace in a few weeks.

Daniel

Moo!

Although some competition would be great among the distributed computing projects, dcypher.net seems to have picked a bad contest to try and get off the ground with. Perhaps more of a "marathon" challenge would be optimal, instead of the "sprint" that CSC provides.

We had already announced our intent to do CSC, and have an enormous amount of computing power in comparison to the newly-formed dcypher. Dcypher really can't expect to beat us to the CSC key, and after one unsuccessful challenge, their users will likely be unmotivated to stay around.

At this point, our CSC/OGR clients are only in a beta testing phase; however, based on the few hours that we've been running this public beta, our key-checking rate is at least twice that of dcypher. We'll probably be releasing the final clients in the next week or two, and at that point, our rate will be large enough that we should be able to exhaust the entire keyspace in a few weeks.

Daniel

As you can see from the public ledger, distributed net has donated almost US$20,000 to selected non-profits such as EFF, FSF, and Project Gutenberg.

What money we have retained has gone directly to supporting the network and buying necessary equipment, and not to staff.

As you can see from the public ledger, distributed net has donated almost US$20,000 to selected non-profits such as EFF, FSF, and Project Gutenberg.

What money we have retained has gone directly to supporting the network and buying necessary equipment, and not to staff.

Too bad there isn't a project which uses floating point. If there was, they could write a client that interleaves floating point with integer calculations to _use more of your computers brain at once_ :)

Many of the distributed.net cores already use a combination of "normal" and MMX instructions to achieve this effect. Unfortunately, the d.net mailing list archive doesn't appear to be searchable, but I did find some preliminary analysis of an Athlon core which would derive similar benefits (read: chew through keys like a crazed wolverine on crack :-) ).

To "icing": your analysis of multiple-process issues isn't relevant here -- we're talking about a single execution thread, so there's no context switching. (What you said was true of course, but it just doesn't apply in this situation.)

No, nor will it finish anytime soon. RC5-64 can pretty much be assumed to be brute-force resistant. They're still in the low percentages of the total keyspace and they've been at it for AGES.

I would have to respectfully disagree. With a couple of notable exceptions, the distributed.net attack on RC5-64 (and before that, RC5-56) has been growing quite quickly. I remember participating in the RC5-56 contest when the estimated time to completion was in the decades. Moore's Law and a word-of-mouth spread of participants has caused it to rise dramatically. For an example, take a look at the distributed.net statistics at rc5stats.distributed.net and compare the current keyrate against the average. It's more than double! Also note the "The odds are 1 in 1,680 that we will wrap this thing up in the next 24 hours." So that's 1 out of 5 years, but a simple doubling of computing power over 18 months means 1 out of 2.5 years, and another doubling 1 out of 1.25, etc., even if you don't count the keyspace exhausted while waiting for the doubling to happen. Add that to substantial growth in participants, and you have a solution in probably 2 years.

I know, it's a long time, but this is using completely idle cycles and general purpose hardware and volunteered programming and organizational ability. A full-time project with the funding and wherewithal to develop custom hardware (along the lines of EFF's "Deep Crack" machine for DES [see http://www.eff.org/descracker.html]) would be able to crack RC5-64 fairly easily. RC5-128, probably not.

Actually, the last DES cracking contest (DES-III) was cracked in under 24 hours

Encryption is dead? Don't you really mean that weak encryption is worthless? Click here for some insight on encryption. Distributed.net has been running its RC5-64 bit key challenge for two years. That's right, two years. There are, on average, some 40~60 thousand participants everyday. But if you look at the top performers, you will see that many of what is counted as a single participant is actually a group of hundreds of computers working together. Now, the amazing part is that with all the participants involved donating all of their spare CPU cycles for 2 years, less than 15 percent of the keyspace has been checked. That means that if for some reason the real key is the last one checked, it won't be found for another 11 years or so. But maybe in your eyes that's not a long time. For many practical purposes, 13 years is a long-enough time for gov-intel to be obsolete, or for private citizens hiding from the gov't, 13 years is long enough to pass the statute of limitations of many crimes.
----------------------------------------- -----------------

duh assign everyone a digital signiture

That might be cool until Distributed.net cracks your encryption and anyone can vote as anyone else.

It's a special-need kernel, not something for general consumption. As much as how every article on /. has a comment saying "Man, I'd like a Beowulf of these babies," most of the people saying that never will have a Beowulf or a need for a clustered system. (I mean, come ON, what would you, personally, use all that computing power for?)

Personally, I would use it for Distributed.Net, but that may just be me.

In all seriousness, the main home use of a Beowulf-type cluster is not to make a supercomputer, but to use all those '86es sitting around (like the 3 under my desk).

Although for me disk capacity & speed are the greatest computing bottlenecks, I would have no problem putting 1100 MHz to good use compressing MP3s and running software DVD. Also, just think of all the RC5 key checking you could do for distributed.net!

It might even make Win2K run at a decent clip. ;)

See the distributed.net Projects page. Specifically, scroll down a bit to the "Possible Projects" section.

distributed.net used to host a mailing list for the discussing the possiblity of a distributed chess system; however, all references to the list seem to have disappeared from their web site. Also missing are any archives of the list discussions, which is unfortunate because a great many very smart people involved themselves in some wonderful discussions on that list.*

The web page does provide the email address of one Remy de Ruysscher, who may be contacted regarding work on the creation of a distributed chess module for the v3 Bovine clients. You may be able to obtain more information that way.

* This is not to to imply that I in any way participated in those discussions. My knowledge of both chess and distributed computing are limited enough that silently lurking was my most helpful contribution.

While this may be a bit off-topic, with the mention of distributed.net, I thought some people would be interesting in helping the organization. By simply signing up to iGive (http://www.iGive.com/html/ssi.cfm?cid=1098&mid=91 085), distributed.net gets $10. Then, a certain percentage of all things you buy go to distributed.net and even clicks earn money for them.

While I know that I can't donate money to them, it is nice to be able to pay them back somehow. If others are interested in helping the organization, join iGive now!
--
ZZWeb.net Web Hosting - http://www.zzweb.net

Perhaps there would be some merit in creating a consortium of net users, in a way similar to distributed.net, to which academics could submit proposals in order to be awarded CPU time.

This would merely be an "open" equivalent of the academic facilities in current use, e.g. the Cray installations at Edinburgh or the Hitachi in Cambridge, UK, but with potentially tens of thousands of nodes.

Thus, rather than thinking, "Hey, maybe my machine will discover ETI," you would actually know that your computer would have been used for an immediately useful project and the results would be published with appropriate references to the computing facilities used. My own research involved the quantum mechanical modelling of materials' properties; sure, it's not as glamorous as SETI, but a) it's immediately and industrially relevant and b) it wouldn't aim to take all time available and would therefore be just one of the projects enabled by such a distributed facility.

The only problem I see is that with Net users as (presumably) the arbiters of what passes for viable research, there would be an unfair prejudice towards "cool" rather than academically useful projects. On reflection, however, that doesn't seem too different to the Research Councils here in the UK.