4 ms·
WSL1 is an emulation of Linux system calls to allow running Linux tools and software in a special sandbox. It was fast, lightweight and worked well enough to ru
by manigandham 6y ago
WSL1 is an emulation of Linux system calls to allow running Linux tools and software in a special sandbox. It was fast, lightweight and worked well enough to run modern apps but had limited functionality.
WSL2 is a Hyper-V virtual machine that runs actual Linux kernel/distros with some special integrations to allow accessing the filesystem, terminal, docker, and now the GUI.
It's no different than running a Linux VM yourself, but it's installed with a few clicks from the Windows Store and has much better tooling. It's fantastic for building software for Linux while being on Windows. MS has already spent 5 years making the cross-platform .NET Core framework which now runs more on Linux than anywhere else, even in Azure. If you want to build on Linux itself then just boot into Linux, but this is great for Windows becoming a central platform for development, regardless of the final destination for the work.
- easton 6y agoThe VM is different somehow, as it can dynamically free RAM when the rest of the system needs it, whereas normal Hyper-V VMs capture all of the RAM they ever need and never give it back (this was a problem with Docker Desktop, as if I had my browser and Spotify up, it wouldn’t be able to start because it couldn’t reserve enough RAM. Now, since they ship it as a WSL2 distro, it works fine). A similar strategy is used for Windows Sandbox and Defender Application Guard (which run Windows in a proto VM so applications like web browsers can’t access the rest of the system). Interestingly, graphics acceleration also works completely like native (at least to my fairly untrained eye), without assigning a discrete GPU. I think this also happens in WSL2.
- fulafel 6y agoOn the interwebs it says that Hyper-V is supposed to support memory ballooning (since about Windows Server 2012), just like other virtualization platforms. Maybe the Docker software just didn't use it, or maybe it requires a Windows Server license? edit: seems Docker just chose to disable it because they thought it made memory usage unpredictable: https://github.com/docker/for-win/issues/521 https://github.com/docker/for-win/issues/521
- panpanna 6y agoHasn't this been around since 2.6? http://lxr.linux.no/#linux+v2.6.34.1/drivers/virtio/virtio_balloon.c http://lxr.linux.no/#linux+v2.6.34.1/drivers/virtio/virtio_b...
- easton 6y agoIn KVM, yes, not in Windows. I've never had good luck with Hyper-V's dynamic memory management, unless the OS was already completely installed (Windows' installer would fail unless I dedicated the RAM. I remember it working better with Linux unless you needed to PXE boot).
- anaisbetts 6y agoTo elaborate, it is different in that it's a VM that starts faster than many native applications, < 3 sec
- colejohnson66 6y agoCurious: how? Is it just always running in the background suspended, and then woken up when it’s needed?
- developer2 6y agoI've heard WSL2 is different and better than WSL1. However, you say WSL2 is backed by Hyper-V. Which leads me to a very important question: does enabling WSL2 (which now supposedly uses Hyper-V) have the same problem that previously enabling Hyper-V had; namely that all other virtualisation software is incompatible? At my day job, my company hasn't yet released the version of Windows that provides WSL2 (IIRC Microsoft released that in June, and my company takes ~12 months to validate and push out new versions of Windows). Many developers have tried to get away with using Docker for Desktop on Windows, which requires the direct use of Hyper-V unless your version of Windows supports WSL2, in which case Docker for Desktop will use that instead of Hyper-V. Our problem is we have some legacy non-Dockerized apps that require the use of vagrant and VirtualBox (we've failed trying to use vagrant and Hyper-V due to lack of boxes), and VirtualBox is 100% incompatible with Hyper-V. VirtualBox has long "supposedly" been able to function alongside/with Hyper-V, but we have not had a single employee encounter success, out of at least a dozen who have tried. To the point where just disabling Hyper-V from Windows' Optional Features isn't enough to get VirtualBox to work again; it took some searching to discover that you additionally have to prevent the virtualisation stack from even being loaded at boot by running "bcdedit /set hypervisorlaunchtype off" as Administrator. All we want is Docker to run natively on desktop; and yet, we also need to run VirtualBox VM's side-by-side. Because of work-from-home, some employees are "getting away" with running work-related stacks on their personal macOS or Linux machines, which of course have no such limitations. You can run Docker for Desktop and VirtualBox side-by-side on macOS with zero compatibility problems (and you can use NFS for mounts too instead of the buggy and slow-ass vboxfs or cifs/samba). Proving that Windows is, once again, the outsider and shit operating system that can't even do virtualisation properly (seriously, the "exclusive use of virtualisation" that Hyper-V requires is a fucking joke). We have to run vagrant on each developer's machine for the sole purpose of running a Docker daemon within it, or use shared hosting for a hundred developers on a single VM with only a dozen CPU cores, backed by slow network storage instead of SSDs, because that's what a company with multi-million dollar revenues, and thousands of employees, is willing to provide. End of rant. I did have a question initially, which is this: does installing and using WSL2 break other virtualisation layers (VirtualBox and friends) in the same way that enabling Hyper-V to use Docker for Desktop broke such software prior to WSL2 support?
- 6y ago