Saturday, May 18, 2013

Computer culture shock

Heard some stories about the clash of computer cultures, from an American tech guy working with an international non-profit. The first story was one about not writing your password down. The new user was disappointed that he couldn't write the password down, and he wanted to use a password in his native language—which you can't type on a US keyboard. When he heard he couldn't do that, he protested: "I know only 4 words in English!" (which he didn't remember how to spell). The American tech guy said, "Let's use those," and typed the login ID. "Now type your password."

The user had never used a keyboard before! He looked at the keyboard. "Where's 'H'"?

He learned how to hunt and peck each letter out. After maybe half an hour of practice, he was able to reliably type his password in before the login timeout. Whew!

Before this interaction, the tech guy hadn't met a lot of people who didn't speak English, and not many who didn't touch-type.

Another interaction was with a user at the other end of a telephone line. "Type “sudo rm /var/run blahblah.pid”," said the tech help guy. "It'll ask for your password."

The response wasn't encouraging: "Aaaa! I broke it! It's broken!"

After several back-and-forth sessions, the reason came out. In a terminal window, when the password is requested, "echoing" is turned off. So you type your password, and you don't see anything. Of course the password isn't shown (this prevents "shoulder surfing") but neither are asterisks shown, and the cursor doesn't advance. So the user thought the computer had died.

Makes sense, but this is not the sort of thing I could have predicted, had I been in the tech guy's place.

Last story: The Unix™ Way says that when a command completes successfully, we don't show anything. So one can imagine a novice at the keyboard, wanting to remove (i.e., "rm") a file named a.out, and typing something like this:

$ rm a.out
$ _
and saying, "Huh? Why didn't it work?" Well, actually it did work, which is why it didn't say anything. But he doesn't know that; perhaps he expected it to say "Delete succeeded." or something. Maybe he types it again, with this result:
$ rm a.out
$ rm a.out
rm: cannot remove `a.out': No such file or directory
$ _
At this point our novice may be quite confused: the first one failed, but the second one... failed because... the file isn't there any more... then why didn't the first one give me that same messa... Oh! The first one succeeded, but it didn't say anything; the second one failed, with that message, because it succeeded the first time! Oh! OK!

And the light comes on. He remembers reading somewhere about how commands don't say anything when they succeed, only when they fail. It didn't sink in when he read it, but now the "no news is good news" thing has started to become part of his computer consciousness, his culture.

And a few years from now, he'll tell someone, "Okay, now type rm a.out" and he won't mention the part about how no news is good news. When the other person says, "It didn't work!" he'll probably say, "It didn't? What was the error message?"

No comments: