3 ms·

> The abstractions are there in Linux, largely imported from plan 9. Which abstractions are those?

zozbot234 5y ago
> to be able to do computation, discovery, message passing/IO, instrumentation over multiple nodes. Kernel namespaces are the building blocks for this, because an app that accesses all kernel-managed resources via separate namespaces is insulated from the specifics of any single node, and can thus be transparently migrated elsewhere. It enables the kind of location independence that OP is arguing for here.
- glorfindel66 5y ago
  That’s not at all what Linux namespaces permit. It’s a side effect of using them that could be leveraged using something like CRIU, sure, but it’s not what they’re for and they’re not a building block for anything mentioned in the portion of their comment you quoted. Namespaces simply make the kernel lie when asked about sockets and users and such. It’s intended for isolation on a single server. They’re next to useless in distributed work, particularly the kind being discussed here (Plan 9ish). You actually want the opposite: to accomplish that, you want the kernel to lie even harder and make things up in the context of those interfaces, rather than hide things. Namespaces don’t really get you there in their current form.
  - zozbot234 5y ago
    > That’s not at all what Linux namespaces permit. Isolating processes from the specifics of the system they're running on is a key feature of the namespace-based model; it seems weird to call it a "side effect only". We should keep in mind that CRIU itself is still a fairly new feature that's only entered mainline recently, and the kernel already has plenty of ways to "make up" more virtual resources that are effectively controlled by userspace. While it may be true that these things are largely ad hoc for now, it's not clear that this will be an obstacle in the future,
    - gnufx 5y ago
      I can talk about namespaces in HPC distributed systems, and they don't look anything like Plan 9 to me. They make life harder in various respects, and even dangerous with Linux features that don't take them into account (like at least one of the "zero-copy" add-on modules used by MPI shared memory implementations).
- stormbrew 5y ago
  Linux namespaces don't actually do any of those things though? Like, not even a single one of them are made possible because of namespaces. They're all possible or not possible precisely as much with or without namespaces. The thing is when comparing plan9 and linux here, you have to recognize that linux has it backwards. On plan9 namespaces are emergent from the distributed structure of the system. On linux they form useful tools to build a distributed system. But what's possible on plan9 is possible because it really does do "everything is a file," so your namespace is made up of io devices (files) and you can construct or reconstruct that namespace as you need. Like, this[1] is a description of how to configure plan9's cpu service so you run programs on another node. [1] https://9p.io/wiki/plan9/Expanding_your_Grid/index.html https://9p.io/wiki/plan9/Expanding_your_Grid/index.html Nothing in there makes any sense from a linux containers perspective. You can't namespace the cpu. You can't namespace the gui terminal. All you can namespace is relatively superficial things, and even then opening up that namespacing to unprivileged users has resulted in several linux CVEs over the last year because it's just not built with the right assumptions.
  - zozbot234 5y ago
    Doesn't Linux create device files in userspace these days, anyway? I thought that's what that udev stuff was all about. So I'm not sure that the Plan9 workflow is inherently unfeasible, there's just no idiomatic support for it just yet.
    - stormbrew 5y ago
      device nodes are managed in userspace nowadays yes, but they're just special files that identify a particular device id pair and then the OS acts on them in a special way. udev is just the userspace part of things that manages adding and removing them in response to hotplug events. Everything that matters about them is still controlled by the kernel.

> to be able to do computation, discovery, message passing/IO, instrumentation over multiple nodes. Kernel namespaces are the building blocks for this, because an app that accesses all kernel-managed resources via separate namespaces is insulated from the specifics of any single node, and can thus be transparently migrated elsewhere. It enables the kind of location independence that OP is arguing for here.

glorfindel66 5y ago
That’s not at all what Linux namespaces permit. It’s a side effect of using them that could be leveraged using something like CRIU, sure, but it’s not what they’re for and they’re not a building block for anything mentioned in the portion of their comment you quoted. Namespaces simply make the kernel lie when asked about sockets and users and such. It’s intended for isolation on a single server. They’re next to useless in distributed work, particularly the kind being discussed here (Plan 9ish). You actually want the opposite: to accomplish that, you want the kernel to lie even harder and make things up in the context of those interfaces, rather than hide things. Namespaces don’t really get you there in their current form.
- zozbot234 5y ago
  > That’s not at all what Linux namespaces permit. Isolating processes from the specifics of the system they're running on is a key feature of the namespace-based model; it seems weird to call it a "side effect only". We should keep in mind that CRIU itself is still a fairly new feature that's only entered mainline recently, and the kernel already has plenty of ways to "make up" more virtual resources that are effectively controlled by userspace. While it may be true that these things are largely ad hoc for now, it's not clear that this will be an obstacle in the future,
  - gnufx 5y ago
    I can talk about namespaces in HPC distributed systems, and they don't look anything like Plan 9 to me. They make life harder in various respects, and even dangerous with Linux features that don't take them into account (like at least one of the "zero-copy" add-on modules used by MPI shared memory implementations).
stormbrew 5y ago
Linux namespaces don't actually do any of those things though? Like, not even a single one of them are made possible because of namespaces. They're all possible or not possible precisely as much with or without namespaces. The thing is when comparing plan9 and linux here, you have to recognize that linux has it backwards. On plan9 namespaces are emergent from the distributed structure of the system. On linux they form useful tools to build a distributed system. But what's possible on plan9 is possible because it really does do "everything is a file," so your namespace is made up of io devices (files) and you can construct or reconstruct that namespace as you need. Like, this[1] is a description of how to configure plan9's cpu service so you run programs on another node. [1] https://9p.io/wiki/plan9/Expanding_your_Grid/index.html https://9p.io/wiki/plan9/Expanding_your_Grid/index.html Nothing in there makes any sense from a linux containers perspective. You can't namespace the cpu. You can't namespace the gui terminal. All you can namespace is relatively superficial things, and even then opening up that namespacing to unprivileged users has resulted in several linux CVEs over the last year because it's just not built with the right assumptions.
- zozbot234 5y ago
  Doesn't Linux create device files in userspace these days, anyway? I thought that's what that udev stuff was all about. So I'm not sure that the Plan9 workflow is inherently unfeasible, there's just no idiomatic support for it just yet.
  - stormbrew 5y ago
    device nodes are managed in userspace nowadays yes, but they're just special files that identify a particular device id pair and then the OS acts on them in a special way. udev is just the userspace part of things that manages adding and removing them in response to hotplug events. Everything that matters about them is still controlled by the kernel.