9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Plan 9
@ 2001-11-07 10:03 forsyth
  2001-11-08 10:38 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: forsyth @ 2001-11-07 10:03 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

no, there aren't, or certainly not in any sense that
unix might have used the term.  that's part of the confusion.
the file server provides a strict tree.  full stop.
there are no links there.  (there aren't even any i-nodes or files distinct from directory entries.)
the (non-persistent) mount table provides a way to
alias, although that's not its only function,
but it really does resemble the unix mount table
more than any form of hard/symbolic/firm/weak link,
except that it can be per-process.


[-- Attachment #2: Type: message/rfc822, Size: 1716 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9
Date: Wed, 7 Nov 2001 09:43:55 GMT
Message-ID: <873d3r1hlq.fsf@becket.becket.net>

forsyth@vitanuova.com writes:

> i think part of the confusion is caused by someone
> not realising that there is no link(2) on Plan 9.

No, but there are links.

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] plan 9
@ 2002-08-30 10:15 nigel
  0 siblings, 0 replies; 120+ messages in thread
From: nigel @ 2002-08-30 10:15 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

The summaries in the Plan 9 documentation are excellent.
Much more trustworthy than anything I might mindlessly
pop down in an ill-considered email.

http://plan9.bell-labs.com/sys/doc/index.html

[-- Attachment #2: Type: message/rfc822, Size: 1757 bytes --]

From: Isaac Stern <drmoses@techie.com>
To: 9fans@cse.psu.edu
Subject: [9fans] plan 9
Date: Fri, 30 Aug 2002 09:57:14 GMT
Message-ID: <86e2dbb4.0208291800.5cfd604c@posting.google.com>

I have heard lots of good things about plan9 in a past. How it is
innovative OS and it takes file abstractions step futher then UNIX,
but have never really made any serious research on topic.
Could someone please sum up for me what is new in plan 9 besides it
being "multiserver/distribured" OS.
Sincerely,
IS.

^ permalink raw reply	[flat|nested] 120+ messages in thread
* [9fans] plan 9
@ 2002-08-30  9:57 Isaac Stern
  0 siblings, 0 replies; 120+ messages in thread
From: Isaac Stern @ 2002-08-30  9:57 UTC (permalink / raw)
  To: 9fans

I have heard lots of good things about plan9 in a past. How it is
innovative OS and it takes file abstractions step futher then UNIX,
but have never really made any serious research on topic.
Could someone please sum up for me what is new in plan 9 besides it
being "multiserver/distribured" OS.
Sincerely,
IS.


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-13 10:53 Fco.J.Ballesteros
  0 siblings, 0 replies; 120+ messages in thread
From: Fco.J.Ballesteros @ 2001-11-13 10:53 UTC (permalink / raw)
  To: 9fans

Do people asking for the thread to stop account as members of the thread?
☺ sorry, couldn't resist.


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-09 22:39 David Gordon Hogan
  0 siblings, 0 replies; 120+ messages in thread
From: David Gordon Hogan @ 2001-11-09 22:39 UTC (permalink / raw)
  To: 9fans

> Don't hold your breath, I'm getting older by the
> minute.

If you hold your breath long enough, you'll stop aging.



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-09 12:25 geoff
  2001-11-12 10:32 ` Thomas Bushnell, BSG
  2001-11-12 11:41 ` Sam Ducksworth
  0 siblings, 2 replies; 120+ messages in thread
From: geoff @ 2001-11-09 12:25 UTC (permalink / raw)
  To: 9fans

> I want an entire directory structure, just for me.  Not shared with
> other people.  How, exactly, do I do that?

mkdir unshared
# populate unshared here
chmod 'go=' unshared

And could we create a new mailing list or comp.religion.gpl newsgroup
for the licence discussions?  Plan 9 is free enough for those who are
more interested in technology than the religion and politics of
licensing and copyright.  Sadly, many Free Software™ advocates are
more interested in licensing and copyright than in getting actual work
done.
___
* "Free Software" is a registered trademark of GNU, Inc., all rights reserved.



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-09  1:47 okamoto
  0 siblings, 0 replies; 120+ messages in thread
From: okamoto @ 2001-11-09  1:47 UTC (permalink / raw)
  To: 9fans

>Yes, but the the capability systems all provided an objective
>sturcture.  All the persistent capability systems mixed the capabilities
>with the objects themselves.

Yes, and most of objects are directories and files.  :-)

Kenji



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-08 15:05 presotto
  0 siblings, 0 replies; 120+ messages in thread
From: presotto @ 2001-11-08 15:05 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Yes, but the the capability systems all provided an objective
sturcture.  All the persistent capability systems mixed the capabilities
with the objects themselves.  The desire here seems to be completely subjective
ones.  There's no reason not to do this with capabilities, I just don't
remember it being done.

[-- Attachment #2: Type: message/rfc822, Size: 1496 bytes --]

From: forsyth@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9
Date: Thu, 8 Nov 2001 14:44:34 0000
Message-ID: <20011108143851.7FCA419A04@mail.cse.psu.edu>

>>I take it that you're suggesting that the file system has no structure
>>other than being an object repository.  It's up to each user to
>>impose order by having his or her own object linkage.

similar things were done at least a few times in the past to provide capability
systems (that provided either persistence or a capability to make
capabilities) and persistent programming languages with a file storage
system.

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-08 14:44 forsyth
  0 siblings, 0 replies; 120+ messages in thread
From: forsyth @ 2001-11-08 14:44 UTC (permalink / raw)
  To: 9fans

>>I take it that you're suggesting that the file system has no structure
>>other than being an object repository.  It's up to each user to
>>impose order by having his or her own object linkage.

similar things were done at least a few times in the past to provide capability
systems (that provided either persistence or a capability to make
capabilities) and persistent programming languages with a file storage
system.



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-08 14:02 presotto
  2001-11-09  0:25 ` Dan Cross
  2001-11-09 10:08 ` Thomas Bushnell, BSG
  0 siblings, 2 replies; 120+ messages in thread
From: presotto @ 2001-11-08 14:02 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

I take it that you're suggesting that the file system has no structure
other than being an object repository.  It's up to each user to
impose order by having his or her own object linkage.

It is indeed an interesting idea.  It seems that sharing views would
also be desirable since you would need to communicate with others.
You'ld also have to have some form of persistence of the structural
information or else run possibly billion line scripts every time
you connect to the system.  You'ld also need a naming scheme so that
you could reference the objects for the links.

Sean Quinlan is doing something similar, though only the file storage
part with a system called venti.  I don't know how much he's released
about it but I know there's a paper in the works.  Look at
http://cm.bell-labs.com/cm/cs/who/seanq

I know I've seen something similar before though I can't remember
where.  The idea there was a sea of objects with multiple views
that made the interrelation subjective.  I'll see if I can find
a reference.  Don't hold your breath, I'm getting older by the
minute.

So, it this what you are intending?  Sorry its taken so long to
figure it out but your descriptions have been less than clear.

[-- Attachment #2: Type: message/rfc822, Size: 1931 bytes --]

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9
Date: Thu, 8 Nov 2001 10:39:02 GMT
Message-ID: <87zo5xyau4.fsf@becket.becket.net>

geoff@collyer.net writes:

> To back up presotto's claim of efficiency of binds, my old department
> overlaid our sparsely-populated file server onto the main plan 9 file
> server.  ovfs got written late in the game, so for a long time, we had
> a /lib/namespace that was 346 lines (by the end, anyway).

By a "large mount table" I mean one which has a similar number of
entries to the size of the file system.  For a filesystem with ten
thousand files, that would be something a similar number of entries.
I'm sorry if that wasn't clear.

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-08 13:07 Bruce Janson
  2001-11-09 10:07 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: Bruce Janson @ 2001-11-08 13:07 UTC (permalink / raw)
  To: 9fans

    From tb+usenet@becket.net Thu Nov  8 23:54:50 EST 2001
    ..
    ".. the per-process mount table is a very nice thing: let's make the
    entire directory structure per-process, rather than just selected
    parts of it." ..
    Obviously, it results in a system very different from .. Plan 9.
    ..

Doesn't Plan 9's per-process(group) mount table already
allow a per-process(group) "entire directory structure"?


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-08 13:06 rob pike
  2001-11-09 10:08 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: rob pike @ 2001-11-08 13:06 UTC (permalink / raw)
  To: 9fans

> 1) The same tools should work on all file names, however set up, to
>    create them, remove them, rename them, and so forth.
> 2) Whether a file name mapping is per-user or not should be decoupled
>    from what the user sees.

I guess I'm dim. I can't see how either of these properties is unmet by
Plan 9.

Maybe you're trying to get at some other form of name space, like Linda
or something, some inherently unstructured pairing of name and object
that is structured by user actions.

-rob



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-07 18:05 anothy
  0 siblings, 0 replies; 120+ messages in thread
From: anothy @ 2001-11-07 18:05 UTC (permalink / raw)
  To: 9fans

thank kenji. i got ktrans working, with minor help from
him, and really like it. and, purely asthetically, i decided i
liked the "ア" better than the old α.
ア



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-07 17:43 anothy
  2001-11-07 17:47 ` Boyd Roberts
  0 siblings, 1 reply; 120+ messages in thread
From: anothy @ 2001-11-07 17:43 UTC (permalink / raw)
  To: 9fans

// ...we're not completely mad.

well, okay, maybe we were. but for other reasons, at least.

i believe it's true that while we were working in that environment, we
did stress the system a bit more than it was used to, and uncovered a
few things that didn't work exactly as predicted. but they'd get
reported and fixed.

my current namespace file, on a seperate project, currently has 207
lines. this is on a single cpu server with the fs being served via kfs,
with a tiny 64MB ram. again, fs performance is not noticably affected
by the mount table. i'd still _love_ to get ovfs, but that's mainly for the
sake of administration - getting additions to a namespace file of that
size correct can get confusing.
ア



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-07 17:28 Russ Cox
  2001-11-08 10:39 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: Russ Cox @ 2001-11-07 17:28 UTC (permalink / raw)
  To: 9fans

You're calling a link a map (dir,name)->file.
Fine.  But that's not what the mount table is.
In the kernel, the mount table map is from current file to
replacement file.  If I mount a file server onto /n/emelie,
it is NOT the case that what happens to lookup /n/emelie/sys is
	walk to /n via 9P
	notice /n/emelie in the mount table
	walk to /sys on the emelie connection

What really happens is
	walk to /n/emelie via 9P
	notice /n/emelie in the mount table
	walk to /sys on the emelie connection

If I mount a file server onto /n/emelie and then in
another window remove the /n/emelie directory (in the
other window there's nothing mounted there so it's empty)
then I lose the mount in the first window, because the
link (/n,emelie)->empty directory is provided by
the protocol not the kernel.

The mount table stores no names at all (at least
for the forward direction).   Instead, the qid we get
from walking to the mount point directs whether
a translation happens.  The mount table is a
bunch of file->file mappings.

There are no ``links'' in the mount tables.  None.
Every (directory,name)->file mapping happens
by doing a 9P transaction, whether over the wire
or to a kernel-provided tree.

I still don't understand your proposal, but I think
a lot of our confusion has to do with this fact:
there are no links in the kernel mount tables.  None.

Russ



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-07 12:58 rob pike
  2001-11-08 10:39 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: rob pike @ 2001-11-07 12:58 UTC (permalink / raw)
  To: 9fans

> My idea is that these two should be unified (keep in mind I'm talking
> about "some future system", not suggesting a big design alteration of
> existing systems).

So you keep saying, and so we believe.  But why?  To what visible
effect?  So far all you've claimed is efficiency, which is not an
issue, and elegance, which you haven't quite demonstrated yet since
the distinction between public defaults and private adjustments
requires some sort of extra mechanism or at least extra instance of
mechanism.

System design is about artifacts and should lead to tangible benefit.
I remain unconvinced in this case.  In fact, the issue has hardly
been addressed; saying 'should be' in every post is not an argument.

So again, why?  Give me an example of something your notion
accomplishes that we can't do now and that is worth doing.

-rob



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-07 11:00 geoff
  2001-11-08 10:39 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: geoff @ 2001-11-07 11:00 UTC (permalink / raw)
  To: 9fans

To back up presotto's claim of efficiency of binds, my old department
overlaid our sparsely-populated file server onto the main plan 9 file
server.  ovfs got written late in the game, so for a long time, we had
a /lib/namespace that was 346 lines (by the end, anyway).  The first
cut was generated by a shell script; we're not completely mad.  Of
those lines, 260 were binds and 14 were mounts (the rest was
whitespace or comments).  On top of that, people's profiles usually
added a few more binds.  There was no observable performance penalty,
either when creating a new namespace or when working in same.  If
performance had been dreadful, we would have done something else.



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-07  1:09 David Gordon Hogan
  0 siblings, 0 replies; 120+ messages in thread
From: David Gordon Hogan @ 2001-11-07  1:09 UTC (permalink / raw)
  To: 9fans

> And in a namespace bind(2) them
> In the Land of Inferno where the Styx lies.

``And I will give unto thee the keys of the kingdom of
  heaven: and whatsoever thou shalt bind(2) on earth
  shall be bound in heaven: and whatsoever thou shalt
  loose on earth shall be loosed in heaven.''  -MAT 16:19

(I guess they called unmount ``loose'' in those days...).


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06 18:46 anothy
  2001-11-07  9:44 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: anothy @ 2001-11-06 18:46 UTC (permalink / raw)
  To: 9fans

// You don't understand my point at all, I'm afraid.

that's entirely possible, but i am trying.

// If a link is found in the process's name space,
// then it *isn't* found on a remote file server.

again, depending on what you mean by a "link",
this is false. take this example:

my client imports a remote file server. that import
presents me with files /dog/woof and /cat/meow.
i then bind /dog over /cat, replacing it. now, when
i do a 'ls /cat', that's looked up in the namespace
(in the mount table), and resolved to /dog. /dog is
then resolved to the imported file server. the file is
found in the process's name space, and then on a
remote file server.

please define what you mean when you say "link",
as i think that would help me understand what
you're getting at, or where the confusion is.
ア



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06 18:14 forsyth
  2001-11-07  9:43 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: forsyth @ 2001-11-06 18:14 UTC (permalink / raw)
  To: 9fans

i think part of the confusion is caused by someone
not realising that there is no link(2) on Plan 9.



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06 18:07 presotto
  2001-11-07  9:44 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: presotto @ 2001-11-06 18:07 UTC (permalink / raw)
  To: 9fans

>Right now, if I want a given file to appear *here* in my visible
>filespace, there are two ways: I can bind it, I can move/copy it.

Making copies of something is very different than adding a new
name for it.  Are you suggesting that one can get away with
one or the other?  Not attacking, just trying to understand.

>And, if I want a very different visible filespace from other users, I
>get that by doing a very large number of binds, but that has bad
>performance costs because it was assumed that users wouldn't have a
>huge number of them.

The number would have to be truly huge to get a measurable
performance hit, the table is hashed fairly well.  Similarly,
forking a new name space is rare enough that the copy wouldn't
hurt much unless we're talking megabytes.  What
exactly are you thinking of?  Or is it actually setting
up the table in the first place?


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06 16:59 anothy
  2001-11-06 17:54 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: anothy @ 2001-11-06 16:59 UTC (permalink / raw)
  To: 9fans

// Some links are found by asking a file server; some
// are found by consulting the process's name space.

this is incorrect. _all_ "links" are found by consulting
the processes name space, _then_ eventually by consulting
the appropriate file server. said file server may be a
"real" fs with lots of disk running a special kernel, a
user-land process providing disk access, a local kernel
device, a memory-based file system imported from another
system, a dæmon on a unix box...

the point is that there's one protocol for access to all
these devices, regardless of type, and one chunk of code
that acts as a client for them all (the kernel). i just
don't understand what you'd like to "take even further".
there are more things we can do, but i'm not sure what
disparity you see that you want to unify.

i want _more_ different types of file servers, doing more
and more interesting things, giving acces to more types
of information and services. would thins make worse the
problem you're trying to address?
ア


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06 13:45 nigel
  0 siblings, 0 replies; 120+ messages in thread
From: nigel @ 2001-11-06 13:45 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

> I've gotten so fed up with fiddling with PC hardware recently
> that I think my next PC will be a Dell or Gateway or something
> instead of the built-it-myself one I now have. That way I'm
> fairly sure the hardware will work together.

Sorry to disappoint you, but buying such machines is often a recipe
for ensuring only Windows will work.  The hardware works very well
together, yes, but it is not always obvious how it is connected
together.  This is why laptops are such trouble.

Dell do their own motherboards, BIOS etc., and reason that if they
also do the drivers, then it will all work.  You then need to be sure
that they do drivers for your OS of choice.  Not good for Plan 9
users.

Harking back to olden times, when a 386DX with 8MB was a huge machine,
the supplier to buy from was Compaq.  As PCs went at the time, Compaqs
were the LEAST compatible, but also the MOST reliable. Of course, we
only had a choice of one OS then.

So, if you want zero hardware hassle, don't buy a PC at all, unless
you want to run Windows, and only Windows.


[-- Attachment #2: Type: message/rfc822, Size: 3535 bytes --]

From: Tomas <psycho@pobox.com>
To: 9fans <9fans@cse.psu.edu>
Subject: Re: [9fans] Plan 9
Date: Tue, 6 Nov 2001 14:34:53 +0100 (MET)
Message-ID: <Pine.GSO.4.33.0111061421270.15195-100000@hoth.cs.umu.se>

On Tue, 6 Nov 2001 at 10:31am, Jonadab the Unsightly One wrote:

> forsyth@vitanuova.com writes:
>
> > the aim was to avoid the PC user having to put a network card
> > in the machine to use ADSL. most machines (now) have got USB,
> > but haven't got ether on the motherboard, which is just as
> > well because when they do include one, it's often something
> > stupid.
>
> Yes, as cheap as decent 10/100 cards are these days, onboard
> ethernet seems silly. As far as not wanting to put in a card...
> I thought most of the people who didn't want to open the case
> and put in an expansion card used either MacOS or Windows
> (because they use whatever came on the hard drive when they
> bought the thing).

Or they could be like me, and just hate fiddling with the
hardware. I recently tried to install a new graphics card and a
new hard drive in my computer, and got so frustrated by the
experience that I wrote a 250+ lines rant about it. In the end,
after upgrading the BIOS, I still haven't gotten the graphics
card to work, and the BIOS doesn't detect the new hard drive, but
Linux does detect it so I hope that will allow me to install and
boot Win* and Plan 9 from the new hard drive through use of LILO
(since Plan 9 under VMWare not yet seems to work).

Some people like to dig into hardware, some like to dig into
software, and some just like to use computers without sinking
their teeth into neither hardware nor OS/software. If computers
and computing is to evolve, we computer professionals have to
accept that all these categories of people (and more) exist, and
try to make computers and software that they can use without
occasionally wanting to smash the monitor with a baseball bat.

I've gotten so fed up with fiddling with PC hardware recently
that I think my next PC will be a Dell or Gateway or something
instead of the built-it-myself one I now have. That way I'm
fairly sure the hardware will work together.

/Tomas

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06 13:33 rob pike
  2001-11-06 17:53 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: rob pike @ 2001-11-06 13:33 UTC (permalink / raw)
  To: 9fans

> I'm not suggesting a change in Plan 9; I'm thinking about file system
> name spaces in general, and thinking that the per-process variability
> of Plan 9 is great, but I think it could be taken even further; in
> that way unifying all the different kinds of links there are.

To what effect?  You've yet to ponit out a problem or limitation introduced
by the way Plan 9 does this.  It's one thing to say things could be different;
it's quite another to make a convincing argument why it's worthwhile.

-rob



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-06  1:14 presotto
  2001-11-06  1:30 ` Scott Schwartz
  0 siblings, 1 reply; 120+ messages in thread
From: presotto @ 2001-11-06  1:14 UTC (permalink / raw)
  To: 9fans


> same protocol talks to them all,
> same tools manipulate them all,

sounds like:

one ring to rule them, one ring to find them, one ring to bring them all, and in the
darkness bind them.


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-05 21:47 David Gordon Hogan
  2001-11-05 21:53 ` andrey
  2001-11-06 10:43 ` pac
  0 siblings, 2 replies; 120+ messages in thread
From: David Gordon Hogan @ 2001-11-05 21:47 UTC (permalink / raw)
  To: 9fans

> > What do people think about per-process directory hierarchies?  I've
> > asked the question about four times now, and sadly, nobody in this
> > happy collaborative environment has anything to say.
>
> 	Nice thing. Linux is to borrow it :>

No, no, Plan 9 is to borrow Linux users.

All your user base are belong to us!



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-05 21:04 rob pike
  0 siblings, 0 replies; 120+ messages in thread
From: rob pike @ 2001-11-05 21:04 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 66 bytes --]

