Comparing subsystems WSL 1 and WSL 2. Should I switch?

In this post in the style of "thinking out loud" the author would like to compare WSL of the first and second versions, since there is experience of communication.

WSL 1 vs WSL 2, which made me happy

MSDN source

1. Using a real Linux kernel

The inclusion of a real Linux kernel has increased file system IO and system calls. 

A specially optimized Linux kernel makes WSL 2 seem to be faster than WSL 1. 

In some tasks, according to Microsoft measurements , such as unpacking archives, WSL 2 was 20 times faster than WSL 1, and about 5 times faster when using Git clone and npm install.

You can spend your time looking at benchmarks here and here .

2. Native docker support.

In principle, such an opportunity appeared only with WSL 2.



The joy ended there.

WSL 1 vs WSL 2, which did not please

Let's start with the newest crutches from Microsoft and the kind of innovation that upset me personally.

The first version of WSL did not use a real Linux kernel, nor did virtualization. WSL was a bit like Wine, but not quite.



Some special layer was used there to translate calls from Linux programs into this shell.

This, of course, slowed everything down, but it also had advantages.



For example, all programs that ran on WSL 1 were visible in the task manager, these tasks could be prioritized and given specific kernels for execution.







Also, all processes of the first version of WSL were visible to antiviruses, they could be allowed or denied access to folders, just like regular programs for Windows.







With the advent of WSL 2, specific processes in this virtual machine are no longer visible, and the ability to write protection to folders has also disappeared. WSL 2 has file system access bypassing Windows Defender. What specific vulnerabilities this will bring in the future - we'll see. But WSL 2 may well become an attack vector for encrypting the entire disk.







Networking also changed slightly in WSL 2. The first version of WSL had a very strange implementation of the network stack, it hung on a network that Windows itself used, moreover, the WSL listening ports could be checked in Netstat and closed with a regular Windows Firewall.







Now, in WSL 2 there is a separate switch specifically for WSL, because now it's a separate virtual machine, sheer boredom.

Benchmarks

WSL made it possible to use commands from WSL directly in Windows. Including in PowerShell.

Using divine Powershell, the author made measurements of his favorite WSL programs, which he himself most often uses.



All benchmarks used Ubuntu 18.04 LTS for WSL1 and WSL2.

Jekyll

Site generation. One pass:



WSL1





WSL2





As you can see, WSL2 is much inferior to WSL1 when building a site using Jekyll. 1.5 seconds versus 9.6. The result is in favor of WSL1. Interestingly, WSL1 always required Sudo for write access and did not want to generate without root.

Call speed

Here we test the speed of calling the shell and executing one simple command.

Measure-Command {
    [int]$i
    do {
        $i++
        wsl.exe -e 'uname'
       
    } until ($i -eq 20)
}

WSL1





WSL2





WSl2 loads a little slower. This is completely imperceptible, since the result of 20 launches is taken.

Git init and Mkdir

Now let's beat Git init and Mkdir. Create a folder with Mkdir and do Git init inside that folder using WSL.



The code:

Measure-Command {
    [int]$i
    do {
        Set-Location "C:\Users\user\Desktop\TestFolder"
        $i++
        $Foldername = Get-Random
 
        wsl.exe ''mkdir $Foldername''
        Set-Location $Foldername
        wsl.exe ''git init''
       
    } until ($i -eq 20)
}

WSL1





WSL2





The results are identical.

WSL vs. other crutches

So why choose WSL?



WSL 2 still retains the ability to use Linux commands directly from Windows. It is convenient to invoke Bash directly from the explorer line.



And of course, WSL uses the default OS environment you supplied, you don't have to use Mingw's loathsome Vim if you're used to working with human editors.



Why is it better to bypass WSL.



Libnotify, in WSL1, as well as / proc / sys / fs, are completely absent in WSL1, as mentioned above, the first version does not use the same Linux kernel and WSL 2 had to fix this jamb.



All these libraries appeared in WSL 2, now it all works on the hypervisor, but the problems have not diminished. Automatic generation when a new file is created and sometimes even when the old one is changed does not work.



Fans of NPM and other things, this is all for now, can bypass the WSL side, use solutions developed for Windows.

Cool Lay Hack for WSL (͡ ° ͜ʖ ͡ °)

Now let's talk about the only reason to install WSL - Vlmcsd .

Do you want to activate your licensed copy of Windows in a slightly different way solely for the sake of a scientific experiment, but do not want to use strange KMS activators downloaded from the Internet?

Thanks Microsoft, you can use WSL, here's a quick guide.



Link to project Github , link to releases .

Snap on Ubuntu

Install Snap:



sudo apt update

sudo apt install snapd



Install vlmcsd:



sudo snap install vlmcsd



Using ip addr, we check the ip address on which WSL hangs and use it as a KMS server. Here is a link to the project page at snapstore .

vlmcsd and Docket on WSL

The same can be done through Docker itself, or WSL and Docker. Here is a link to the project , I can't explain it better.

From the Windows side:

This is what activating Windows 10 PRO through KMS looks like.



-ipk-W269N the slmgr.vbs WFGWX-YVC9B-4J6C9-T83GX

the slmgr.vbs -skms 192.168.88.166

the slmgr.vbs -ato



This installation method is suitable only for jokes, because WSL instance will always be turned off as soon as you close its window, as in the by the way, for now, all WSL is only good for jokes and Git.

The author hopes that you are not too bored.