From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 20 Aug 2008 22:46:57 +0100 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <1A65C224C4D988F3504822E7@computer> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [9fans] Using the Acme Editor Topicbox-Message-UUID: 032ad1c4-ead4-11e9-9d60-3106f5b1d025 Thank you, sqweek. The second golden Golden Apple with = =CE=BA=CE=B1=CE=BB=CE=BB=CE=B9=CF=83=CF=84=CE=B9 on=20 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=20 "public" namespace as long as there is one user on the system. mount=20 restriction in UNIX systems was put in place because multiple users exist=20 some of whom may be malicious. Virtualization and jailing will relax that=20 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.=20 _Someone_ or _something_ has to decide whether to route your packets=20 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=20 its own. When P. G. suggested an imaginary "motorola" file server he never said how=20 the file server is supposed to access the cellular network. If it's going=20 to happen by tunnelling through another protocol, e.g. IP, then the=20 question remains of _which_ interface to choose from. And if it's going to=20 happen over some special protocol then it must occupy a place on the=20 network stack over some _configured_ network interface. On a different note, what purpose did his "-M 'RAZR V3' 555 555 5555"=20 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=20 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=20 boot your home/portable personal computer they are set for collecting all=20 you've stored on it. In that respect, I don't see how the "disposable"=20 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,=20 some sort of data warehouse at a data center. This isn't a new=20 idea--actually, it's _very_ old--and it's not what happens in home (or=20 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.=20 You'll need a cpu for a number of tasks. And you'll need auth if there's=20 going to be more than one user on the system, or if you need a safe way of=20 authenticating yourself to your computer. A single glenda account doesn't=20 quite cut it. If you're going to access your storage you'll need some=20 fs('s), too. The bottom line is: term is _certainly_ not enough for doing all the tasks=20 a *BSD does, and requiring a home computer to do all these tasks is far=20 from inconceivable. One *BSD system is almost functionally equivalent to a=20 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=20 more a "disposable terminal," its security becomes as important as the=20 security of a heavily used auth server. The "disposable" machine paradigm=20 fails as miserably as the the traditional UNIX paradigm: one machine, many=20 users. Now, your home computer may be a true single user machine but you store=20 _some_ authentication information on it anyway; those of yours, namely.=20 Such machine is in that respect as vulnerable as a UNIX machine. It has to=20 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=20 auth/attach/open/read/write/clunk/walk/remove/stat. ioctl and VFS are suspiciously similar even though they serve less generic=20 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=20 that by not maturing, by avoiding diversification. Before you get angry I=20 must say that's my "personal" opinion. Nothing I'm going to "force" unto=20 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=20 device on UNIX? And why should avoiding system calls be considered an=20 advantage? Your VFS layer could do anything expected from /net provided=20 that file system abstraction for the resources represented under /net is=20 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=20 every application verges on being an "ideology." The VFS approach is by no means inferior to Plan 9's everything-is-a-file,=20 but on UNIX systems it is limited to resources that can be meaningfully=20 represented as file systems. Representing a relational database as a file=20 system is meaningless. The better representation is something along the=20 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 =20 wrote: > 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 >