ADSL is much more complex than that, I can assure you.

-rob


[-- Attachment #2: Type: message/rfc822, Size: 1550 bytes --]

From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Plan 9
Date: Mon, 5 Nov 2001 21:00:52 0000
Message-ID: <20011105210129.8FAA5199E3@mail.cse.psu.edu>

> i read somewhere that
> they run some form of ATM over the USB.  well.

Yes I can confirm that, having just hooked up to British Telecom's
ADSL service which provides IP via PPP over ATM through USB
into ADSL.  Yikes.

-- Richard

^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-05 21:00 Richard Miller
  0 siblings, 0 replies; 120+ messages in thread
From: Richard Miller @ 2001-11-05 21:00 UTC (permalink / raw)
  To: 9fans

> i read somewhere that
> they run some form of ATM over the USB.  well.

Yes I can confirm that, having just hooked up to British Telecom's
ADSL service which provides IP via PPP over ATM through USB
into ADSL.  Yikes.

-- Richard



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-05 18:18 anothy
  2001-11-06  1:06 ` YAMANASHI Takeshi
                   ` (2 more replies)
  0 siblings, 3 replies; 120+ messages in thread
From: anothy @ 2001-11-05 18:18 UTC (permalink / raw)
  To: 9fans

// So in that case, in Plan 9 there are at least four different sets of
// tools for making a new link--at least.  Some sample places that links
// get specified:
//
//   * Default links go in the fileserver's data structures on disk, and
//     are manipulated by a host of cooperating programs and syscalls.
//   * Other defaults go in the file that specifies the initial contents
//     of users' mount tables.
//   * Users have startup files that fill their mount tables with links.
//   * Shell commands and syscalls are available to change the mount
//     tables transiently.

i think you're confused, and i think it's because the idea of "links" from
the Unix world doesn't really translate well into the Plan 9 world.

first off, take a look at /lib/namespace (what i think you're getting at in
the second item in your list) and the namespace operations in
/usr/<user>/lib/profile (the third in your list, i think). bind, mount,
unmount, etc. in both places. same for the user. at the system level, it
all goes down into calls to things in bind(2). same system mechanics
regardless.

you _tell_ the kernel where to get its root file system (the first thing it
mounts) from at the "root is from" prompt on booting. there's nothing
special about "creating links" going on when you import a fs that
happens to be living on disk. the tools for manipulating "links" are not
different depending on whether we're dealing with disk or not. try:
	cd /env ; echo bark > tree ; mv tree wood ; cat wood
and lemme know what you get. no disk structures. same in ramfs and
other places.

// having on-disk data structures that represent them is a perfectly
// decent implementation strategy, but now I hope it's clear that this is
// just an implementation detail, and need not directly influence the
// appearance of the system to the user.

maybe i just totally miss what you're getting at (as you warned we
might). but the above point is kinda fundamental to Plan 9. of _course_
structures on disk is just an implementation. when my terminal boots
up, it doesn't know - nor care - where the files being served to it come
from, or how they're stored. local or remote disk, tape, ram, kernel
devices, optical jukeboxes, CDs, whatever. same protocol talks to them
all, same tools manipulate them all, and to the system they're more or
less indistinguishable. that's the point.
ア



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-05 17:45 forsyth
  2001-11-05 17:44 ` Boyd Roberts
  2001-11-06 10:31 ` Jonadab the Unsightly One
  0 siblings, 2 replies; 120+ messages in thread
