Re: [9fans] Using the Acme Editor

[sqweek <sqweek@gmail.com>]

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