Sign language
by Greg Lehey


This is my first contribution to the Dæmon's Advocate, so an introduction is in order. First, the column: as Wes Peters indicated last month, my topics are going to be somewhat different from his. My next few articles will be about getting comfortable with UNIX--that starts with the parable below.

Who I am

I'm not going to repeat the stuff that's on my Home page, but it might help you to understand the articles if you know where I'm coming from.

Compared to Wes Peters, I'm a relative newcomer to UNIX: I was working for Tandem in the 80s, and it wasn't until late 1986 that Tandem started marketing a UNIX box. I came to UNIX from Tandem's Guardian platform, now known as NonStop Kernel, and moving to UNIX was quite an experience. I liked what I saw, though, and moved to UNIX completely before leaving Tandem in 1992 to become an independent consultant.

At Tandem, we had been using UNIX System V.2 and V.3. One of the things that concerned me about ``going it alone'' was the lack of access to source code. Sure, I could buy my own System V license, but that would take up my first year's income. Instead, I found out about a small startup which was selling a PC-based implementation of 4.3BSD called BSD/386 for only $1000, including complete source code. I was ecstatic. At that price, I didn't expect the quality of System V, but it was UNIX, so I ordered it.

I was very pleasantly surprised by BSD/386. The version I got was Beta 0.3.1. It installed from tape very well, and right from the beginning I had almost no problems with it. It had a feeling about it which I missed in System V: it came in one integrated package: there were no hard-to-install ``optional'' packages like TCP/IP support. At the time, I had another machine running Interactive UNIX/386, a reasonably good implementation of System V.3.2, and I soon became the German representative of ConsensysComputer Corp, who at the time were marketing the first version of System V.4 for PCs. BSD/386 blew both systems out of the water in all areas: it was faster, more reliable and easier to use.

In the course of my other work, I developed a connection to Walnut Creek CDROM, who published my System V.4 ported software CD-ROM in 1994. Walnut Creek became the main sponsor of FreeBSD, and I was involved from an early date, though I continued to use BSD/386 (later called BSD/OS), since I had it, and it was more polished. On the other hand, I knew a number of people who were interested in UNIX, but weren't prepared to spend the price of BSD/OS, so I gave them FreeBSD.

In October 1995, I had a visit from a number of Walnut Creek people, notably Vice-President Jack Velte, who bemoaned the fact that there was no book about FreeBSD: he wanted a book to explain how to install the system, about 50 pages. We went down to my office and I hacked together about 10 pages in troff to have a basis for discussion. Jack liked it, and Installing and Running FreeBSD was born, later to become The Complete FreeBSD.

Writing the book forced me to spend more time with FreeBSD, of course. I discovered that FreeBSD had improved immensely in the course of time, and though I still considered BSD/OS superior, FreeBSD was catching up fast. In the course of time I transferred all my machines to FreeBSD. I received the 3.0 version of BSD/OS, but never installed it.

So now you know that I'm a FreeBSD user, and not (currently) a NetBSD or OpenBSD user. This is probably the last time I'll mention the fact in these articles: I intend to talk about things that are common to all the *BSDs, not ones which differentiate them. Initially I'll be talking about the strangeness which newcomers perceive when they move from Microsoft to UNIX.

A parable

In 1967, my father and I drove a car from Singapore to Tavistock in the South-West of England. In the course of nearly two months, we passed through a number of remote countries, including Afghanistan, Iran and Turkey. In these countries, they speak Afghan, Farsi and Turkish. We don't.

Obviously, this difference made communication less simple than it might have been, but it wasn't too difficult. If you go to a gas station you could guess which fuel to use, by smell if necessary, and point at it. The same applied pretty well to food, and even getting accomodation for the night wasn't too difficult. Sign language worked pretty well in this environment, and in extreme cases we could get a piece of paper and draw a picture of somebody sleeping on a bed.

After getting to England, my father went back to Malaysia, and I went to the University of Hamburg in Germany. I had learnt German at school, but obviously a few words filled in with sign language wouldn't cut it at University. I had to take a 6 week course to improve my German and to pass a language test before I was allowed to start my studies.

Well, you may be thinking, that's straightforward enough. What does that have to do with learning UNIX? Read on.