From: forsyth @ 2001-11-05 17:45 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

the aim was to avoid the PC user having to put a network card in the
machine to use ADSL.  most machines (now) have got USB, but haven't
got ether on the motherboard, which is just as well because when they
do include one, it's often something stupid.  i read somewhere that
they run some form of ATM over the USB.  well.

fortunately, my set-top box has an RJ45 port so i can ignore all that
nonsense.


[-- Attachment #2: Type: message/rfc822, Size: 2110 bytes --]

To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Plan 9
Date: Mon, 5 Nov 2001 18:08:25 +0100
Message-ID: <00d601c1661c$7dd9d5b0$f9b9c6d4@SOMA>

> USB?  Just say no.

The new fad seems to be USB mice.  I have a bad feeling about this.

It's a sad state of affairs when you have to get a RS-232 protocol
analyser out to work out what your mouse is doing.

France Telecom even have an ADSL offering that uses ...

   USB

Couldn't get UTP/RJ-45s this year?


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-05 15:48 presotto
  2001-11-06 10:31 ` Jonadab the Unsightly One
  2001-11-06 10:32 ` Thomas Bushnell, BSG
  0 siblings, 2 replies; 120+ messages in thread
From: presotto @ 2001-11-05 15:48 UTC (permalink / raw)
  To: 9fans

No, everyone has to have exactly the same size screen and
has to type the same characters simultaneously...

The essence of rob's statement is that if you do nothing
to change it, your default working environment includes the
same set of shared resources that everyone else has, i.e.,
sources in the same place, servers with the same names, etc.
However you can modify that to hell and gone to the point
that one would be hard pressed to figure out two people are
in the same world.  The intentions were:

1) create an environment that was as easy to collaborate
 in as we had when we all lived on a single machine
