> If anyone knows of any projects trying to work around that problem I'd love to hear about it.
Containers are namespaced processes. These processes exec against the corresponding kernel they require. There is no workaround: if you have an ELF binary calling Linux syscalls it can only run on a Linux kernel†, so to run that you need a VM††. It's not as bad as it appears thanks to memory ballooning†††.
Conversely if you want to exec a Windows binary in a container, the Windows kernel needs to provide process namespacing features (which it does). And if you want to exec a Darwin binary in a container, then the Darwin kernel needs to provide process namespacing features (which it doesn't).
† WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be.
The challenge of running OCI containers in every OS is a bit similar to the problem of running the same binary in every OS.
I think the only true solutions are (a) OS vendors develop their own native container platforms with UX similar or better than Docker (b) OS vendors agree on some common ABI standard
> running a x86 windows binary - looking for 32bit stuff under SysWOW64 - under x86_64 wine in a x86_64 Linux container AOT translated to aarch64 by Rosetta 2 for Linux that switched the ARM M1 memory model to Total Store Ordering on a aarch64 Linux kernel under Virtualisation.framework on arm64 darwin.
> WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be.
I've long wondered, and again now that Chat GPT is proving so adept at coding, if this translation layer could be automated. Do humans actually have to hand-code each syscall? Or are there just enough edge conditions that can't be automated?
The hard part isn't so much writing the code as it is testing the code. The WINE server is decades old, porting API calls to another kernel isn't an entirely new or novel process. Getting all the software to work right is an ongoing process though, and it requires careful deliberation over what works and what doesn't. WINE code is still being refined to this day in response to new titles and old bugfixes.
So, I won't preclude the idea of AI helping, but I think human effort is still the bottleneck for projects like this. Even if AI could write perfect code 100% of the time, testing and troubleshooting would probably still be the larger timesink.
Containers are namespaced processes. These processes exec against the corresponding kernel they require. There is no workaround: if you have an ELF binary calling Linux syscalls it can only run on a Linux kernel†, so to run that you need a VM††. It's not as bad as it appears thanks to memory ballooning†††.
Conversely if you want to exec a Windows binary in a container, the Windows kernel needs to provide process namespacing features (which it does). And if you want to exec a Darwin binary in a container, then the Darwin kernel needs to provide process namespacing features (which it doesn't).
† WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be.
†† Or colinux (https://en.wikipedia.org/wiki/Cooperative_Linux), or user-mode Linux (https://en.wikipedia.org/wiki/User-mode_Linux).
††† https://en.wikipedia.org/wiki/Memory_ballooning