In fact, learning foreign languages (or getting by without learning them) does have a lot to do with how we learn to get by with computers. You don't have to drive halfway across Asia or to go to University in a foreign country in order to have problems communicating. If you're a typical reader of this column, you speak only one or two languages. If you decide to take a vacation overseas, there's a very good chance you'll go where they speak a language you understand. But what happens when somebody is first exposed to a computer? They don't speak the same language, and somehow they have to learn to communicate.

Explain yourself

How do you communicate with a computer? In the early days, the answer was simple: anybody who used a computer was heavily technical, and the communication was in the form of storing programs into the computer's memory and running them: the program was the language. As time went on, two developments occurred:

Well, that's fine, but if you can't load and execute programs, you can't use the computer. Obviously you're going to have to know something. On a really old machine, loading a program might have involved toggling it in on a series of switches, or loading it from a deck of cards or a tape in by pressing a series of switches. Major work. The new generation of users wanted something different.

At about this time, UNIX was written. One of the first uses of UNIX really was document preparation. Twenty years ago, the Seventh Edition of the UNIX Manual included a number of documents designed for use for document preparation by non-technical personnel. You can read up on it at http://plan9.bell-labs.com/7thEdMan/index.html.

By the end of the 70s, running programs on most operating systems had become less baroque than it was at the beginning of the decade: something like a de-facto standard had evolved. Programs were stored in files, and to start them, you just typed in the name. Most, but not all systems also allowed you to pass additional information to the program. For example, to edit a file called article, you might enter:

edit article

Look familiar? It should. The syntax is pretty intuitive, at least at this level. You tell the computer to run do something to an object. You can use the same sort of syntax in English:

mow the lawn wash the dishes service the car

The only difference is the article the, which, as any Russian will tell you, doesn't change anything (there's no word for ``the'' in Russian).

The problem with this approach is that the words have changed. You no longer know all the verbs. You need to learn the name of every program you want to run. That's fine as long as your editor is called edit. But even 20 years ago, things were no longer that simple. The standard UNIX editor was called ed, but a more powerful editor was also available, called ex. Both these editors had the disadvantage that they only showed you a small amount of the text at a time, and then only when you specifically asked for it. That was appropriate for the typical hardware of the time (a teletype), but in Berkeley, Bill Joy had modified ex to display on a glass tty, the first generation of visual display units. He called his version vi. So even in those days, you might have three standard editors on a machine, none of them with a name you would expect.

A little later, the unthinkable happened: IBM entered the small computer market with a machine called a Personal Computer, and instead of using the industry's leading operating system, CP/M, they did a deal with a company called Microsoft, then better known for relatively buggy language compilers and interpreters. The rest, as they say, is history. Microsoft bought out Seattle Computer Products' QDOS (Quick and Dirty Operating System, a clone of CP/M), modified it slightly, and renamed it MS-DOS (and IBM modified it a little more and called their version PC-DOS).

At a superficial level, the DOS command language looked pretty much the same as UNIX. You could use the same command to start the editor (except that you still needed to know the name of the editor, which in this case was EDLIN). DOS made it harder than UNIX because it didn't have an on-line manual. In UNIX, you can usually get some information with the command apropos, which searches the manual for keywords. The following is a heavily trimmed output on a FreeBSD system:

$ apropos edit mcedit(1) - Full featured terminal text editor for Unix-like systems pico(1) - simple text editor in the style of the Pine Composer ed(1), -(1) - ed text editor ee(1) - easy editor ex(1), vi(1), view(1) - text editors fontedit(1) - Edit fonts install-info(1) - edits info/dir file for the GNU info hypertext system ld(1) - link editor sed(1) - stream editor xedit(1) - simple text editor for X

You'll see two important differences between UNIX and DOS here:

Just show it

Now nobody's claiming that this way of finding your software is perfect, and beginners hate it. It's one reason for UNIXs reputation of being hard to use. One obvious alternative would be to help the user: tell him what he has. This menu system wasn't completely new even 20 years ago, though it became popular with the advent of full-screen display software. Don't confuse this with programs like Microsoft's ``Windows''. The menus were there a long time before.

Menus solve the problem ``what's available'' in an obvious way: they tell you. Instead of having to go to look for the programs, you press a key or a mouse button and the list appears on the screen. In many cases, they're ideal. By the mid-80s, a whole new generation of full-screen software had arisen, typified by the spreadsheet Lotus 1-2-3. It wasn't ideal, of course: even then, there were so many options available that two-level menus were required: you first select a topic, and then you get the menu you were looking for. Maybe. It depends on how well you guess the structure of the program.

