The wording gives an Apache license only to MinIO, not to people who use it. So MinIO can relicense the the contributor code under a commercially viable license, but no one else can. Everyone else will only have access to the contribution under AGPL as part of the whole project.

GPU access. Actual graphics use is so so, but essential for doing CUDA/AI stuff

Faster file system access on the Linux side (for Linux compiles etc). Ironically, accessing Windows filesystem is slower than WSL1.

Better Linux compatibility.

Vs a Linux VM:

GPU access!

Easier testing for localhost stuff, Linux ports get autoforwarded to Windows (if your test http server is running in WSL2 at port 8080, you can browse to http://localhost:8080 in your Windows browser)

Easy Windows filesystem interaction. Windows local drives show up in /mnt automatically.

Mix Windows commands with Linux commands. I use this for example to pipe strings.exe, which is UTF-16 aware, with Linux text utils.

I think WSL2 tends to be better at sharing memory (releasing unused memory) with the rest of the system than a dedicated VM.

You can mimic some of this stuff to a degree with a VM, but the built in convenience facetor can't be overlooked, and if you are doing CUDA stuff there isn't a good alternative that I am aware of. You could do PCI passthrough using datacenter class GPUs and Windows Server, but $$$.

Interestingly both had a relationship to a NLS in there lives.

For Andrew, it was Non-Linear Systems, where Andrew invented the digital voltmeter.

For Alan, it was oN-Line System, where he attended "The Mother of All Demos", which spawned the mouse and some other inventions used in the Xerox Alto, which is where Smalltalk was primarily developed initially.

Where?

They might both cover ~70M, but the NHS population has a median age of ~41, for Medicare it's ~71. The US health system is expensive, but NHS vs Medicare cost is not really a valid comparison with such drastically different demographics.

For me the reason for the distinction between hardware virtualization and emulation based virtualization is the differences in suitability based on instance creation cost, and instruction performance, and as you mention security.

My usage was just an attempt to explain why I saw a distinction, not to pedantically define any of the terms. My apologies if you felt I used them incorrectly.

A hypervisor VM typically requires more extensive setup involving hardware configuration and is usually used for running existing native code, so it often means emulating a real machine, including OS and sometimes even firmware/BIOS. There are "lightweight" environments like Firecracker, but the overhead of creating an instance is still heaver than the overhead of a function call. The instance creation overhead is high, but the instruction performance can be close to native. Microsecond VM creation is notable given the typical instance creation overhead in this case.

A emulator VM for a sandbox typically will just be a software CPU emulator with some level of OS emulation. The instance creation overhead is setting up a data structure and issuing a function call to "run" the CPU emulator. The instruction performance is generally much slower than executing native code. Microsecond VM creation is not very notable in this case.

If your running a long running process the hypervisor approach is usually superior. If your running a very short lived process (for instance a VM per http request), the emulator approach may work better.

There is also the container approach like Docker which is somewhat in between in overhead and can run at native speed on bare metal. The OS virtualization GVisor approach of capturing syscalls.

Staring emphermial hypervisor VMs quickly is more noteworthy (since they are often slow to start) than an emulator VM where it's expected to be fast since it's usually not much more than setting up a datastructure and executing a call to an interpreter. I clicked hoping for the former, only to find out the project is the latter.