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