2) don't force every user to be a system administrator

The system itself is malleable enough that I can create
sandboxes for users on my systems in which they think they are on
totally separate boxes.

That said, the amount of configurability of the UI is much
smaller than X windows.  Having just spent 3 weeks trying to
make 3 Linux systems look sort of the same, I appreciate that
less can be better.  However, I was a minimalist to start with
and this certainly will grate on the people that like to remap
every key, command name, function, and window border.  If you
do, Plan 9 isn't for you.


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-02 18:36 Russ Cox
  2001-11-05 16:49 ` Jonadab the Unsightly One
  0 siblings, 1 reply; 120+ messages in thread
From: Russ Cox @ 2001-11-02 18:36 UTC (permalink / raw)
  To: 9fans

> But the BIOS should understand the USB floppy and from there you can
> boot/install from c: unless this m/c is weirder than a VAIO.

We tried that.  Loading the kernel off the disk never gets
the right bits.  We suspect that maybe the USB is busmastering
and we need to turn it off.  It's all just never-ending hacks
because we don't have real USB support.

Russ



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-02 17:57 forsyth
  2001-11-02 18:22 ` Boyd Roberts
  0 siblings, 1 reply; 120+ messages in thread
From: forsyth @ 2001-11-02 17:57 UTC (permalink / raw)
  To: 9fans

