Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Dcypher.net Linux Clients Available 69

Posted by Roblimo from the more-distributing-computing-challenges dept.
Steve Porter writes "Dcypher.net has released MMX-only Linux clients for its CSC Contest. Full information is available at dcypher.net. Non-MMX Linux clients will be available shortly and will feature an improved non-MMX integer core. We would like to take this opportunity to welcome those who will join us, and would also like to apologize for the delay in releasing the Linux clients. FreeBsd clients and proxies will be out shortly."
This discussion has been archived. No new comments can be posted.

Dcypher.net Linux Clients Available More

Dcypher.net Linux Clients Available

Comments Filter:
  • Is either team using a method where they don't crack whole blocks at once, and only those blocks?

    It'd get messy to crack a block of keys, and about half as many again that were scattered across the keyspace, yet happened to be helped by using information from the cracking of the primary key block. So it seems likely that both projects sacrifice the theoretical gains you could get from running the project on one big computer, by only attempting keys in a linear block.

    So, the specifics of their optimizations shouldn't prevent them from saying "We use blocks of N keys long, and we'll allocate from 0xffff... down and you allocate from 0x0000... up, and we'll meet in the middle..."

    If you have specifics that show otherwise, I'd love to see them.
  • well, actually im not in the least afraid of any one reading my mind - i have a free, open mind and i dont care who reads it.

    What i am concerned about however is the fact that i have to install some binary chunk of code inside my firewalled,secured network that sends some arbitrary unintelligible data though the firewall systems.
    Its the integrity of corporate security im takling about here.

    This strict view probably does not apply to most educational institutions or installations without sensitive data/traffic.

    Why Backups? - All my data gets stored at Echelon...
    --
  • While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.

    DCTI publishes only a fraction of the source code. The only part they let the general public see is the "cores" -- the part at the heart of the client doing the actual project/contest work. There's a boat load of other source code that comprises the network layer, the buffer handling, and (the part they must protect to the death) the block encryption. Out of the entire tree, only two files must be hidden from the public.

    Again, I'm surprised this amazingly weak method of protection has held for soo long. As my dad says, "Locks are to keep the honest people out."

  • Re:distributed.net? and a few facts. (Score:3)

    by ToLu the Happy Furby ( 63586 ) on Monday November 22, 1999 @10:43AM (#1513353)
    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 [distributed.net] and here [24.141.28.12]; 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!
  • (Note to Nugget: no one listens to AC's)

    (Note to reader: Nugget is not a "coder". He's said this himself on several occasions.)

    Dcyhper.net doesn't need to release their code to coopereate with anyone else. One only needs to know what section of the keyspace (i.e. what keys) each will be processing. CSC may not be as forthcoming as a linear search of the DES keyspace, but there are still keys to be checked.

    There were two problems with DeepCrack (read the board minutes where BovineOne explained the options.) First, DCTI processes both the key and the compliment of the key (neato DES optimization) while EFF processes only the key. So, for every DCTI "block" assigned to DeepCrack, it would have to test the keys in that block twice -- the key and the compliment of the key. Second, DeepCrack eats much larger chunks of the keyspace. If DeepCrack were handled as a regular client, it would need it's own key proxy -- DC needs contigous blocks larger than the proxy network could handle.

    In the end, the keyspace was broken down into 32 sections. DeepCrack started at one end of the sub-space and the DCTI proxy network from the other end. I'm not certain how the keymaster figured into all this. I wrote a perl script for dbaker to tally the key rate from the proxy network and DeepCrack.

  • In DES (and this is true for CSC too), we picked some 'interesting' bits from the 56 of the key, and we're using them to increment the key to be checked each time.
    This is not to obfuscate the process but for performance reasons.

    These bits are definitely *not* contiguous.

    For example, we can check key 0x01234567890123 and then 0x45798AF1245EBC and then 0xEFB47870E01901 etc ... (this is just a random example)

    So the keyspace is *not* contiguous.

    If dcypher and d.net haven't choosen the same bits, it's nearly impossible to say "ok, we will check keys from xxx to yyy and you will check keys from zzz to ttt).

    For DES, these 'interesting' bits were :
    3, 5, 8, 10, 11, 12, 15, 18, 42, 43, 45, 46, 49, 50

    Now, you understand ?

    --
    Rémi
    (broken english spoken fluently)
  • Comment removed based on user account deletion

  • I see where they say that they give you the full prize money (right on their front page), but where do you get that their clients are faster? I searched their site high and low with no luck validating your statement. In the future please give reference points.

    Wouldn't that be the decision maker on whether to run dcypher or distributed's clients?

    - Dekaner

  • Care to qualify that remark? Why is it garbage?
  • The timelimit doesn't matter. Assuming you're crunching keys as fast as possible, you're going to go through roughly the same number at either project. If the prize is five times higher with one project, then go with the one with the most prize money.

    But, you know, they really should cooperate. Share the keyspace to avoid duplication, that way at least someone will get the money. They could just say 'We get 0x0000... to 0x7f00... and you get the rest. When one of us runs out, we'll split up the remainer.'

    Sort of prisoner's dilema-ish. Help your opponent a little bit, risk being cheated, to reap greater rewards if you both cooperate.
  • I think here in the UK the chances of winning the lottery are 1 in 14 million something (is this right?) So for DCypher you'd get worse odds, and end up winning a pretty pathetic some of money in comparison. Hardly a gamblers dream win, is it? ;)
  • http://xempt.darpa.org/dcypher/FAQ/

    Unfortunately its timing out right now from here at work... but I believe the information your looking for is contained there.

    From personal experience the Dcypher client is ~2x faster than D.net's

    Rosie_BHJP
  • ah - but it doesn't cost you anything to enter (assuming the extra cost of electricity used by running CPU at 100% rather than 2% is small)
    --

  • This simply isn't true, and probably isn't legit (Score:3)

    by Nugget94M ( 3631 ) on Monday November 22, 1999 @05:39AM (#1513367) Homepage
    I sincerely doubt that this AC posting is from the real dcypher.net administration, since there's absolutely no factual basis for the statements.

    It's unfortunate that dcypher.net chooses to post to slashdot anonymously, making this type of confusion possible.

    dcypher.net has never approached distributed.net to discuss cooperating in the CSC contest.

    The truth is, that unless dcypher.net releases their code, cooperation is impossible. CSC, like DES, is a bitslicable algorithim. This means that performance improvements can be achieved by overlapping common work for multiple keys.

    Since the dcypher.net cores are not available, there is no way for us (distributed.net) to know what real range of keys is represented in one of their blocks.

    Even knowing the start block and size of the block, without knowing the details of their core, there's no way to be certain what work is contained in the block.

    Even if we did know the full details of their code, if the two codebases take differing approaches to optimization (which is likely), coordination of the keyspace might still prove to be cumbersome and impractical. This is exactly the situation distributed.net faced when we joined forces with EFF's deep crack box during the most-recent DES challenge. Due to the nature of deep crack's bitslicing, we had very little flexibility in subdividing the keyspace. We had very few options for the division that did not involve duplicating work between the distributed.net network and the deep crack boxes.

  • ...or so the guys in the strnage suits told me...
    --
  • This is not a lottery at all. Everybody having checked false keys before increased the chance of the right key being assigned to you, so they _did_ help with your work.
  • I see where they say that they give you the full prize money (right on their front page), but where do you get that their clients are faster? I searched their site high and low with no luck validating your statement. In the future please give reference points.

    There's a link right on the front page:

    http://24.141.28.12/cscstats/speed.html [24.141.28.12]

    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 [distributed.net]!) and, thanks to faster clients, my computing power is maximized.

    Cheers,
    -j.

  • We recommend you go and bench them for yourself. Please note that DCypher.Net blocks are 2^32 keys while distributed.net ones are 2^28. To calculate kkeys/s divide DCypher's kbps by 64.

    We put up a short table at this location [24.141.28.12] for some selected CPUs.
  • Actually we'd love to provide support for the PPC platform (whether it be under Linux or MacOS), but for lack of a dedicated PPC platform programmer it cannot be done. We have one primary coder working on Shadow (DCypher client 1.1) right now, one coder for Linux/FreeBSD porting the code and one database wizard. That's all we have to our name and we must allocate our resources wisely to create the most efficient infrastructure for post-CSC projects, of which we have tagged one so far. If, by any means, you feel competent to port x86 MMX-based assembler code to the PPC platform, feel free to contact our lead programmer at steve@dcypher.net and offer your help :)
  • Discovering radio waves from a galaxy hundreds of light years away that were inadvertently beamed this way is not going to have that great an effect on our society or world. Yes, it will be a triumphant discovery. But what are they saying? When were they sent? What did those creatures look like? Without answering those questions, the average citizen just won't care.

    If on the otherhand the aliens show up on our doorstep, yes, everyone on the world will stop and take notice, and yes, it could have profound effects on our lives. But simply identifying radio frequencies that appear to be non-naturally occuring in a galaxy so far away that we don't stand a chance of us or our kids or our kids kids see what originated it, well, that'll end up being something that really only scientists and "geeks/nerds/fill in the blank" will care about.
  • Exactly where did I say the bits are contiguous? In the case of DeepCrack, the section of the keyspace it works with is alot larger than anything the proxy network would (could at the time) generate. The usual (old) client works with 2^28 key blocks which means it can process 4 non-contiguous 2^28 blocks just fine. DeepCrack cannot do that. (The current clients can process 2^28 up to 2^32(?) blocks at once (as a single contiguous set of keys) and can request a block larger than 2^32.)

    I never said "key++" == "key += 1" (of course, that depends on how you define "key".) For DES that's absolutely not true -- suffice it to say, it's much faster to skip some of the reversable initial steps and start partway into the cypher.

    No matter how much math is behind the "++" operator, it all comes down to moving from one key to another. At least to the "core", that's usually simple addition (or subtraction.) If my CSC stepping is spanning the entire keyspace and your stepping is spanning the entire keyspace, then it could be hard to decide on what "half the keyspace" means -- esp. if both of us are already working on the same half. Dividing the keyspace only requires ONE BIT in common. Likewise, further division requires more bits.

    (PS: Login you bloody git.)
  • And people need to realize that it is not only LinuxPPC. The MacOS/PPC version of distributed.net's RC5 client was last updated in January of this year. There have been no reports of development on AltiVec optimizations. Mac FBA clients have been "in progress" for almost *two years* now. That is simply unacceptable.

    I am cracking RC5 keys at 1.25 Mkeys/sec on my dual processor clone.

    There is no MacOS CSC client from distributed.net or dcypher.net This is eliminating a large group of people willing to crack keys. Since distributed.net is not breaking up stats by OS/platform, it is difficult to say how many MacOS clients are out there. The EvangaList, at second overall, has over 230,000,000 blocks completed.

    I understand that it is difficult to support every platform out there. With the size of distributed.net, at least, it is difficult to imagine that finding a Mac coder is that hard.

    If distributed.net does not release a new MacOS client by the end of the year, their client will no longer be running on my computer. I hate SETI, so I will not go to that.

    Are there other contests out there that support the MacOS platform?
  • 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.

    Hmm.... sounds like the situation with Microsoft to me... Inferior code, lots of users, use simply because it's the most prevalent solution, arrogance in that "we don't need to optimize the core because we have so many users"

    Wondering if distributed.net has gotten into talks with Billy G.

    Don't get me wrong, I've got the d.net client running right now, and I have been since a year or so ago, but the situation with CSC is pretty funny.

    Jonathan Wang

  • Actually, IIRC the PPC chip is RISC (late 1980s instruction set) whereas x86 is CISC (circa 1970s instruction set). If you'd like to back your claim that the x86 architecture is superior to the PPC architecture please feel free to do so.

    Jonathan Wang
  • I don't know what my CSC chances are w/ d.net (server's offline right now :), But I get a kick out of looking at my RC5 stats and seeing something like:

    "The odds are 1 in a billion trillion that this participant will find the key before anyone else does."
  • What's the difference between this and distributed.net? I just installed the rc5des client today and noticed that it also did CSC--so what's the deal? how do these differ?

    Jeremy
  • I got my first computer when P-II was out so I was never explained what MMX really does for you.. Can anyone explain?
  • For mmx info check out this [internet.com]
  • What's the difference between this and distributed.net?

    If distributed.net does what it has done in the past, then there's about EU 2000,- for you and they keep (or donate to some charity) EU 8000,- (they haden't updated this info on their site last time I looked). With dcypher.net, you get EU 10000,- they keep nothing. I get the feeling that dcypher.net wants to attrack former distributed.net team(member)?s. They sell ads, so I think they have figured out they can at least pay for their time and resources, and in case a person using their client finds the correct key, they they "lose" nothing, yet gain some publicity. The distributed.net client is well tested and has a large stablished user base...

  • Re:What Difference does MMX Make? (Score:1)

    by Anonymous Coward
    MMX is a set of SIMD instructions for integer values. SIMD applies a single instruction (SI) to multiple data values (MD) at the same cycle.

    For example you could add a single integer value to 4 other integer values that are stored in the MMX registers at the same clock cycle instead of doing 4 sequential additions (this is just an example, mileage may vary depending on implementation of MMX)
  • IIRC, MMX allows the processor to perform the same instruction on a set of integer data. For instace, you could pass 4 ints to a function and have the processor perform the same instruction on those 4 ints without having to reload the instruction.

    It's the same thing as 3dnow! and SSE and Altivec, except for integers.

    Jeremy

  • Re:Celeren & MMX Issue (Score:1)

    by Anonymous Coward
    Pretty accurate list of MMX capable processors :

    - Intel Pentium MMX
    - Intel Celeron
    - Intel Pentium II
    - Intel Pentium III (ISSE)
    - AMD K6
    - AMD K6-2 (3DNow!)
    - AMD K6-III (3DNow!)
    - AMD Athlon (Enhanced 3DNow!)
    - Cyrix 6x86MX
    - Cyrix MII
    - Cyrix/VIA Josh (3DNow!)
    - IDT Winchip
    - IDT Winchip-2 (3DNow!)

    I think that's all for now :)

  • Re:distributed.net? and a few facts. (Score:3)

    by Anonymous Coward on Monday November 22, 1999 @03:35AM (#1513399)

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

    The distributed.net [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/ [distributed.net]

    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

  • Re:distributed.net? (Score:3)

    by Anonymous Coward on Monday November 22, 1999 @03:16AM (#1513400)
    DCypher.Net started first (November 8) DCypher.Net has faster clients (between 100% and 150% faster) DCypher.Net hands out the full prize money of 10,000 Euros ($10,500) to the finder of the key instead of just $2,000 at d.net DCypher.Net offers stats that are updated every hour or realtime instead of every 24 hours.
  • Once again, those of us running Linux on PowerPC hardware get to be second-class citizens.

    Now, I realize that the majority of boxen out there are x86-powered. So, sure, one would expect to see clients for distributed-cracking efforts to be x86-first (and Windows-first, unfortunately). But, c'mon. Once a Linux-x86 binary is posted, there's just no reason not to spend the couple of hours or so it would take to find someone who would be willing to compile and test the same code on a LinuxPPC box.

    PowerPCs are make great crunchers. With distributed.net's RC5-64 client, my LinuxPPC box at home (with a 270MHz PPC750) hums along at around 920Kkeys/sec -- about the same speed as my previous box at work (a 333MHz Pentium II). All of this despite the fact that the d.net client for LinuxPPC hasn't been revised in almost a year and has some pretty glaring bugs (most notably hostname lookup failures -- and this could probably be fixed just by re-linking the dang thing). Both the Linux-x86 and Linux-Alpha clients are at version 2.8x and have received some attention lately, but the LinuxPPC client is still at 2.7x has apparently been left behind.

    Myself and other LinuxPPC friends of mine have tried to volunteer our time and boxen for various projects to compile and test LinuxPPC clients. We rarely get any response.

    I'm becoming disconcerted with the growing trend/mindset that: (Linux == Intel). This was always one of Windows' biggest drawbacks, that it was tied exclusively to one architecture. Through sheer laziness, I fear the same fate for Linux. It doesn't have to be this way.

    And, yeah yeah, I know x86 hardware gives you more "bang for the buck." Yawn. Thankfully, not everyone in the world wants to drive a Camaro. How boring would that be?

  • Maybe be its just me, but... (Score:3)

    by Psiren ( 6145 ) on Monday November 22, 1999 @03:19AM (#1513402)
    I really don't see the reasoning behind cracking these encryption routines. Surely we know that by throwing enough computing power at it, we'll get there eventually. So why bother with it? What does it actually achieve? This isn't flamebait. I'm generally interested in why people want to do something like this.

    I'm a fan of SETI, since it's an attempt to discover something new. If you believe in the possibility of extra-terrestrial life or not, surely from a scientific standpoint, SETI is a far more worthwile use of computing power, isn't it?
  • I believe you will see alot more of this in the future. With the Internet, we can connect hundreds, if not thousands, of computers to perform a single task. Well, actually, each computer will perform a segment of a single task. With more and more computers hooked to the Net doing nothing, we could use these machines for advancing technology. I would prefer to have the source to these programs that get installed, or atleast an outside inspection of the code, since you could abuse this access into other's machines.

    This contributed effort I think is a Good Thing. But like I said, it should always carry the source with it. I know that this could cause problems with those that tweak the code and create problems with the final project. There should be a way to check against this. Like randomly giving the same tasks to different computers, and comparing the result of both.

    Who knows, maybe someday this will help in curing diseases and diagnose DNA.

    Steven Rostedt
  • Okay, so anyone know what the odds are?

  • 4 words (Score:1)

    by Jor ( 58607 )
    where is the source ?

    ---

    When i first joined the seti@home project in february, i believed their promises to release the source later...
    now i no longer run any seti@home crap on my systems, and kill every user-run process i find.
    -> No source = no trust.

    i dont give a damn about some remote chance to win some bucks - be it 10000€ or 2000$ - when i can't verify the integrity of the code i am suppost to run on my systems - especially if it exchanges some cryptic data with a remote site.

    You might call me paranoid - but my aversion against the idea to run some code which i cant verify is one of the things that pull me towards Unix.

    btw: i wouldn't participate at this for the prize money - i would do it to make a point.

    (i get more money doing something that is fun for me - and is called 'work' by others ;-)

    --
  • I really don't see the reasoning behind cracking these encryption routines. Surely we know that by throwing enough computing power at it, we'll get there eventually. So why bother with it? What does it actually achieve? This isn't flamebait. I'm generally interested in why people want to do something like this.

    The whole point is to make a point.

    What I mean is for some people it is more important to help some goverments in this planet realize that 56-bit encription is a joke and by imposing some arbitrary limit on the number of bits that "exportable" crypto-software (or hardware for that matter) can legally employ, they are only damaging themselves and their citizens. Basically this gets press coverage and the average person then says "uh, that's not good, this bunch of crazy psychos got together and cracked what my goverment says it safe enough to use" (they won't even get past the headline, so they won't realize it took months for this "bunch of psychos" to crack the thing). In other words, this promotes public awareness of crypto issues.

    On the other hand, helping SETI look for some form of evidence regarding the existance of civilizations somewhere in the Universe will help to create a "we belong to a greater thing" feeling, which for some odd reason, most humans on this side of the planet seem to need to get on with their lives...

    I don't know, one day you will be able to tell your children the world is a better place... even if that world is ruled by an all mighty goverment or some alien counsel

  • Basically I read them as "ok, you have to trust us not to make conffetti out of your pc, but we choose not to trust you not to make conffetti out of our project..."

    Is this really so unreasonable, though? Distributed.net is a public organization offering membership to anyone and everyone. As such, it has a certain amount of credibility, as none of these people have had confetti made of their PCs. On the other hand, by virtue of being public with unrestricted membership, d.net is quite at risk for unsavory people doing unsavory things. Mistrust is a necessary evil. In short, -you- don't have to accept distributed.net, but -they- have to accept -you-. As such, different trust levels are appropriate.

    Don't forget: If we lived in a perfect enough world that this sort of security was unneeded, the projects which distributed.net is currently working on wouldn't even exist.

    --neil

  • Re:distributed.net? (Score:3)

    by Holger ( 36233 ) on Monday November 22, 1999 @04:47AM (#1513409) Homepage
    And distributed.net had the first linux client when dcypher.net was still promising one. I am not going to reinstall clients after just having done that on several machines. I also don't really trust a new, closed source, binary only client.
    While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.

    Regarding the money: distributed.net only claims 20%, but insists on donating 60% to a charity. Anybody can suggest one, but the one to get the 60% is decided by vote (everyone gets one vote per block done). Which is only fair. Why should one person get all the money tens of thousands of people have worked for? This isn't for the money, after all. And the odds of finding the key are slim.

    So with distributed.net, you are working for a donation to a charity, which is certain. With dcypher.net, you are trying to get all the money, while most probably somebody else will get it, leaving you _and_ a worthy cause without money.

    (The above leaves 20% for the participant, which gets split with his team if he joined one.)

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

    I don't want to start nitpicking, but I can't help pointing out the fact that althought there is code for something like the d.net client, it is not the source code for the client. I personally don't mind much this (it's their code, they get to pick the license), but I don't like their reasons for not releasing the source for the client. Basically I read them as "ok, you have to trust us not to make conffetti out of your pc, but we choose not to trust you not to make conffetti out of our project..."

  • People just want to brag about MKeys/s ... (Score:1)

    by Anonymous Coward
    ... especially the ones with exotic hardware.

    Typical : "My PoverPC G8+ can do 9721.57 Key/s ! Hey your pentium sucks so much" ...

    Or "My Quad-Xeon linux server puts the smack on your Athlon-500 on RC5 ..."

    If there were NOT stats available, these contests would never work.

  • Discovering radio waves from a galaxy hundreds of light years away that were inadvertently beamed this way is not going to have that great an effect on our society or world. Yes, it will be a triumphant discovery. But what are they saying? When were they sent? What did those creatures look like? Without answering those questions, the average citizen just won't care.

    Are you crazy? It will drastically influence society. For one it would debunk a lot of religious beliefs, as it will (hopefully) foster a new interest in the sciences.

    This is getting way offtopic, who moderated this clown up?

Slashdot Top Deals

There are two ways to write error-free programs; only the third one works.

Close