Re: [9fans] sad commentary

["Russ Cox" <rsc@swtch.com>]

As a first approximation, there are two types of computer users.
There are the ones who just want something that does everything
they need it to, out of the box, and then there are the ones who
don't care so much what it can do at first, but they want to be able
to adapt the system to their needs as time goes on.
If you want, you can call the former "end users" and the latter
"programmers."  These camps have very different mindsets.

Most of your arguments seem to be about creating a system for
the "end users," but as Rob said, Plan 9 is not primarily for them.
Plan 9 is for people who want a system they can understand and customize
and adapt to their own purposes.  I don't mean setting a couple of buttons
in a preference dialog, either.  I mean writing actual programs to make
the system do something its designers did not explicitly anticipate.
When the computer doesn't already have some feature, it's a question
of thinking "this dumb system should already have that feature"
versus thinking "how can I add that feature?"

The fact that Plan 9 is not targeted at end users doesn't mean that
it's not usable by end users.  It just means that the system often
needs to be customized (by programmers) to fit the needs of the
particular end users.  For example, Coraid programmers built
software to adapt Plan 9 into a particular kind of end-user storage
server.  Rangboom adapted Plan 9 into a different kind of end-user
storage service.  In the past, other companies have done other things.

It doesn't have to be companies that are customizing the system for
other users.  Eric Nichols studies natural language processing and
has built a customized acme environment to speed manual translation
of text.  Nemo created a very interesting computing environment
on top of Plan 9 that is popular in his computer science department
and used by non-developers.  I know a handful of very happy end
users of venti, vbackup, and vac.

Notice that I haven't defended any of the individual Plan 9 tools--sam,
acme, rc, rio, fossil, venti, and so on.  There are people with strong
opinions on both sides for each of these.  The specific details of a
particular tool are far less important than the overall simplicity and
flexibility of the entire system.  That's not to say that no one likes the
tools.  Plan 9 from User Space exists exactly to provide the tools to
a broader audience, and I've heard from a surprising number of people
who were thrilled to find a new version of sam.  But no individual tool
is the point, and the Plan 9 tools alone are not Plan 9.

John Lions famously said about Sixth Edition Unix that, ``The whole
documentation is not unreasonably transportable in a student's
briefcase,'' and the same is true of Plan 9 today.  It's a system that
people can keep entirely in their head, that they can adapt to
their own needs and understand and fix if it breaks.


> The fact the UTF-8 was first "implemented" on Plan 9 has nothing to do with
> Plan 9's funtionality as an OS.

One way to read this sentence is as saying "Plan 9's support of UTF-8 doesn't
distinguish it anymore; other OSes now support UTF-8 too."  This is almost
true, although in my experience none of those systems approach Plan 9
for how everything UTF-8 just works out of the box.  (I still don't know
how to put UTF-8 in file names in Linux, for example, or to tell whether
a given file name is intended to be interpreted as UTF-8 or as Latin-1
or as some other character set.)

Another way to read this sentence is as saying "UTF-8 could have been first
implemented just as easily on some other OS as on Plan 9."  This is the
interpretation that Rob was replying to, and it's simply not true.
UTF-8 is as clean as it is because Ken Thompson came up with
a clean design, but that design alone would not have been enough.

Rob's history at http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
doesn't emphasize this as much as it could, but it does mention it:
in order for the design to be an acceptable proposal, it had to be
implemented in a real system.  Ken designed UTF-8 on a Wednesday
night, and by lunch on Saturday, Ken and Rob had completely
converted Plan 9--libraries, programs, graphics, and text files--to use it.
That was necessary to get the proposal accepted, and there are very
few systems out there in which something like that would be possible,
that quickly.

That's a key strength of Plan 9.  It is powerful enough to use well, simple
enough to understand completely, and small enough to make wholesale
changes to the system quickly.

In its early days, Unix was like that--Ken implemented pipes and converted
all the existing programs like grep to act as filters overnight--but not anymore.


