[henesy]

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

[ori_b]

> 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.

[jstimpfle]

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]

Because it's a kernel data structure thing that exists in the file system. The remote machine doesn't have access to it.

[jstimpfle]

That's true for regular files as well.

[ori_b]

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?

[jstimpfle]

What does it mean to mmap a file on an NFS server? Isn't it a connection drop when a local process dies, too? What happens when a disk is suddenly removed?

> On top of that, you'd need to run on a treadmill to add support for new ioctls.

Absolutely, it'd be a lot of work. So it's a better idea to not implement many of these things and instead simply return an error.

[pjmlp]

To be fair that is a general UNIX issue.

[chungy]

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

[AsyncAwait]

Except the user interface for them on FreeBSD compared to i.e. docker is atrocious.

[henesy]

Yeah zones especially, I agree.

[hestefisk]

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]

Somehow I think Tru64 and HP-UX vaults had it first.