NetNews Usenet Archive 1992 #26

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4651 < prev next >

Wrap

Internet Message Format | 1992-11-12 | 58.0 KB

Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!ames!elroy.jpl.nasa.gov!usc!hela.iti.org!cs.widener.edu!dsinc!netnews.upenn.edu!gynko!rsk From: rsk@gynko.circ.upenn.edu (Rich Kulawiec) Newsgroups: comp.unix.wizards Subject: Re: The Problem with UNIX [Includes ANCIENT Usenet traffic] Message-ID: <97393@netnews.upenn.edu> Date: 13 Nov 92 00:24:02 GMT References: <1992Nov9.172715.16367@cs.wisc.edu> <96927@netnews.upenn.edu> <1992Nov11.210729.11676@cs.wisc.edu> Sender: news@netnews.upenn.edu Organization: GSP Whitewater Slalom Racing Team Lines: 1389 Nntp-Posting-Host: gynko.circ.upenn.edu I've included a sharchive at the end of this with the full text of Don Norman's paper and some comments that various netfolks made at that time. If I recall correctly, this was the first instance of a Usenet forgery -- he claimed that the paper was sent without his knowledge -- and so a couple of the messages deal with that issue rather than with the points raised in his paper. I got quite a kick out of reading these messages again 11 years later; it's kind of interesting to look back on these with a decade's perspective. By the way, you'll notice a paucity of headers in those old messages; that might make identifying people difficult. I believe that "ber" is Brian Redman, csvax.mark is Mark Horton, jej is James Jones, nowicki is Bill Nowicki, mo might be Mike O'Brien, and utzoo!henry is Henry Spencer. In article <1992Nov11.210729.11676@cs.wisc.edu> so@brownie.cs.wisc.edu (Bryan S. So) writes: >Concerning Don Norman's paper "The Trouble With UNIX", Datamation 27, >rsk@gynko.circ.upenn.edu (Rich Kulawiec) writes: > >>Norman's paper is (a) a decade out-of-date and (b) extraordinarily >>inaccurate, as it was when published. In my opinion, it represents >>the uninformed rantings of someone who is simply too lazy to read the >>manuals and therefore should not be using a computer at all. > >I agree it's a decade old but can you indicate why it's inaccurate? > >To me, some problems like "cat a b > b" are obviously undesirable >designs and still unsolved after more than a decade. Nearly every problem that Norman addressed himself to was a function of the shell, not of Unix. "cat a b > b" is solvable at the shell level, should it ever really become necessary to do so. (I personally think that people who type that deserve what they get, and that there's no need to fix it, but I digress.) Let me quote some choice nuggets from his paper and comment on them: DN > I would have written a program that listed the contents onto DN > the terminal, perhaps stopping every 24 lines if you had DN > signified that you were on a display terminal with only a 24 DN > line display. To the designers of Unix, however, such a DN > solution lacks elegance. Unix has no basic listing com- DN > mand, but instead you must use a program meant to do some- DN > thing else. "more" was already around and in widespread use when he wrote this. In fact, Norman mentions that he's using 4BSD in his paper. DN > In Unix, if you wanted to list the contents of a file DN >called "HappyDays", you would use the command named "cat": DN > cat HappyDays DN >Why cat? Why not? After all, said Humpty Dumpty to Alice, DN >who is to be the boss, words or us? The use of an alias, or 1-line shell script, easily provides the functionality of "cat" by any name the user desires. DN > The standard text editor is called Ed. Ding. DN > [...] and Unix move (mv) and copy (cp) operations will DN > destroy existing files without any warning. "mv -i". "cp -i". Also around when he wrote his paper. DN> The bad news is that Berkeley Unix is jury-rigged on DN> top of regular Unix, so it can only patch up the faults: it DN> can't remedy them. This belies the contributions of the CSRG team. DN > The listing program is called "more" (as in, DN > "give me more"). Ah, so he does know about "more"; then why berate "cat"? DN > A common theme runs through the com- DN > mands: don't be nice to the casual user -- write the system DN > for the dedicated expert. The system is a recluse. It uses DN > weird names, and it won't speak to you, not even if spoken DN > to. For system programmers, Unix is a delight. It is well DN > structured, with a consistent, powerful philosophy of con- DN > trol and structure. My complaint is simple: why was not DN > the same effort put into the design at the level of the user? Actually, here, he's dead right. Unix was written for programmers by programmers, and the biggest mistake we've ever made as a community was trying to dumb it down so that the average clueless user could use it. Let 'em have Macintoshes. Gimme back "dsw". ---Rsk # This is a shell archive. # Remove everything above and including the cut line. # Then run the rest of the file through sh. #----cut here-----cut here-----cut here-----cut here----# #!/bin/sh # shar: Shell Archiver # Run the following text with /bin/sh to create: # rumor.shrink # rumor.ber # rumor.bh # rumor.clyde # rumor.eps # rumor.greg # rumor.henry # rumor.henry2 # rumor.jej # rumor.jerry # rumor.mark # rumor.mark2 # rumor.mo # rumor.nowicki # rumor.swd # This archive created: Thu Nov 12 18:58:11 1992 # By: Rich Kulawiec (GSP Whitewater Slalom Racing Team) cat << \SHAR_EOF > rumor.shrink From cincy!duke!decvax!utzoo!datamat!rumor Sat Aug 1 23:37:27 PDT 1981 The Truth about UNIX: fa.unix-wizards The truth about Unix: The user interface is horrid Donald A. Norman Department of Psychology and Program in Cognitive Science Center for Human Information Processing University of California, San Diego La Jolla, California 92093 (to appear in Datamation) Unix is a highly touted operating system. Developed at the Bell Telephone Laboratories and distributed by Western Electric, it has become a standard operating system in Universities, and it promises to become a standard for the large micro- mini- systems for home, small business, and educational setting. But for all its virtues as a system -- and it is indeed an elegant system -- Unix is a disaster for the casual user. It fails both on the scientific principles of human engineering and even in just plain common sense. The motto of the designers of Unix towards the user seems to be "let the user beware." If Unix is really to become a general system, then it has got to be fixed. I urge correction to make the elegance of the system design be reflected as friendliness towards the user, especially the casual user. I have learned to get along with the vagaries of its user interface, but our secretarial staff persists only because we insist. And even I, a heavy user of computer systems for 20 years have had difficulties: copying the old file over the new, transfer- ring a file into itself until the system collapsed, and removing all the files from a directory simply because an extra space was typed in the argument string. In this arti- cle I review both the faults of Unix and also some of the principles of Cognitive Engineering that could improve things, not just for Unix, but for computer systems in gen- eral. But first, the conclusion; Unix fails several simple tests. Consistency: The command names, language, functions and syntax are inconsistent. Functionality: The command names, formats, and syntax seem to have no relationship to their functions. Friendliness: Unix is a recluse, hidden from the user, silent in operation. "No news is good news" is its motto, but as a result, the user can't tell what state the system is in, and essentially, is completely out of touch with things. Cognitive Engineering: The system does not understand August 2, 1981 - 2 - about normal folks, the everyday users of Unix. Cognitive capabilities are strained beyond their limits, the lack of mnemonic structures places large loads of memory, and the lack of interaction puts a strain on one's ability to retain mentally exactly what state the system is in at any moment. (Get distracted at the wrong time and you lose your place -- and maybe your file.) What is good about Unix? The system design, the generality of programs, the file structure, the job structure, the powerful operating system command language (the "shell"). To bad the concern for system design was not matched by an equal concern for the human interface. One of the first things you learn when you start to decipher Unix is how to list the contents of a file onto your terminal. Now this sounds straightforward enough, but in Unix even this simple operation has its drawbacks. Sup- pose I have a file called "testfile". I want to see what is inside of it. How would you design a system to do it? I would have written a program that listed the contents onto the terminal, perhaps stopping every 24 lines if you had signified that you were on a display terminal with only a 24 line display. To the designers of Unix, however, such a solution lacks elegance. Unix has no basic listing com- mand, but instead you must use a program meant to do some- thing else. In Unix, if you wanted to list the contents of a file called "HappyDays", you would use the command named "cat": cat HappyDays Why cat? Why not? After all, said Humpty Dumpty to Alice, who is to be the boss, words or us? "Cat", short for "con- catenate" as in, take file1 and concatenate it with file2 (yielding one file, with the first part file1, the second file2) and put the result on the "standard output" (which is usually the terminal): cat file1 file2 Obvious right? And if you have only one file, why cat will put it on the standard output -- the terminal -- and that accomplishes the goal (except for those of us with video terminals who watch helplessly as the text goes streaming off the display). The Unix designers are rather fond of the principle that special purpose functions can be avoided by clever use of a small set of system primitives. Their philosophy is essentially, don't make a special function when the side- effects of other functions will do what you want. But there are several reasons why this philosophy is bad; August 2, 1981 - 3 - 1. A psychological principle is that names should reflect function, else the names for the function will be difficult to recall; 2. Side-effects can be used for virtue, but they can also have unwarranted effects. Thus, if cat is used unwisely, it will destroy files (more on this in a moment). 3. Special functions can do nice things for users, such as stop at the end of screens, or put on page headings, or transform non-printing characters into printing ones, or get rid of underlines for terminals that can't do that. Cat, of course, won't stop at terminal or page boundaries, because if it did that, why that would disrupt the concate- nation feature. But still, isn't it elegant to use cat for listing? Who needs a print or a list command. You mean "cat" isn't how you would abbreviate concatenate? gee, it seems so obvious to us. Just like _f_u_n_c_t_i_o_n _U_n_i_x _c_o_m_m_a_n_d _n_a_m_e c compiler cc change working directory chdir (cd in Berkeley Unix) change password passwd concatenate cat copy cp date date echo echo editor ed link ln move mv remove rm search file for pattern grep Notice the lack of consistency in forming the command name from the function. Some names are formed by using the first two consonants of the function name, unless it is the editor which is abbreviated "ed" and concatenate which is "cat" or "date" or "echo" which are not abbreviated at all. Note how useful those 2 letter abbreviations are. See how much time and effort is saved typing only 2 letters instead of -- heaven forbid -- 4 letters. So what is a little inconsistency among friends, especially when you can save almost 400 milliseconds per command. Similar statements apply to the names of the file directories. Unix is a file oriented system, with hierarch- ical directory structures, so the directory names are very important. Thus, this paper is being written on a file named "unix" and whose "path" is /csl/norman/papers/CogEngineering/unix. The name of the top directory is "/", and csl, norman, papers, and CogEngineer- ing are the names of directories hierarchically placed August 2, 1981 - 4 - beneath "/". Note that the symbol "/" has two meanings: the name of the top level directory and the symbol that separates levels of the directories. This is very difficult to justify to new users. And those names: the directory for "users" and "mount" are called, of course, "usr" and "mnt." And there are "bin," "lib," and "tmp." (What mere mortals might call binary, library, and temp). Unix loves abbrevi- ations, even when the original name is already very short. To write "user" as "usr" or "temp" as "tmp" saves an entire letter: a letter a day must keep the service person away. But Unix is inconsistent; it doesn't abbreviate everything as 2 or 3 letter commands. It keeps "grep" at its full four letters, when it could have been abbreviated as "gr" or "gp". (What does grep mean, you may ask. "Global REgular expression, Print" -- at least that's the best we can invent, the manual doesn't even try to say. The name wouldn't matter if grep were something obscure, hardly ever used, but in fact it is one of the more powerful, frequently used string processing commands. But that takes me from my topic.) Do I dare tell you about "dsw"? This also turns out to be an important routine. Suppose you accidentally create a file whose name has a non-printing character in it. How can you remove it? The command that lists the files on your directory won't show non-printing characters. And if the character is a space (or worse, a "*"), "rm" (the program that removes files) won't accept it. "dsw" was evidently written by someone at Bell Labs who felt frustrated by this problem and hacked up a quick solution. Dsw goes to each file in your directory and asks you to respond "yes" or "no," whether to delete the file or keep it (or is it to keep it or delete it -- which action does "yes" mean?). How do you remember dsw? What on earth does the name stand for? The Unix people won't tell; the manual smiles its wry smile of the professional programmer and says "The name dsw is a carryover from the ancient past. Its etymology is amusing." (The implication, I guess, is that true professionals never need to use such a program, but they are allowing it to be released for us novices out in the real world.) Which __________________________ Verification of my charges comes from the experiences of the many users of Unix, and from the modifications that other people have been forced to make to the sys- tem. Thus, the system of Unix I now use is called The Fourth Berkeley Edition for the Vax, distributed by Joy, Babaoglu, Fabry, and Sklower at the University of California, Berkeley (henceforth, Berkeley Unix). They provide a listing program that provides all the features I claim a user would want (except a sensible name -- but Berkeley Unix even makes it easy to change system names to anything you prefer). August 2, 1981 - 5 - operation takes place if you say "yes": why the file is deleted of course. So if you go through your files and see important-file, you nod to yourself and say, yes, I better keep that one, type in yes, and destroy it forever. Does dsw warn you? Of course not. Does dsw even document itself when it starts, to remind you which way is which? Of course not. That would be talkative, and true Unix programmers are never talkative. (Berkeley Unix, has finally killed dsw, saying "This little known, but indispensible facility has been taken over...". That is a fitting commentary on standard Unix: a system that allows an "indispensible facility" to be "little known.") The symbol "*" means "glob" (a typical Unix name: the name tells you just what action it does, right?). Let me illustrate with our friend, "cat." Suppose I want to put together a set of files named paper.1 paper.2 paper.3 and paper.4 into one file. I can do this with cat: cat paper.1 paper.2 paper.3 paper.4 > newfilename Unix provides "glob" to make the job even easier. Glob means to expand the filename by examining all files in the directory to find all that fit. Thus, I can redo my command as cat paper* > newfilename where paper* expands to {paper.1 paper.2 paper.3 paper.4}. This is one of the typical virtues of Unix; there are a number of quite helpful functions. But suppose I had decided to name this new file "paper.all". After all, this is a pretty logical name, I am combining the separate indi- vidual files into a new one that contains "all" the previous ones. cat paper* > paper.all Disaster. I will probably blow up the system. In this case, paper* expands to paper.1 paper.2 paper.3 paper.4 paper.all, and so I am filling up a file from itself: cat paper.1 paper.2 paper.3 paper.4 paper.all > paper.all Eventually the file will burst. Does nice friendly Unix check against this, or at least give a warning? Oh no, that would be against the policy of Unix. The manual doesn't bother warning against this either, although it does warn of another, related infelicity: "Beware of 'cat a b > a' and 'cat b a > a', which destroy the input files before reading them." Nice of them to tell us. The command to remove all files that start with the word "paper" rm paper* becomes a disaster if a space gets inserted by accident: rm paper * for now the file "paper" is removed, as well as every file in the entire directory (the power of glob). Why is there not a check against such things? I finally had to alter my August 2, 1981 - 6 - version of rm so that when I said to remove files, they were actually only moved to a special directory named "deleted" and they didn't actually get deleted until I logged off. This gave me lots of time for second thoughts and for catch- ing errors. This also illustrates the power of Unix: what other operating system would make it so easy for someone to completely change the operation of a system command for their own personal satisfaction? This also illustrates the evils of Unix: what other operating system would make it so necessary to do so? (This is no longer necessary now that we use Berkeley Unix -- more on this in a moment.) The standard text editor is called Ed. What a problem that turned out to be. It was so lovely that I spent a whole year using it as an experimental vehicle to see how people dealt with such awful things. Ed's major property is his shyness; he doesn't like to talk. You invoke Ed by say- ing, reasonably enough, "ed". The result is silence: no response, no prompt, no message, just silence. Novice are never sure what that silence means. What did they do wrong, they wonder. Why doesn't Ed say "thank you, here I am" (or at least produce a prompt character)? No, not Unix with the philosophy that silence is golden. No response means that everything is ok. If something had gone wrong, then it would have told you (unless the system died, of course, but that couldn't happen could it?). Then there is the famous append mode error. To add text into the buffer, you have to enter "append mode." To do this, one simply types "a", followed by RETURN. Now everything that is typed on the terminal goes into the buffer. (Ed, true to form, does not inform you that it is now in append mode: when you type "a" followed by "RETURN" the result is silence, no message, no comment, nothing.) When you are finished adding text, you are supposed to type a line that "contains only a . on it." This gets you out of append mode. Want to bet on how many extra periods got inserted into text files, or how many commands got inserted into texts, because the users thought that they were in com- mand mode and forgot they had not left append mode? Does Ed tell you when you have left append mode? Hah. This problem is so obvious that even the designers knew about it, but their reaction was to laugh: "hah-hah, see Joe cry. He just made the append mode error again." In the tutorial introduction to Ed, written at Bell Labs, the authors joke about it. Even experienced programmers get screwed this way, they say, hah hah, isn't that funny. Well, it may be funny to the experienced programmer, but it is devastating to the beginning secretary or research assistant or student who is trying to use friendly Unix as a word processor, or as an experimental tool, or just to learn about computers. Anyone can use Unix says the programmer, all you need is a sense of humor. August 2, 1981 - 7 - How good is your sense of humor? Suppose you have been working on a file for an hour and then decide to quit work, exiting Ed by saying "q". The problem is that Ed would promptly quit. Woof, there went your last hour's work. Gone forever. Why, if you would have wanted to save it you would have said so, right? Thank goodness for all those other people across the country who immediately rewrote the text editor so that us normal people (who make errors) had some other choices besides Ed, editors that told you politely when they were working, that would tell you if they were in append or command mode, and that wouldn't let you quit without saving your file unless you were first warned, and then only if you said you really meant it. I could go on. As I wrote this paper I sent out a mes- sage on our networked message system and asked my colleagues to tell me of their favorite peeves. I got a lot of responses, but there is no need to go into detail about them; they all have much the same flavor about them, mostly commenting about lack of consistency, about the lack of interactive feedback. Thus, there is no standardization of means to exit programs (and because the "shell" is just another program as far as th system is concerned, it is very easy to log yourself off the system by accident). There are very useful pattern matching features (such as the "glob" * function), but the shell and the different programs use the symbols in inconsistent ways. The Unix copy command (cp) and the related C programming language "stringcopy" (strcpy) have reversed order of arguments, and Unix move (mv) and copy (cp) operations will destroy existing files without any warning. Many programs take special "argument flags" but the manner of specifying the flags is inconsistent, varying from program to program. As I said, I could go on. The good news is that we don't use standard Unix: we use Berkeley Unix. History lists, aliases, a much richer and more intelligent set of system programs, including a list program, an intelligent screen editor, a intelligent set of routines for interacting with terminals according to their capabilities, and a job control that allows one to stop jobs right in the middle, startup new ones, move things from background to foreground (and vice versa), examine files, and then resume jobs. And the shell has been ampli- fied to be a more powerful programming language, complete with file handling capabilities, if--then--else statements, while, case, and all the other goodies of structured pro- gramming (see the accompanying box on Unix). Aliases are worthy of special comment. Aliases let the user tailor the system to their own needs, naming things in ways they themselves can remember: self-generated names are indeed easier to remember than arbitrary names given to you. August 2, 1981 - 8 - And aliases allow abbreviations that are meaningful to the individual, without burdening everyone else with your clev- erness or difficulties. To work on this paper, I need only type the word "unix," for I have set up an alias called "unix" that is defined to be equal to the correct command to change direc- tories, combined with a call to the editor (called "vi" for "visual" on this system) on the file: alias unix "chdir /csl/norman/papers/CogEngineering; vi unix" These Berkeley Unix features have proven to be indispens- able: the people in my laboratory would probably refuse to go back to standard Unix. The bad news is that Berkeley Unix is jury-rigged on top of regular Unix, so it can only patch up the faults: it can't remedy them. Grep is not only still grep, but there is an egrep and an fgrep. But worse, the generators of Berkeley Unix have their problems: if Bell Labs people are smug and lean, Berkeley people are cute and overweight. Programs are wordy. Special features proliferate. Aliases -- the system for setting them up is not easy to for beginners (who may be the people who need them most). You have to set them up in a file called .cshrc, a name not chosen to inspire confidence! The "period" in the filename means that it is invisible -- the normal method of directory listing programs won't show it. The directory listing pro- gram, ls, comes with 19 possible argument flags, that can be used singly or in combinations. The number of special files that must be set up to use all the facilities is horrendus, and they get more complex with each new release from Berke- ley. It is vey difficult on new users. The program names are cute rather than systematic. Cuteness is probably better than the lack of meaning of standard Unix, but there are be limits. The listing program is called "more" (as in, "give me more"), the program that tells you who is on the system is called "finger", and a keyword help file -- most helpful by the way -- is called "apropos." Apropos! who can remember that? Especially when you need it most. I had to make up an alias called "help" which calls all of the help commands Berkeley provides, but whose names I can never remember (apropos, whatis, whereis, which). __________________________ The system is now so wordy and so large that it no longer fits on the smaller machines: our laboratory machine, a DEC 11/45, cannot hold the latest release of Berkeley Unix (even with a full complement of memory and a reasonable amount of disc). I write this paper on a Vax. August 2, 1981 - 9 - One reader of a draft of this paper -- a systems pro- grammer -- complained bitterly: "Such whining, hand- wringing, and general bitchiness will cause most people to dismiss it as over-emotional nonsense. ... The Unix system was originally designed by systems programmers for their own use and with no intention for others using it. Other hackers liked it so much that eventually a lot of them started using it. Word spread about this wonderful system, etc, the rest you probably know. I think that Ken Thompson and Dennis Ritchie could easily shrug their shoulders and say 'But we never intended it for other than our personal use.'" All the other users of Unix who have read drafts of this paper agreed with me. Indeed, their major reaction was to forward examples of problems that I had not covered. This complaint was unique. I do sympathize with the spirit of the complaint. He is correct, but ... The "but" is that the system is nationally distributed, under strict licensing agreements, with a very high charge to industry, and nominal charges to educational institutes. Western Electric doesn't mind getting a profit, but they have not attempted to worry about the product. If Unix were still what it started to be, a simple experiment on the develop- ment of operating systems, then the complaints I list could be made in a more friendly, constructive manner. But Unix is more than that. It is taken as the very model of a proper operating system. And that is exactly what it is not. In the development of the system aspects of Unix, the designers have done a magnificent job. They have been creative, and systematic. A common theme runs through the development of programs, and by means of their file struc- ture, the development of "pipes" and "redirection" of both input and output, plus the power of the iterative "shell" system-level commands, one can combine system level programs into self-tailored systems of remarkable power with remark- able ease. In the development of the user interface aspects of Unix, the designers have been failures. They have been dif- ficult and derisive. A common theme runs through the com- mands: don't be nice to the casual user -- write the system for the dedicated expert. The system is a recluse. It uses weird names, and it won't speak to you, not even if spoken to. For system programmers, Unix is a delight. It is well structured, with a consistent, powerful philosophy of con- trol and structure. My complaint is simple: why was not the same effort put into the design at the level of the user? The answer to my complaint is a bit more complex. There really are no well known principles of design at the level of the user interface. So, to remedy the harm that I may have caused by my heavy-handed sarcasm, let me attempt to provide some positive suggestions based upon the research August 2, 1981 - 10 - that has been done by me and by others into the principles of the human information processing system. Cognitive Engineering is a new discipline, so new that it doesn't exist: but it ought to. Quite a bit is known about the human information processing system, enough that we can specify some basic principles for designers. People are complex entities and can adapt to almost anything. As a result, designers are often sloppy, for they can design for themselves without realizing the difficulties that will be faced by other users. Moreover, there are different lev- els of users: people with a large amount of knowledge of the device they are about to use are quite different from those who lack a basic understanding. Experts are different than novices. And the expert who is normally skilled at the use of some systems but who has not used it for awhile is at a peculiar level of knowledge, neither novice nor expert. The three most important concepts for system design are these: 1. Be consistent. A fundamental set of principles ought to be evolved and followed consistently throughout all phases of the design. 2. Provide the user with an explicit model. Users develop mental models of the devices with which they interact. If you do not provide them with one, they will make one up themselves, and the one they make up is apt to be wrong. Do not count on the user fully understanding the mechanics of the device. Secretaries and scientists alike will share a lack of knowledge of a computer system. The users are not apt to understand the difference between the buffer, the working memory, the work- ing files, and the permanent files of a text edi- tor. They are apt to believe that once they have typed something into the system, it is permanently in their files. They are apt to expect more intelligence from the system than the designer knows is there. And they are apt to read into comments (or the lack of comments) more than you have intended. Feedback is of critical impor- tance, both in helping to establish the appropri- ate mental model and in letting the user keep its current state in synchrony with the actual system. 3. Provide mnemonic aids. Human memory is a fragile thing. Actually, for most purposes it is con- venient to think of human memory as consisting of two parts: a short-term memory and a long-term memory (modern cognitive psychology is developing more sophisticated notions than this simple two- August 2, 1981 - 11 - stage one, but this is still a valid approxima- tion). Short-term memory is, as the name sug- gests, limited in duration and quantity: about five to seven items is the limit. Thus, do not expect a user to remember the contents of a mes- sage for much longer than it is visible on the terminal. Long-term memory is robust, but it faces two difficulties: getting stuff in so that it is properly organized and getting stuff out, so that it can be found when needed. Learning is difficult, unless there is a good structure, and it is visible to the learner. The system designer must provide sensible assistance to the user so that the material can be structured. There are lots of sensible memory aids that can be provided, but the most powerful and sensible of all is understanding. Make a system so that it can be understood and the memory follows with ease. Make the command names ones that can be understood, where the names follow from the function that is desired. If abbreviations must be used, adopt a consistent policy of forming the abbreviations. Do not deviate from the policy, even when it appears that it would be easier for a particular command to deviate: inconsistency is an evil. Remember the major problem of any large-scale memory is finding the information that is sought, even if the information is there someplace. We retrieve things from memory by starting off with some description of the information we seek, use that description to enter their memory system in an attempt to match against the desired information. If the designer uses cute names and non-standard abbreviations, our ability to generate a valid description is impaired. As a result, the person who is not expert and current in the use of the system is apt to flounder. There are many ways of formatting information on termi- nals to provide useful memory and syntax aids for users. With today's modern terminals, it is possible to use menus, multiple screens and windows, highlighted areas, and with full duplex systems, automatic or semi-automatic command completion systems. The principles for these systems are under active study by a number of groups, but none are directly relevant to my critique of the UNIX operating sys- tem. UNIX is designed specifically so that it can be used with a wide variety of terminals, including hard copy termi- nals. The problem with Unix is more fundamental. Unix does not provide the user with a systematic set of principles; it August 2, 1981 - 12 - does not provide a simple, consistent mental model for the user, consistent not only in the shell but in the major sys- tem programs and languages; it does not provide the user with simple memory aids that can be used to learn the system structure and then, when one is not completely current in the use of a particular command, still to be able to retrieve (or better, derive) what is needed. There are essentially no user help files, despite the claim that all the documentation is on-line via the command named man (for manual, of course). But "man" requires you to know the name of the command you want information about, although it is the name that is probably just the information you are seek- ing. System designers take note. Design the system for the person, not for the computer, not even for yourself. People are also information processing systems, with varying degrees of knowledge, varying degrees of experience. Remember, people's short-term memories are limited in size, and they learn and retrieve things best when there is a con- sistent reason for the name, the function, and the syntax. Friendly systems treat users as intelligent adults who, like normal adults, are forgetful, distracted, thinking of other things, and not quite as knowledgeable about the world as they themselves would like to be. Treat the user with intelligence. There is no need to talk down to the user, nor to explain everything. But give the user a share in understanding by presenting a consistent view of the system. __________________________ SHAR_EOF cat << \SHAR_EOF > rumor.ber From uucp Fri Aug 14 11:59:42 1981 remote from pur-ee NAharpo.423 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!mhtsa!harpo!ber NThu Aug 13 23:31:58 1981 NYAUF NGee whiz. Bitch bitch bitch. There is better documentation than Nmanual pages provided with your unix system. The manual page Nis a brief description of a command, routine or concept. It's a starting Npoint, and frequently enough. If you want to know more, look at the source. N NI think the page for lorder is terrific. I never use lorder for anything Nother than ordering libraries, and to have an example right there is great. N NAll this crap about UNIX being unfriendly and UNIX lacking documentation Nand so on is just that. UNIX is an operating system. It's clean, concise, Nand clear (at least traditionally). The beauty of the environment that Ngenerally surrounds a unix is that it is easilly growable by the people Nthat use it. If some turkey writes a poor manual page, then unix is blamed. NLook at all the crap you have to deal with at IH because they won't permit Na public directory for NON-STANDARD this and that. Well I guess they want Nto make sure nobody polutes their system. That stinks. But that's the only Nway your going to censor it. At least you can point your finger directly Nat the computer center staff. N NIf you don't like a command or documentation your free to avoid it. NOr better yet, improve it! Unix provides an excellent program development Nenvironment. If you can't figure out what a syntax error is, ask someone. NYou'll find dozens of experts in every hallway. Why? Because it's relatively Neasy to comprehend. N NPlease don't start restricting creativity with naming standards and style Nstandards and how many lines are permitted in a subroutine ... NThat's almost tolerable for a project, but unix isn't a number 7 electronic Nsump pump. Just because management feels that 'C' and UNIX are the do-all Nto end-all doesn't make it so. And the attempts to fit that misconception Nare ruining a perfectly good environment. N NWhy don't you send your comments to the MINI-SYSTEM newsletter in the Nform of a modification request? I'ld like to see an OFFICIAL response. N N(deep breath) N NNow I feel better. Let's face it, unix is not geared to the naive user. NSo what? It's great for the knowledgable user. Why bring the level Nof excellence down to least common denominator? For a profit! Yeh well Nthat's another story. But let's try to raise the level of the users. SHAR_EOF cat << \SHAR_EOF > rumor.bh From uucp Fri Aug 14 11:39:22 1981 remote from pur-ee NAucbvax.2619 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NTue Aug 11 09:14:54 1981 Nunix on large machines N>From BH@SU-AI Tue Aug 11 09:06:37 1981 NSince KLH doesn't seem to have answered the request for details on Nwhy UNIX isn't perfect for big machines, let me try: N N1. The file system is flaky. UCB is working on some aspects of Nthis problem but not all. They seem to be fixing the problems in Nwhich a disk block is added to one list BEFORE it's removed from Nanother, which is how the file system is compromised by a system Ncrash. But they aren't changing the fact that overwriting a file N(a creat with an existing name) deletes the old file right away Nrather than on a successful close, nor are they adding an exclusive Naccess discipline to the kernel. (About once a month or so my N/etc/passwd disappears when several people try to change their Npasswords or create new accounts at once, despite supposedly Nfoolproof lock-file code in the user programs.) N N2. Debugging facilities leave a lot to be desired. You can't Ntype instuctions in to adb, so it's hard to patch code. The Nsymbol table doesn't know about things like fields in a struct, Nso symbolic debugging only partly exists. You can't use adb Nstandalone to poke at a crashed system. N N3. Many smaller, easily-fixed things show that UNIX was designed Nwith a small machine in mind. One example: the result of compiling N"foo.c" should be called "foo", not "a.out". Clearly they designed Nthe naming convention for a machine without much disk space, in which Nit was antisocial to have executable files for more than one program Nat a time! N N4. There are terminals in the world other than the model 37 TTY. NThe UCB termcap package makes it possible for there to be a few Nhuge, hairy user programs which support displays. But there needs Nto be kernel support (or the equivalent in shell support, with Nall other user level tty interaction funneled through the shell, Nwhich would be awkward) for things like automatically dividing the Ndisplay screen into pieces for different processes. The user must Nbe able to type escape sequences of some sort to control which piece Nhse's typing into right now. It should be possible to write a NTRIVIAL user program which can still fit into this display Ndiscipline, e.g., it shoul be able to type a control-L and have that Nmean "clear my piece of the screen". N N5. Some things aren't written as efficiently as they might be. N NThere's more, but this will do to begin the discussion. Mind you, NI think UNIX is wonderful in many ways. Pipes are great, filters Nare great, process trees are great, etc. Many of the flaws in UNIX Ncould be fixed in a more or less compatible way. (Not the one about Ndeleting the old file too soon, though.) (By the way, yes I know Nyou can program around it. The difference between an okay system and Na great system is that you don't have to program around the great Nsystem, you can program THROUGH it!) It's not that the future Nlarge-computer standard operating system should look nothing like NUNIX, it's that the standard large-computer UNIX needs some redesign Nbefore it gets ossified as a standard. N N N SHAR_EOF cat << \SHAR_EOF > rumor.clyde From uucp Fri Aug 14 11:59:13 1981 remote from pur-ee NAucbvax.2671 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NThu Aug 13 10:01:32 1981 NReply to 'The Truth about UNIX' N>From clyde@UTEXAS-11 Thu Aug 13 09:53:17 1981 N N While the gentelman has some cogent points, I also believe he Nhas permanent brain damage . He is obviously used to DEC systems which Nlike to hold lusers hands lest they damage themselves, and I had great Ndifficulty reading completly through his treatise (diatribe?) because Nof his own inconsistancies and notions. N N Oh well, not everyone can be enthusiatic (though I noticed he Nwrote his document on a UNIX system, using NROFF -- I wonder how Nhe managed to hold his nose with one hand and type with the other) . N------- N SHAR_EOF cat << \SHAR_EOF > rumor.eps From uucp Fri Aug 14 11:56:06 1981 remote from pur-ee NAucbvax.2642 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NTue Aug 11 22:35:29 1981 NRe: The Truth about UNIX N>From Eps@UCLA-SECURITY Tue Aug 11 22:31:19 1981 NThe date given on this mesage is obviously wrong; Nit should have read "Apr 1" instead of "Aug 1." N N --Eric N------- N N SHAR_EOF cat << \SHAR_EOF > rumor.greg From uucp Fri Aug 14 11:43:52 1981 remote from pur-ee NAucbvax.2643 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NWed Aug 12 00:12:07 1981 NYet more truth about Unix..... N>From greg@NPRDC Wed Aug 12 00:08:58 1981 NI almost hesitate to mention this, but Donald A. Norman, the author of N"The Truth About Unix", gets mail as "Norman at NPRDC". (NPRDC is Nnotorious enough; a little more won't hurt, right?) You could send him Ncopies of your flames to see if he might respond. It could be a very Ninteresting discussion..... N---- N SHAR_EOF cat << \SHAR_EOF > rumor.henry From cincy!duke!decvax!utzoo!henry Sun Aug 9 23:43:32 1981 datamat!rumor : net.general,NET.general There is no such system as "datamat" connected to us, nor is there any person named "rumor" locally. Any communication purporting to be from such a person at such an address is either garbled or fraudulent. Will somebody PLEASE tell me why we are suddenly getting tons of mail addressed to "...!utzoo!datamat!rumor", apparently related to an unfriendly evaluation of Unix that I have never heard of and that most certainly did not come from here? SHAR_EOF cat << \SHAR_EOF > rumor.henry2 From uucp Fri Aug 14 11:56:36 1981 remote from pur-ee NAutzoo.885 Nnet.general,NET.general,fa.unix-wizards Npur-ee!cincy!duke!decvax!utzoo!henry NThu Aug 13 00:56:51 1981 Ndatamat!rumor NI've now seen a copy of the infamous utzoo!datamat!rumor article Nthat has caused all the fuss (I thank decvax!jm for mailing it to Nme). It most definitely DID NOT originate at or pass through Ndecvax!utzoo, the University of Toronto Zoology department. The N"PDT" in its postmark strongly suggests a west-coast origin, as Ndoes the author's affiliation, and a friend of mine who gets various Nthings from the Arpanet community says he has seen "utzoo" on the Ncc-list of a document that may even be the same article (we haven't Nyet had a chance to compare notes). THIS IS NOT US. We may have Na first here: the first real live authentic name conflict on Usenet. N[Why me, Lord?] Would anyone knowing the possible identity of the Nother "utzoo" please pass this information on to me? My friend's Ncomments suggest it may be in the Stanford area, the origin of Nthe article itself suggests the San Diego area. N N Henry Spencer N decvax!utzoo!henry N (416)978-2006 (for now) N (416)978-6060 (shortly) SHAR_EOF cat << \SHAR_EOF > rumor.jej From uucp Fri Aug 14 11:55:22 1981 remote from pur-ee NAihuxl.103 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!ihnss!ihuxl!jej NThu Aug 13 20:19:50 1981 NForced Interaction, and YAUF (Yet Another Unix Flame) NSubject: program interface to mail-like commands, Unix documentation N NI've run into a problem of how to automate commands that, to quote NRitchie, "force interaction on the user whether it is wanted or not:" Nthe primordial example is mail. N NIt is not clear how one could write a program that would issue the Ncorrect commands to mail to do a particular filtering, such as "save Nall mail from John Doe, and delete the rest after printing it offline." Nmail expects standard input to direct it, based on what it itself has Noutput. N NAny notions of a technique for writing such programs? N N---------------------------------------- N NThe item about the Unix user interface was very good--one item Nthat the author left out, though, was Unix documentation. N NMost notorious, I think, are the multitude of manual pages which Nsay about the error messages that they are "self-explanatory." NI believe that this must mean that the author intends them to be Nmeaningful to himself. N NExamples: N N1. run-time error messages from C programs--these are QUITE machine N dependent; rather embarassingly so for an OS based on C as N Unix is, one would think. N2. C compiler error messages, which describe every syntax error as N "syntax error," which may be enough for Dennis Ritchie, but N not for mere mortals. Another worthless error message is N that which describes the error in terms of compiler internals. N What does that have to do with the constructs the user knows? N NAlso quite helpful are the error codes one gets from make(1), such as N"Error code 100". N NManual pages are frequently vague and casual: I recall the times when NI had to try VERY hard to persuade someone that egrep(1) should treat N'$' as just another character when it is not at the end of a regular Nexpression, and in another case, that ed(1) permitted nested escaped Nparentheses in regular expressions. Formal specifications of options Nand accepted commands may not be useful to some readers, but they cer- Ntainly are more useful to those who CAN understand them than vague NEnglish prose. N N"Casualness" at times degenerates into flippancy or display of the Nauthor's self-estimated cleverness: e.g. N N "This brash one-liner intends to build a new library from N existing .o files." (This sentence, with absolutely NO other N explanation, accompanies an example of lorder(1).) N Nor N N "This is an area where experience and informed courage N count for much." N NWhat good do these do to the reader who is trying to figure out Nwhat on EARTH a command does? N NOptions on commands, in a sense documentation, don't have much chance Nto indicate their meaning, since they're typically restricted to one Nletter. (Some day I intend to write a phony command page containing N N SYNOPSIS N cmd -[abcdefghijklmnopqrstuvwxyz] name ... N N OPTIONS N -a Use the 'a' option. Netc.) N N James Jones (ihuxl!jej) SHAR_EOF cat << \SHAR_EOF > rumor.jerry From uucp Fri Aug 14 09:31:36 1981 remote from pur-ee NAharpo.407 Nnet.general Npur-ee!cincy!duke!mhtsa!harpo!jerry NWed Aug 12 10:42:36 1981 Nforgery N NI suppose Steve should know better than I do, but why couldn't Na forger just uux (or execute directly) rnews on a machine Nwith the input indicating the item came from datamat!rumor. NIn fact couldn't you drop it in almost anywhere in the net? NPotentially the later can be detected because you will end up with Npeculiar headers (e.g. the item Nappears to have passed through a machine twice.) A little Nmore cleverness, and a better understanding of netnews might Ncircumvent even that problem, and in any event the only thing Nyou could learn would be the machine rnews was executed on. SHAR_EOF cat << \SHAR_EOF > rumor.mark From uucp Sun Aug 9 15:54:14 1981 remote from pur-ee NAucbvax.2534 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!mark NWed Aug 5 08:47:18 1981 NThe truth about Unix NI read your Unix flame with interest, but you seem to be Nill informed about lots of things. Obviously you are comparing NV6 Unix with 3BSD, but you claim to be comparing "Unix" with N"Berkeley Unix". You credit Berkeley with things that are Npart of V7 (getting rid of dsw, adding egrep and fgrep). NI might compare your note with a message saying "don't go Nout and buy a 1975 VW Rabbit - those are crummy cars because Nthe 1979 Rabbit is better". (No, I'm not complaining about Nthe recent Rabbit note, this just happened to be a handy example). NYou also claim that "Berkeley Unix is too big to fit ... on an 11/45". NHogwash! 3BSD is a Vax distribution - it has a C compiler that Ngenerates Vax object code, a kernel that knows the Vax memory management Nand I/O conventions, and some other VAX specific things. So are 4BSD Nand 4.1BSD, which superceded 3BSD the same way V7 has superceeded V6. NWe have lots of PDP-11's here at Berkeley, including 70's, a 45, and Nseveral 40's. Most of them run some version of Berkeley Unix. NBigness is not important - we run vi 3.6 on a 40 in the virus lab. NOf course, it is a different system than the one on the vax. N"Berkeley Unix" is about as specific as "Chevrolet". N NYou also have to bear in mind that the various flavors of Unix have Nevolved from one system years ago in Bell Labs. In upgrading from Nversion x to version x+1, issues of upward compatibility have to Nbe taken into account. If you changed /usr to /user, not only would Nyou infuriate most of the users "What a pointless change! Now I Nhave to retype half my commands!" but you would break a large number Nof programs that look for such places as /usr/spool/mail, /usr/dict/words, Nand so on. Things that are not obviously wrong and horrible tend Nto get left alone. (There are, unfortunately, exceptions. index Nand rindex are called strchr and strrchr in some versions of Unix.) SHAR_EOF cat << \SHAR_EOF > rumor.mark2 From uucp Mon Aug 10 22:18:44 1981 remote from pur-ee NAucbvax.2598 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NMon Aug 10 12:23:20 1981 NEUNUCH for large machines N>From csvax.mark@Berkeley Mon Aug 10 12:15:19 1981 NCare to back up your flame about big machines with some reasons? NIt does run on a Vax, Univac 1100, Amdahl, 370, and 3B. N NBell invests lots of effort into Unix - about as much as the rest Nof the world. But their version doesn't get released. N N Mark N N SHAR_EOF cat << \SHAR_EOF > rumor.mo From uucp Fri Aug 14 11:40:30 1981 remote from pur-ee NAucbvax.2628 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NTue Aug 11 11:41:44 1981 NFlaming Psychologists N>From mo@LBL-UNIX Tue Aug 11 11:23:32 1981 NWell, you see what kind of stuff gets into DATAMATION. NI don't understand these things: many of the criticisms Nare right, but the facts are categorically wrong! Unix Ncould benefit from some "normalizaion" (the Software Tools Nbenefitted greatly from having been written all at once, not Nover the years), but the claim that Unix does not present Na simple set of principles is the most incomprehensible Nstatement he could have made! That is ALL Unix does, Nand that is precisely why he doesn't like it! If he hates Nit so much, why doesn't he go get an account on a TOPS-10 system Nor since he is at UCSD, a UCSD PASCAL machine? N Well, enough of that. I yield the floor to Lauren. N -Mike N SHAR_EOF cat << \SHAR_EOF > rumor.nowicki From uucp Fri Aug 14 11:57:07 1981 remote from pur-ee NAucbvax.2660 Nfa.unix-wizards Npur-ee!cincy!duke!decvax!ucbvax!unix-wizards NWed Aug 12 11:44:04 1981 NMisunderstanding about Unix..... N>From Nowicki@PARC-MAXC Wed Aug 12 11:35:03 1981 NI would like to make a few comments on Donald Norman paper on "The NTruth About Unix". The arguments for Consistency, Simple Models, and NMnemonic Aids should all be Motherhood, even though many system Ndesigners continue to ignore them. (If you want consistent Nabbreviations you can use RSX-11M for a while where all commands are Nthree letters; then you'll appreciate Unix.) N NThe major mistake that is made, however, is failing to consider the Npossible multiple levels of abstraction. For example, the title says N"The user interface is horrid", but in reality every level of Nabstraction has a "user interface," namely its interface to the next Nhigher level. The motto of the Unix was not "let the user beware," but Nrather, "make the primitives simple but powerful, so as much as Npossible can be done at higher levels". With his arguments, you could Nsay that all man-computer communication is doomed to failure because it Nuses only ones and zeros, which are not very mnemonic. The real Nproblem is that an appropriate level for a systems programmer is not Nappropriate for casual end users. This conclusion is hinted at near Nthe end of the paper, but it means that the paper should not be a Ncriticism of Unix itself, but rather a criticism of how people use NUnix. N NThe point that someone reading only the first few paragraphs of the Npaper can miss is that the primitives in Unix CAN be either easily Nreplaced or encapsulated, while almost no other systems provide this Ncapability. As an example, two Stanford students have implemented a NTOPS-20 style command interpreter for Unix. It has arbitrary Nabbreviations, <escape> command completion, the question-mark help Nfacility, and a delete-undelete-expunge facility. Version numbers for Nbackup files are implemented with a simple suffix to the file name. N NThe real shame is that the Unix users themselves are forced to make the Nsystem as distributed from Western more humane, and thus every wheel Ngets reinvented many times. Luckily groups like Berkeley and Usenix Nare trying to help this situation, but as indicated progress is very Nslow. N N -- Bill N N N SHAR_EOF cat << \SHAR_EOF > rumor.swd From uucp Fri Aug 14 11:37:48 1981 remote from pur-ee NAduke.943 Nnet.general Npur-ee!cincy!duke!swd NThu Aug 13 09:23:28 1981 Nmore rumor rumors NSome random thoughts on the datamat!rumor article. N N1) it did not enter the net at utzoo by having someone N there run rnews to submit it. If they had, utzoo N would have seen the article. If it entered at decvax, N it would not have been sent to utzoo -- the anti loop N code in news will not send an article to any system N on the return path. Since the article did show up at N decvax, it entered the net there. N N2) what probably happened is that someone on the west coast N (Note the PDT in the date line) created the article N and ran uux - decvax!rnews <fake article. N N3) there is no way to prevent this (short of an elaborate N public key encryption scheme). SHAR_EOF # End of shell archive exit 0