Re: [9fans] Using the Acme Editor

Re: [9fans] Using the Acme Editor

[Eris Discordia]

Thank you, sqweek. The second golden Golden Apple with καλλιστι on 
it is totally yours. The first one went to Russ Cox.

>  You don't care who mounts what where, because the rest of the system
> doesn't notice the namespace change.

So essentially there shouldn't be a problem with mounting on a single 
"public" namespace as long as there is one user on the system. mount 
restriction in UNIX systems was put in place because multiple users exist 
some of whom may be malicious. Virtualization and jailing will relax that 
requirement.

>  As Pietro demonstrated, no interface configuration is necessary here.

Only because the concept is hidden in Plan 9, though I don't know how. 
_Someone_ or _something_ has to decide whether to route your packets 
through, say, a ppp interface or an eth interface--when both interfaces are 
present--and to do that according to configuration. That won't happen on 
its own.

When P. G. suggested an imaginary "motorola" file server he never said how 
the file server is supposed to access the cellular network. If it's going 
to happen by tunnelling through another protocol, e.g. IP, then the 
question remains of _which_ interface to choose from. And if it's going to 
happen over some special protocol then it must occupy a place on the 
network stack over some _configured_ network interface.

On a different note, what purpose did his "-M 'RAZR V3' 555 555 5555" 
switches serve? Don't they qualify as interface configuration?

>  Certainly. If someone has access to, say, the physical machine, then
> they have the ability to boot whatever operating system they wish,
> potentially modified to their liking and do whatever they want with
> the hardware.

This result comes from the "disposable" machine paradigm, in which the 
machine you work at need not be in any way _significant_ to you. It doesn't 
quite match the "home computer" scheme of things. If someone manages to 
boot your home/portable personal computer they are set for collecting all 
you've stored on it. In that respect, I don't see how the "disposable" 
machine paradigm can be applicable. Your personal machine is not disposable.

It seems the security ascribed to disposable machines comes from that "user 
data" is stored on a different, presumably safer, machine in, for example, 
some sort of data warehouse at a data center. This isn't a new 
idea--actually, it's _very_ old--and it's not what happens in home (or 
personal) computing.

> Plan 9 respects that. Not trusting the hostowner is a waste of effort.

Not with reliable biometric authentication, but that's out of scope here.

>  Uh, what now? You either have an interesting definition of home
> computer or some fucked up ideas about plan 9. You only need a cpu
> server if you want to let other machines run processes on your
> machine. You only need an auth server if you want to serve resources
> to a remote machine.

