hey @p I was wondering how per-process filesystem namespaces change how you use your computer systems?
@izaya This is a very long explanation! I'll give you the short version, which is still a bit long, maybe. One of the things to keep in mind is it's a feature that is useful on its own, but it's more interesting as a building block in a larger system, so whatever I say is going to be a fraction of the picture.
For one thing, you no longer have to set $PATH, you just bind the stuff you want. It also changes a lot of facets of the system, like drawterm exposes the host filesystem as /mnt/term, which would allow anyone to access your filesystem if it weren't per-process, but since it is, it's fine.
As far as things changing for me personally, I make a lot of throwaway mounts. vacfs and zipfs, things like that. In Inferno, instead of authenticating myself once per auth server, I just auth against my main system and then bind my main system's /usr/pete/keyring under the local directory. I make pretty heavy use of it for stuff like mothra (multiple instances of webcookiefs), acme (binding dumpfiles), so software doesn't have support for multiple "profiles" you can just have that by binding stuff over the config. I like the Inferno man page browser so I bound $plan9box/sys/man on top of one shell's /man to look at man pages in Inferno's wm/man. Things like that.
For one thing, you no longer have to set $PATH, you just bind the stuff you want. It also changes a lot of facets of the system, like drawterm exposes the host filesystem as /mnt/term, which would allow anyone to access your filesystem if it weren't per-process, but since it is, it's fine.
As far as things changing for me personally, I make a lot of throwaway mounts. vacfs and zipfs, things like that. In Inferno, instead of authenticating myself once per auth server, I just auth against my main system and then bind my main system's /usr/pete/keyring under the local directory. I make pretty heavy use of it for stuff like mothra (multiple instances of webcookiefs), acme (binding dumpfiles), so software doesn't have support for multiple "profiles" you can just have that by binding stuff over the config. I like the Inferno man page browser so I bound $plan9box/sys/man on top of one shell's /man to look at man pages in Inferno's wm/man. Things like that.
@izaya
> more interesting as a building block in a larger system
Think of it like the difference between having only global variables and local variables. It can be difficult to explain how you use local variables, but it's like that kind of effect.
> more interesting as a building block in a larger system
Think of it like the difference between having only global variables and local variables. It can be difficult to explain how you use local variables, but it's like that kind of effect.
Follow
@p
that sounds pretty neat, but maybe cumbersome. Is this using Linux namespaces or (judging by one of your var names) Plan 9 or some offshoot of that?
I've made some use of Docker for certain applications, but I've some vague thoughts about using Linux namespaces more directly to isolate some applications--figuring out what all of the files are that the application might need could be annoying. I can possibly automate this by running the application and tracing opened files, but I haven't tried it yet. Possibly a long tail of files I missed that I have to keep adding to my "container".
> that sounds pretty neat, but maybe cumbersome.
Not really. It's less cumbersome, in fact, because you don't need to be root to manipulate the namespace (there is no root, in fact), because it doesn't affect anything up the chain from the current process's namespace. It is a lot like global variables vs. lexical closures, it makes things easier.
> Is this using Linux namespaces or (judging by one of your var names) Plan 9 or some offshoot of that?
Plan 9 and Inferno. (Linux's namespaces actually *are* cumbersome. Please don't get me started on Docker.)
> vague thoughts about using Linux namespaces more directly to isolate some applications
I've done this, but mainly for ridiculous stuff. (For example, I used cgroups stuff to throttle an emulator that didn't have slow-motion mode because there is a touchscreen-heavy mini-game in Lost in Blue that is nearly impossible to do with a mouse, but if you throttle the CPU and turn off frameskip, you get slow-motion.) LxC is fun, I've gotten more use out of that than Docker, but it's really not comparable. cgroups is like the Netflix adaptation of Plan 9. You interact with the network by using the /net filesystem (the filesystem is not "files" any more, it's just the uniform interface for interacting with system objects, some of which are files on disk but some of which are the screen or the DNS server or window manager or whatever), so if you do `bind -c /n/other-machine/net /net` you're using the other machine's network interface, effectively a one-line implementation of a VPN.
> figuring out what all of the files are that the application might need could be annoying.
Yeah, it's not like that. A process inherits its parent's namespace, you can remove parts as needed, add parts as needed, and then that propagates to child processes. So you can replace / with a read-only version of /, for example, that's one command. It gets cooler if you use fossil, because venti is content-addressed and fossil only loads blocks on demand (essentially, fossil is a hot cache of the data stored in venti), so you can create, like, a 200MB fossil FS in RAM, tell it to use the venti score of your root FS, then give it to some application as its root FS, and the application won't notice unless it needs more data than that between flushes.