Re: [9fans] Using the Acme Editor - Plan9

This is a discussion on Re: [9fans] Using the Acme Editor - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: [9fans] Using the Acme Editor

  1. Re: [9fans] Using the Acme Editor

    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 ****ed 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:ata:ataGrid 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
    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 ****ed 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 )
    >
    >> 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
    >




  2. Re: [9fans] Using the Acme Editor

    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.



  3. Re: [9fans] Using the Acme Editor


    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



  4. Re: [9fans] Using the Acme Editor

    > 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



+ Reply to Thread