Neither statement is true. On a home computer you certainly need a term. 
You'll need a cpu for a number of tasks. And you'll need auth if there's 
going to be more than one user on the system, or if you need a safe way of 
authenticating yourself to your computer. A single glenda account doesn't 
quite cut it. If you're going to access your storage you'll need some 
fs('s), too.

The bottom line is: term is _certainly_ not enough for doing all the tasks 
a *BSD does, and requiring a home computer to do all these tasks is far 
from inconceivable. One *BSD system is almost functionally equivalent to a 
combination of term, cpu, auth, and some fs('s).

>  "each machine?" I thought we were talking about my "home computer"???
>  If you have a home network, you have ONE auth server.

No. The point is if you have _one_ home machine and _multiple_ users you'll 
have to store authentication information on that same machine. It is no 
more a "disposable terminal," its security becomes as important as the 
security of a heavily used auth server. The "disposable" machine paradigm 
fails as miserably as the the traditional UNIX paradigm: one machine, many 
users.

Now, your home computer may be a true single user machine but you store 
_some_ authentication information on it anyway; those of yours, namely. 
Such machine is in that respect as vulnerable as a UNIX machine. It has to 
be _physically_ guarded. It's no more a "disposable" machine.

> incantation, that's beside the point. In 9p, the abstraction is a file
> tree, and the interface is 
auth/attach/open/read/write/clunk/walk/remove/stat.

ioctl and VFS are suspiciously similar even though they serve less generic 
functions.

> argue HTTP is simpler because it just has GET/PUT/DELETE/HEAD, but you
> have to deal with rfc822 formatted messages and different transfer
> encodings and auth mechanisms and all sorts of options coming out your
> ass.

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.

> network operations - everything is done via /net. Thanks to private
> namespaces, you can transparently replace /net with some other crazy
> [compatible] filesystem, which might load balance over multiple

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.

> implemented on any system, which is true [to an extent]. But it's
> apparent than no others have the taste to do it as elegantly as plan 9 -

It's not a matter of taste. There are situations, many situations actually, 
where the file system abstraction is plainly naive. Sticking with it for 
every application verges on being an "ideology."

The VFS approach is by no means inferior to Plan 9's everything-is-a-file, 
but on UNIX systems it is limited to resources that can be meaningfully 
represented as file systems. Representing a relational database as a file 
system is meaningless. The better representation is something along the 
lines of the System::Data::DataGrid class on Microsoft .NET framework.

>  Eris, if you've further issues to raise, we should take this off-list.

No more "issues." I simply rest my case here.

--On Thursday, August 21, 2008 2:08 AM +0800 sqweek <sqweek@gmail.com> 
wrote:

> On Wed, Aug 20, 2008 at 8:56 PM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>>>  No. Private namespaces.
>>
>> And how does that solve the problem of whom to trust with mounting?
>
>  You don't care who mounts what where, because the rest of the system
> doesn't notice the namespace change. But it sounds like what you're
> really talking about is who to trust with device access, so lets roll
> with that.
>
>> Or with configuring a network interface?
>
>  As Pietro demonstrated, no interface configuration is necessary here.
>
>> If someone has access to, say, eth0 then
>> they have access to eth0. No amount of private namespaces keeps them from
>> reading everything that goes through eth0, including other users'
>> unencrypted traffic.
>
>  Certainly. If someone has access to, say, the physical machine, then
> they have the ability to boot whatever operating system they wish,
> potentially modified to their liking and do whatever they want with
> the hardware. Plan 9 respects that. Not trusting the hostowner is a
> waste of effort.
>
>> Plan 9's model says if you have physical access to a terminal there is no
>> way to secure _that_ terminal against your mischief. Therefore, it
>> totally trusts you _that_ terminal. However, your home computer doesn't
>> run only a terminal. To be usable, it has to run at least a cpu and an
>> auth, in addition to a term.
>
>  Uh, what now? You either have an interesting definition of home
> computer or some fucked up ideas about plan 9. You only need a cpu
> server if you want to let other machines run processes on your
> machine. You only need an auth server if you want to serve resources
> to a remote machine.
>
>> Now, where is the difference between running
>> authentication on the same machine as the terminal and the traditional
>> UNIX way of keeping authentication/authorization databases on each
>> machine?
>
>  "each machine?" I thought we were talking about my "home computer"???
>  If you have a home network, you have ONE auth server.
>
>>>  Sorry, that should have been "no such file or directory". You need a
>>> mkdir.
>>
>> The directory could've been there beforehand.
>
>  Well allow me to present a more concise set of commands:
>
>
>  (the file was there beforehand :D)
>
>> In any case, your deflection
>> has nothing to do with the fact that Pietro Gagliardi's demand for "a few
>> commands" to accomplish a certain task has been supplied with an adequate
>> UNIX answer.
>>
>> He's under the false impression that abstraction actually _does_ things,
>> and that because Plan 9 has an everything-is-a-file model it is any more
>> trivial to access a cell phone over its proprietary communication
>> protocol over the cellular network. An impression perpetuated by the
>> 9people.
>
>  Sure, at the end of the day you're still pushing the same packets
> over the same network. However, there is one thing abstraction does:
> it defines an interface. Sure, each file server has its own
> incantation, that's beside the point. In 9p, the abstraction is a file
> tree, and the interface is
> auth/attach/open/read/write/clunk/walk/remove/stat.
>  The nice part about the interface is it is simple and consistent.
> Once you know what each of those messages mean, you are set - there
> aren't really any sharp corners to watch out for. I mean you could
> argue HTTP is simpler because it just has GET/PUT/DELETE/HEAD, but you
> have to deal with rfc822 formatted messages and different transfer
> encodings and auth mechanisms and all sorts of options coming out your
> ass.
>  Mind you, a lot of the time you only care about files and
> open/read/write/clunk are all you need. Case in point, awk or rc in
> plan 9 have zero networking code, yet it is entirely possible to have
> them communicate over tcp or whatever protocols are supported in /net
> since they can open/read/write. In fact, there are no syscalls for
> network operations - everything is done via /net. Thanks to private
> namespaces, you can transparently replace /net with some other crazy
> [compatible] filesystem, which might load balance over multiple
> connections or somesuch. Network transparency means you can use /net
> from a different machine and everything just works - hang around some
> less technical folk sometime and tell me NAT doesn't deserve to die.
> Even with resources like http://portforward.com available, port
> forwarding is an impassable obstacle for many people.
>  I'd like to take a moment to note your unix example used the same
> abstraction.  You said elsewhere that plan 9's filesystems could be
> implemented on any system, which is true [to an extent]. But it's
> apparent than no others have the taste to do it as elegantly as plan 9 -
> it's all MORE APPS (netcat), MORE FEATURES (tcp code in gawk/bash),
> MOOORRREE CODE.
>
>  Eris, if you've further issues to raise, we should take this off-list.
> -sqweek
>

Re: [9fans] Using the Acme Editor

[Pietro Gagliardi]

I'm sorry, but this needs a comment.

On Aug 20, 2008, at 5:46 PM, Eris Discordia wrote:

>> As Pietro demonstrated, no interface configuration is necessary here.
>
> Only because the concept is hidden in Plan 9, though I don't know
> how. _Someone_ or _something_ has to decide whether to route your
> packets through, say, a ppp interface or an eth interface--when both
> interfaces are present--and to do that according to configuration.
> That won't happen on its own.

The program does so. What happens is the program sets up a 9P server
that runs in the background as a background process. It takes care of
everything. The user never needs to actually say "my cell phone is
interfacing off a proprietary network" because the program will take
care of that. ftpfs, for instance, doesn't ask the user for port
number, ASCII/Binary mode, etc. More elaborate FTP programs do, and I
don't know why.

> When P. G. suggested an imaginary "motorola" file server he never
> said how the file server is supposed to access the cellular network.
> If it's going to happen by tunnelling through another protocol, e.g.
> IP, then the question remains of _which_ interface to choose from.
> And if it's going to happen over some special protocol then it must
> occupy a place on the network stack over some _configured_ network
> interface.

Like I just said, the program does all of that. Take a look at srv,
which can connect to both local and remote servers.

> On a different note, what purpose did his "-M 'RAZR V3' 555 555
> 5555" switches serve? Don't they qualify as interface configuration?


No. -M 'RAZR V3' simply says the model of the phone. It does not say
over what protocol, serial number, or connection type. And 555 555
5555 is a phone number that is required for obvious reasons.

[9fans] aquarela only uses /rc/bin/9fs?

[Benjamin Huntsman]

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

Suppose I want to have Windows clients be able to connect to their /usr/<username> share via SMB.
Plan 9 comes with aquarela, but from the man page, and my own testing, it apparently only calls 9fs <arg> where <arg> is whatever you type after the \, such that in my case:

\\myplan9server\benhu

will properly prompt for authentication, then execute '9fs benhu' which fails, obviously, since 9fs tries to contact the machine 'benhu', which doesn't exist.  Is there another way around this, or would I need to modify /rc/bin/9fs to recognize subdirectories of /usr and mount them on /n just to make this work?

Thanks in advance!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2804 bytes --]

Re: [9fans] aquarela only uses /rc/bin/9fs?

[Steve Simon]

The trick you want is in /rc/bin/service/startcifs - this may not be exactly
the code  you want but it demonstrates the technique you need.

-Steve

Re: [9fans] aquarela only uses /rc/bin/9fs?

[Benjamin Huntsman]

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

>The trick you want is in /rc/bin/service/startcifs - this may not be exactly
>the code  you want but it demonstrates the technique you need.
>
>-Steve

That gets me a hair closer.  \\myplan9server\local is still empty after using startcfs, though executing

9fs local
ls /n/local

gives me a listing of the filesystem as it should... am I missing something?

Thanks much!!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2540 bytes --]

