9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cpu server
Date: Sat,  7 Feb 2004 19:54:22 +0000	[thread overview]
Message-ID: <b89a88f3506ffdb5adafcb395df34efc@terzarima.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0402071004240.20463-100000@einstein.ssz.com>

>>That is correct Bruce. 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.



  reply	other threads:[~2004-02-07 19:54 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-07  0:24 vdharani
2004-02-06 22:50 ` Jim Choate
2004-02-07  3:41   ` Bruce Ellis
2004-02-07 14:48     ` Jim Choate
2004-02-07 15:21       ` Bruce Ellis
2004-02-07 16:05         ` Jim Choate
2004-02-07 19:54           ` Charles Forsyth [this message]
2004-02-07 22:26             ` a
2004-02-07 23:16               ` andrey mirtchovski
2004-02-09 17:47                 ` rog
2004-02-09 18:19                   ` andrey mirtchovski
2004-02-09 18:43                     ` rog
2004-02-09 18:49                       ` andrey mirtchovski
2004-02-09 18:49                     ` rog
2004-02-09 18:50                       ` andrey mirtchovski
2004-02-09 19:32                     ` 9nut
2004-02-09 18:44                       ` andrey mirtchovski
2004-02-10  1:38                     ` Kenji Okamoto
2004-02-10  1:40                       ` David Presotto
2004-02-10  1:50                       ` boyd, rounin
2004-02-10  1:11                         ` andrey mirtchovski
2004-02-10  3:03                           ` Lyndon Nerenberg
2004-02-10  5:00                           ` Geoff Collyer
2004-02-11  3:14                             ` Jack Johnson
2004-02-08  1:04               ` Taj Khattra
2004-02-08  1:20             ` Jim Choate
2004-02-08  2:56               ` Bruce Ellis
2004-02-08  2:40           ` Bruce Ellis
2004-02-07  8:18   ` andrey mirtchovski
2004-02-07 11:12     ` Bruce Ellis
2004-02-07 11:33     ` a
2004-02-07 13:30     ` boyd, rounin
2004-02-07 13:38     ` boyd, rounin
2004-02-07 14:51     ` Jim Choate
  -- strict thread matches above, loose matches on Subject: below --
2007-12-28  3:09 [9fans] CPU Server Joshua Wood
2007-12-22 23:12 "Rodolfo \"kix\" Garci­a"
2007-12-22 23:15 ` Iruata Souza
2007-12-23  3:13 ` John Soros
2007-12-23  3:35   ` erik quanstrom
2007-12-27 16:16     ` "Rodolfo \"kix\" Garci­a"
2007-08-15 22:13 Rodolfo (kix)
2007-08-16  1:26 ` geoff
2007-08-16 13:18   ` rob
2007-08-16 13:29     ` erik quanstrom
1998-07-13 15:46 Franklin

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=b89a88f3506ffdb5adafcb395df34efc@terzarima.net \
    --to=forsyth@terzarima.net \
    --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).