> namespaces are not public in the sense that they are visible to all
> processes.


I was trying to compare UNIX to Plan 9. Apparently, UNIX processes share a
single "public" namespace which therefore has to be protected by access
privileges.

> since this started out as a discussion of terminals, i should point out
> that terminals by definition have a single user at a time.


What about the so-called "standalone" terminals (~ home computers)? My
intention was to equate a single user UNIX to a Plan 9 standalone terminal.
It's the same difference, I suppose.

> i'm not sure what passes for unix these days, but linux at least
> does not present network interfaces as block devices. there is no
> /dev/eth0.


The point is this can be done even if it hasn't been done. In case of
FreeBSD, the network interfaces are represented under /dev/net. A sample
installation shows this:

crw------- 1 root wheel 0, 29 Aug 21 18:02 de0
crw------- 1 root wheel 0, 70 Aug 21 18:02 lo0
crw------- 1 root wheel 0, 35 Aug 21 18:02 plip0

Does it mean network interfaces are presented as _character_ devices?

Doing "cat foo >de0" gives "Operation not supported by device."

> what do you mean by this? the VFS is a kernel interface along the general
> lines of plan 9's devtab. everything-is-a-file[server] is a general
> principle.


I mean VFS is an abstraction layer that presents a file system. What it
represents as a file system is rather arbitrary.

>> but on UNIX systems it is limited to resources that can be meaningfully
>> represented as file systems.

>
> so why is the network hidden in side channels in adjunct namespaces?


I don't understand this one.

--On Thursday, August 21, 2008 6:36 AM -0400 erik quanstrom
wrote:

>> So essentially there shouldn't be a problem with mounting on a single
>> "public" namespace

>
> namespaces are not public in the sense that they are visible to all
> processes.
>
>> as long as there is one user on the system.

>
> since this started out as a discussion of terminals, i should point out
> that terminals by definition have a single user at a time.
>
>> This is classic. Complication is a sign of maturation. Plan 9 has evaded
>> that by not maturing, by avoiding diversification. Before you get angry
>> I must say that's my "personal" opinion. Nothing I'm going to "force"
>> unto you. Nothing I _can_ force unto you.

>
> equally one could say complication is a sign that one's vision was
> lacking; a sign that one's system lacks generality.
>
> if you call the opposite of complication immaturity, i'll be proud
> to have an operating system that suffers from it.
>
>> How does that differ from presenting of a network interface by a block
>> device on UNIX? And why should avoiding system calls be considered an
>> advantage? Your VFS layer could do anything expected from /net provided
>> that file system abstraction for the resources represented under /net is
>> viable in the first place.

>
> i'm not sure what passes for unix these days, but linux at least
> does not present network interfaces as block devices. there is no
> /dev/eth0.
>
>> The VFS approach is by no means inferior to Plan 9's
>> everything-is-a-file,

>
> what do you mean by this? the VFS is a kernel interface along the general
> lines of plan 9's devtab. everything-is-a-file[server] is a general
> principle.
>
>
>> but on UNIX systems it is limited to resources that can be meaningfully
>> represented as file systems.

>
> so why is the network hidden in side channels in adjunct namespaces?
>
> - erik
>
>