Re: [9fans] Using the Acme Editor

[Geoffrey Avila]

Not (currently) a Plan 9 user, but I gotta chime in:

> It seems the security ascribed to disposable machines comes from that "user
> data" is stored on a different, presumably safer, machine in, for example,
> some sort of data warehouse at a data center. This isn't a new
> idea--actually, it's _very_ old--and it's not what happens in home (or
> personal) computing.

You're right; it isn't. Is that good or bad? What about in an office
environment? Same answer there?

>> Plan 9 respects that. Not trusting the hostowner is a waste of effort.
>
> Not with reliable biometric authentication, but that's out of scope here.
>

Way, way out of scope. Kinda like a fusion-powered terminal.

>
> Now, your home computer may be a true single user machine but you store
> _some_ authentication information on it anyway; those of yours, namely. Such
> machine is in that respect as vulnerable as a UNIX machine. It has to be
> _physically_ guarded. It's no more a "disposable" machine.

This is the argument I had for using Sunrays in public places at work.
Single user, and if they were ganked from the lobby one night, the theives
would only have a middling LCD monitor instead of a windows system with
cached credentials.

>
> This is classic. Complication is a sign of maturation.

...or incipient schizophrenia.

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


Would that I could force you into not using double-quotes for emphasis!

-GBA

