From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30808201108q5f45956cgde3dc9360c90ab26@mail.gmail.com> Date: Thu, 21 Aug 2008 02:08:16 +0800 From: sqweek To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <9857CD0765466E1BE9BD9051@computer> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9857CD0765466E1BE9BD9051@computer> Subject: Re: [9fans] Using the Acme Editor Topicbox-Message-UUID: 02da77c4-ead4-11e9-9d60-3106f5b1d025 On Wed, Aug 20, 2008 at 8:56 PM, Eris Discordia 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