Re: [9fans] Plan 9

Re: [9fans] Plan 9

[anothy]

// 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.
ア

Re: [9fans] Plan 9

[YAMANASHI Takeshi]

> local or remote disk, tape, ram, kernel
> devices, optical jukeboxes, CDs, whatever.

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

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

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

anothy@cosym.net writes:

> 	cd /env ; echo bark > tree ; mv tree wood ; cat wood

If I understand the above, that's pretty cool.  It would tend to make
writing shell scripts somewhat easier...

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

anothy@cosym.net writes:

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

By "link" I mean specifically what it is that gets followed in a
directory when a name is looked up.  That might be in a mount table or
on a filesystem, and I'm counting up the places where one might
specify "I want a link to exist here".

The various wrappers around bind(2) certainly all boil down to the
same thing.  So let's pretend they are all one thing, and we still
have two different kinds of links: those made by bind(2) and those
made by link(2).

This is a matter of an implementation difference being exported to
users.  One consequence of it is that there is a performance penalty
on users who might want very large mount tables.

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

I was being sloppy.  Instead of "on disk" I should have meant
"accessible by the file protocol" (whatever kind of file it is).

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

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.

Re: [9fans] plan 9

[nigel]

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

[9fans] plan 9

[Isaac Stern]

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.

Re: [9fans] Plan 9

[Fco.J.Ballesteros]

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

Re: [9fans] Plan 9

[David Gordon Hogan]

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

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

Re: [9fans] Plan 9

[geoff]

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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

geoff@collyer.net writes:

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

I wasn't saying anything about Plan 9 being evil or a waste of time,
just explaining why a particular large developer base is not spending
effort on it.  Other people were musing about why this might be, and I
added one very important reason.

Re: [9fans] Plan 9

[Ozan Yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

> I wasn't saying anything about Plan 9 being evil or a waste of time,
> just explaining why a particular large developer base is not spending
> effort on it.  Other people were musing about why this might be, and I
> added one very important reason.

i informally find (amongst grad students, many foreign) that license has
nothing to do with it. seems like path of least resistence with most fun
has a lot to do with it. connectivity and community has to do with it.
moreover, most instructors use linux for grad teaching. importance of
subtle license details is overblown.

oz
--
www.cs.yorku.ca/~oz	 | if you couldn't find any weirdness, maybe
york u. computer science | we'll just have to make some!   -- hobbes

Re: [9fans] Plan 9

[Jim Choate]

On Mon, 12 Nov 2001, Ozan Yigit wrote:

> i informally find (amongst grad students, many foreign) that license has
> nothing to do with it.

Well that certainly defines the potential market for distributed
computing services.

I feel so much better now, thank you.


 --
    ____________________________________________________________________

             Day by day the Penguins are making me lose my mind.

                                             Bumper Sticker

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Plan 9

[Sam Ducksworth]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1069 bytes --]

i agree. i would also like to point out to all those who have
downloaded a copy of plan9 and do not agree to the terms of the
license, 'YOU' are in violation of the license agreement. so you
should discontinue your use of this product and delete any and
all traces of the plan9 software and unsubscribe from this list
and go play elsewhere.

On Fri, 9 Nov 2001 geoff@collyer.net wrote:

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

--sam

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

sam@ducksworth.com (Sam Ducksworth) writes:

> i agree. i would also like to point out to all those who have
> downloaded a copy of plan9 and do not agree to the terms of the
> license, 'YOU' are in violation of the license agreement.

Is there anyone who has done this?

Re: [9fans] Plan 9

[okamoto]

>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

Re: [9fans] Plan 9

[presotto]

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

Re: [9fans] Plan 9

[forsyth]

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

Re: [9fans] Plan 9

[presotto]

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

Re: [9fans] Plan 9

[Dan Cross]

In article <20011108140245.3ADD6199F2@mail.cse.psu.edu> you write:
>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.

Doesn't Amoeba basically do this?  Everything is represented as a
(named) object, and there's a mapping from symbolic name to object
ID.  There's nothing inherent in the system that says that the
mapping can't be arbitrary, user driven, etc.

	- Dan C.

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

presotto@closedmind.org writes:

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

This is certainly the nutshell version.

> It is indeed an interesting idea.  It seems that sharing views would
> also be desirable since you would need to communicate with others.

Sharing is totally important, and most users will want to inherit a
fairly similar default vie.

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

The cost of running such scripts is one thing that makes kludging this
into Plan 9 a bad idea; I hadn't thought of that explicitly.

I think that it's not actually necessary to have a separate naming
scheme, except for the case of privileged maintenance procedures that
want to be able to get at every object.

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

That's pretty close indeed.  Part of the difficulty has been that I'm
trying to work out the idea, not claiming that it's fully formed.

Re: [9fans] Plan 9

[Dan Cross]

In article <87hes5vzj1.fsf@becket.becket.net> you write:
>I think that it's not actually necessary to have a separate naming
>scheme, except for the case of privileged maintenance procedures that
>want to be able to get at every object.

