Sign language
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.
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
accommodation 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:
- It became practical for the computer to do more than one thing
at a time. This made it necessary to explain to the computer what to
do next. The program itself was no longer enough: you needed to tell
it which program. The command language was born.
- More and more non-experts started to use computers. Instead of
being an object of research, it became a tool. People wanted to use
a computer to, say, write a document, without knowing the details of
instruction set, disk layout, or how to load and execute programs.
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 from a tape 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 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 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:
-
You have a large choice of editors. If you look in the Ports Collection, you'll
find dozens more. We'll get back to this point.
-
With the aid of the online manual, you can get more information about what's
available on your system. If the system has been installed correctly,
the documentation (``man pages'') get installed along with the programs, so what
is documented is also available. No book can boast that kind of consistency.
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 UNIX's 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 ``what's available'' problem 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, and 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?
