This is like suggesting that running applications in a Windows VM and running them under WINE isn't a big difference.

(One might say "but it's the same OS!" - but it's only really a similar kernel, and even that is heavily customized and not at all the same as your laptop runs. The graphical stack is also nothing like neither X nor Wayland.)

Also, rant: it's not KVM, but QEMU. KVM is a small API to deal with virtualization instructions, but while that makes VMs much faster than without (similar to how floating point is much faster with hardware support), it does very little on its own. The virtualization instructions are basically a way to let QEMU run code as is but intercept everything important - syscalls, faults, you name it - whereas without, it would have to instrument or outright interpret the executed program.

It's QEMU that micro-manages setup, execution and importantly is responsible for emulating all the VM devices - KVM just exposes memory mapped into the virtual CPU's memory space.

> This is like suggesting that running applications in a Windows VM and running them under WINE isn't a big difference.

False equivalence. WINE reimplements windows libraries and higher level APIs to convert to Linux-native ASAP.

Waydroid/containers operate at a kernel level. The entire userspace is "virtualized".

> One might say "but it's the same OS!" - but it's only really a similar kernel, and even that is heavily customized and not at all the same as your laptop runs.

Exactly my point. The only difference is whether or not the kernel is shared, which is a very, very small fraction of the OS.

WINE reimplements windows libraries and higher level APIs to convert them to something compatible with your host kernel, providing as full a glue Windows user-space as needed to support Windows user-space applications integrating into your host system. This includes a full, Windows-centric emulated filesystem hierarchy.

Waydroid reimplements Android libraries and higher level APIs to convert them to something compatible with your host kernel, providing as full a glue Android user-space as need to support Android user-space applications integrating into your host system (such as by providing a Wayland-backed implementation of SurfaceFlinger or HWComposer). This includes a full, Android-centric emulated filesystem hieararchy.

They are equivalent, even if their targets are different. And most importantly, they are both the polar opposite of a VM setup, as the user-space is not the user-space of the VM, but a dedicated user-space that presents Windows and Android behaviors respecitvely, but implementing them in terms of your host system's window management, input management, audio management, etc.

(That waydroid relies heavily on namespaces is a technical detail, not a relevant difference between WINE and Waydroid. WINE if implemented again today would likely do the same.)

> Exactly my point. The only difference is whether or not the kernel is shared, which is a very, very small fraction of the OS.

No, the main difference is whether the user-space is deeply integrated through various glue, or whether you're emulating the whole system as-is, with its original user-space and kernel, with just a virtual screen to interact with.

> Waydroid reimplements Android libraries and higher level APIs to convert them to something compatible with your host kernel,

This is simply incorrect, though, negating the entirety of the rest of your argument.

> No, the main difference is whether the user-space is deeply integrated through various glue, or whether you're emulating the whole system as-is

Okay, sure, but then again waydroid and a VM are kissing cousins going off of that definition anyway. Both emulate the whole system. The only difference is whether or not the kernel is replaced.

> That waydroid relies heavily on namespaces is a technical detail, not a relevant difference between WINE and Waydroid. WINE if implemented again today would likely do the same.

No, it wouldn't. WINE does the approach it does to avoid redistribution of any Microsoft binaries. Simply containerizing & emulating the kernel API would be useless for WINE as a result