if you haven't got a supported floppy disk drive you can still install the
system, if you've got a CD drive, and
if you've got Windows 9x running, with
ftp, but you need to do much of the installation by hand,
and you'll need a version of the kernel that
runs off a CD (booting the kernel from the hard disk).
i've just had to do that with a new thinkpad a22e.
you can even do it without the ethernet, but you'll need
to transfer the 9pccd kernel some other way.


^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-02 17:26 Russ Cox
  2001-11-02 18:29 ` Boyd Roberts
                   ` (2 more replies)
  0 siblings, 3 replies; 120+ messages in thread
From: Russ Cox @ 2001-11-02 17:26 UTC (permalink / raw)
  To: 9fans

> Sadly, it doesn't run on my laptop.  Despite much energy from Russ Cox
> (for which I am grateful) it doesn't install.  Some of the reasons for
> the problem include a dependency on Microdreck in the install system
> and forgetting about extended partitions when designing the install
> process.

Now, now, be fair.  The real problem is that we don't have a USB
driver at boot, we require a floppy disk to install, and your laptop's
floppy drive is USB.  There is no dependency on Microsoft operating
systems whatever (though our boot floppy happens to use their
file system format), and what we ``forgot'' was the ability to boot
out of extended partitions that are pretending to be a floppy disk,
which no one else does either.  There are some bugs in fdisk's
extended partition table parsing too, but we didn't get far.

