5 ms·

Linux containers feel like a very weak imitation of what they could be under an environment like Plan9 imo. Linux lacks a lot of core abstraction properties th

by henesy 7y ago

Linux containers feel like a very weak imitation of what they could be under an environment like Plan9 imo. Linux lacks a lot of core abstraction properties that would make containers elegant to implement under something like the Plan9 model, at least. Cool project inspired partially by Linux containers: https://doc.9gridchan.org/guides/spawngrid https://doc.9gridchan.org/guides/spawngrid

chungy 7y ago
Linux containers feel like weak imitations of jails and zones found in FreeBSD and Solaris/illumos, for that matter.
- henesy 7y ago
  Yeah zones especially, I agree.
  - hestefisk 7y ago
    Why not Jails? It was pretty much the first to provide this in Unix land. I guess the advantage of Docker / containers was / is the nice TUI for developers as well as Hub. We never had a ‘jailshub’ in FreeBSD.
    - pjmlp 7y ago
      Somehow I think Tru64 and HP-UX vaults had it first.
- AsyncAwait 7y ago
  Except the user interface for them on FreeBSD compared to i.e. docker is atrocious.
ori_b 7y ago
> Linux lacks a lot of core abstraction properties No, it's worse than that: It has too many of them, leading to a mess of special cases that you have to deal with. What happens when you have a socket in your file system, and you export it over NFS? Lacking abstraction properties is fixable -- you can add them. But removing them, especially if they're widely used, is incredibly hard.
- pjmlp 7y ago
  To be fair that is a general UNIX issue.
- jstimpfle 7y ago
  Making good abstractions is hard. On Unix I sometimes wish I could unwrap the stream abstraction, but nevertheless I think it is one of the few abstractions that have really stood the test of time. Why wouldn't a a socket exported over NFS just work seamlessly?
  - ori_b 7y ago
    Because it's a kernel data structure thing that exists in the file system. The remote machine doesn't have access to it.
    - jstimpfle 7y ago
      That's true for regular files as well.
      - ori_b 7y ago
        No, the remote machine has access to file structures via NFS, which is complicated enough. NFS doesn't have protocol-level special cases for forwarding operations for the local sockets, handling setsockopt(), various socket ioctls -- which, mind you, are often machine specific, where the data sent in ioctl is ABI dependent. I'm not even sure how you'd do that sort of thing, since NFS is a stateless protocol. And then you would need to repeat the exercise for these special cases for all of the other special types of node, like /dev. What does it even mean to mmap the video memory of a video card on a remote machine? And then you'd need to fix the assumptions of all the software that assumes local semantics ("the connection doesn't drop, and poll() is always accurate"). On top of that, you'd need to run on a treadmill to add support for new ioctls. Do you really want to implement the server side of a protocol that can handle all of the complexity of all you can do on all file systems, with all ioctls, across all node types? How many implementations providing resources via this protocol do you think would exist?

by henesy 7y ago

chungy 7y ago

Linux containers feel like weak imitations of jails and zones found in FreeBSD and Solaris/illumos, for that matter.

henesy 7y ago
Yeah zones especially, I agree.
- hestefisk 7y ago
  Why not Jails? It was pretty much the first to provide this in Unix land. I guess the advantage of Docker / containers was / is the nice TUI for developers as well as Hub. We never had a ‘jailshub’ in FreeBSD.
  - pjmlp 7y ago
    Somehow I think Tru64 and HP-UX vaults had it first.
AsyncAwait 7y ago
Except the user interface for them on FreeBSD compared to i.e. docker is atrocious.

ori_b 7y ago

> Linux lacks a lot of core abstraction properties No, it's worse than that: It has too many of them, leading to a mess of special cases that you have to deal with. What happens when you have a socket in your file system, and you export it over NFS? Lacking abstraction properties is fixable -- you can add them. But removing them, especially if they're widely used, is incredibly hard.

pjmlp 7y ago
To be fair that is a general UNIX issue.
jstimpfle 7y ago
Making good abstractions is hard. On Unix I sometimes wish I could unwrap the stream abstraction, but nevertheless I think it is one of the few abstractions that have really stood the test of time. Why wouldn't a a socket exported over NFS just work seamlessly?
- ori_b 7y ago
  Because it's a kernel data structure thing that exists in the file system. The remote machine doesn't have access to it.
  - jstimpfle 7y ago
    That's true for regular files as well.
    - ori_b 7y ago
      No, the remote machine has access to file structures via NFS, which is complicated enough. NFS doesn't have protocol-level special cases for forwarding operations for the local sockets, handling setsockopt(), various socket ioctls -- which, mind you, are often machine specific, where the data sent in ioctl is ABI dependent. I'm not even sure how you'd do that sort of thing, since NFS is a stateless protocol. And then you would need to repeat the exercise for these special cases for all of the other special types of node, like /dev. What does it even mean to mmap the video memory of a video card on a remote machine? And then you'd need to fix the assumptions of all the software that assumes local semantics ("the connection doesn't drop, and poll() is always accurate"). On top of that, you'd need to run on a treadmill to add support for new ioctls. Do you really want to implement the server side of a protocol that can handle all of the complexity of all you can do on all file systems, with all ioctls, across all node types? How many implementations providing resources via this protocol do you think would exist?