Back to Afghanistan

This is boring stuff. We've been there, and we've progressed. Why talk about it? Well, think back 15 years earlier to when my father and I were in Afghanistan. When we went into an eating place, it was easy to decide what to eat: they'd show us what they had, and we'd point to what we wanted. A physical menu.

If you look at the menu in a typical Chinese restaurant in a Western country, you get a matrix with type of meat on one side and way of cooking on the other--you could represent it as a second-level menu. As a result, many Chinese restauarants have a series of photos, but they can only show you so much: what if you don't like ginger? Usually you can't tell by looking at the photo whether the dish contains ginger or not.

By contrast, things were easier in Germany: we could ask the waiter what they had, and he could tell us (apropos). If we weren't sure about the details, we could ask him (man). Sure, it took me several years in school to learn German, but it paid off: I can order food unseen in Germany and have a reasonable expectation to get what I want.

The grand obfuscation

Let's come back and look at the scene today. Both DOS and UNIX have changed: the biggest change was that they have both gained graphical interfaces (``Windows'' in the case of DOS, X in the case of UNIX).

At this point, you may be about to send me a mail message explaining that ``Windows'' is not the same thing as DOS. That's a matter of viewpoint. ``Windows 95'' and ``Windows 98'' are still based on DOS. Microsoft may prefer to use the word ``contain''; I'd prefer to say that DOS is the operating system component, such as it is, of ``Windows 95'' and ``Windows 98''. The terminology is symptomatic of another problem with the Microsoft Way: everything is lumped together into an amorphous mass. I'll rant about that some other time.

Problems of scale

By the time ``Windows'' became even remotely usable, in the late 80s, menus had become The Way to do things, but they were also getting unwieldy. Microsoft has expended a lot of energy trying to fix the inherent disadvantages, but it hasn't been easy: menus don't scale. Consider the number of editors in the list above. That's only a minor part of the problem. On my system, I have about 1,600 programs in five directories. How can you possibly select one of them easily from a menu? When using electronic mail, you often want to access archives of stored mail, either to read them or to store a message in them. Microsoft's reinvented electronic mail system will give you a menu display of your mail folders, and all you have to do is select them. It's easier now with the new mice with the rollers on them, but I have 3,800 folders. Even with a high-resolution display it's difficult to show more than 50 folders at a time, which means that the menu alone will encompass about 75 screens full. Just finding the correct entry becomes a serious problem. There are better alternatives, which I'll discuss in another column.

Another problem is the way you point: keyboards are for writing with, but they're not convenient for pointing. Instead, you use a mouse. Well, that's fine if you want to point, but it's not very fast. Use a high-resolution screen (1600x1200 or up), and you'll find that it's also very difficult to hit the right part of the screen. People who are comfortable with keyboards find using the mouse a time-wasting and inconvenient way to do things.

Where do we go from here?

Clearly both approaches have their advantages and disadvantages. It's easier to get started with ``Windows'' than with UNIX. Once you understand the system, though, it's easier to do things with UNIX. Why not have a combination of the two approaches?

Good idea. We do. If you have a command-line based approach and a good scripting language, it's trivial to build menus which offer whatever you want to offer. On the other hand, if your system is built on menus and icons, you need a lot of effort to provide a useful command language. In the terms of the Asia Trip, if you can speak a language correctly it's easy to learn sign language. If all you can do is sign language, it's pretty difficult to learn to speak a language.

Both UNIX and Microsoft are developing. UNIX, in particular BSD UNIX, comes from a position of technological strength: developed at the world's leading research facilities by people more interested in doing the right thing than getting a broad user base. Microsoft comes from a position of technological weakness: a system initially so quick and dirty that it was actually given that name, bought quickly to satisfy an urgent customer need, developed by an army of programmers to ensure Microsoft's financial success in a marketplace dominated by newcomers to computers.

Times are changing: more and more people are becoming computer literate, and the decades of kludges are showing even to those who are new to computers. Why is ``Windows 98'' so buggy? Microsoft is fighting an uphill battle: conceptually, they're still somewhere in an eating place in Qandahar pointing at various kinds of sheep kebabs. UNIX, on the other hand, is sitting in a smoky student café in Hamburg discussing abstract philosophy, and the people around don't have the faintest idea what they're talking about. You may not be in either situation, but who would you ask to answer your question?