Windows: my new Linux OS
Unsurprisingly, this article is now outdated. WSL got improved, both in Windows 10 and 11.
WSL 2 enables Linux GUI applications to feel native and natural to use on Windows.
Prerequisites
Original article is available below for reference.
________________________________________
Although Windows Subsystem Linux (WSL) has been available on Windows 10 since 2016, I still see many users using VMWare or VirtualBox just to have a Linux box on Windows.
Let's take a look at what WSL is, how to configure it, how to run terminal and graphics applications on it, and assess its performance.
What is WSL?
The Windows Subsystem for Linux lets developers run a GNU/Linux environment -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a virtual machine. [Source: MS Docs]
Several GNU/Linux distros are available from the Microsoft Store, such as Ubuntu, Kali, SuSE, Alpine, etc. With it, you can run command-line apps, Bash shell scripts, and X11 graphical apps.
WSL provides a close integration with the host operating system: clipboard sharing, access to the host file system, evoking Windows applications from the Bash shell, etc.
About WSL 1
Windows 10 version 2004 released an updated WSL version, called WSL 2, which makes the original WSL being named WSL 1.
WSL 1 is made up of two main parts, the Windows Subsystem for Linux and the Linux Usermode binaries.
The WSL1 interface translates Linux system calls from the binaries into Windows system calls and then executes them at native speed. Linux applications run within the Linux distribution which provides the application's dependencies and package management in a container-like environment. WSL provides an interface to mount drives within WSL.
Using these two systems together, a user is able to run ELF64 Linux binaries within the Windows environment.
About WSL 2
WSL2 was announced at Microsoft Build 2019. WSL2 features a Linux kernel running inside Windows 10 and is built on the core technology of Hyper-V to provide better Linux application support and improved file performance.
Compared to WSL 1, the biggest difference is the presence of a Linux Kernel on Windows. Where WSL 1 required a translation layer between the Linux system calls and the Windows NT kernel, WSL 2 ships with a lightweight VM running a full Linux kernel. This VM runs directly on the Windows Hypervisor layer. This kernel includes full system call compatibility and allows for running apps like Docker and FUSE natively on Linux. With this new implementation, the Linux kernel has full access to the Windows file system.
The full WSL 2 architecture is depicted next.
wsl.exe is the entry point to WSL. It lists the available distributions, which of them are running, etc. It handles all the interactions with the subsystems.
Lxss is the WSL service that keeps track of which distributions are installed or running, etc.
The host compute service is the virtualization technology behind WSL. It creates the lightweight VM with the Linux kernel shipped by Microsoft.
The VM with the Linux Kernel running maps in the Linux distribution file system. Then it launches the Linux app it was commanded to launch (e.g. the Bash shell).
This VM only runs while it is being used. That is if Bash is killed, then the VM is terminated.
With WSL 2, unlike with WSL 1, the files are in different machines. So the 9P protocol server is used to access the files in the host. The 9P server runs on the Windows host and the client runs on Linux guest. This enables the Linux guest to access the files on the Windows host.
To access the files on the Linux guest from the Windows host, a similar strategy is used, in the opposite direction, as illustrated by the next diagram.
A 9P server is used, this time running on the Linux guest, with the 9P client running on the Windows host.
Setup WSL
Microsoft provides detailed instructions to setup WSL. See: Windows Subsystem for Linux Installation Guide for Windows 10. Basically, these steps are required:
领英推荐
After completing the setup, it's possible to run terminal applications. The next picture shows vim running in WSL.
More applications can be installed with the package manager.
X11 setup
To be able to run graphical applications, it is necessary to install the x11-apps on the Linux guest and a X Server on Windows.
Installing x11-apps (example for Ubuntu) :
?sudo apt install x11-apps
Installing a X Server on Windows:
Several X servers are available for Windows. I tried X410 (trial available) and VcXsrv (free). Xming is also available for Windows, but it has issues with sharing the clipboard.
Both X410 and VcXsrv provide similar performance and usability. X410 is managed directly by the Microsoft Store, giving it automatic updates.
The WSL2 architecture uses virtualized network components. This means that WSL2 has a different IP address than the host machine. Therefore, it is required to enable public access on the X Server:
To keep the system closed to unwanted X connections from public access, the IP address range can be restricted to the WSL subnet in the settings of a new rule, under scope 172.16.0.0/12 (details).
Setup Bash environment
To automatically enable the graphical applications to connect to the X server, add the following lines to your ~/.bashrc:
export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0
export LIBGL_ALWAYS_INDIRECT=1
After completion of these steps, you can run graphical applications as shown in the next image.
WSL 2 performance
Microsoft has announced WSL 2 as a big performance boost compared to WSL 1. I ran a few tests to have a rough idea of how WSL 2 compares to a native Windows host and to VMWare Player.
Test 1: Speedometer
Speedometer is a browser benchmark that measures the responsiveness of Web applications. It uses demo web applications to simulate user actions such as adding to-do items. I used it to have an idea of the performance of graphical applications.
The test runs about 24% slower on WSL when compared to its execution directly on the Windows host.
Running the same test on VMware Workstation Player 15.5.6, which already supports hosts with Hyper-V mode, gave a similar performance result as in WSL 2.
Test 2: file access performance
In this test, I copied a 2.4GB zip file and then unzipped it. The average values are given next.
In rough numbers, the WSL file operations take 2 to 3 times longer than in the Windows host. And VMWare file operations take 3 to 4 times longer than in the Windows host.
Remember: WSL is not a VM
That's right. A VM provides full isolation from the host, while WSL is closely integrated. Keep this in mind when using it. If you need the isolation provided by a VM, then WSL is not for you. On the other hand, if you need a Linux box that starts very quickly (~1 second) with access to the host resources, then go for WSL. As an extra, file access appears to have better performance in WSL than in VMWare with VMWare tools.
Typical use case for WSL
A typical use case for WSL is for software development, where part of the development stack is on Linux. Visual Studio Code?has an?extension?available to allow for developing within WSL from VS Code. The?Visual Studio Code Remote?- WSL extension allows for the VS Code UI to run on the Windows side with a VS Code Server running within the WSL VM. This allows for running commands directly within WSL and treating the mounted file system as a Linux file system reducing pathing issues or other cross-OS difficulties.
Additionally, this extension allows for running and debugging applications directly within the Linux including the usage of breakpoints.
References
This article mixes my own materials with contents taken form the following sources: