Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Distributed.net Forum IRC Logs 111

Posted by michael from the mooooo dept.
acidblood writes "The distributed.net forum held up in SlashNET today has just finished! Lots of questions regarding stats, future projects and other subjects were answered. A log of the conversation is available here. Thanks to everybody who participated!"
This discussion has been archived. No new comments can be posted.

Distributed.net Forum IRC Logs More

Distributed.net Forum IRC Logs

Comments Filter:

  • Does anyone read logs like this? (Score:4, Insightful)

    by Ed Avis ( 5917 ) <ed@membled.com> on Sunday September 29, 2002 @06:20AM (#4353039) Homepage
    Isn't there some more readable way to generate an IRC log? Like joining consecutive utterances by the same person into a single entry, or colour-coding to make it clearer who said what. Maybe it's just because I'm not an experienced IRC user, but these text logfiles seem almost unreadable.
  • Lets see how well you can interpret it.

    I feel like my eyes are pointing in opposite directions now.

  • My favorite part (Score:4, Funny)

    by User 956 ( 568564 ) on Sunday September 29, 2002 @06:31AM (#4353059) Homepage
    My favorite part of the discussion:

    [19:20:41] * bwilson pets the cow

    Seriously, it's in there.
    • FWIW, here are some more interesting parts of the discussion:

      [17:10:47] (Famous quote: http://bash.org/?6699)

      [17:12:14] Lazy asks: How comes it took so much time between the key is found and the message of end (more than 2 months)
      [17:12:50] there are two parts to this answer.
      [17:13:09] The first portion of the delay was entirely our fault, and we're quite embarassed by it.
      [17:13:52] It simply took us a month to notice that the key had arrived. On the keymaster there is a success.log which, in past projects, sits at 0 bytes until the day the winning key arrives.
      [17:14:44] however, with the rc5-64 project there exists a buggy version of the client which generates false-positives. Consequently, the success.log became huge and was constantly growing.
      [17:15:16] As luck would have it, the subspace we started with was one higher than the subspace where the solution was actually found. Luck of the draw, but we'll blame it on dbaker anyway.

      [17:34:16] 256 times more work does not mean 256 times as long working, after all.

      [17:35:15] As the saying goes, "if brute force won't solve your problem, you aren't using enough"

      [17:43:58] we came quite close to being deployed to a few thousand pay telephones but the person behind the scheme couldn't get management approval.

      [18:09:55] stealth`` asks: Why does PowerPC's have higher keyrates than the x86, even if a faster x86 is compared to a slower PowerPC?
      [18:11:04] G4 CPUs have some architectural features very suited for RC5.
      [18:11:20] koremore asks: To add to that, why do AMD processors give better keyrates than Intel ones?
      [18:11:36] First, in the fastest cores, all processing is done in the vector unit of the chip (Altivec).
      [18:12:07] Intel and AMD CPUs do have integer vector units (SSE2 and MMX), but they're less suited to RC5 than Altivec for two main reasons:
      [18:13:09] More registers available (32 in the PowerPC versus 8 in MMX and SSE2), plus 128-bit wide registers (MMX is only 64-bit wide), and the existence of a hardware vector rotate instruction in Altivec, which isn't available in MMX and SSE2.

      The whole thing is still worth a read though

  • Even here, AMD rocks- did you read the part where they say: "The most recent AMD processors have better hardware rotate support than the most recent Intel ones...

    I just LOVE my AMD... :-)

  • More readable version (Score:3, Informative)

    by Anonymous Coward on Sunday September 29, 2002 @07:10AM (#4353123)
    A more readable version is here:
    http://www.slashnet.org/forums/DCTI-2002092 8.html
  • The work you complete in a distributed project like this can be written as:

    keys/sec for a typical CPU of the project

    times

    number of participants

    times time spent (seconds).

    As for the first we have Moore's law, which will probably continue to be accurate for some years to go. So that's a very good thing for d.net. Unfortunately the number of active participants isn't growing, and may well start to diminish with a timeframe as this. And that leaves time spent to get us there.

    Rc5-72 is basicly just doing rc5-64 over again. There's no novelty value, no sense of accomplishment. It's just the same again, but 256 times bigger. I think people will change to other more instantly gratifying projects. SETI has a very pretty graphical client, public nterest and it's something new if you've been at d.net for 5 years.

    In 10-20 years when Moore has made computers fast enough, that this project is accomplishable, there will be noone left to work at it.
    • I've been doing the dnetc research since day 1, and attributed 18 months ago some CPU cycles towards the SETI@home (Got above the 10000 Units completed). But I got a bit annoyed with the way the SETI@home clients where optimized. Compaq, SGI and Sun had some specific highly-optimzed code and this made them compete in the Big Companies class, but the word then was there was no need to further optimize the x86 clients as it was good enough. So I decided to contributed all my cpu cycles to dnetc (rc5/ogr).
  • Considering that RC5-72 is 256 times bigger than RC5-64, I don't think that it's going to be cracked any time soon. Even with Moore's Law in place, you're STILL talking about a 10+ year project to crack this code. This brings up two interesting questions:

    * How many people are patient enough to wait that long for the job to finish? D.net has already lost a lot of geeks to the flashier projects like SETI, and most people just don't have the attention span to complete a long project without some periodic rewards along the way.

    * What will it prove when they finally complete their task? If it takes thousands of computers over a decade to crack the code, are you REALLY going to be able to convince anyone that code isn't secure enough for basic data encryption? Sure, some paranoid government folks might panic, but the general public really isn't going to care.
    • Sure, some paranoid government folks might panic, but the general public really isn't going to care.

      I don't know about where you live but very few of the "general public" really gave a damn about the RC5-64 project... Not exactly something that lead the news in the typical area.

      I doubt the "average" computer user thinks about the security of their data beyond the vague "evil hackers might get my AOL account" mindset.

      That said, at the current rate, RC5-72 should take less time than the estimated completion time of RC5-64. (figure rc5-64 started 4+ years ago when the PII was the hottest thing around and clock speeds increased by tens, not by hundreds, of MHz)
    • I only switched to SETI yesterday, after wondering for several days about what to do with the two machines that MUST stay on all the time (or else bearings in the fans and drives sieze... - all the other machines that were used for RC5 that don't have to stay on are now off.) Why not switch earlier? Easy - the money! If they decide to put RC5-72 on the plate for distributed.net, you can bet I'd run my machines on that.
  • From the FreeBSD -STABLE man page:

    NAME
    fold - fold long lines for finite width output device

    SYNOPSIS
    fold [-bs] [-w width] [file ...]

    DESCRIPTION
    The fold utility is a filter which folds the contents of the specified files, or the standard input if no files are specified, breaking the lines to have a maximum of 80 columns.

    The options are as follows:

    -b Count width in bytes rather than column positions.

    -s Fold line after the last blank character within the
    first width column positions (or bytes).

    -w width
    Specify a line width to use instead of the default 80
    columns. Width should be a multiple of 8 if tabs are
    present, or the tabs should be expanded using expand(1)
    before using fold.

  • Just for the record, we also have a list of the questions [slashnet.org] that were sent to the bot, but not used due to time constraints. The d.net guys were nice enough to hang around for an hour or so after the forum was over (and after the log ended) to chat with everyone who stuck around.

  • HTML Log (Score:3, Informative)

    by drdink ( 77 ) <smkelly+slashdot@zombie.org> on Sunday September 29, 2002 @08:05PM (#4355916) Homepage
    For those wanting a more readable version, try the HTML version [slashnet.org].
  • The correct block seems to have been turned in back in July, and even though it's reasonable to not expect to have find it by now, shouldn't they have kept the stats up for what was done since? Seriously - the stats page seems to have been rewinded back to July and they seem to be pretending that then is when people stopped submitting blocks. This doesn't make me want to help Distributed.net in any future projects.
  • If men are not afraid to die,
    it is of no avail to threaten them with death.

    If men live in constant fear of dying,
    And if breaking the law means a man will be killed,
    Who will dare to break the law?

    There is always an official executioner.
    If you try to take his place,
    It is like trying to be a master carpenter and cutting wood.
    If you try to cut wood like a master carpenter,
    you will only hurt your hand.
    -- Tao Te Ching, "Lao Tsu, #74"

    - this post brought to you by the Automated Last Post Generator...

Slashdot Top Deals

Receiving a million dollars tax free will make you feel better than being flat broke and having a stomach ache. -- Dolph Sharp, "I'm O.K., You're Not So Hot"

Close