5 ms·

> no reason why containerization can't be pushed right down to the language level I started my reply by listing a plethora of reasons why this wouldn't work. (

> no reason why containerization can't be pushed right down to the language level I started my reply by listing a plethora of reasons why this wouldn't work. (For one, this would work because it does work, right now in Erlang.) But they all came down to that it seems like you're missing some of the problems that containerization solves. You can wrap up almost any service -- regardless of language or versions or runtimes or how it interacts with the filesystem or what versions of libraries it depends on or what global configs it expects or anything -- and ship it as a self-contained normalized service that can run right alongside any other number of other self-contained normalized services that require their own global configs and libraries etc etc even if they're incompatible and whoever is deploying them doesn't even need to care. Everyone has their own language and toolset that they're comfortable with and productive in. That will never change. Containerization abstracts over all of them and normalizes their deployment. You can never get that with a solution at the language level.

derefr 10y ago
> For one, this would work because it does work, right now in Erlang. Eh? Erlang has no equivalent to cgroups/namespaces, or even an equivalent of non-UID-0 code execution on its VM. There is in fact no isolation mechanism in the Erlang VM; all code is "privileged." Untrusted multitenant code execution is a pipe-dream for now, unless you graft on another sandbox inside Erlang, ala CouchDB's V8 C-port [and more recently luerl] sandboxes. (I've been very much considering contributing code for "non-privileged Erlang processes" and "Erlang process namespaces"—adding things like "namespace outboxes" that will crash their own virtual nodes rather than flood peers—but it's not there right now.)
- infogulch 10y ago
  Well, no, it doesn't have privilege isolation. But it does have isolation from a fault tolerance perspective which I admit is only a portion of the purpose of isolation. But if you're deliberately running malicious code even cgroups/namespaces won't save you from some attacks. Timing and cache attacks can be done without breaking out of the jail.
  - derefr 10y ago
    Not deliberately running malicious code, no; but deliberately running user-supplied code, yes. A properly isolated container system (whether at the OS or the runtime level) allows one system to serve as host for the programmatic equivalent of members of two rival gangs (mutually-untrustworthy processes), without anyone "getting shot."
    - infogulch 10y ago
      Separating "malicious code" from "user-supplied code" is a distinction without a difference. I would say one member having their private keys stolen[1] is a "fatal shot". [1]: https://news.ycombinator.com/item?id=11891579 https://news.ycombinator.com/item?id=11891579

derefr 10y ago

> For one, this would work because it does work, right now in Erlang. Eh? Erlang has no equivalent to cgroups/namespaces, or even an equivalent of non-UID-0 code execution on its VM. There is in fact no isolation mechanism in the Erlang VM; all code is "privileged." Untrusted multitenant code execution is a pipe-dream for now, unless you graft on another sandbox inside Erlang, ala CouchDB's V8 C-port [and more recently luerl] sandboxes. (I've been very much considering contributing code for "non-privileged Erlang processes" and "Erlang process namespaces"—adding things like "namespace outboxes" that will crash their own virtual nodes rather than flood peers—but it's not there right now.)

infogulch 10y ago
Well, no, it doesn't have privilege isolation. But it does have isolation from a fault tolerance perspective which I admit is only a portion of the purpose of isolation. But if you're deliberately running malicious code even cgroups/namespaces won't save you from some attacks. Timing and cache attacks can be done without breaking out of the jail.
- derefr 10y ago
  Not deliberately running malicious code, no; but deliberately running user-supplied code, yes. A properly isolated container system (whether at the OS or the runtime level) allows one system to serve as host for the programmatic equivalent of members of two rival gangs (mutually-untrustworthy processes), without anyone "getting shot."
  - infogulch 10y ago
    Separating "malicious code" from "user-supplied code" is a distinction without a difference. I would say one member having their private keys stolen[1] is a "fatal shot". [1]: https://news.ycombinator.com/item?id=11891579 https://news.ycombinator.com/item?id=11891579