9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] What makes Plan 9 unique?
Date: Thu, 25 Oct 2001 07:56:49 -0400	[thread overview]
Message-ID: <20011025115712.2EF13199B5@mail.cse.psu.edu> (raw)

http://www.eecs.harvard.edu/~rsc/plan9.html

Why Plan 9?

Why Plan 9 indeed.  Isn't Plan 9 just another Unix clone?  Who cares?

First, Plan 9 presents a consistent and easy to use interface.  Once
you've settled in, there are very few surprises here, whereas Windows
still surprises me once in a while (though, to its credit, not as much
as older versions did).  After I switched to Linux from Windows 3.1, I
noticed all manner of inconsistent behavior in Windows 3.1 that Linux
did not have.  Switching to Plan 9 from Linux highlighted just as much
in Linux.

One reason Plan 9 can do this is that the Plan 9 group has had the
luxury of having an entire system, so problems can be fixed and
features added where they belong, rather than where they can be.  For
example, there is no tty driver in the kernel.  The window system
handles the nuances of terminal input.

If Plan 9 were just a really clean Unix clone, it might be worth
using, or it might not.  The neat things start happening with
user-level file servers and per-process namespace.  Recall that in
Unix, /dev/tty refers to the current window's output device, and means
different things to different processes.  This is a special hack
enabled by the kernel for a single file.  Plan 9 provides full-blown
per-process namespaces.  Thus, in Plan 9 /dev/cons also refers to the
current window's output device, and means different things to
different processes, but the window system (or telnet daemon, or ssh
daemon, or whoever) arranges this, and does the same for /dev/mouse,
/dev/text (the contents of the current window), etc.

Since pieces of file tree can be provided by user-level servers the
kernel need not know about things like DOS's FAT file system or
Linux's EXT2 file system or NFS, etc.  Instead, user-level servers
provide this functionality when desired.  In Plan 9, even FTP is
provided as a file server: you run ftpfs and the files on the server
appear in /n/ftp.

We need not stop at physical file systems, though.  Other file servers
synthesize files that represent other resources.  For example, upas/fs
presents your mail box as a file tree at /mail/fs/mbox.  This models
the recursive structure of MIME messages especially well.

As another example, cdfs presents an audio or data CD as a file
system, one file per track.  If it's a writable CD, copying new files
into the /mnt/cd/wa or /mnt/cd/wd directories creates new audio or
data tracks.  Want to fixate the CD as audio or data?  Remove one of
the directories.

Finally, Plan 9 fits well with a networked environment.  Since files
or directory trees can be imported from other machines, and all
resources are files or directory trees, it's easy to share resources.
Want to use a different machine's sound card?  Import its /dev/audio.
Want to debug processes that run on another machine?  Import its
/proc.  Want to use a network interface on another machine?  Import
its /net.  And so on.




             reply	other threads:[~2001-10-25 11:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-25 11:56 Russ Cox [this message]
2001-10-26  9:25 ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2001-11-07  6:34 Russ Cox
2001-11-07  1:02 David Gordon Hogan
2001-11-06 17:08 anothy
2001-11-06 16:45 Russ Cox
2001-11-06 17:53 ` Thomas Bushnell, BSG
2001-11-06 18:28   ` William Josephson
2001-11-07  2:46 ` Boyd Roberts
2001-11-06 11:01 geoff
2001-11-05 22:14 David Gordon Hogan
2001-11-06 10:22 ` Jonadab the Unsightly One
2001-10-29 21:28 David Gordon Hogan
2001-11-05 14:59 ` Jonadab the Unsightly One
2001-11-06 10:22   ` Jonadab the Unsightly One
2001-10-29 20:54 David Gordon Hogan
2001-10-29 18:54 presotto
2001-10-29 13:07 bwc
2001-10-29  1:56 okamoto
2001-10-26 17:09 forsyth
2001-10-26 16:58 presotto
2001-10-29 10:16 ` Ozan Yigit
2001-10-29 20:54   ` Skip Tavakkolian
2001-10-30 16:50   ` Dan Cross
2001-10-26 15:01 Russ Cox
2001-10-26 16:48 ` Thomas Bushnell, BSG
2001-10-29  9:04 ` pac
2001-10-25  9:00 Matt Senecal
2001-10-25  9:36 ` Lucio De Re
2001-10-26  9:25   ` Douglas A. Gwyn
2001-10-26 14:03     ` Matt Senecal
2001-10-26 15:36 ` Borja Marcos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011025115712.2EF13199B5@mail.cse.psu.edu \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).