This article was originally published in my blog.
Microsoft made big announcements during its last Microsoft Build. A lot of new and exciting products for developers have been announced. While the main focus of the people was centered on the new windows terminal, a terminal with a lot of long awaited enhancements and the new VS Code features, what held my attention was the improvements on the Windows Subsystem for Linux or what was called the WSL 2.0.
Why should you get excited about WSL 2.0
WSL 1.0 was amazing
While I was doing my whole development work on Linux, mainly Xubuntu and Arch, I had to always install it along side of windows, since Linux didn't support a lot of the tools I was using on nearly a daily basis (Specially games). But upon discovering WSL, everything changed, I suddenly found myself able to migrate my development work completely to windows, except for some system development with C, and living inside CMD (I have tried a lot windows terminal emulator, but I always found CMD to be the best one, any suggestions ?).
WSL 1.0, besides some of it's limitations, like not being able to install a lot of Linux applications or it's very slow speed, was quite successful at delivering the promise it gave us; A Linux development environment on Windows.
Where WSL 2.0 will make it better
The Big problem of WSL 1.0
The biggest complain about WSL 1.0 was its slow speed, some commands took ages to complete, when they should have needed few seconds. This was due to the compatibility layer that WSL 1.0 was introducing, a layer whose role was to primarily translate Linux syscalls into Windows syscalls, so it didn't find a use to having a Linux kernel.
WSL 2.0 solution
The solution is quite simple and obvious, shipping a linux kernel directly into Windows and let it do the work. That's the engineering feat that the WSL team was formidably successful at accomplishing. So now the programs run as if they were running on the Linux kernel, because they finally do. This will enable a lot of the tools that wouldn't be able to run using the compatibility layer to run, and most notably Docker.
How does it work
The Linux kernel runs in a very lightweight virtual machine, and all of your WSL instances will run on top of it. This has an incredible impact on the performance of WSL. Since only a single instance of the virtual machine with the kernel is running, having a lot of instances of WSL won't result in a huge performance drop, a feature accentuated by the really lightweight nature of the VM containing the kernel.
Adding to this, the WSL team dropped the usage of the weird compatibility layer they were using for files, and instead use native Linux filesystems directly in WSL, that way the filesystem performance are significantly enhanced.
This doesn't mean that you would not be able to access your files on windows directly or vice versa, they are using a network protocol to share files across Linux and Windows. It's the method that uses Vagrant to have access to some part of your host filesystem in the guest by using Samba for example, but this time with WSL 2.0, you have access in both ways.
Conclusion
With WSL 2.0, Windows give us more of the great experience that it gave the developer community with WSL 1.0. It is an impressive achievement not only because of what it enables Windows users to do, but also because of the incredible engineering feat it represents.
for more information you can check the WSL.
If you are interested in knowing more I invite to you to see the WSL Team keynote.
Top comments (3)
What I find interesting about all this is that in theory, it should give a pretty easy path for Windows to be able to (mostly directly) access pretty much any Linux filesystem with minimal compatibility issues. That in and of itself is huge because Linux has at best shoddy support for NTFS and exFAT, which makes sharing files between Windows and Linux on the same system a bit of a pain.
It will be interesting as well to see how Windows Defender's on-access file scanning interacts with all of this. That by itself was actually a bigger performance hit for me than the VFS compatibility layer was (I've actually tested the VFS performance in WSL with and without Windows Defender enabled, it's a rather startling difference).
Indeed ! I am not sure if Microsoft would want to share the network protocol, the 9P protocol, it uses to access the filesystem, because it will be a game changer (Imagine being able to access files on a ext4 partition directly in Windows with no problems).
However I haven't thought about how Windows Defender would interact with it. It will be interesting to see how it would unfold. The idea of having a cross operating system antivirus looks promising. Do you have any resources on the subject ?
If they're using 9P (which I had not previously realized) it's more a question of whether the transport is user accessible, not whether the protocol is 'shared'. 9P itself is open, and it's remarkably easy to write clients for.
As far as Defender, it would not be unique in any manner as a cross-OS AV system (ClamAV for example already handles both Windows and Linux just fine, it just doesn't have in-built realtime scanning). What I'm more interested in is seeing if they decide to try and shoehorn Defender's on-access scanning into the VFS layer for WSL itself, which would probably translate to a pretty big performance hit.