Re: [9fans] aquarela only uses /rc/bin/9fs?

[Steve Simon]

the correct namespace I would guess, you did do the import before you started cifs?

I think you should be able to connect to \\myplan9server\root implying 9fs root,
though this is just your fossil file system, so /dev/ will be fairly empty.

-Steve

Re: [9fans] aquarela only uses /rc/bin/9fs?

[Benjamin Huntsman]

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

>the correct namespace I would guess, you did do the import before you started cifs?

What is there to import?  I did this from the cpu/auth/fs server console: /rc/bin/service/startcifs

>I think you should be able to connect to \\myplan9server\root implying 9fs root,
>though this is just your fossil file system, so /dev/ will be fairly empty.
>
>-Steve

I'd thought it should be \\myplan9server\local
should do a '9fs local' and give me the contents of /

I might end up modifying startcifs or 9fs after all... :)

Thanks!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2632 bytes --]

Re: [9fans] aquarela only uses /rc/bin/9fs?

[Benjamin Huntsman]

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

>the correct namespace I would guess, you did do the import before you started cifs?

Hmm... I used consolefs to the /srv/fscons to add srv -A test
then as my user I could do \\myplan9server\test and get the root of the drive.
Looks like a namespace issue after all.
However, might this  prevent users from all connecting to the system, unless I add a /srv/ entry for every user who might connect...?

Thanks!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2540 bytes --]

Re: [9fans] Using the Acme Editor

[Uriel]

On Wed, Aug 20, 2008 at 11:46 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> Thank you, sqweek. The second golden Golden Apple with καλλιστι on it is
> totally yours. The first one went to Russ Cox.
>
>>  You don't care who mounts what where, because the rest of the system
>> doesn't notice the namespace change.
>
> So essentially there shouldn't be a problem with mounting on a single
> "public" namespace as long as there is one user on the system. mount
> restriction in UNIX systems was put in place because multiple users exist
> some of whom may be malicious. Virtualization and jailing will relax that
> requirement.

