Re: [9fans] Some Plan9 questions

["Russ Cox" <rsc@plan9.bell-labs.com>]

>  1) My main question is how much compatibility is there between Plan9 and
> other UNIX-based operating systems, like BSD, Linux, etc.? That includes
> running applications that were developed for Linux, BSD, and UNIX systems in
> general.
>  2) If Plan9 does not run applications that other UNIX operating systems can
> run, how hard is it to port the code over?
>  3) How hard is it for someone who is coming from a more common UNIX OS to
> get used to Plan9?

This isn't an answer to any one of these questions but at the
same time it addresses all of them.

As Scott said, you have to come at Plan 9 with an open mind.
System interfaces that are felt unnecessary or clunky are
not implemented, and this makes Plan 9 nice but also makes
it not Unix.  ANSI C code typically is easy to compile.  Once
you get into heavily POSIX code, things get harder.  The graphics
and networking models are completely different (much simpler),
so graphics code almost never ports, and network code only
sometimes ports (if it uses select, you've got your work cut
out for you, though APE can make that easier).

I don't know what your level of interest in IRC is, but it's a good
recent example.  On most systems if you wanted an IRC client
you'd just port some other IRC client and end up with an IRC
client.  But Plan 9 isn't really a good base for running external
programs.  There's no X11, there's only rudimentary cursor
addressing, so you'd have to port a command-line program.
(If you want to run a Unix program, that's what Unix is for.)
The Plan 9 way to attack the problem would be to step
back and wonder whether there was a simpler and/or more
general interface that might be good.

I occasionally use IRC and AIM and ICQ, and would like to be
able to do so in Plan 9 rather than switching to Windows XP.
I wrote an ICQ implementation six years ago, but it ran in a
window by itself and I'd always forget about it, and it still
didn't really fit well with the rest of the system.  A few
months ago I started thinking about this again, and have slowly
(a few hours here and there, very occasionally) been building
a generic chat file system interface:

/*
 * Chat file system.  Conventionally mounted on /net to provide /net/chat,
 * for some value of chat.
 *
 *  clone           open and read to obtain new connection
 *  n               connection directory
 *      ctl             control messages (like connect user)
 *      data            retrieved data
 *      err             last error
 *      local           local name
 *      remote          remote name or channel
 *      status          connection state
 *      who             list of people in chat room
 *      ...             other protocol-specific files
 *
 * The connect message typically takes the following possible addresses:
 *
 *  #channel    a channel
 *  chat room   a chat room
 *  user        a user
 *  *snoop*     all traffic
 *  *mop*       traffic with nowhere else to go
 *
 * It would be more true to form if there weren't a *mop* but instead
 * you announced chat!you and then listened for connections.
 * The *mop* is good enough.
 *
 * The data file returns messages one at a time.  The messages are attr=value
 * lists that can be parsed with the attribute parsing routines in auth.h [sic].
 * Typical attributes include:
 *
 *  src     who is sending the message
 *  dst     destination for message (you, a chat room)
 *  cmd     command being sent
 *  args    other arguments
 */

I have an IRC implementation of this pretty much done,
and I plan to do an AIM TOC implementation too.  Once you've
got this as a building block, it's easy to build whatever
interfaces you want on top of it.  I have a fairly nice Acme gui
pretty much done.  (Because of Acme and win, it's hardly
any code.)  You could build a really simple gui using rio
windows (using the same code, actually) with one window
per conversation.  In a pinch, con -l 'irc!#plan9' would work
reasonably, and it's great for debugging.  Another nice
thing is that suppose you want to write some sort of 'bot.
It could be something complicated, or something as trivial
as logging a particular chat session (or all your chat sessions).
Since all the programs can use the fs interface, none of them
have to worry much about the details of connection setup
or anything like that.  And one connection can be shared
between many programs without any extra effort.
While there will probably be slight differences in syntax
and the frills commands that can be executed on each
network, the core interface is the same meaning that I'll
have multiprotocol guis for free.

I think the end result is that it will fit well with the
rest of the system and be more pleasant to use than
most standalone clients.

> 6) Is there going to be another release? If so, any idea when?

In a sense, the fourth edition release is the release to end
all releases.  System updates are now distributed via a
Plan 9 file server on the internet, sources.cs.bell-labs.com.
We put changes out much closer to as they occur than ever
before.  Some of us run generic installations as our day-to-day
system, which provides incentive to keep sources and the
internal Bell Labs system in sync.

There are no really big changes planned at the moment.
9P2000 was the big addition for the fourth release and
we're still coming to terms with a lot of that.  If big
changes happen down the road then maybe that would be
another number.

But releases in the small happen very frequently.

Russ