So how do you reference the objects?  Even a disk block address can
be thought of as a name.  Amoeba did it by assigning each object a
128-bit globally unique identifier, and then defining a mapping from
``name'' to OID.  In a sense, the OID is a name which references a
specific object.  You need some such underlying scheme to be able to
get at the objects.

>> So, it this what you are intending?  Sorry its taken so long to
>> figure it out but your descriptions have been less than clear.
>
>That's pretty close indeed.  Part of the difficulty has been that I'm
>trying to work out the idea, not claiming that it's fully formed.

Amoeba did it; go ask Andy Tannenbaum.  Now, can we please take the
discussiout out of 9fans?  It's pretty clear that you're not interested
in much other than bitching.

	- Dan C.

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> In article <87hes5vzj1.fsf@becket.becket.net> you write:
> >I think that it's not actually necessary to have a separate naming
> >scheme, except for the case of privileged maintenance procedures that
> >want to be able to get at every object.
>
> So how do you reference the objects?  Even a disk block address can
> be thought of as a name.  Amoeba did it by assigning each object a
> 128-bit globally unique identifier, and then defining a mapping from
> ``name'' to OID.  In a sense, the OID is a name which references a
> specific object.  You need some such underlying scheme to be able to
> get at the objects.

There certainly do need to be some kind of universal ID's inside the
system.  I just suspect it's not ever necessary to export those ID's
to the user, that's all.  Rather like how Lisp never exports actual
machine addresses to the users of objects.

> Amoeba did it; go ask Andy Tannenbaum.  Now, can we please take the
> discussiout out of 9fans?  It's pretty clear that you're not interested
> in much other than bitching.

Well, I'm posting to comp.os.plan9, whose name indicates nothing about
the obligation to be a fan.  Though I am a fan about lots of parts of
Plan 9.

Re: [9fans] Plan 9

[Dan Cross]

In article <87k7wztt7n.fsf@becket.becket.net> you write:
>There certainly do need to be some kind of universal ID's inside the
>system.  I just suspect it's not ever necessary to export those ID's
>to the user, that's all.  Rather like how Lisp never exports actual
>machine addresses to the users of objects.

Yeah, sure.  Go ask Andy Tannenbaum how you write a name server for
Amoeba, will ya?

>> Amoeba did it; go ask Andy Tannenbaum.  Now, can we please take the
>> discussiout out of 9fans?  It's pretty clear that you're not interested
>> in much other than bitching.
>
>Well, I'm posting to comp.os.plan9, whose name indicates nothing about
>the obligation to be a fan.  Though I am a fan about lots of parts of
>Plan 9.

Comp.os.plan9 is gatewayed to and from a mailing list called 9fans.

Part of netiquette is recognizing such things and showing some
sensitivity to them.  Part of netiquette is also learning to keep
things more or less on-topic.  While some off-topicness is fine and
even good (how can you build a community without humor, for instance,
or germinate new ideas?) repeated off-topic posts about a particular
subject which isn't new when people are asking you to stop is just
rude.

Perhaps you should buzz by news.announce.newusers?

	- Dan C.

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> Yeah, sure.  Go ask Andy Tannenbaum how you write a name server for
> Amoeba, will ya?

Amoeba is a different sort of system in a jillion ways.  But I think
that's strayed from the things I'm most interested in, so I won't
address it in principle.  But basically I was agreeing with you.

> Comp.os.plan9 is gatewayed to and from a mailing list called 9fans.
>
> Part of netiquette is recognizing such things and showing some
> sensitivity to them.  Part of netiquette is also learning to keep
> things more or less on-topic.  While some off-topicness is fine and
> even good (how can you build a community without humor, for instance,
> or germinate new ideas?) repeated off-topic posts about a particular
> subject which isn't new when people are asking you to stop is just
> rude.

The status of the license for Plan 9, and OS questions that Plan 9
people are particularly well placed to think about, are both on topic
here, for the simple reason that this is the one and only Plan 9
newsgroup.

If you want to create more topic-specific Plan 9 newsgroups, I have no
objection.

I posted exactly two posts that originated the topic of licensing; all
other posts of mine on the subject have been responses to those of
others.  If I were the only one who finds it an interesting and
relevant topic, then why are there several other people also
participating in the thread?

Perhaps the problem is that your mail/news client is unable to kill
threads that aren't interesting to you.

Thomas

Re: [9fans] Plan 9

[Bruce Janson]

    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"?

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

bruce@cs.usyd.edu.au (Bruce Janson) writes:

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

Really?  So think about it.  I want an entire directory structure,
just for me.  Not shared with other people.  How, exactly, do I do
that?

Once I have it, will I be able to create a directory that appears only
in my structure, and not in anyone else's?  Will I be able to delete a
file such that it goes away for me and not for other people?  As I
understand it, those are not possible in Plan 9, certainly not in any
convenient way, and certainly not by using tools like normal file
creation and normal file deletion.

This leaves aside the scale issue.  Will Plan 9 be happy if each user
on a system with 10,000 files has a 10,000 big mount table?

