Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Slashback GUI Software Technology

Slashback: Flashmob, Currency, Verification 218

Posted by timothy from the nothing-important-happened-this-month dept.
The first Slashback in a while, with updates and reactions to previous Slashdot stories, including a Flash-mod supercomputing reminder, the upside of microwave-tested currency, CUPS' user-interface foibles, an alternative to MD5 sums, and more. Read on for the details.

Reminder of your scheduled spontaneous appointment. Zero_K writes "As previously posted on Slashdot and the NY Times, the University of San Francisco's, Computer Science department is building a 'flash mob' supercomputer on April 3rd. On their newly updated official web-site (Main Site, ISO's) the team has now posted the ISO image of their custom morphix that will be used to boot all the computers into the cluster, documentation is on the website (under 'downloads') and on the CD (index.html). I personally plan on downloading and testing this ISO tonight. And after the cluster is taken off line, there will be a massive LAN PARTY (Possibly one of the biggest in San Francisco...) On a 10-Gigabit LAN...Oh sweetness ... So if you are in or around the SF Bay Area on April 3rd, be sure to sign up and bring your laptop or desktop to campus and help make history."

Whaddya mean, "no pun intended"? Rudiger writes "After the dust (no pun intended) has settled around the whole Operation Dust Bunny thing, McAfee updates their signature database classifying Dust Bunny as an application. To be more specific: 'This program is detected as a "potentially unwanted application."' They also say 'This is not a virus or trojan.' Should we leave it to the experts this time?"

Would you read Atlas Shrugged on this screen? An anonymous reader writes "The so-called 'electronic paper,' being a high-clarity monochrome display to become a foundation for comfortable and inexpensive 'electronic papers,' has finally shown its face. The new electronic paper, which looks a bit like an iPod, has 10MB memory, keyboard, Memory Stick PRO slot, voice recorder, speaker, and headphones output, and USB2.0 interface."

(We mentioned the device yesterday, but this link provides better images of it.)

Now they're Pragmatic Publishers as well -- much success! AndyHunt writes "As you may have heard, the Pragmatic Programmers have started their own publishing company (see Slashdot reviews here and here). We've just signed our first outside author: Mike Clark, editor of the JUnit FAQ and developer of JUnitPerf and JDepend. He'll be writing the eagerly-anticipated Pragmatic Project Automation book, the third volume in our Jolt Productivity award-winning series."

Exactly how many bits, Ma'am? And in what order, did you say? jlcooke writes "Two months (almost to the day) after getting slashdotted for an innocent post to sci.crypt - the MD5CRK project has launched. The aim is to get the thousands of applications and websites to drop MD5 for SHA-1 or SHA-256 by finding a counter-example of a security requirement in MD5. Press Release is here."

How to take criticism, by example. slashdot_commentator writes "Eric S. Raymond has recently written a wonderful piece explaining to the Linux zealot why it may not be the operating system of choice of all users. (Or what user aspects open source developers need to focus on to further Linux World Domination.) The op-ed specifically focuses on the CUPS printing system. (But it would be a mistake to dismiss it as a screed against CUPS.) The CUPS authors surprisingly acknowledged ESR's points, and he wrote a followup to the article."

Hitting them where it figuratively hurts. Ian Wilson writes with a followup to the Slashdot post earlier this month on "website thieves stealing content and designs from others, taken from silicon.com. Well, now silicon.com is reporting that it has contacted the offending site's advertisers and forced them to stop paying ad revenues - thus effectively crippling the illegal site - after all, no revenue, no reason to the run the site."

Express your appreciation with PizzaPal. Chuck writes "After you guys published the article on $20 bills exploding when microwaved, a co-worker of mine went to put his soup in the microwave and found a $20 bill in it. Too bad it was an older one, but someone around the office must have left it in there after reading your article. The co-worker then took me out to lunch. Thanks, Slashdot!"
This discussion has been archived. No new comments can be posted.

Slashback: Flashmob, Currency, Verification More

Slashback: Flashmob, Currency, Verification

