CHARLES FORSYTH:

>> A single P9 box is brain dead, it is unable to 
>> demonstrate -any- of its advantages over a traditional OS.

actually, i don't think that's quite right, if you look at the construction of many of the services, for instance. initial design is often given a focus by thinking about possible use of the name space and then the design or structure of that name space; when it makes sense, the consequent split into name-space provider and name-space user(s) can simplify application structure, regardless whether distribution is involved or not. thus, there is still advantage in its use and significant difference with more `traditional' systems.

now, a message-passing system (say) will obviously encourage applications to be based on message-passing, but plan 9's name space sits at a higher level of abstraction than message-passing (or soft SOAP), and therefore comes in at a higher level of application design (i'd say). use of name spaces is encouraged and supported by mechanisms deeply embedded into the system itself.

acme provides a good example of using those ideas on a single machine. it's a file server but that's not primarily for reasons of distribution, and indeed i haven't seen much use of its services being subject to import or export (though they could be). its activity is usually confined to a single box, but it's still an advantageous structure. that's why i often call it an `integrating' not an `integrated' environment. the latter tend to be self-contained (i know, i know. `plug-ins', where you have to come to grips with deep knowledge of the IDE's internals). acme is much more open-ended, and i shouldn't think the typical acme client has any idea or need to know what acme looks like inside.

keyfs and factotum similarly simplify the interface for their clients, by being name space servers, again in a different way from traditional OSs. (implementation of the service itself is also given focus by its being a file server.)

of course, you're right that there is still greater power once the name space is available across a network. one of the interesting things about the Vita grid work to me was how representing things in the name space led to a simple yet flexible interface from the client's point of view. it's described in terms of reading and writing a few files, and it's natural to describe the protocol for the use of those files. i wasn't involved in the design or implementation, but i found it easy to see what a new client had to do, much more so than with the more traditional API/ABI descriptions.

ANTHONY SORACE:

when i was first exposed to plan 9, i was a unix admin. the very first thing that struck me about it was /lib/ndb. plan 9 was build with networks in mind, and as such the handling of them is so far superior to, well, everything else as to be operating at a different level entirely. no more changing host names in 3-5 different places, no more worrying about if my dns data was synched with my arp data and so on. designing the system around the idea of being network-centric meant dealing with and organizing a network was simple, even when not making use of the advanced networking capabilities the system presents. the small stuff falls out of doing doing the big stuff right.

a few days later i had my second big "whoa" moment with plan 9 while looking at aux/listen. tcp7 and tcp9 just blew my mind. i could write network listeners! in like three lines!!! whereas something like xinetd is (arguably; or not) an incremental step up from inetd on modern unix systems, aux/listen is something else entirely. i've written cross-protocol port forwarding in two lines of shell code. the amount of times since then that i've wished for aux/listen on whatever unix i was working on at the time is beyond number. it's not just incremental; it's totally different. and it works stand-alone, too.

again: the small stuff falls out of doing the big stuff right.

and plan 9 does the big stuff right.

GEOFF COLLYER:

One of the things I like about Plan 9 is that it requires almost no system administration, so adding more `common applications' for system administrators would seem to be just creating busy work. Barring problems with new hardware, after initial installation and set up of the main file server (which is never likely to resemble installation of any other system), here are the system administration activities needed:

• (re)configure the mail system: edit /mail/lib/rewrite;

• add a new machine: add one entry to /lib/ndb/local or your local equivalent, plug the machine into a switch, insert a boot floppy if it's a PC, turn it on;

• add a new printer: add one line to /sys/lib/lp/devices and one entry to /lib/ndb/local or your local equivalent, plug it in, turn it on;

• add a new user: type a newuser command on your file server console, have the user login and run /sys/lib/newuser.

Perhaps I've forgotten something, but those are the main activities and they're all pretty easy. Setting up a console server (add a Perle serial-port multiplexor, run some serial cables, and edit /lib/ndb/consoledb) makes administration even easier. There's no sendmail, so administrators can toss that huge O'Reilly book. There's no BIND, so administrators can toss that huge O'Reilly book. Without those two, the main (l)unix security bugs are absent.

Familiar applications aren't going to get people intrigued about Plan 9, they're going to lull them into thinking that Plan 9 is Just Another Unix.

I much prefer 8c & 8l to gcc & gld and /n/dump to CVS. Providing gcc, gld, CVS and the like would make developers think `what's so special about this system?', rather than `gee, there are some different and interesting ideas here'.

I don't think that the lack of interest by the world at large is due to a lack of comfortable, familiar applications. I think it's got more to do with a lack of understanding of why Plan 9 is (*really!*) interesting and a shortage of people who find that utterly compelling. People have given various excuses in the past (lack of gcc or X11, cost, licence terms) but if you're really enthused, none of that matters. Unix was a hit because it filled a niche, and what passes for Unix these days is still filling that niche, and for a lot of peple that's good enough. Those of us who can't imagine going back to living on what passes for Unix are a definite minority.

So what should be done? I don't think we should measure success by counting noses. I'm not even sure that Plan 9 needs to be a ``success''. We're using it, we like it and perhaps that's enough. Keeping up with new hardware is a worthy goal. We're all stretched a bit thin; as far as I know, none of us are able to work on Plan 9 development full-time. People have various pieces of work in progress. Perhaps after the election, the economy will pick up and we'll all have more time to devote.

	`Plan 9: a ``Failure'' for 17 years and still ``failing''.'