Re: [9fans] Plan 9

[rob pike]

> 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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

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

For number 1), the issue is decoupling different kinds of sharing from
the tools that set them up.

Depending on exactly what kind of sharing I want in doing a bind, I
can type a shell command, edit a per-user config file or edit a system
config file.

There are very different tools to set up these different kinds of
sharing.

For number 2), suppose I want to set up a file that is visible in my
name space, but not in other peoples'.  How do I do that?

Those aren't the only cases, but they are the most immediately clear,
I think.

Re: [9fans] Plan 9

[anothy]

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 α.
ア

Re: [9fans] Plan 9

[anothy]

// ...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.
ア

Re: [9fans] Plan 9

[Boyd Roberts]

    ア

Nice katakana 'a' :)

Re: [9fans] Plan 9

[Russ Cox]

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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

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

Right, I knew this, but I was short-cutting my description in the
hopes of consiceness, and it seems I failed in my attempt.

If there is a mapping from the file FOO to the file BAR specified in
the mount table, then the user will never be able to see FOO, right?

So if there is a directory DIR, and it has a name "foo" which maps to
the file FOO, then the user who looks for DIR/foo will get BAR.
That's the conjunction of a pair of mappings; one is the link in the
directory DIR; the other is the mapping translation from FOO to BAR.

But a user who looks up a file name always and only sees BAR, except
when they use the special tools to manipulate the mount table.  Right?

That situation involves a link from DIR/foo to BAR; the link (a
mapping from a name to a file) is the composition of the in-directory
link DIR/foo -> FOO; and the mount-table mapping FOO -> BAR.

But the second part of that is quite automatic: opening a file always
evaluatios the composed mapping.  It's that composed mapping that I
was (hoping for brevity) calling a link in the mount table.  Yes, it's
actually both in the mount table and in the directory DIR.  But the
point is that if you want to know what looking up DIR/foo gets you,
it's not enough to just look at DIR... you also have to know the
FOO->BAR mapping.

So my idea is that Plan 9 has a great idea: take mount tables and make
them per-process.  From that one very simple idea, a great many
important advantages come.

I'm saying that I think very nice advantages can accrue from saying
"hey, 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."  Now nothing here prevents a clever implementation that
has a default, that allows for careful sharing and efficient lookups.
But at the level of interfaces and what the user sees, this could be,
I think, an improvement.

Obviously, it results in a system very different from both Unix and
Plan 9.  But that's not a stroke against it, is it?

Re: [9fans] Plan 9

[Steve Kilbane]

> I'm saying that I think very nice advantages can accrue from saying
> "hey, 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."  Now nothing here prevents a clever implementation that
> has a default, that allows for careful sharing and efficient lookups.
> But at the level of interfaces and what the user sees, this could be,
> I think, an improvement.

Seems to me that this would be the equivalent of binding every single
file in every file server, or alternatively restricting each file server
to serving but a single file.

Now the big question: what's the point? The early Plan 9 papers make the
point that one can rearrange one's view of the system to one's heart's
content, but that there are conventions that apply if you want everything
to work as expected. The advantages accrue from judicious application of
the namespace abilities. In the context of what you're describing, the
existing directory structures provided by the file servers are those
expected conventions.

steve

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

steve@whitecrow.demon.co.uk (Steve Kilbane) writes:

> Now the big question: what's the point?

Not much point in Plan 9.  It would be a ludicrous mistake to make
Plan 9 be such a system.

But that's not the point here.

Re: [9fans] Plan 9

[rob pike]

> 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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

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

There are several advantages:

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.

The principal goal is unification: a goal that says to reduce wherever
possible the number of ways there are of doing the same thing, thus
resulting in a simplification of the system.  Unification is not the
only goal, but it's an important one.

Re: [9fans] Plan 9

[geoff]

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.

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

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.

Re: [9fans] Plan 9

[forsyth]

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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

forsyth@vitanuova.com writes:

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

A link, in Unix, is the mapping from a directory name to a file.

It is *not* only that thing that the unlearned call a "hard link" or a
"soft link".  A link exists even if there is only one name for the
file: that one name is the link.

Re: [9fans] Plan 9

[David Gordon Hogan]

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

Re: [9fans] Plan 9

[anothy]

// 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.
ア

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

anothy@cosym.net writes:

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

Call these two files file WOOF and file MEOW; found in directories
I'll call respectives REMOTE-1 and REMOTE-2.

In translating the pathname /cat/meow; your system must do three
things:

1) Locate /
2) Find out what "cat" means within / [this gives REMOTE-1, thanks to
   the bind]
3) Find out what "woof" means within REMOTE-1 [this gives WOOF, thanks
   to what the remote server tells you]

Lookup step (2) is *not* done by looking on any local fileserver;
there is a step which occurs in the mount table.

