|
|
|
|
|
by stephenr
2016 days ago
|
|
> considering Docker's use of a VM behind the scenes in some situations (in which case the "host running the container" is technically the VM, not the user's PC). That is exactly the point. If you want to run Linux binaries you need a Linux container. On windows or macOS that means a Linux vm. If you want to run windows binaries you need a windows container. Conversely if you had a macOS container you’d only be able to run macOS binaries. This is my point. It’s not a hard concept to understand. I’m not asking people to learn about cgroups or Chroots or network namespaces or any of that. |
|
So, maybe all the people you're yelling at understand the concept you think they don't, and they're okay with it.
Two, it's not at all true that to run Linux binaries on non-Linux, you need a Linux VM. WSL1 is an existence proof against this on Windows, as is the Linuxulator on FreeBSD, as are LX-branded zones on SmartOS. Linux itself has a "personality" mechanism for running code from non-Linux UNIXes. You could do the same thing on macOS, and teach the kernel to handle a good-enough subset of the Linux system call interface - it would be far less work than adding containerization (namespacing and resource isolation) in the first place, so I'm not sure why you're so hung up about this.