Our lack of USB support is the real problem here.  I wish...

Russ



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-11-02 13:53 rob pike
  2001-11-05 10:20 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 120+ messages in thread
From: rob pike @ 2001-11-02 13:53 UTC (permalink / raw)
  To: 9fans

> To repeat: Plan 9 has a nifty idea of making mount tables per-process,
> and as a result gets huge benefits across the board.  But why stop
> there?  Why should not *all* links (instead of just some) be a
> per-process matter?

Any 'link' can be per-process in Plan 9, but in practice only those ones
that need to be are invested with the trouble to make them so. Otherwise,
I would have to write down somewhere what all the default links would
be for a process when it starts running, and that would be a huge
list of information and also unpredictable since I can't say what resources
the process is likely to need dynamically.  It seems both much simpler
and just as general to let the file system set the defaults with its directory
structure and override them for the relatively small number of cases
needed, which is exactly what Plan 9 does.

In other words, in Plan 9 all links *can* be per-process but only those
that *need* to be actually are.  Why do it differently?

Or perhaps I don't understand what you're asking.

-rob



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-10-29 21:08 David Gordon Hogan
  2001-11-05 15:00 ` Jonadab the Unsightly One
  0 siblings, 1 reply; 120+ messages in thread
From: David Gordon Hogan @ 2001-10-29 21:08 UTC (permalink / raw)
  To: 9fans

> On a related note, I think it'd be nice to have
> an oracle for the halting problem.  'Twould make
> kernel debugging a small bit easier.
> 
> Feature lists are great, but don't forget that there's
> always an implementation cost.

Yeah, but in your example, the cost is infinite...



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-10-26 15:12 Russ Cox
  2001-10-29 10:16 ` Ozan Yigit
  0 siblings, 1 reply; 120+ messages in thread
From: Russ Cox @ 2001-10-26 15:12 UTC (permalink / raw)
  To: 9fans

>	Berkeley has also project of storage called OceanStore, it allows
>	decentralized multiserver storage of unlimited scalability and
>	virtually maintenance-free storage nodes. It is a step to global
>	transparency of storage, like Internet is global transparency of
>	communication. Very nice thing to have in Plan9, I think.

On a related note, I think it'd be nice to have
an oracle for the halting problem.  'Twould make
kernel debugging a small bit easier.

Feature lists are great, but don't forget that there's
always an implementation cost.

Russ