[Of course, actually there is a step 1a which looks "cat" up within /,
gets some "local node" and *that* is what is mapped to REMOTE-1, but
for my purposes here that's irrelevant, since the user never sees it.]

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

A link is the logical mapping between a name-in-directory and the file
[or directory] that the name refers to.

Re: [9fans] Plan 9

[forsyth]

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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

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.

Re: [9fans] Plan 9

[presotto]

>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?

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

presotto@closedmind.org writes:

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

I'm not implying that either is sufficient for the other.  In Unix,
say, there is this thing called a "hard link" by the masses; the
cognoscenti just call it a "link".  A "link" is what connects a
name-in-directory to a file.

Now in Unix, and in Plan 9, there are two places that links get
specified.  One place is in directories themselves.  In Unix, it's "on
disk"; in Plan 9, it's via the file protocol.

The other places is in the "mount table"; in Unix there's one
system-wide table; in Plan 9 there is a per-process inherited table.

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

Re: [9fans] Plan 9

[anothy]

// 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?
ア

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

anothy@cosym.net writes:

> 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 dmon on a unix box...

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

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

Re: [9fans] Plan 9

[nigel]

[-- 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

Re: [9fans] Plan 9

[rob pike]

> 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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

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

I'm not suggesting a change in Plan 9.  Let me repeat, because you and
someone else both seem to have missed that.  I'm not suggesting a
change in Plan 9.

Now, to what point?  The goal is unification.  There shouldn't be
sixteen different ways to accomplish the same effect, and users
shouldn't have to see sixteen ways.

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.

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.

Re: [9fans] Plan 9

[presotto]

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

Re: [9fans] Plan 9

[Scott Schwartz]

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

``Ash C++ durbatuluk, ash C++ gimbatul,
ash C++ thrakatuluk agh burzum-ishi krimpatul!''
 -- Nicholas C. Weaver

Re: [9fans] Plan 9

[YAMANASHI Takeshi]

> ``Ash C++ durbatuluk, ash C++ gimbatul,
> ash C++ thrakatuluk agh burzum-ishi krimpatul!''

`Never before has any voice dared to utter words
of that tongue in 9fans,' said Elrond.
--
YAMANASHI Takeshi

Re: [9fans] Plan 9

[David Gordon Hogan]

> > 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!

Re: [9fans] Plan 9

[andrey]

David Gordon Hogan wrote:

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

P9 is to borrow FreeBSD users.. Linux users have not yet had the chance to
mature for P9. Simply the lack of GNOME or KDE to fight over would be
detrimental to their health...

They can hardly cope with the license P9 is under too (proven on this list
several times).

Flame On! :P~

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

aam396@mail.usask.ca (andrey) writes:

> They can hardly cope with the license P9 is under too (proven on
> this list several times).

Out of curiousity, what kind of license is it?

[You won't bother me too much there; I use both Linux and VMS without
worrying about the license...  guess I must not be a laywer.]

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

aam396@mail.usask.ca (andrey) writes:

> They can hardly cope with the license P9 is under too (proven on this list
> several times).

And you think FreeBSD will be more congenial to non-free software?

Re: [9fans] Plan 9

[pac]

>> > > 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!
>>
>>

I am one of those ;-)

Peter.

Re: [9fans] Plan 9

[rob pike]

[-- 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

Re: [9fans] Plan 9

[Richard Miller]

> 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

Re: [9fans] Plan 9

[forsyth]

[-- 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?

Re: [9fans] Plan 9

[Boyd Roberts]

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

Yes, I grilled them on this point before signing anything.

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

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

Re: [9fans] Plan 9

[Tomas]

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

Re: [9fans] Plan 9

[presotto]

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.

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

presotto@closedmind.org writes:

> The essence of rob's statement is that if you do nothing
> to change it,

Oh, system-level defaults.  I see.  Sorry for the confusion.

> That said, the amount of configurability of the UI is much smaller
> than X windows.

Well, X is pretty baroque, in terms of configurability.  (It can look
almost like MacOS 8, or it can look astonishingly similar to Windows
98, or with Gnome it can look like an artist's misguided vision of
what computers will look like in 2037, or...)  I wouldn't expect every
system to be quite that malleable.  I do want simple things like the
ability to change my colors around.  BeOS, for example, annoys me
because there's no global way to specify that I don't want blinding
white backgrounds.  Such a simple thing.

> Having just spent 3 weeks trying to make 3 Linux systems look sort
> of the same,

Heh.  Of course, you could just set them all to use twm...

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

I have most of the keys remapped in my editor, but that's because the
defaults are so horrible.  (I don't use Emacs for the default
settings; I use it for the power.)  I don't need to tweak quite so
much in the OS, just enough to make it liveable -- basic things like I
want a reasonable (i.e., not blinding) background colour, so I can
stand to sit in front of the thing for more than a few minutes.  Oh,
and it's nice if I can get around the system mostly with the keyboard,
with minimal need to drag the mouse all over creation.

If the GUI is even half as customisable as Windows, that's probably
enough for me.

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

presotto@closedmind.org writes:

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

It's not at all that configurability is that great at thing when it
comes to user interfaces.  Jef Raskin puts it that we should not
expect our users to be experts in interface design.  All too often
interface designers figure that if they put in enough configurability
they don't have any obligation to design a terrific interface.

Re: [9fans] Plan 9

[Ozan Yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

>		 Jef Raskin puts it that we should not
> expect our users to be experts in interface design.  All too often
> interface designers figure that if they put in enough configurability
> they don't have any obligation to design a terrific interface.

there must be  a happy medium somewhere between staring at the thousand
levers of n possible interfaces (for some very large n) by a designer who
never was vs being the marionette of The Paternal Designer who have done
everything just right, so no levers needed.

oz

Re: [9fans] Plan 9

[Russ Cox]

> 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

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

rsc@plan9.bell-labs.com (Russ Cox) writes:

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

Unless I misunderstood your previous post, isn't the real problem that
you don't have the ability to boot from CD and install?  Bootable CDs
are a good deal more universal than USB support.  Linux and BeOS and
OS/2 and so on and so forth can all boot from CD and install, but
their USB support is...  well, they have some, but last I checked
(which admittedly has been several months) the USB support in most
OSes (apart from MS and Apple, who have support from the hardware
vendors) only covers certain specific devices (scanners and such), not
floppies and keyboards and modems and mice and other things that have
perfectly good unified extant interface standards and shouldn't be
using a USB interface in the first place.

Re: [9fans] Plan 9

[Ian Cooper]

> are a good deal more universal than USB support.  Linux and BeOS and
> OS/2 and so on and so forth can all boot from CD and install, but
> their USB support is...  well, they have some, but last I checked
> (which admittedly has been several months) the USB support in most
> OSes (apart from MS and Apple, who have support from the hardware
> vendors) only covers certain specific devices (scanners and such), not
> floppies and keyboards and modems and mice and other things that have
> perfectly good unified extant interface standards and shouldn't be
> using a USB interface in the first place.

Linux and Solaris do support USB mice and keyboards.  The Sun Ray
"network appliance" completely relies on USB, much like the iMac.

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

ian@wpi.edu (Ian Cooper) writes:

> Linux and Solaris do support USB mice and keyboards.  The Sun Ray
> "network appliance" completely relies on USB, much like the iMac.

Interesting.  Especially about Linux.  Sun, of course, has (at least
for the Sparc version of Solaris) the same kind of hardware vendor
support Apple has, though I forgot to mention them (and also DEC, or
what's left of DEC after it got swallowed a couple of times).

It's interesting that Linux would support USB mice and keyboards,
precisely because they don't have much hardware vendor support.

Re: [9fans] Plan 9

[forsyth]

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.

Re: [9fans] Plan 9

[Boyd Roberts]

> but you'll need to transfer the 9pccd kernel some other way.

I nearly built a bootable CD image, but had more pressing
things to do.

Re: [9fans] Plan 9

[Russ Cox]

> 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

Re: [9fans] Plan 9

[Boyd Roberts]

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

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.

The process is tedios, but I did document it:

    http://home.fr.inter.net/boyd/code/plan9/usbflop.html

All credit goes to Russ.

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

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

I'm not trying to be unfair; you did bend over backwards to try and
get it working, and sadly it just doesn't.  I wasn't trying to poke
fun or anything like that.

By dependency on Microdreck, I meant the dependency on the filesystem
that you mention.

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

rsc@plan9.bell-labs.com (Russ Cox) writes:

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

USB?  Just say no.  We have a handful of iMacs at work, so I have
worked with USB a little, and I can tell you, it's a *lot* more
trouble than it's worth -- to the user, to the administrator, and
(judging from the level of support it has in various operating
systems) to the implementor as well.

When USB is replaced by the next fad, people will still be using PS/2
keyboards and serial-port modems.  (Parallel port printers we'll
probably replace sooner or later with network printers, however, as
more households get second and third computers, like happened with
cars and phones and televisions.)

Re: [9fans] Plan 9

[Boyd Roberts]

> 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?

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

boyd@fr.inter.net (Boyd Roberts) writes:

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

USB mice are almost tollerable.  USB keyboards are the real joke.

Re: [9fans] Plan 9

[rob pike]

> 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

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

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

Right, that's what I meant by "leave aside implementation for the
moment". :)  I understand why it might be challenging to do it
efficiently.

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

In a logical sense then, every link *is* per-process.  (Because if it
can be, then in a very real sense, it already is, even if all
processes happen to agree about it.)

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.

Now by far the easiest is the first (if only because there are so many
tools to manipulate such links).

(If you wonder what I'm asking, it's because I'm trying to home in on
a concept, not that I already have it full developed.)

So perhaps part of the issue is a unification of the different kinds
of links, and a reduction in the number of tools and places that all
manipulate and store information about what links there are.

There are two things about links that seem important:

  * Is the link shared between processes/users, and how?
  * Is the link transient or permanent?

You are certainly correct that most links will be shared among most
users; 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.

Thomas

Re: [9fans] Plan 9

[David Gordon Hogan]

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

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

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

That was his point.

Re: [9fans] Plan 9

[Russ Cox]

>	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

Re: [9fans] Plan 9

[Ozan Yigit]

rsc@plan9.bell-labs.com (Russ Cox) writes:

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

presumably this needs to be uttered in an undergrad class
to impress them.

Re: [9fans] Plan 9

[Russ Cox]

	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

Re: [9fans] Plan 9

[Wladimir Mutel]

Russ Cox <rsc@plan9.bell-labs.com> wrote:
>        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.

	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.

Re: [9fans] Plan 9

[William Josephson]

On Fri, Oct 26, 2001 at 09:23:54AM +0000, Wladimir Mutel wrote:

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

Could someone explain to me what OceanStore isn't? :-/

  -WJ

Re: [9fans] Plan 9

[Dan Adkins]

William Josephson wrote:
> Could someone explain to me what OceanStore isn't? :-/
> 
>   -WJ

Free, somebody has to pay for all the disks/servers.
Simple, the protocol is horribly complex.

-Dan

[9fans] Plan 9

[rob pike]

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

Re: [9fans] Plan 9

[Borja Marcos]

On Thursday 25 October 2001 14:45, you wrote:
> 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

	Well, not just the typical dumb terminals. I really liked the "network 
computer" model implemented in Plan 9 and Inferno. It is a pity that 
broadband home networks have not reached lots of people, and the marketing 
FUD killed the idea (commercially).


	Borja.

Re: [9fans] Plan 9

[Jim Choate]

On Thu, 25 Oct 2001, Borja Marcos wrote:

> 	Well, not just the typical dumb terminals. I really liked the "network 
> computer" model implemented in Plan 9 and Inferno. It is a pity that 
> broadband home networks have not reached lots of people, and the marketing 
> FUD killed the idea (commercially).

Good. The lack of a commercial venue will be what ensures its long life
and universal access.


 --
    ____________________________________________________________________

     The people never give up their liberties but under some delusion.

                                             Edmund Burke (1784)

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Plan 9

[Lucio De Re]

On Thu, Oct 25, 2001 at 04:52:03PM -0500, Jim Choate wrote:
> 
> Good. The lack of a commercial venue will be what ensures its long life
> and universal access.
> 
This must be the first time I have occasion to agree with you, and
then it may be for all the wrong reasons.  Still, it's good to see
one's opinions reflected elsewhere :-)

++L

Re: [9fans] Plan 9

[Wladimir Mutel]

rob pike <rob@plan9.bell-labs.com> wrote:

> Sure, with NFS you can get somewhere close to that ideal, but then why
> 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.

	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.

Re: [9fans] Plan 9

[Randolph Fritz]

...lurklurklurk...

In article <20011025124551.4A1E1199B5@mail.cse.psu.edu>, rob pike wrote:
> 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.
> [...]
>

Plan9 is, in other words, a platform for ubiquitous, collaborative
computing.  This, I think, reflects the social environment of Bell
Labs.  Whether or not this is a model worth pursuing in other
contexts is left as an exercise for the student...

Randolph

...lurklurklurk...

Re: [9fans] Plan 9

[Ronald G Minnich]

On Thu, 1 Nov 2001, Randolph Fritz wrote:

> ...lurklurklurk...
>
> In article <20011025124551.4A1E1199B5@mail.cse.psu.edu>, rob pike wrote:
> > 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.
>
> Plan9 is, in other words, a platform for ubiquitous, collaborative
> computing.  This, I think, reflects the social environment of Bell
> Labs.  Whether or not this is a model worth pursuing in other
> contexts is left as an exercise for the student...

yes but ... just because that is what it was designed for does not mean
that is what it is limited to. I kind of doubt the designers anticipated
our little rack of DL360s running plan9. But it is pretty nice for
clusters.

ron

Re: [9fans] Plan 9

[Thomas Bushnell, BSG]

Randolph Fritz <randolph@panix.com> writes:

> Plan9 is, in other words, a platform for ubiquitous, collaborative
> computing.  This, I think, reflects the social environment of Bell
> Labs.  Whether or not this is a model worth pursuing in other
> contexts is left as an exercise for the student...

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.

So I'm stuck.

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.

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?  Leave aside for the moment implementation
strategy, and just consider: what would the implications be for
design?  Would this be a feasable UI strategy?

(I'm not speaking strictly of Plan 9; I'm speaking in general.)

Re: [9fans] Plan 9

[Wladimir Mutel]

Thomas Bushnell, BSG <tb+usenet@becket.net> wrote:

> 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 :>

> 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

	Linux should also borrow 'fileserver' concept.
	Nice to have it instead of VFS-layer. And to make userspace
	fileserver-processes instead of kernel VFS modules.

Re: [9fans] Plan 9

[Alexander Viro]

On Fri, 2 Nov 2001, Wladimir Mutel wrote:

> Thomas Bushnell, BSG <tb+usenet@becket.net> wrote:
>
> > 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 :>

Not likely, unless you can show a damn good reasons why it's a good idea.

> > 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
>
> 	Linux should also borrow 'fileserver' concept.
> 	Nice to have it instead of VFS-layer. And to make userspace
> 	fileserver-processes instead of kernel VFS modules.

Huh?  What in your opinion VFS is and how could userland filesystems
replace it?  BTW, Plan 9 _does_ have VFS equivalent - code that deals
with channels, mounts, etc.

Re: [9fans] Plan 9

[Wladimir Mutel]

Alexander Viro <viro@math.psu.edu> wrote:

>> > 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 :>

> Not likely, unless you can show a damn good reasons why it's a good idea.

	I am not sure the reasons are 'damn', I just thought that linux kernel
	patches on this topic should have some future.

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

>>       Linux should also borrow 'fileserver' concept.
>>       Nice to have it instead of VFS-layer. And to make userspace
>>       fileserver-processes instead of kernel VFS modules.

> Huh?  What in your opinion VFS is and how could userland filesystems
> replace it?  BTW, Plan 9 _does_ have VFS equivalent - code that deals
> with channels, mounts, etc.

	VFS is a kernel module interface to support different filesystems. It
	describes protocol similar (to some degree) to 9P. Plan9 has some
	in-kernel modules (device drivers) working by 9P, but it supports FAT
	and EXT2 filesystems by fileservers that are processes. Similar
	approach is used in Hurd; strong decomposition of traditionally-kernel
	fucnctionality into processes can be found in QNX. I do not think they
	all were wrong in their design decisions. The more functionality is
	possible to express as separate process, the simpler is to control it.
	Linux kernel itself has more and more "kernel processes" from version
	to version. Here is what i have in 2.4.12 -
	[keventd] [ksoftirqd_CPU0] [kswapd] [bdflush] [kupdated]

	So, that is overall cause of my words written in comp.os.plan9 above.

Re: [9fans] Plan 9

[Alexander Viro]

On Mon, 5 Nov 2001, Wladimir Mutel wrote:

> 	VFS is a kernel module interface to support different filesystems. It
> 	describes protocol similar (to some degree) to 9P. Plan9 has some
> 	in-kernel modules (device drivers) working by 9P, but it supports FAT
> 	and EXT2 filesystems by fileservers that are processes. Similar

Not exactly.  You are confusing 9P with set of methods provided by
filesystems.  There is _one_ in-kernel fs that speaks 9P - mnt.
Nothing stops you from doing similar under Linux/*BSD/whatever,
but result will be VFS->9pfs->fileservers, same as with Plan 9.

IOW, it's not a replacement for VFS code - you still have a part
that translates system calls into sequence of method calls +
part that uses 9P to provide such set of methods.  Notice that there
is a _lot_ of filesystems that belong to kernel - see /sys/man/3 for
the list of Plan 9 ones.  So separating 9P-speaking layer from
the VFS logics is a Good Thing(tm).

BTW, a lot of Unices (Linux included) _do_ support userland fileservers.
And I'm not talking about "make it look like NFS" schemes.  CODA actually
allows to do userland filesystems, but its intended use is for heavy
caching stuff and that shows (you still can do more RPC-style fileservers,
but overhead won't be pretty).

As for the Hurd...  I'd rather avoid commenting on Hurd "architecture" -
I'm not interested in that flamewar and this is not the place for it
anyway.  I'm not saying that all GNU folks are tasteless wankers, but
the culture and design philosophy of GNU in general...  Sigh.

Re: [9fans] Plan 9

[Boyd Roberts]

Most unix VFS's expect (if not insist) unix like semantics and are
generally a horrible mess.  One good thing ULTRIX did was that you
could have user mode NFS file-servers.  The down side was that NFS
was far too limiting.  I implemented a version of ftpfs on ULTRIX
when I was at Digital.  Without going into NFS protocol problems
the basic lesson is to _never_ implement a file-server protocol
over an unreliable, connectionless transport.

ULTRIX also had some neat (undocumented) pty messages so 9term
wouldn't have to call ioctl(2) on every keystroke.  And yes, I
stuck 'look' on button 2; extremely useful for examining tail -f
output.

Re: [9fans] Plan 9

[Alexander Viro]

On Mon, 5 Nov 2001, Boyd Roberts wrote:

> Most unix VFS's expect (if not insist) unix like semantics and are
> generally a horrible mess.  One good thing ULTRIX did was that you

... that being the main reason why I gave up on *BSD.  Linux VFS
was much cleaner and these days it's actually pretty decent.

> could have user mode NFS file-servers.  The down side was that NFS

You can do the same on a _lot_ of Unices, but most of them suffer
from fairly nasty deadlocks around the code handling mmap() over
NFS when server runs on the same box.  They may be harder or
easier to trigger, but if you manage to get the box low on memory
and create a situation when the only way to reclaim something is
to write out a dirty page and throw it away - expect a trouble
(page contents is sent to server, server needs memory to write it
out, memory pressure only leads to more requests of the same kind).

> was far too limiting.  I implemented a version of ftpfs on ULTRIX
> when I was at Digital.  Without going into NFS protocol problems
> the basic lesson is to _never_ implement a file-server protocol
> over an unreliable, connectionless transport.

<nod>

CODA is cleaner in that respect - exactly for these reasons.  For
ftpfs it's downright nice - especially since it has commit-on-close
semantics (open creates a copy on local fs and passes it back to
kernel, then all IO happens on local fs and only metadata-related
requests are passed to server; sync and close tell server to commit
the changes; there is a mechanism for handling invalidation).  For
RPC-style filesystems it's a pure hell, obviously - for that stuff
9P fits much better.

Re: [9fans] Plan 9

[Boyd Roberts]

> You can do the same on a _lot_ of Unices, but most of them suffer
> from fairly nasty deadlocks around the code handling mmap() over
> NFS when server runs on the same box.

mmap() should never hit the VFS, but I know why they'd want that.

mmap() is just a stupid way to do read() and write().

Re: [9fans] Plan 9

[Alexander Viro]

On Mon, 5 Nov 2001, Boyd Roberts wrote:

> > You can do the same on a _lot_ of Unices, but most of them suffer
> > from fairly nasty deadlocks around the code handling mmap() over
> > NFS when server runs on the same box.
>
> mmap() should never hit the VFS, but I know why they'd want that.

???
Normally mmap() handling sits in VM code, not in VFS.

> mmap() is just a stupid way to do read() and write().

Mostly.  For text segment it (or its equivalent) is a Good Thing(tm).
Load-on-demand is a nice thing to have.  Writable MAP_SHARED, OTOH...
<shudder>

Re: [9fans] Plan 9

[Boyd Roberts]

> > mmap() should never hit the VFS, but I know why they'd want that.
>
> ???
> Normally mmap() handling sits in VM code, not in VFS.

Yes, but it's a system call and they have a nasty habit of
turning up in the VFS, where they should not be.

Re: [9fans] Plan 9

[Ronald G Minnich]

On Monday 05 November 2001 11:04, you wrote:

> Normally mmap() handling sits in VM code, not in VFS.

Depends on the os.

See SunOS.

ron

Re: [9fans] Plan 9

[Ronald G Minnich]

On Friday 02 November 2001 04:43, you wrote:
> Thomas Bushnell, BSG <tb+usenet@becket.net> wrote:
> > 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 :>

I've done it twice now, once on my own, once with Peter Braam.

Dec. Dr. Dobb's describes the one I did on my own.

ron

Re: [9fans] Plan 9

[andrey]

http://www.ddj.com/articles/2001/0112/0112a/0112a.htm

for those who are not subscribed to it..

Ronald G Minnich wrote:

> I've done it twice now, once on my own, once with Peter Braam.
>
> Dec. Dr. Dobb's describes the one I did on my own.
>
> ron

Re: [9fans] Plan 9

[Ronald G Minnich]

On Friday 02 November 2001 08:42, you wrote:
> http://www.ddj.com/articles/2001/0112/0112a/0112a.htm

Great. Now all the experts on the list will flame me for all that parts I got
wrong. Oh well.

ron

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

rob@plan9.bell-labs.com (rob pike) writes:

> When I go home, my environment - that is, the working state of my
> machine - is identical not only with my environment at work,

This part would be nice, but...

> but with all my colleague's working state, too.

This would be utterly unacceptable to me.  I want things configured
the way I want them, not the way everyone else decides is a good
compromise.

Surely plan9 allows individual users to customise their environments?

Re: [9fans] Plan 9

[Markus Friedl]

On Mon, Nov 05, 2001 at 03:01:58PM +0000, Jonadab the Unsightly One wrote:
> Surely plan9 allows individual users to customise their environments?

sure
	sam $home/lib/*

Re: [9fans] Plan 9

[Lucio De Re]

On Mon, Nov 05, 2001 at 03:01:58PM +0000, Jonadab the Unsightly One wrote:
>
> > but with all my colleague's working state, too.
>
> This would be utterly unacceptable to me.  I want things configured
> the way I want them, not the way everyone else decides is a good
> compromise.
>
> Surely plan9 allows individual users to customise their environments?

Microsoft calls it a roaming profile.  Except that with Plan 9 any
resource not available on a particular workstation can be imported
from other hosts, obviously within limits, to create the customised
environment _each_ user is accustomed to, no matter what equipment she
sits in front of, or where it is located.

++L

Re: [9fans] Plan 9

[Jonadab the Unsightly One]

lucio@proxima.alt.za (Lucio De Re) writes:

> Microsoft calls it a roaming profile.  Except that with Plan 9 any
> resource not available on a particular workstation can be imported
> from other hosts, obviously within limits, to create the customised
> environment _each_ user is accustomed to, no matter what equipment she
> sits in front of, or where it is located.

Ah.  So you can customise your environment, but you don't have to do
it separately for each individual workstation you might want to use.

That actually sounds good.  (Although in my case I would only have
plan9 installed on one computer...)

[9fans] Plan 9

[Scott]

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.

[9fans] Plan 9

[Mats]

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"