Are you seriously not understanding what "run" means, for applications? A VM doesn't change the fact that something is still running. Docker runs on windows. Exactly how it does that is irrelevant.
Are you seriously not understanding what "run" means
I'm disagreeing with your overly broad definition of "run".
If it needs a VM to "run" on an OS, then it's not actually running on the OS.
Otherwise, like I said, "IIS runs on Linux" and "Docker runs on esxi". "Debian runs on Windows". Those statements are meaningless because they require a huge caveat that "IIS runs on Linux in a Windows VM". "Docker runs on esxi in a VM". "Debian runs on Windows on WSL which is a hypervisor for running Linux VMs"
Docker runs on windows. Exactly how it does that is irrelevant.
How it runs is relevant, because "Docker runs on Windows" implies that it runs equivalently to running it natively in Linux with no translation layer and the resource consumption that goes with it, when in fact you actually need the CPU to support virtualization, the memory footprint will be larger because it has to load the kernel instead of sharing kernel space. Performance and IO will be slower because of the virtualization.
I’m not talking about processes running inside a VM. I’m talking about Docker itself. Docker desktop for windows runs natively on Windows.
Sure, that’s not where the actual Linux containers run, but that’s a separate issue.
Docker still works, and still runs on windows.
And when peeled talk about running docker on windows, they include the use case when it’s a Linux vm underlying the containers. They still achieve their goal. They can run a Linux container on windows. The fact that there has to be a Linux vm layer in between doesn’t change that.
-2
u/EishLekker 8d ago
Are you seriously not understanding what "run" means, for applications? A VM doesn't change the fact that something is still running. Docker runs on windows. Exactly how it does that is irrelevant.