[9fans] dir tree Qs

[9fans] dir tree Qs

[cej]

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

hi,

 

why do we have 

 

/386

            /bin

            /lib

/rc

 

...

but:

 

/$home

            /bin

                        /386

                        /rc

 

??

 

also,

 

/lib, /sys/lib, and /$cpuname/lib is confusing...

would welcome some explanation underneath a tree structure, best on wiki

(I would like to get some idea on how to structure my /$home dir....

 

thanks, best,

++pac.

 


[-- Attachment #2: Type: text/html, Size: 5330 bytes --]

Re: [9fans] dir tree Qs

[erik quanstrom]

you make some good points.  i noticed that glenda has that directory structure last
night.  i think it would make more sense to have $home/rc/bin and $home/$cputype/^(bin lib)
in one's home directory.

the difference between /$cputype/lib and (/lib and /sys/lib) is that /$cputype/lib stuff
depends on the $cputype.  it's actual system libraries.

- erik

Re: Re: [9fans] dir tree Qs

[andrey mirtchovski]

/386 contains much more than just binaries, while $home/bin/386
contains only that: binaries.

i think the rationale was that having a directory for each
architecture back when 386 wasn't the dominant one would clutter
$home. we rarely spend any time in / after all. besides, Plan 9
shouldn't expose the architecture to the user right at the front line:
what the current arch is was not meant to be something we ought to
care about.

i could be wrong, of course.

Re: Re: [9fans] dir tree Qs

[erik quanstrom]

why would one never keep a library in one's home directory?  keeping the 
structure the same would make it easier to bind $home/$cputype 
before/after /$cputype.

$0.02
- erik

On Thu Aug 17 09:08:52 CDT 2006, mirtchovski@gmail.com wrote:
> /386 contains much more than just binaries, while $home/bin/386
> contains only that: binaries.
> 
> i think the rationale was that having a directory for each
> architecture back when 386 wasn't the dominant one would clutter
> $home. we rarely spend any time in / after all. besides, Plan 9
> shouldn't expose the architecture to the user right at the front line:
> what the current arch is was not meant to be something we ought to
> care about.
> 
> i could be wrong, of course.

Re: Re: [9fans] dir tree Qs

[rog]

i've wondered in the past why this difference. on balance i prefer the way
it's done in $home, as the set of objtypes is open-ended, so it results in a somewhat
less cluttered home directory - it's easy to remove all binaries, for example,
without knowing the name of all objtypes (quick aside: i wish there was a constant
pattern that would match all c compiler intermediate object files...)

maybe the real reason why it's done differently
in / is that there's already a /bin, and it is assumed to contain only binaries
for the current objtype, which having (for instance) /bin/m68k would violate.

one could have had (for instance) /arch/bin/386, /arch/lib/386, ...
but would it have been worth it?

Re: Re: [9fans] dir tree Qs

[jmk]

you'll be wanting dotfiles next.

Re: Re: [9fans] dir tree Qs

[John Floren]

On 8/17/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
> you'll be wanting dotfiles next.
>
.rcrc
muhahahaha


John
-- 
"The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI

Re: Re: [9fans] dir tree Qs

[erik quanstrom]

hey, that's a good idea!  i shudda thunkofit. ☺

- erik

> you'll be wanting dotfiles next.

Re: Re: [9fans] dir tree Qs

[csant]

Speaking of file structures - I have (in vane) tried to find some doc on  
what the rationale behind /mnt vs /n is (or rather: what exactly goes in  
/n ?). I *think* I know what the difference is, but I wanted to find some  
documentation on it. Anybody'd have apointer, please? (or a quick answer?)  
:)

/c

Re: Re: Re: [9fans] dir tree Qs

[andrey mirtchovski]

/n is remote servers. /mnt/is local.

On 8/17/06, csant <csant@csant.info> wrote:
> Speaking of file structures - I have (in vane) tried to find some doc on
> what the rationale behind /mnt vs /n is (or rather: what exactly goes in
> /n ?). I *think* I know what the difference is, but I wanted to find some
> documentation on it. Anybody'd have apointer, please? (or a quick answer?)
> :)
>
> /c
>

Re: Re: Re: [9fans] dir tree Qs

[rog]

> /n is remote servers. /mnt/is local.

/mnt/term ?

Re: [9fans] dir tree Qs

[Ronald G Minnich]

rog@vitanuova.com wrote:
>>/n is remote servers. /mnt/is local.
> 
> 
> /mnt/term ?

yeah, I think that is a tenuous claim (/mnt vs. /n)

I always figured it was that stuff in /mnt was supposed to be in /mnt, 
otherwise if it was in /n, it was supposed to be in /n?

ron

Re: [9fans] dir tree Qs

[erik quanstrom]

not to throw a monkey wrench in your taxonomy, but
what about /mail/fs?

- erik

On Thu Aug 17 12:26:41 CDT 2006, rminnich@lanl.gov wrote:
> rog@vitanuova.com wrote:
> >>/n is remote servers. /mnt/is local.
> > 
> > 
> > /mnt/term ?
> 
> yeah, I think that is a tenuous claim (/mnt vs. /n)
> 
> I always figured it was that stuff in /mnt was supposed to be in /mnt, 
> otherwise if it was in /n, it was supposed to be in /n?
> 
> ron

Re: [9fans] dir tree Qs

[csant]

> rog@vitanuova.com wrote:
>>> /n is remote servers. /mnt/is local.
>>   /mnt/term ?
>
> yeah, I think that is a tenuous claim (/mnt vs. /n)
>
> I always figured it was that stuff in /mnt was supposed to be in /mnt,  
> otherwise if it was in /n, it was supposed to be in /n?

	/n/dump
