Re: [9fans] Using the Acme Editor

[Uriel <uriel99@gmail.com>]

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