^ permalink raw reply	[flat|nested] 120+ messages in thread
* Re: [9fans] Plan 9
@ 2001-10-25 17:52 Russ Cox
  2001-10-26  9:23 ` Wladimir Mutel
  0 siblings, 1 reply; 120+ messages in thread
From: Russ Cox @ 2001-10-25 17:52 UTC (permalink / raw)
  To: 9fans

	Is not it bad to have centralized fileserver in Plan9 ? May be this
	affects scalability ? Is there a way for Plan9 to use multiple-server
	or serverless filesystem like Berkeley xFS or DEC Frangipani ? Also,
	lack of local caching hurts, especially between cpu-server and
	9fs-server.

Sure, it affects scalability.  But when you need to support
tens or even a hundred nodes, it doesn't matter.  I don't think
we'd scale to a thousand nodes very well.  But the answer to
that is probably some sort of leases and tokens to enable
more agressive caching, rather than something like xFS or
Frangipani.  Be pragmatic: it's easier to maintain one Plan 9
file server than a whole bunch of xFS or Frangipani nodes,
especially since you don't have to worry about things like
consistency or node disconnections.

Russ



^ permalink raw reply	[flat|nested] 120+ messages in thread
* [9fans] Plan 9
@ 2001-10-25 12:45 rob pike
  2001-10-25 13:47 ` Borja Marcos
                   ` (3 more replies)
  0 siblings, 4 replies; 120+ messages in thread
From: rob pike @ 2001-10-25 12:45 UTC (permalink / raw)
  To: 9fans

The original reason behind Plan 9 is still the most important and,
unfortunately, is largely obscured by the need to make a distribution
and the desire for individuals to run it on PCs: a shared environment.
We boot all our machines in the lab over the network; they have no
local state except a configuration file (plan9.ini) usually held on a
floppy.  When I go home, my environment - that is, the working state
of my machine - is identical not only with my environment at work, but
with all my colleague's working state, too.  Diskless operation is not
only possible, it's the basic principle of the system.  It's just like
the good old timesharing days: our machines are *terminals* to a large
computing system; whatever machine I sit down at to work, I have
equivalent access to identical resources.  It's more than diskless,
it's transparent statelessness.

Local administration?  What's that?

Sure, with NFS you can get somewhere close to that ideal, but then why
are there so few truly diskless Unix systems out there?  One reason is
that the storage file system isn't enough: the environment includes a
huge array of other machines with special local services
(authentication, printing, backup, connections to other OSs and
networks, etc.)  and the NFS model doesn't permit a general enough
notion of file.  Plan 9 does.  That's the true joy of it.

-rob



^ permalink raw reply	[flat|nested] 120+ messages in thread
* [9fans] Plan 9
@ 1998-11-13  8:29 Scott
  0 siblings, 0 replies; 120+ messages in thread
From: Scott @ 1998-11-13  8:29 UTC (permalink / raw)


Mats Karlssohn <sm5tfx@swipnet.se> writes:
| Will the IPC be fas enough to give resonable performance?
| Better ideas ?

I used an ss2, which was ok, but I had random problems with the scsi
controllers in my SLCs.  (I didn't have any IPCs, sorry.)  If you use
an x86 you can use more modern scsi controllers, which will probably be
faster and more stable.





^ permalink raw reply	[flat|nested] 120+ messages in thread
* [9fans] Plan 9
@ 1998-11-11 21:08 Mats
  0 siblings, 0 replies; 120+ messages in thread
From: Mats @ 1998-11-11 21:08 UTC (permalink / raw)


I'm thinking about ordering the Plan 9 distribution to get something
fresh
to play around with. Not to make things too easy for me I'm (and to make
use of machines present in the appartment) thinking of using an old
SPARCstation IPC as my file server and a pentium/200 as CPU server. What
I
basically want to know is: is this a resonable configuration ? Will the
IPC
be fas enough to give resonable performance ? Better ideas ?

-- 
Mats Karlssohn (SM5TFX), sm5tfx@swipnet.se
"Without mistakes there is no forgiving, without forgiving there is no
love"




^ permalink raw reply	[flat|nested] 120+ messages in thread

end of thread, other threads:[~2002-08-30 10:15 UTC | newest]

Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-07 10:03 [9fans] Plan 9 forsyth
2001-11-08 10:38 ` Thomas Bushnell, BSG
  -- strict thread matches above, loose matches on Subject: below --
