Domain: dcypher.net
Stories and comments across the archive that link to dcypher.net.
Comments · 10
-
Re:When is this going to be commercially exploited
> Given the reasonable success of these systems I wonder when people are going to start exploiting this sort of system comercially.
there are number of companies that are going to offer for pay project. you should check out following sites:
popular power: Research on influenza vaccination. has windows and gnu/linux clients. mac, solaris and *bsd clients about to be released soon. it has tim oreilly of o'reilly as board member.
parabon: Research on cancer treatment (chemotherapy). clients exist only for windows but they are going to release gnu/linux client soon. they are giving out 100$ on daily basis to random providers.
Dcypher/Processtree they have some kind of physics project. problem is that its easily to cheat on this project. they are also giving out 100$ to random users.
now to my conclusion. all of these projects are paying to little to warrant me donating my cpu time to them. many of them demands that you have 24/7 access to inet. this is something that is unnacaptable to large number of users in europe because we dont have flat rate, so i'll keep donating my cpu cycles to ogr project on dist.net -
Re:I am not participating currently
so goto dcypher.net and start working on gamma flux project. here is some info from their page
"One of the big unsolved problems of mankind is the final storage of radioactive waste and substances that the latter half of the century produced in weapons of mass destruction, power plants and research labs. These highly hazardous materials will be a liability for generations to come, even if we decided to abandon fission here and now....
you can find more info on it at http://www.dcypher.net/projects.shtml.
btw there is actually some benefit out of rc5 project. there have been very few publically documented projects of brute force cracking of large keyspaces so this one might help us to understand brute force cracking a bit more. i agree with you that ogr project is more beneficial for human society. -
Re:Finally!
As an alternative, what about the Gamma Flux project over at dcypher.net ?
This has a useful application to it - ray tracing for making safer containers to hold radioactive waste.
Stats aren't quite as cool as distributed though
;) -
Re:Isn't there *something* worthwhile?
How about Dcypher.net's Gamma Flux Radiation project?
-
SETI@Home useless....
People should give their spare CPU cycles to useful distributed computing efforts like www.dcypher.net or www.distributed.net. If you want to actually contribute to something useful you should go to the links above instead of wasting your time with SETI@Home which sends out duplicate work because it already has too many people helping
:P -
Dcypher.Net Calculates Safer Nuclear Storage
If you're looking for for something that fills the equation useful+success. Just to letcha know.
-
Re:I hate to say this, but...
and that they haven't even *released* a finished client for the Mac!
Interesting you mention this, since Distributed.net did recently release a new Mac client (finally), one that is capable of running CSC. However, what is ironic is that you promote dcypher, which I would love to run, but a quick look at their clients shows no MacOS client, nor even a LinuxPPC client. In fact, it does not seem that they have a non-x86 platfom mentioned.
For a web page that so often has such an anti-monopoly, anti-Wintel stance, Slashdot's hatred of Distributed and love of Dcypher seems strange.
You mention that Dcypher is running CSC about 2.5 times faster than Distributed, but fail to mention that Distributed has RC5 running about twice as fast on Altivec-based MacOS machines. Can you imagine a Dcypher-based, Altivec-aware CSC client? Well, it will take imagination since they do not have one.
Yes, I realize that Dcypher is working with only a few coders and is trying to get a Mac client out the door, but at the rate they are going at, do you really thing they will get one out before CSC is done?
-
I hate to say this, but...I think I've finally had it with distributed.net.
Anyone who's been following their .plans for the past month and a half or so knows that this is just the latest in a ridiculous string of fuckups. While they haven't lost any blocks (yet), they've had stats down for days at a time, screwed up participant ID's, and misplaced and miscounted blocks left and right. True, none of these incidents has been too big a deal, but when you have to check the d.net .plans every day just to make sure you still belong to the same team, something's amiss.
Wait--did I say this was the latest in their string of fuckups? Well guess what--as several hours had passed without a new bug report coming out of distributed.net, wouldn't you know it, now it turns out that they haven't actually completed 91% of the CSC project after all.
Yep, you read that correctly. Oh, but don't worry--it's not a bug, it's a feature. For those of you who won't take the time to click on the last link, here's how dbaker's latest .plan update begins:
As we near the 100% mark of CSC keyspace completion, I think it's
time to explain what that CSC statistics mean, and how they are
determined.
It is perhaps a common misconception that each CSC work unit
completed is unique...
He goes on to describe the fact that they've implemented redundancy checking to weed out hacked clients with the CSC project--a very good if a bit overdue move (although perhaps they could have disclosed this earlier?)--and that they've decided to give everyone full credit for all their blocks, even redundant ones--also a good idea--and so therefore there's obviously absolutely no way that they could avoid the actual keyspace being more than 100% of the reported "keyspace". Obviously. And this was the plan all along. Which is why they even wrote up not one but two new scripts which (falsely) calculate that the "keyspace" will be exhausted in only 2 days now. Obviously.
And of course it's perfectly fine that they just hoped that the project would get solved before it his 100%, so that they wouldn't have to inform their users that they've implemented redundancy checking. And no, they're not going to tell us how many percents are actually in the keyspace (105%? 110%?), or how many days it will actually take before we check all the keys and get to find out if they've somehow managed to fuck up yet again. Why should we be entitled to know silly information like that??
Meanwhile, dcypher.net has sprung up, and, in only a couple months, and with what certainly seems to be fewer people working for them than distributed.net has debugging their database they've:
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. -
More important news
Well I guess it is more important news than DCypher.Net bringing out clients for Linux and FreeBSD for the new Gamma Flux distributed computing project. That one was rejected twice.
*sarcasm off* -
Why is it so much slower than DCypher CSC???
Aargh, this is annoying. I mean, I heard rumours that the beta client was a little slowish, but I just benchmarked the d.net CSC client on my machine, and I got about 380.4kkeys/sec cracking rate (it's a K6-2-300).
It there a problem with some systems, software-wise, or is there a bug in the d.net implementation of CSC? I tried out the DCypher.net CSC client (it's been out for a week or so, I think) and for 732.6kkeys/sec on the same system, under the same circumstances!
Actually, I checked and I'm finding similar comparisons from various people I know, with d.net's CSC client being about half as fast in cracking compared to DCypher.net's (a friend of mine tried both on an Athlon-650 and got 2,023,437keys/sec for DCypher and 1,040,189.47keys/sec for d.net, for example).
My testing is being done with all programs except the shell and systray (and a dos box, as I'm using the command line clients) closed and out of memory.
Is this an optimization issue? Will d.net release improved clients in a few days? I'm really getting worried and annoyed. I had planned to do a DCypher-CSC/d.net-CSC comparison on my website to show which was faster on which of a variety of cpu cores. But this is insane!
Oh ... ummm, I guess it's only fair that I link to DCypher, as they're kinda the underdog here and not as many people know about them.
-JC
PC News'n'Links
http://www.jc-news.com/pc