> In just pointing out that people are saying they want "docker" to work fine on non-Linux platforms but really, they want to run Linux binaries on non-linux kernels.
Is that true? Plenty of people are using multi-arch images (x86 and aarch64) which are essentially the Docker image equivalent of a fat binary. I might be wrong, but I think what I want are preconfigured macOS binaries packaged up a convenient image format with a layered filesystem, networking support, etc. Ideally with an equivalent linux image such that I can later switch the OS specifier and get an image containing an equivalent linux binary to run on linux.
I am for example quite happy to run a macOS native version of Postgres. But that doesn't give me the easy disposable database for testing that a docker-compose setup gives me. If I could specify that I want the "postgres" docker image in my docker-compose file, and running that file on macOS ran a macOS version of postgres in a macOS-native container then I'd be very happy.
I think it's more than just multi-arch, it's also multi-OS (i.e. if we take Windows and BSD into account too we'd get 8 image types required for just 4 operating systems and 2 architectures if kept 'simple').
Packaging (including fat binaries but also byte code self-unpackers) has tried to make this possible for decades but it just won't stick. Take Debian or RedHat packages for example, there have been tools and repositories for very long times that were meant to make a universal method of distributing pre-packaged (and natively also chrootable/jailable) software for a multitude of architectures and operating systems possible, but package authors just didn't really want to do the work for what is essentially not something they wanted themselves.
Building software for 1 or 2 major release versions within a single operating system is hard enough, tacking on extra systems is usually a step too far.
The closest we got (and it still exists) is autotools, but that's just build tooling. It does however make it possible to build software from a single source for many targets and check for all the required features ahead of time. But this is so close to developing the software itself that it's not really compatible with the influx of end-user-style developers that expect pre-packaged 'commercial grade' software, which is essentially what Docker and OCI and Containers are.
The only 'new' thing so far has been cgroupsv2, the v1 version and everything else (distribution, sandboxing, capabilities, separate user land etc) has been done for over three decades. But again, using it means knowing how to use chroot, cap, tun and jail for example, and not everyone wants to learn that much. So we get things like docker, which under the hood does exactly that, plus some union filesystem magic to make it cheaper/faster for registries to store data; essentially a re-implementation of dynamic linking and shared libraries, but for files.
So now we have created an interface (docker) that is easy to adopt, easy to promote and easy to use, but it's hard-wired into Linux (the kernel) and only much later (post-OCI) got some hacked up windows version that is completely different and doesn't work anywhere else (because, well duh, not-windows isn't going to run windows apps). Aside from the fact that it's an OCI artefact, windows containers have very little to do with docker containers as we know them.
Most of this stuff also didn't really come from a need to get containers on windows (or macOS) but from the need to get more 'developer light edition' into the workforce, which can be trained and onboarded faster. If you can get people to ignore the foundation they stand on, they can be put to work in building upwards much sooner. This does of course come to bite everyone in the ass at some point, because if you're standing on top some 'magic' infrastructure and something breaks, it's going to be really hard to fix it. Right now we're all trying to make it redundant enough so we can ignore the breakage, but I doubt this is a winnable race.
Docker is a convenience, not a technical solution to a technical problem.
Is that true? Plenty of people are using multi-arch images (x86 and aarch64) which are essentially the Docker image equivalent of a fat binary. I might be wrong, but I think what I want are preconfigured macOS binaries packaged up a convenient image format with a layered filesystem, networking support, etc. Ideally with an equivalent linux image such that I can later switch the OS specifier and get an image containing an equivalent linux binary to run on linux.
I am for example quite happy to run a macOS native version of Postgres. But that doesn't give me the easy disposable database for testing that a docker-compose setup gives me. If I could specify that I want the "postgres" docker image in my docker-compose file, and running that file on macOS ran a macOS version of postgres in a macOS-native container then I'd be very happy.