is yet another one confusing me. If /mnt stands for "mount", what does /n  
stand for?
/c

Re: [9fans] dir tree Qs

[erik quanstrom]

i think it's a holdover from research unix. "network."

- erik

On Thu Aug 17 12:39:22 CDT 2006, csant@csant.info wrote:
> > rog@vitanuova.com wrote:
> >>> /n is remote servers. /mnt/is local.
> >>   /mnt/term ?
> >
> > yeah, I think that is a tenuous claim (/mnt vs. /n)
> >
> > I always figured it was that stuff in /mnt was supposed to be in /mnt,  
> > otherwise if it was in /n, it was supposed to be in /n?
> 
> 	/n/dump
> is yet another one confusing me. If /mnt stands for "mount", what does /n  
> stand for?
> /c

Re: [9fans] dir tree Qs

[rog]

> is yet another one confusing me. If /mnt stands for "mount", what does /n  
> stand for?

actually, the main distinction seems to be that /n holds filesystems
that contain regular files, and /mnt has service interfaces.

personally i wouldn't mind losing /mnt - /n is so much easier to type.

Re: [9fans] dir tree Qs

[Iruatã Souza]

2006/8/17, rog@vitanuova.com <rog@vitanuova.com>:
> > is yet another one confusing me. If /mnt stands for "mount", what does /n
> > stand for?
>
> actually, the main distinction seems to be that /n holds filesystems
> that contain regular files, and /mnt has service interfaces.
>
> personally i wouldn't mind losing /mnt - /n is so much easier to type.
>

i don't know if that's too silly of me, but having this separation
with this semantics (regular files vs service interfaces) doesn't goes
against the idea that in plan9 one wouldn't have to differentiate
between types of files unless he/she wishes so?

Re: [9fans] dir tree Qs

[Charles Forsyth]

> i don't know if that's too silly of me, but having this separation
> with this semantics (regular files vs service interfaces) doesn't goes
> against the idea that in plan9 one wouldn't have to differentiate
> between types of files unless he/she wishes so?

there are several different types of files, and
a few significant conventions,
so that /net is not interchangeable with /mnt, say.
put another way, things under /net deliberately present a
particular interface so that ndb/cs and dial will function,
regardless of what the names actually mean (ip vs datakit for instance).
if you try dialling things in /mnt, you're bound to be disappointed.

what plan 9 says is that to access anything, ultimately you
open a name, read/write, close.
it doesn't say that you don't differentiate between files,
and what you read and write will differ for /dev/draw as against
/net/tcp

Re: [9fans] dir tree Qs

[Iruatã Souza]

2006/8/17, Charles Forsyth <forsyth@terzarima.net>:
> > i don't know if that's too silly of me, but having this separation
> > with this semantics (regular files vs service interfaces) doesn't goes
> > against the idea that in plan9 one wouldn't have to differentiate
> > between types of files unless he/she wishes so?
>
> there are several different types of files, and
> a few significant conventions,
> so that /net is not interchangeable with /mnt, say.
> put another way, things under /net deliberately present a
> particular interface so that ndb/cs and dial will function,
> regardless of what the names actually mean (ip vs datakit for instance).
> if you try dialling things in /mnt, you're bound to be disappointed.
>
> what plan 9 says is that to access anything, ultimately you
> open a name, read/write, close.
> it doesn't say that you don't differentiate between files,
> and what you read and write will differ for /dev/draw as against
> /net/tcp
>
>

that really explains the point to me :]
thanks charles.

Re: [9fans] dir tree Qs

[rog]

> if you try dialling things in /mnt, you're bound to be disappointed.

mind you i've used /mnt/term/net/tcp!machine!port before now...

Re: Re: Re: [9fans] dir tree Qs

[Skip Tavakkolian]

>> /n is remote servers. /mnt/is local.
> 
> /mnt/term ?

/n for ephemeral and /mnt for eternal?

Re: Re: Re: [9fans] dir tree Qs

[csant]

> /n for ephemeral and /mnt for eternal?
like in /n/dump ?

Re: Re: Re: [9fans] dir tree Qs

[Skip Tavakkolian]

>> /n for ephemeral and /mnt for eternal?
> like in /n/dump ?

/n for one and /mnt for all?

Re: Re: Re: [9fans] dir tree Qs

[Skip Tavakkolian]

>>> /n for ephemeral and /mnt for eternal?
>> like in /n/dump ?
> 
> /n for one and /mnt for all?

also, in my world, /n has mntgen and /mnt doesn't.

Re: [9fans] dir tree Qs

[andrey mirtchovski]

On Aug 17, 2006, at 11:10 AM, rog@vitanuova.com wrote:

>> /n is remote servers. /mnt/is local.
>
> /mnt/term ?

obviously a mistake :)

Re: Re: [9fans] dir tree Qs

[Charles Forsyth]

> /n ?). I *think* I know what the difference is, but I wanted to find some  
> documentation on it. Anybody'd have apointer, please? (or a quick answer?)  

namespace(4) has a stab at it, including answering (however briefly)
quite a few of the questions people have asked so far.

Re: Re: [9fans] dir tree Qs

[Russ Cox]

Why look in man pages when the answer's already known not to be in the wiki?

Russ

Re: Re: [9fans] dir tree Qs

[csant]

> namespace(4) has a stab at it, including answering (however briefly)
> quite a few of the questions people have asked so far.
Oh - nice, thank you. I somehow missed that one.
/c

RE: [9fans] dir tree Qs

[cej]

I decided to adhere to namespace (4) dir structure in my home dir,
thus, the mkfiles in /n/sources/contrib/pac/* will hopefully reflect this change. thanksd for all the points,
best,
++pac