Mount restrictions on unix are needed (among other reasons) because of
a broken security model (ie., suid).

Virtualization and jailing are hacks to work around the inherent
limitation that in unix resources can not be easily
abstracted/isolated and are plagued by the 'only root can do X'
restriction ('only root can become another user', hence su/sudo, only
root can open certain ports, etc.) which Plan 9 cleanly does away
with.

Linux could do many things plan9 can do, if it got rid of all suid
programs (by perhaps using the cap device implementation for the linux
kernel, if that is ever accepted in mainline linux), but until then...

>>  Uh, what now? You either have an interesting definition of home
>> computer or some fucked up ideas about plan 9. You only need a cpu
>> server if you want to let other machines run processes on your
>> machine. You only need an auth server if you want to serve resources
>> to a remote machine.
>
> Neither statement is true. On a home computer you certainly need a term.
> You'll need a cpu for a number of tasks. And you'll need auth if there's
> going to be more than one user on the system, or if you need a safe way of
> authenticating yourself to your computer. A single glenda account doesn't
> quite cut it. If you're going to access your storage you'll need some
> fs('s), too.
>
> The bottom line is: term is _certainly_ not enough for doing all the tasks a
> *BSD does, and requiring a home computer to do all these tasks is far from
> inconceivable. One *BSD system is almost functionally equivalent to a
> combination of term, cpu, auth, and some fs('s).

A plan9 terminal can run programs, and can have a local storage file
system, with multiple users. As for authentication, in such use case
unix auth is little more than a farce of security theater which could
easily be implemented in plan9 (and I think some people has) if you
wanted to keep your three year old child from accessing your account
but is futile for much else.

>> incantation, that's beside the point. In 9p, the abstraction is a file
>> tree, and the interface is
>
> auth/attach/open/read/write/clunk/walk/remove/stat.
>
> ioctl and VFS are suspiciously similar even though they serve less generic
> functions.

Try to do ioctl over the network.

>> network operations - everything is done via /net. Thanks to private
>> namespaces, you can transparently replace /net with some other crazy
>> [compatible] filesystem, which might load balance over multiple
>
> 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.

Here is a reason: Because Plan 9 has no network-related syscalls, and
applications contain no networking code (even when they are still
network transparent thanks to 9P), when ipv6 was added to plan9, no
changes were required to either any syscalls or any applications. On
the other hand on unix they are still to this day adding ipv6 support
to certain apps (and every app that needs to access remote resources
needs its own networking code that is aware of each protocol it wants
to support, etc).

When ipv6 needs to be replaced, the pain in the unix software
ecosystem will be even greater, while in plan9 it will be virtually
painless.

There are also the benefits of allowing different applications
(namespaces) use different network stacks without requiring full
virtualization of the whole OS (the few unix systems that have been
able to implement this functionality have done so after many years of
painful efforts and the result is incredibly clunky and complex), and
I don't think any unix systems allows a single application (or
namespace) to access *multiple* network stacks concurrently... and
remote network stacks? don't think so either.

>
>> implemented on any system, which is true [to an extent]. But it's
>> apparent than no others have the taste to do it as elegantly as plan 9 -
>
> It's not a matter of taste. There are situations, many situations actually,
> where the file system abstraction is plainly naive. Sticking with it for
> every application verges on being an "ideology."
>
> The VFS approach is by no means inferior to Plan 9's everything-is-a-file,
> but on UNIX systems it is limited to resources that can be meaningfully
> represented as file systems. Representing a relational database as a file
> system is meaningless. The better representation is something along the
> lines of the System::Data::DataGrid class on Microsoft .NET framework.

Ah, interesting example, isn't it sad that every database system on
unix (or windows) needs to include its own networking code, its own
authentication, etc.?

Peace

uriel

Re: [9fans] Using the Acme Editor

[erik quanstrom]

> 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

Re: [9fans] Using the Acme Editor

[erik quanstrom]

> A plan9 terminal can run programs, and can have a local storage file
> system, with multiple users.

i think this is misleading.  while the fs running on the terminal can have
multiple users, it is not true that you can have multiple users using
the cpu resources of a terminal concurrently.

you can have all that and auth if you run a single machine with a cpu
kernel with the downside that if you use the console you must be eve.

since it's easy to get small, cheep, low-power machines, i run a
traditional terminal with a seperate auth and fs.

- erik

Re: [9fans] Using the Acme Editor

[john]

>> A plan9 terminal can run programs, and can have a local storage file
>> system, with multiple users.
>
> i think this is misleading.  while the fs running on the terminal can have
> multiple users, it is not true that you can have multiple users using
> the cpu resources of a terminal concurrently.
>
> you can have all that and auth if you run a single machine with a cpu
> kernel with the downside that if you use the console you must be eve.
>
> since it's easy to get small, cheep, low-power machines, i run a
> traditional terminal with a seperate auth and fs.
>
> - erik

http://plan9.bell-labs.com/wiki/plan9/Drawterm_to_your_terminal/index.html


John

Re: [9fans] Using the Acme Editor

[David Leimbach]

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

On Thu, Aug 21, 2008 at 3:58 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > A plan9 terminal can run programs, and can have a local storage file
> > system, with multiple users.
>
> i think this is misleading.  while the fs running on the terminal can have
> multiple users, it is not true that you can have multiple users using
> the cpu resources of a terminal concurrently.
>
> you can have all that and auth if you run a single machine with a cpu
> kernel with the downside that if you use the console you must be eve.
>
> since it's easy to get small, cheep, low-power machines, i run a
> traditional terminal with a seperate auth and fs.
>

You can even run 9vx as a totally reasonable terminal now... On a system
that needs not be dedicated to Plan 9, and still have your CPU/FS/AUTH
elsewhere.  (Thanks Russ!)

I'm a big fan of this approach, if people find it difficult to justify a
whole machine as a Plan 9 terminal.

I think Inferno is somewhat usable for this purpose even too right?  I've
just never managed to get it going (or admittedly spent much time trying).

Dave


>
> - erik
>
>
>

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

Re: [9fans] aquarela only uses /rc/bin/9fs?

[Benjamin Huntsman]

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

>The trick you want is in /rc/bin/service/startcifs - this may not be exactly
>the code  you want but it demonstrates the technique you need.
>
>-Steve

startcifs didn't work quite like what I had in mind, so I ended up modifying /rc/bin/9fs.  The excerpt below gives me exactly what I wanted:

...
case wiki
     srv -m 'net!plan9.bell-labs.com!wiki' wiki /mnt/wiki
case *
     switch($#*){
     case 1
          # Help out auarela:
          for(i in /usr/*) if($1=`{basename $i}){
               bind -ac /usr/$1 /n/$1
               exit
          }
          srv -m $1
     case *
...

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2656 bytes --]

Re: [9fans] Using the Acme Editor

[Eris Discordia]

A correction:

Mea culpa. UNIX systems apparently force processes to share a single
network stack, but that can be changed:

http://www.tel.fer.hr/zec/papers/zec-03.pdf

A paper on virtualizing network stacks in FreeBSD kernel, 2003 USENIX.

Re: [9fans] Using the Acme Editor

[ron minnich]

On Thu, Aug 21, 2008 at 9:59 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> A correction:
>
> Mea culpa. UNIX systems apparently force processes to share a single network
> stack,

gee how about that? Isn't it nice to acquire knowledge and *then* post?

> but that can be changed:
>
> http://www.tel.fer.hr/zec/papers/zec-03.pdf
>
> A paper on virtualizing network stacks in FreeBSD kernel, 2003 USENIX.

Similar work is being done in Linux. I talked to the guy who is doing
it a year ago. Want to know what inspired it? Which OS? Wanna guess?

And, they are putting other "namespaces" into Linux. Wonder where they
got that idea and name? I know. Do you?

yeeesh.

ron