2002-08-30 10:15 [9fans] plan 9 nigel
2002-08-30  9:57 Isaac Stern
2001-11-13 10:53 [9fans] Plan 9 Fco.J.Ballesteros
2001-11-09 22:39 David Gordon Hogan
2001-11-09 12:25 geoff
2001-11-12 10:32 ` Thomas Bushnell, BSG
2001-11-12 15:11   ` Ozan Yigit
2001-11-13  0:15     ` Jim Choate
2001-11-12 11:41 ` Sam Ducksworth
2001-11-13 10:25   ` Thomas Bushnell, BSG
2001-11-09  1:47 okamoto
2001-11-08 15:05 presotto
2001-11-08 14:44 forsyth
2001-11-08 14:02 presotto
2001-11-09  0:25 ` Dan Cross
2001-11-09 10:08 ` Thomas Bushnell, BSG
2001-11-09 17:31   ` Dan Cross
2001-11-12 10:33     ` Thomas Bushnell, BSG
2001-11-13  2:10       ` Dan Cross
2001-11-13 10:34         ` Thomas Bushnell, BSG
2001-11-08 13:07 Bruce Janson
2001-11-09 10:07 ` Thomas Bushnell, BSG
2001-11-08 13:06 rob pike
2001-11-09 10:08 ` Thomas Bushnell, BSG
2001-11-07 18:05 anothy
2001-11-07 17:43 anothy
2001-11-07 17:47 ` Boyd Roberts
2001-11-07 17:28 Russ Cox
2001-11-08 10:39 ` Thomas Bushnell, BSG
2001-11-08 19:38   ` Steve Kilbane
2001-11-09 10:18     ` Thomas Bushnell, BSG
2001-11-07 12:58 rob pike
2001-11-08 10:39 ` Thomas Bushnell, BSG
2001-11-07 11:00 geoff
2001-11-08 10:39 ` Thomas Bushnell, BSG
2001-11-07  1:09 David Gordon Hogan
2001-11-06 18:46 anothy
2001-11-07  9:44 ` Thomas Bushnell, BSG
2001-11-06 18:14 forsyth
2001-11-07  9:43 ` Thomas Bushnell, BSG
2001-11-06 18:07 presotto
2001-11-07  9:44 ` Thomas Bushnell, BSG
2001-11-06 16:59 anothy
2001-11-06 17:54 ` Thomas Bushnell, BSG
2001-11-06 13:45 nigel
2001-11-06 13:33 rob pike
2001-11-06 17:53 ` Thomas Bushnell, BSG
2001-11-06  1:14 presotto
2001-11-06  1:30 ` Scott Schwartz
2001-11-06  1:37   ` YAMANASHI Takeshi
2001-11-05 21:47 David Gordon Hogan
2001-11-05 21:53 ` andrey
2001-11-06 10:31   ` Jonadab the Unsightly One
2001-11-06 10:32   ` Thomas Bushnell, BSG
2001-11-06 10:43 ` pac
2001-11-05 21:04 rob pike
2001-11-05 21:00 Richard Miller
2001-11-05 18:18 anothy
2001-11-06  1:06 ` YAMANASHI Takeshi
2001-11-06 10:31 ` Jonadab the Unsightly One
2001-11-06 10:32 ` Thomas Bushnell, BSG
2001-11-05 17:45 forsyth
2001-11-05 17:44 ` Boyd Roberts
2001-11-06 10:31 ` Jonadab the Unsightly One
2001-11-06 13:34   ` Tomas
2001-11-05 15:48 presotto
2001-11-06 10:31 ` Jonadab the Unsightly One
2001-11-06 10:32 ` Thomas Bushnell, BSG
2001-11-06 17:53   ` Ozan Yigit
2001-11-02 18:36 Russ Cox
2001-11-05 16:49 ` Jonadab the Unsightly One
2001-11-05 17:21   ` Ian Cooper
2001-11-06 10:30     ` Jonadab the Unsightly One
2001-11-02 17:57 forsyth
2001-11-02 18:22 ` Boyd Roberts
2001-11-02 17:26 Russ Cox
2001-11-02 18:29 ` Boyd Roberts
2001-11-05 10:21 ` Thomas Bushnell, BSG
2001-11-05 16:49 ` Jonadab the Unsightly One
2001-11-05 17:08   ` Boyd Roberts
2001-11-06 10:23     ` Jonadab the Unsightly One
2001-11-02 13:53 rob pike
2001-11-05 10:20 ` Thomas Bushnell, BSG
2001-10-29 21:08 David Gordon Hogan
2001-11-05 15:00 ` Jonadab the Unsightly One
2001-10-26 15:12 Russ Cox
2001-10-29 10:16 ` Ozan Yigit
2001-10-25 17:52 Russ Cox
2001-10-26  9:23 ` Wladimir Mutel
2001-10-26 15:03   ` William Josephson
2001-10-26 20:14     ` Dan Adkins
2001-10-25 12:45 rob pike
2001-10-25 13:47 ` Borja Marcos
2001-10-25 21:52   ` Jim Choate
2001-10-26  8:35     ` Lucio De Re
2001-10-25 16:59 ` Wladimir Mutel
2001-11-01  9:47 ` Randolph Fritz
2001-11-01 14:18   ` Ronald G Minnich
2001-11-02  9:58   ` Thomas Bushnell, BSG
2001-11-02 11:43     ` Wladimir Mutel
2001-11-02 12:39       ` Alexander Viro
2001-11-05 14:11         ` Wladimir Mutel
2001-11-05 15:13           ` Alexander Viro
2001-11-05 16:30             ` Boyd Roberts
2001-11-05 17:37               ` Alexander Viro
2001-11-05 17:42                 ` Boyd Roberts
2001-11-05 18:04                   ` Alexander Viro
2001-11-05 18:30                     ` Boyd Roberts
2001-11-05 19:58                     ` Ronald G Minnich
2001-11-02 15:36       ` Ronald G Minnich
2001-11-02 15:42         ` andrey
2001-11-02 15:54           ` Ronald G Minnich
2001-11-05 15:01 ` Jonadab the Unsightly One
2001-11-05 15:29   ` Markus Friedl
2001-11-05 15:49   ` Lucio De Re
2001-11-06 10:23     ` Jonadab the Unsightly One
1998-11-13  8:29 Scott
1998-11-11 21:08 Mats

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).