Cloud Hosting

With Windows 2004 in the final run-up to launch, what's happening to Microsoft's Linux tools?

It's been a while since Microsoft unveiled the re-architecture of its Windows Subsystem for Linux (WSL) at its Build conference. Since then it's been tested as part of the 20H1 series of Insider previews and will launch as part of Windows 10's next major update, which will be called Windows 2004.

That update is now close to feature complete, with only bug fixes expected between now and its likely April launch date. The long delay between completion and launch is part of Microsoft's new approach to Windows 10 updates, giving it longer in the Slow and Release Preview rings to identify and fix bugs and issues. That provides an opportunity to experiment with WSL 2 and look at how it will fit into your toolchain.

There's a big change at the heart of WSL 2. Instead of using a translation layer to convert Linux kernel calls into Windows calls, WSL 2 now offers its own isolated Linux kernel running on a thin version of the Hyper-V hypervisor. The WSL 2 hypervisor is similar to that used by the Windows Sandbox, letting Windows and Linux share the same timers to avoid one OS dominating the other. That allows Linux files to be hosted in a virtual disk with a Linux native ext4 file system using the 9p protocol for interactions between Windows and Linux.

It's important to note that using WSL 2 and the Windows hypervisor platform can affect using other virtualisation tools with Windows. Make sure you have one that can work with Hyper-V before you switch to WSL 2.

You're not getting the latest and greatest Linux kernel with WSL 2. Microsoft has made the decision to base it on the Kernel.org long-term support releases. Initially that means using Linux 4.19, with plans to rebase on new releases as they enter LTS. Microsoft has made its own modifications, keeping memory use to a minimum and only supporting specific devices. You shouldn't expect Microsoft to add additional device support -- it's not building a Linux desktop, only providing a way of running Linux binaries in Windows with a focus on developers building applications for cloud-hosted Linux systems.

With a WSL 2 install the virtual disk is initially limited to 256GB. If you need more space, you have to use Windows' DiskPart tool to resize the VHD manually. Once the disk has been resized, you then need to use Linux's filesystem tools to resize its file system. In practice, 256GB should be enough for most purposes -- especially if you're passing files to and from Windows, and using Windows tools alongside Linux.

Running in a thin hypervisor gives WSL 2 some advantages over traditional virtual machines. Microsoft can preload much of the OS in memory before starting up, giving it a very fast boot time. The intent is to give WSL 2 the feel of an integrated Windows command-line application, and by booting quickly it's possible to go from startup to working in only a few seconds.

WSL 2, here running Ubuntu 18.04.3 on Windows 10, now uses an isolated Linux kernel running on a thin version of Hyper-V.

Image: Simon Bisson/TechRepublic

Microsoft has significantly extended the utility of the underlying WSL management tooling by adding more features to the wsl command that manages the WSL service, bringing in commands that were previously part of wslconfig. You can now use it to switch a distribution downloaded from the Windows Store between WSL 1 and WSL 2, as well as defining which is the default WSL distribution. There's no change to the wsl.conf files used to manage WSL 1 installs, so you can use the same configuration files to mount drives and setup network configurations.

SEE:Windows 10: A cheat sheet(TechRepublic)

Moving from a translation layer to a virtual machine does affect how WSL 2 works with networking, and that can disrupt using tools like X410 for X-based graphical applications. Currently shared loopback addresses are only shared one way, from Windows to WSL. Internally WSL has its own IP address, and if you're configuring X you need a script to automatically set the DISPLAY environment variable before launching any X application in WSL 2.

Microsoft's new Terminal is another part of the WSL 2 story. It's a big update on the old Windows command-line experience, with support for it, for PowerShell, for Azure's Cloud Shell, and for all your WSL installs, both WSL 1 and WSL 2. Reworking the Windows Terminal adds support for console text effects, so you can use more Linux applications without worrying about display compatibility. Some features, like graphical backgrounds, show how customisable the Terminal is, while others, like the ability to split terminals into multiple panes, add features that mimic classic Unix features.

The Windows Terminal brings a new monospaced console font to Windows, Cascadia Code. It's an important update to the original Windows terminal fonts, making consoles easy on the eye. While not yet the default, it's actually well worth switching your terminal configurations to use the new font. Cascadia is installed alongside the Windows Terminal, although if you want to manage your own installs you can find the font on GitHub.

One important development has been the release of remote editing for Visual Studio Code, available in both WSL 1 and WSL 2. Using the WSL release of Ubuntu, type 'code' to launch Visual Studio Code. The first time you do this it'll download the server components into your WSL install. Now when you need to edit a file in WSL all you need to do is type 'code ' and it will open in a Windows-hosted Visual Studio Code window, saving automatically into WSL. Remoting into WSL from Windows allows you to use compilers and debuggers inside Linux, keeping your code where it belongs.

If you're using the new Docker Desktop tools with WSL 2, you can use this integration to work directly with your Linux containers from the Windows desktop. While it's still very much in beta, Docker Desktop shows promise, if only to indicate that enterprise software platforms are looking very closely at WSL, and at the benefits of a hybrid operating system.

Microsoft's switch to hosting WSL on Hyper-V is a step forward; it allows it to quickly support changes to the Linux kernel without having to modify its Windows integration layer and offering complete API support to Linux binaries. The result is an effective hybrid of the two operating systems, especially once you get WSL 2 working with X. But don't expect it to be a complete Linux desktop for every user: WSL remains targeted at developers who want to bring existing macOS- and Linux-based UNIX toolchains to Windows to build containers for cloud-native applications.

Be your company's Microsoft insider with the help of these Windows and Office tutorials and our experts' analyses of Microsoft's enterprise products. Delivered Mondays and Wednesdays

More:
WSL 2: Where is it, and where is it going? - TechRepublic