> When I came to actually "use" Plan 9 I found out the two interfaces I'd
> heard about, i.e. rc and rio, are both awkward despite how everybody on
> 9fans thought they were such glorious climaxes of simplicity and usability
> and how everybody would bash Bash. If I were to save one interface (textual
> or graphical) out of all interfaces that exist today that'd be Bash.

Let's run with this, because it is actually a good example of the
philosophical difference here.

Bash is full of useful features, yes, but wow is it complicated.
These features might make it quicker to get some particular
thing done, but they impose a steep learning curve and also
make the software more complex and fragile.  When bash
breaks, about all you can do is keep the many pieces.
Rc is a nice simple shell that one person can completely
understand, and if it breaks, you can read the source code,
see what's going on, and fix it.

Here's a fantastic bash bug that a friend ran across the other day.
I suggested that he put "set -o allexport" in his .bash_profile, like I do,
and when he did on his Linux machine, he lost the ability to run xpdf.
It spewed tons of mysterious garbage about syntax errors:

    /bin/bash: _openssl: line 25: syntax error near unexpected token `('
    /bin/bash: _openssl: line 25: ` -@(in|out|oid))'
    /bin/bash: error importing function definition for `_openssl'
    /bin/bash: _service: line 4: syntax error in conditional expression:
    unexpected token `('
    /bin/bash: _service: line 4: syntax error near `@(*'
    /bin/bash: _service: line 4: ` [[ ${COMP_WORDS[0]} !=
    @(*init.d/!(functions|~)|service) ]] && return 0;'
    /bin/bash: error importing function definition for `_service'
    /bin/bash: _python: line 17: syntax error near unexpected token `('
    /bin/bash: _python: line 17: ` !(python|-?))'
    /bin/bash: error importing function definition for `_python'
    /bin/bash: _apt_cache: line 7: syntax error in conditional expression:
    unexpected token `('
    /bin/bash: _apt_cache: line 7: syntax error near `@(a'
    /bin/bash: _apt_cache: line 7: ` if [[ ${COMP_WORDS[i]} ==
    @(add|depends|dotty|policy|rdepends|madison|show?(pkg|src|)) ]]; then'
    /bin/bash: error importing function definition for `_apt_cache'
    /bin/bash: _aspell: line 5: syntax error near unexpected token `('
    /bin/bash: _aspell: line 5: ` @(-c|-p|check))'
    /bin/bash: error importing function definition for `_aspell'
    /bin/bash: _java_classes: line 5: syntax error in conditional expression:
    unexpected token `('
    /bin/bash: _java_classes: line 5: syntax error near
    ...

We spent quite a while tracking down what this garbage meant.
What happened?  Well, set -o allexport makes bash export
all of its environment variables, including shell functions.
Bash also has a flag you can set that says whether or not to
allow certain extended syntaxes.  The functions in question
were installed by the system as part of the autocompletion
magic, and they use the special syntax, after turning it on.
But when they get exported to the environment, there's no
way for the new shell to know that it needs the special syntax,
so it gets tons of syntax errors trying to reparse them.
Why xpdf?  Well, that was just the first #!/bin/bash script
that ran into this problem.  Why hadn't I run into this?
I don't source /etc/bash.bashrc like the default profiles do.

This bug results from the interaction of at least four different
features: allexport, the special syntax, function exporting,
and the Linux distribution's helpfully-added completion
functions.  And it's only the shell.  If the shell is too complicated to
understand, what about the rest of the system?

Plan 9 is filled with simple tools that actually do one thing well.
That often means a lack of bells and whistles, because the whistles
you might find useful and the ones I might find useful are mostly
different, and putting them all in makes bloated, fragile software
like bash.

Plan 9 is, above all else, simple and malleable.  I'll take that over
complex and brittle any day.

All that said, it sounds like you're not interested in a system that
is easy to program, easy to understand, and easy to adapt to
your needs, if light on traditional out-of-the-box features.
It sounds like you're focused on end-user do-everything features
rather than the ability to program the system to be a better
computing environment for you.  If that's the case, then
Plan 9 isn't for you.

Russ