Comments Filter:

  • Flash-mod? (Score:4, Funny)

    by Rorschach1 ( 174480 ) on Thursday March 25, 2004 @07:13PM (#8674421) Homepage
    I've seen that before... it's when I get modded -1 Flamebait within 30 seconds of posting!

  • Microwave... (Score:5, Funny)

    by ruprechtjones ( 545762 ) <ruprechtjones AT gmail DOT com> on Thursday March 25, 2004 @07:18PM (#8674459) Homepage
    Hmm, just went upstairs and checked my own microwave for cash. Nothing. Maybe I should get my dimwitted roomates to start reading Slashdot.

  • McAfee problems... (Score:5, Interesting)

    by lukewarmfusion ( 726141 ) on Thursday March 25, 2004 @07:21PM (#8674478) Homepage Journal
    The other day, there was a bitTorrent link in the article, and I realized that I didn't have Bit Torrent installed. So when I went to download it, McAfee told me it was Spyware.

    Bit Torrent is spyware?

    Yet another reason for me to hate McAfee.

    • Re:McAfee problems... (Score:3, Insightful)

      by Kenja ( 541830 )
      Its yoru own fault for having it installed. Yank the thing out by the short hairs and install a real anti virus program.

    • Re:McAfee problems... (Score:5, Interesting)

      by ryanr ( 30917 ) * <ryan@thievco.com> on Thursday March 25, 2004 @07:48PM (#8674726) Homepage Journal
      According to Bram, McAfee is currently flagging anything that uses the NSIS installer, which BT uses for recent builds. It's a false alarm, as noted.

      Further, make sure you download the Official client from the Official site. Suprnova has been purposely running a banner ad for a couple of months now for a BT 3.3 client that IS laden with spyware.

    • Re:McAfee problems... (Score:3, Interesting)

      by IO ERROR ( 128968 )
      the original BT client is not spyware (look at the source yourself if you disbelieve) but other BT clients might be.

    • Not a flame or anything, but did you check the source for the Bittorrent client you downloaded? SpywareInfo [spywareinfo.com] shows there is a Bittorent client floating away with an infection of spyware.

      Just for grins, I checked my machine and McAfee ( Virusscan Enterprise 7.0.0, virus defs 4341) didn't complain about ABC [Yet Another Bittorrent Client] 2.6.5 being on my machine. (Nor did AdAware 6.0.) So McAfee doesn't go after all Bittorrent clients.

    • Bit Torrent is spyware?

      The official bittoreent client [bitconjurer.org] and the popular variations like abc [sourceforge.net] and shadows [bittornado.com] are not spyware but there are a few around that have adware/spyware added. It's open source, opportunists are free to do that sort of thing.
      You may have mispelled when searching like the people who end up at the fake site kazza.com instead of kazaa.com

  • Electronic Paper (Score:5, Insightful)

    by El ( 94934 ) on Thursday March 25, 2004 @07:21PM (#8674483)
    Hmm... put an 802.11b interface on this thing, and it won't matter that it has a trivially small amount of memory...

  • Eh? (Score:5, Funny)

    by Feztaa ( 633745 ) on Thursday March 25, 2004 @07:24PM (#8674513) Homepage
    a co-worker of mine went to put his soup in the microwave and found a $20 bill in it.

    He found a $20 bill in his soup?

  • Dustbunny.... (Score:3, Funny)

    by dealsites ( 746817 ) on Thursday March 25, 2004 @07:25PM (#8674516) Homepage
    At least we slashdotted thier site. So I guess there is probably a gap in there where they didn't get all the data they were looking for.

    --
    Live updates from Slickdeals, Tech Bargains, Bens Bargains, Got|Apex, etc.. [dealsites.net]
  • So, let me get this straight. He went to microwave his soup and found a $20 in it? That's better than a fly, I suppose.

  • md5 is weak? (Score:5, Funny)

    by lukewarmfusion ( 726141 ) on Thursday March 25, 2004 @07:28PM (#8674550) Homepage Journal
    This saddens me. I just finished implementing an md5 password hashing routine for a web application.

    At least it's not production yet, so I can switch it over.

    See? This is why my bosses should let me read Slashdot at work.

  • E-paper (Score:4, Interesting)

    by Fiz Ocelot ( 642698 ) <baelzharon@ g m a il.com> on Thursday March 25, 2004 @07:29PM (#8674558)
    I'd love to be able to condence a lot of my books into something like that, but it's still just too small. It should fold out to two sides for one thing since many books are written in a format with that in mind. (at least text books for classes).

    If they can do that, make notes using handwriting easy (no recognition required), I'd love that...

    But I bet the main opponents to this would be book publishers who charge exhorbiant amounts for "new editions" where hardly anything was changed. oh well.

  • If we are trying to get people to move away from MD5 sums, what do we use? CRC?

  • wanna outsource the SF lan party? (Score:5, Insightful)

    by xot ( 663131 ) <fragiledeath@gm[ ].com ['ail' in gap]> on Thursday March 25, 2004 @07:31PM (#8674586) Journal
    Anyone wanna outsource the infrastructure and SW for the Lan party to us indians? ;-)
    Jokes apart, i'd really like to fly down to USA top be a part of the lan party and see how those guys manage things.Its one thing to have a lan party with 100 ppl but using up complete subnets is one different league!

  • I love this guy! (Score:4, Insightful)

    by spurious cowherd ( 104353 ) on Thursday March 25, 2004 @07:34PM (#8674615)
    The technical details of these tests aren't important, and anybody who writes me arguing for a different set will have fixated on the wrong level of the problem.
    The point is that, unlike a command tool for techies that should give them lots of choices, the goal of a GUI is to present the user with as few decision points as possible.
    Remember the Macintosh dictum that the user should never have to tell the machine anything that it knows or can deduce for itself.

    this is as clueful as it gets. Most app designers should heed him

    • I can't tell you how many times I've had users shout at the machines "It's YOUR file! YOU tell me where it is!"

    • Re:I love this guy! (Score:3, Insightful)

      by nautical9 ( 469723 )
      I wholeheartedly agree, more apps should put forth more effort to autodetect and autoconfigure as much as they can, to present the fewest number of options.

      However, it's equally as import to still allow experienced users to bypass any settings with whatever they feel, because try as we might to code perfect autodection routines, there will be times when it is wrong and the user will know better. Bury it behind an "advanced" button or some such, but don't blindly assume the autodection can't possibly be w

  • The luxury of ignorance (Score:5, Insightful)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Thursday March 25, 2004 @07:36PM (#8674627) Homepage
    I don't normally like ESR but in this case he has really been outstanding, possibly because he's not particularly afraid of "uber-geeks" shouting him down with insults and "RTFM motherfucker" epitaphs.

    I see this every single day. The open source community (as it were) is full of people who want to use and like operating systems like Linux and BSD but are just too fucking afraid of even uttering anything that might reveal their ignorance (and I don't use that word in a negative sense) of whatever it it they're trying to accomplish with their computers.

    Slashdot and USENET are full of endless threads about how easy it is to do this-or-that and if you haven't figured it out you must be supremely stupid and lazy. "What, you want it in a fucking silver plate?". Normal people (the ones not buying into open source right now) are petrified at this. They eventually either figure out how to do it ($deity bless Google) or just give up.

    Without gross generalizations of course, I can't claim that everyone is this way. But there seems to be a troubling majority of zealots who are just so fantastically out there in their claims that [insert technology here] is so easy to use that even a "brain dead Windoze luser" must be able to figure it out, so they just cannot figure out why everyone hasn't dumped "M$". I mean, it's all so easy and efortless.

    Maybe this will indeed be a wake up call for everyone.

    • I appreciate ERS is trying to raise the bar on UI design which is good, but I do think his comments are extreme. I see the opposite to you, lots of users at work and at home, happily using GNU/Linux desktops and some rather well written and designed end user applications.

      So to tar all OSS with the same brush seems pointless and counter productive.
      • Like I said, I was not generalizing. I agree that there is good, but at the same time I recognize that there is a lot of bad. Do you?

        There are so many little things that cripple non-expert users in Linux. Just off the top of my head, on RH9/GNOME, inserting a CD-ROM brings up a dialog that reads

        Would you like to mount /dev/cdrom?

        Or something like that. I mean, c'mon. If I wanted that I'd be running fwwm or something. Do I want to "mount" "/dev/cdrom"? How the hell should I know?? Or even better, try ins

        • "Would you like to mount /dev/cdrom?"

          A very nice example. I guess I'm saying that having read both ERS' articles I came away thinking GNU/Linux and associated FOSS products have totally unusable UIs (and are by implication "not yet ready for the desktop", blah blah). This, in my experience and observation of non GNU/Linux users using that OS, is clearly overstating the case.

          Distributions obviously vary and therefore YMMV too.
        • Good example, both of the problem and the not-so-glorious solution.

          In FC1 at least (thought RH9 did too), it is automagically detected and mounted (if it is a data CD), played (if it is audio), or brings up the CD-burning view of Nautilus (if the CD is unwritten).

          Similarily, installing a TrueType font now can be done by dragging it to the font settings window, byt dragging it to the Font view of Nautilus, or by moving it to your ./fonts directory. Next step is to have this happen whenever you double-click
    • One thing troubles me about ESR's rants on this subject. Although he seems quite correct about CUPS, almost all other distributions I know of provide better UIs to configure it, and KDE ships an absolutely fantastic set of printing tools that rival those found in Windows and MacOS.

      So his rant is in a sense accurate but misleading. And your post does more or less the same, for although it is true that there are far too many elitists out there, there are in my experience more good people willing to help, and
      • Time to doublecheck your OWN ignorance.
        Although he seems quite correct about CUPS, almost all other distributions I know of provide better UIs to configure it, and KDE ships an absolutely fantastic set of printing tools that rival those found in Windows and MacOS.

        Apparently you aren't aware that MacOS X uses CUPS. It has a wonderful GUI that conceals the technical details beneath the candy colored Aqua shell.

    • Re:The luxury of ignorance (Score:5, Insightful)

      by Spy Hunter ( 317220 ) on Thursday March 25, 2004 @09:16PM (#8675368) Journal
      The problem is that user interface design is not something that can be done by a geek sitting alone in his/her room coding. Even so-called user-interface experts can't fix a user interface by themselves. The one and only key to designing a good user interface is USER TESTING. This means finding other people who have never used your software and observing them as they learn how to use it. It really is crucial to get actual people to use your software while you watch. Without user testing, your user interface will be crap no matter how many self-proclaimed experts pontificate on the merits of your various design choices. 10 minutes of user testing is worth days of speculation about how to make your interface better. However, nobody writing open-source software does usability testing; they make their GUIs by themselves based soley on their preconcieved notions of what a GUI should be like. No matter how well-intentioned the developer is, this process won't produce easy-to-use software, and it won't produce new innovations in user interface design. I am convinced that this is the reason open-source software interfaces suck and are mostly copycats of other software.

      Another big problem with UI design in general is that when things go wrong, there is a tendancy to blame the user instead of the software. "You should have clicked this other button" or "You should have seen this option" or the ever-popular "You should have read the manual". This attitude is not restricted to open-source software developers; you see it everywhere. The fact of the matter is, if one person makes a stupid mistake, it's quite likely that other people will too, so you should account for it in your design no matter how stupid the mistake seems. If you want a good user interface, you have to make sure that even the stupidest mistakes people make are accounted for in your design. The attitude you need to have to design a good UI is: _every_ mistake a user makes is entirely the fault of the interface, because a truly good interface would either eliminate the possibility of making a mistake or at least be smart enough to indicate that you're making a mistake. Obviously it's not possible to meet this ideal, but a lot can be done to eliminate most mistakes users make. On-the-fly spell/grammar checking is a good example of this philosophy.

  • Wow.. (Score:4, Interesting)

    by msimm ( 580077 ) on Thursday March 25, 2004 @07:38PM (#8674641) Homepage
    ESR just jumped A LOT of points in my book. I haven't read anything so dead on in the community in ages. But add to that his level of tact and his *gasp* sympathy for the user. Wow. Definitely worth the read.

  • Finding 1 MD5 collision does break the system... (Score:3, Insightful)

    by tstoneman ( 589372 ) on Thursday March 25, 2004 @08:13PM (#8674911)
    So you spend all these resources to find one collision amongst 2^128 combinations.... not really that useful. Sure it is significant, but does it really bring down the entire MD5 infrastructure?

    To really destroy MD5, you need to either be able to reverse the plaintext from the hash, or build a lookup table where you can get the plaintext from the hash.

    Both of these seem infeasible, especially the lookup table, so things like Paypal using MD5, which the web site uses as an example, doesn't seem quite true.

    • To really destroy MD5, you need to either be able to reverse the plaintext from the hash, or build a lookup table where you can get the plaintext from the hash.

      Exactly which plain text are you finding, there are (for he purposes of this at least) an infinite number of plain texts for each MD5 hash.

    • Re:Finding 1 MD5 collision does break the system.. (Score:4, Insightful)

      by interiot ( 50685 ) on Thursday March 25, 2004 @08:27PM (#8675064) Homepage
      LOL. You mention in your own post that MD5 is 128 bits long. If you just restrict yourself to documents that are, say, 10mb big, that means there are 2^81920 possible plaintext documents for each MD5 hash. Granted, only some of them will look remotely like english, STILL... 2^81920 is quite enough to come up with many plaintext documents per hash. If you restrict yourself to keys
      • Granted, only some of them will look remotely like english, STILL... 2^81920 is quite enough to come up with many plaintext documents per hash.

        Peachy. Where were you going to put the lookup table for that? 2^81920 is on the order of 10^25000. If you could store one of those documents on an atom (attach it with a little dab of glue, okay?) you'd have enough plaintext documents for every atom in this universe...and for every atom to have its own universe of attached atoms...and still have enough document

    • Re:Finding 1 MD5 collision does break the system.. (Score:4, Insightful)

      by fredrikj ( 629833 ) on Thursday March 25, 2004 @08:31PM (#8675090) Homepage
      As far as I've understood it, the primary purpose is to demonstrate that cracking MD5 is realistic. If this project can then anyone with decent resources (the MD5CRK FAQ claims $100,000 would be enough) can do it. Also, additional collisions will most likely be found soon after the first one (the probability of finding collisions increases), and the data collected from the search can be used for future efforts (e.g. for analysis that might reveal actual statistical flaws in the algorithm).
    • > to...be able to reverse the plaintext from the hash

      THE plaintext? Firstly, there cannot be only one plaintext. By the pigeonhole principle, a few byte sum cannot be unique for all multi-megabyte texts.

      Besides, if that were possible, MD5 would not be destroyed; it would become the world's best compression.

  • $400 book!!! (Score:3, Insightful)

    by iamhassi ( 659463 ) on Thursday March 25, 2004 @08:20PM (#8674985) Journal
    "In Japan it will cost about 40,000 ($365). "

    for a 7.5" by 5" device with 800x600 4-tone grayscale and 10 megs they want how much??? Damn thing probably doesn't even have a decent processor, can't do 1/10th the things a 5 yr old Palm could do and they're charging $400?!? Did I warp back to 1984? Sure it's not a Mac?

    Let Dell copy it and sell them for $149.

    • You're paying for the screen.

  • Proprietary form (Score:3, Insightful)

    by kisielk ( 467327 ) on Thursday March 25, 2004 @08:23PM (#8675020)
    The device supports Sony's BBeB (BroadBand eBook) format and utilizes OpenMG copyright security.


    Apart from this, does it support any other format? I'd love to have something like this to read the countless PDF and HTML books I have, but if I had to buy them again in BBeB format, it's not quite as cool.
    • Agreed. It's need to at least support plain text. My old palm may have a small screen and low res, but it can display nearly any document with the correct software, and it's backlight is handy too.

  • Drop MD5? No. It depends on the intended use. (Score:5, Informative)

    by pla ( 258480 ) on Thursday March 25, 2004 @08:24PM (#8675031) Journal
    I frequently use MD5 in my code, for verifying a file's integrity. I do not use SHA-1 or SHA256, because they run a lot slower than MD5, without providing a realistically better guarantee that a file contains what it did at the time of its creation (if 128 bits leaves a significant chance of collision, you have bigger problems than choice of hashing algorithms... Such as how to store over a trillion yottabytes, which corresponds to one bit per 10 picograms assuming you used the entire Earth as a storage device).

    Now, cryptographically, MD5 does not have the same "strength" as the SHA256. If you want to prevent tampering, you should most certainly switch to an SHA. But to just check the validity of a large block of data (such that a mere CRC doesn't suffice), MD5 works beautifully.

    Additionally, I would point out to those who seem to believe finding a single MD5 collision would invalidate the whole algorithm - BS. For SHA256, going though every possible 257 bit block, you can guarantee a collision. For any hashing algorithm, that will hold true. I don't care if someone came up with a quantum hash (pulled from my posterior, since quantum-blah seems like the word of the day for magical guarantees of computational perfection), you'll still have at least one collision in N+1 bits, where the hash generates N bits.


    So can we drop the SHA elitism that seems to have infected people lately? If you want to waste time in your code, go right ahead. But don't fault those of us who actually understand that, outside the realm of hard cryptography, MD5 more than suffices as an all around good hashing algorithm.
    • Almost forgot your comment about speed. SHA-1 is slightly slower then MD5. SHA-256 is slightly slower then SHA-1. SHA-384/512 use 64 bit operations so it is much slower on 32bit systems. In short, you concerns about speed are unfounded. Read on.

      Run this command:
      openssl speed md5 sha1

      I get: ...
      The 'numbers' are in 1000s of bytes per second processed.
      type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
      md5 13426.71k 46361.18k 124663.83k 222340.64k 286203
      • Almost forgot your comment about speed. SHA-1 is slightly slower then MD5. SHA-256 is slightly slower then SHA-1.

        By the numbers you gave (which running the suggested test on my own system more-or-less supported), for more than 16 byte blocks (ie, anywhere you'd use it, otherwise the idea of a "hash" doesn't mean a whole lot), MD5 performs roughly twice as fast as SHA-1.

        I do not consider that insignificant. Perhaps not enough of a difference to matter in most cases, but why make a program slower for n
      • I'm confused. You say there is little speed difference between SHA1 and MD5, and then post figures to support your claim showing SHA1 to be 50%-100% slower than MD5. Eg processing 8k SHA1 is 122MB/s and MD5 286MB/s. Your processor time is 1.53s for SHA1 and 1.07s for MD5. Did you mean that the parent poster's speed fears are actually founded? Or am I misreading your figures, as they appear to show SHA1 significantly slower?

        Phillip.

  • Error in MD5CRK assumptions (Score:4, Informative)

    by droyad ( 412569 ) on Thursday March 25, 2004 @09:03PM (#8675298)
    We aim to disprove one of the fundamental requirements of a secure message digest: No two inputs can be found which produce the same digest

    That is an incorrect assumption. The fundamental requirement is: It is hard (next to impossible) to find two inputs which produce the same digest (and still make sense

    The message digest is usually shorter than the message, so this means that the digest contains less "information" that the message. Which means there will be more than one message for the same digest. This loss of "information" means also that you cant reverse a hash to get the original message and be 100% certain you have the right message. There is an infinite number of messages that produce that hash.

  • So yeah, someone has to start a slashdot team. I mean, we owe it to them for destorying their site a while back.
    Join! [md5crk.com]

  • of course there are MD5 collisions! (Score:5, Informative)

    by Mr. Slippery ( 47854 ) <`tms' `at' `infamous.net'> on Thursday March 25, 2004 @09:37PM (#8675574) Homepage

    Are the MD5CRK folks trolling, smoking crack, or just not explaining themselves very well?

    They "aim to disprove one of the fundamental requirements of a secure message digest: No two inputs can be found which produce the same digest - this is also known as a collision."

    MD5 gives a 128-bit digest. There are more than 2^128 possible messages. Of course there are collisions. What MD5 claims is that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations. [faqs.org]

    No digest algorithm can claim to be free of collisions; they are many-to-one mappings.

  • Unfortunately, looking at ESR's followup, it's going to be pretty difficult (without taking away perfectly valid functionality, anyway) to do what he's talking about. How exactly can you verify that there's not a Windows print server on a non-local subnet that you want to use? Or CUPS, or LPD? What is your machine going to do? Scan the entire IPv4, or IPv6, address space every time you want to add a stupid printer?

    I mean, if the Windows print servers are local, and you can see the broadcasts, or you use SL

    • The Insanity of Blind Autoconfiguration. (Score:4, Interesting)

      by The Monster ( 227884 ) on Thursday March 25, 2004 @10:47PM (#8676114) Homepage
      How exactly can you verify that there's not a Windows print server on a non-local subnet that you want to use?
      I thought the same thing, and emailed ESR to that effect on the 11th of this month:
      I have been saying for some time that the biggest hurdle for Linux right now
      is the difficulty of configuring the system for a non-geek. But I can't go
      along with you on this:

      > If the preceding rules leave just one choice, so inform the user and go
      straight to the form for that queue type.

      I spend a fair amount of effort getting character-based tools (Bourne
      scripts that run on SCO Open Server, AIX, and occasionally HP-UX and Linux,
      to be precise) for non-technical users to work, including the frequently
      daunting task of autodetecting configurations to come up with reasonable
      defaults. I have learned the hard way that autodetection is never 100%.
      Even Microsoft gets this - their 'Wizards' always have a check box or button
      for [x] Let me choose/configure/whatever. Just because no Jet Direct is
      found on your local subnet via autodetection doesn't mean that you don't
      want to configure printing to it. It might be on the other side of a
      router.

      Should autodetection offer the most likely prospects for what the user
      intends? Absolutely. But there must always be a clearly-labelled way to
      explore other options. It's easy enough to do...

      Which printer do you wish to configure?

      Windows Print Shares:
      [ ] \\DEXTER\HP HP DeskJet 656c
      [ ] \\DEEDEE\EPSON Epson Stylus C84
      Unix Print Shares [LPD]:
      [ ] pana@192.168.1.200 Panasonic KXP-1100
      HP JetDirect:
      [ ] 192.168.1.50:9100 HP LaserJet 4L
      [ ] 192.168.1.50:9101 Dymo SE-300
      [ ] 192.168.1.50:9102 Generic Centronics
      OTHER
      [ ] I don't see the printer in this list.

      [ <- Back ] [ Next -> ] [ Cancel ]
      He hasn't replied to my email.
  • -Cool
    -Duh!
    -huh?
    -Whoa!

    Please feel free to apply to comment of your choice, to the /back story of your choice.... Moderate as appropriate.

  • Maybe this underscores the problem... (Score:4, Insightful)

    by dozer ( 30790 ) on Thursday March 25, 2004 @10:31PM (#8676013)
    ESR says, "Let's go back to the queue type selection screen. Remember that one? It looks like this: Locally connected, Networked CUPS (IPP), Networked Unix (LPD), Networked Windows (SMB), Networked Novell (NCP), Networked JetDirect". He then goes on to say that all of this should be autodetected and then the irrelevant options grayed out. According to him, each host do a Christmas tree scan (!!) of the local network to see what printer types to prompt for.

    First of all, he'd better stay the hell away from my network. I thank goodness that no other (non-script-kiddie) application on this planet performs unprompted scans like this. DHCP, of course, doesn't count. :)

    Second, what if the printer is currently down? Or I'm configuring a machine to be installed offsite? I can think of any number of scenarios where I'd want to configure a network printer that isn't currently on the network.

    A program should NEVER think that it's smarter than the user. What if CUPS doesn't detect "wvlan0" as a network interface? Well, it would gray out all the network printer options. But that's clearly wrong -- the user *knows* that the machine is networked. If CUPS allowed him to configure the network printer, everything would just work. Note that CUPS probably should put up a warning dialog "Warning: I could not detect a network -- do you want to continue," but it should not prevent or restrict anything.

    ESR's solution relies on too much magic and will cause support nightmares. It is too system-dependent -- it might work on Red Hat, but it'll probably break on SuSE. Or an ARM-based machine. Or a token ring network. Etc. And when it breaks, the user will be surprised and have no other recourse than to consult the documentation.

    Incidentally, graying something out is almost always wrong because it gives no indication as to why it's grayed out! You should let the user select it, then put up an informative dialog telling the user that what he's doing doesn't make sense, and what he or she might do to fix it. Always, always, always tell WHY.

    Yes, the CUPS UI is flawed ("client-error-forbidden! client-error-forbidden!"), but ESR's proposal is even worse. It's a measly six-item menu! If Easy Software did try to implement it, after a ton of programmer time they'd have an interface that is more surprising, less informative, and more fragile. Not a step in the right direction.

    The proper way to fix this unfriendly menu is to create a wizard The first page would allow you to select a locally-connected printer or, if there are no unconfigured local printers, a network printer (possibly launching a Samba browser to help). Wizards are great for reducing perceived complexity without reducing functionality.

    Creating a good user interface is hard. I think that ESR just proved this. :)
    • Dude! What he's criticizing _is_ the wizard.
    • First of all, he'd better stay the hell away from my network. I thank goodness that no other (non-script-kiddie) application on this planet performs unprompted scans like this. DHCP, of course, doesn't count. :)

      I like the idea of my computer auto-detecting any network printers. I don't have my printer linked up to the network as I don't have time to try and figure out how to do it.

      Second, what if the printer is currently down? Or I'm configuring a machine to be installed offsite? I can think of any numb
      • I think you are in the minority. If the printer is currently down then you can't use it so configure it later when you CAN use it.

        You've never installed corporate hardware, have you?

        You don't walk in with a OS-only server, jack it into the network and start configuring. You've got a design sitting there, and you configure the server *before* dropping it into production. So when you drop it in place, it does 'just work'.

        If you require auto-detection for configuration, you take yourself out of well-des
      • I like the idea of my computer auto-detecting any network printers. I don't have my printer linked up to the network as I don't have time to try and figure out how to do it.

        I do to. But I also want the ability to say "you're wrong...do it this way" to the computer.

        I think you are in the minority. If the printer is currently down then you can't use it so configure it later when you CAN use it.

        For home users, this may not be an issue. For an office environment, it may be. There have been a few times
  • As described in their FAQ [md5crk.com], they need a cycle that contains a Distinguished Point. But it is not guaranteed - there might as well be a simple fixed point or a small cycle that does not contain any DPs. They do not address this in the FAQ at all! The clients may be stuck in loops without sending anything to the server (having effectively found a collision), but the organizers will have no idea.
    • They don't really need a cycle that contains a DP - they just need two chains that end on the same DP. Pollard-Rho is the inspiration for the algorithm they're using, but actually cycles don't play any part in parallel collision search - the important bit is the "lambda" shape by which a collision in DPs alerts you to a collision earlier in the chain. Their explanation is surprisingly poor - read "Parallel Collision Search with Cryptanalytic Applications" for a better one.

      It's so unlikely that a client mig

  • MD5CRK will need a few more participants... (Score:3, Interesting)

    by Paul Crowley ( 837 ) on Friday March 26, 2004 @03:23AM (#8677616) Homepage Journal
    By my calculations, at the current rate they'll take over 500 years to produce a collision. They need about a hundred times as many people on board to get anywhere.

    The sum I did is

    sqrt(-l(0.5)*2*2^128)/(1.325*10^9*86400*365)
    51 9.78646399116343804161

    N=2^128 is the space they're looking for a collision in. The expected number of collisions found after k items have been produced is very close to k^2/2N, so the probability zero have been found is exp(-k^2/2N) by the Poisson distribution. Assume exp(-k^2/2N) = 0.5 and solve for k, then divide by their declared rate of 1.325 gigaMD5s a second.

    I don't know whether this inclines me to give the whole thing up or to climb on board. The latter is probably more fun.

    Incidentally, the algorithm they're using to do the search efficiently is pretty cool. Paul C van Oorschot and Michael J Wiener, Parallel Collision Search with Cryptanalytic Applications [sympatico.ca] (pdf)

  • MD5CRK boneheaded (Score:4, Insightful)

    by Ed Avis ( 5917 ) <ed@membled.com> on Friday March 26, 2004 @04:25AM (#8677840) Homepage
    According to the MD5CRK site:
    We aim to disprove one of the fundamental requirements of a secure message digest: No two inputs can be found which produce the same digest - this is also known as a collision.
    That is bullshit. Of course two inputs can be found which produce the same message digest. This is the pigeonhole principle. Now the MD5CRK developers seem like smart people, and so it's more likely that they just haven't explained it very well.

    They go on to say
    To raise awareness we will find at least two strings of printable text that produce an identical MD5 hash.
    But I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum. Find a way to produce two documents which both have meaning (perhaps two pieces of source code, or two different school reports) and have the same signature, and that would be impressive.
    • That is bullshit. Of course two inputs can be found which produce the same message digest.

      No, obviously they exist but they can't be found in a computational feasible way. Obviously, RSA is trivially breakable by trial division, given infinite time, too.

      I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum.

      Well, it's a partial crack. I'm not a crypto expert but a partial crack is often a way into an algorithm.
    • But I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum. Find a way to produce two documents which both have meaning (perhaps two pieces of source code, or two different school reports) and have the same signature, and that would be impressive.

      MD4 is considered totally broken. Nobody has ever been able to generate 'arbitary' collisions for that hash either, just semi-random ones. But still, nobody uses it.

      The definition of collision-resistent is that

      • Re:MD5CRK boneheaded (Score:2, Interesting)

        by Ed Avis ( 5917 )

        The definition of collision-resistent is that you cannot find ANY inputs x,y st x!=y and H(x) == H(y). None. No exceptions.

        In other words, that the function H is injective. But no message digest function producing a fixed-length digest from an arbitrary-length input can have such a property.

        Lets say I could easily generate MD5 collisions on 'random-looking' 128-bit strings ... Would MD5 be considerd broken?

        It depends on how you were doing it 'easily'... if you simply had a great deal of brute force to

  • For the most part, I have no problem with what these essays say--better user interfaces are needed and so is documentation that ordinary users have a chance of understanding if they ever get around to reading it. But I think one of the conclusions toward the end is remarkably unproductive:

    It's been twenty years since the GNU Manifesto and nearly seven since The Cathedral and the Bazaar. I think it's time we stopped congratulating ourselves quite so much on our dedication to freedom [...]

    I've never se

  • MD5 colision demonstration. (Score:4, Interesting)

    by rixster ( 249481 ) on Friday March 26, 2004 @06:46AM (#8678339) Journal
    For all those interested in the MD5 signing of a message and how "impossible" it is - take a look at www.cryptool.org and the demonstration under "Individ. Procedures" -> "Attack on the hash value of a signature". You may be (unpleasently) surprised about how easy it is to match two completely different documents to have the same MD5.

    • You ARE aware that the default settings of that procedure considers 16 equal MSB bits (out of 128!) to be a 'successful' attack? Now, increase that value to 128 to get a REAL collision search, and suddenly the calculation time skyrockets.

      (www.cryptool.org is down, but you can download the software from this link [medialab.ch].)

Slashdot Top Deals

"I've got some amyls. We could either party later or, like, start his heart." -- "Cheech and Chong's Next Movie"

Close