Yesterday, I sat in a coffeeshop and installed two Linux distributions on my Windows development PC. They weren’t virtual machines or dual-boot systems, and I didn’t have to go through the usual route of finding download pages and uncompressing installer files. Instead, I went to the Windows Store, searched for Linux, picked the distros I wanted, and clicked Install for each. Once they’d downloaded, all I needed to do was open a terminal window and add a username and password; I was ready to go.
It was all possible because I’m running the latest preview build of the upcoming Windows 10 Fall Creators Update, which has added new features to the Windows Subsystem for Linux (WSL). Introduced in the Windows 10 Anniversary Update (version 1609) and significantly updated in the recently released Windows 10 Creators Update (version 1703), WSL is part of Microsoft’s answer to the question “How do we get developers using Windows again?”
How Microsoft got Windows to where the developers are
The answer to the “How do we get developers using Windows again?” question was simple: Go to where the developers are.
But getting Windows to that answer was not as simple. Where developers were was on MacOS and Linux, using command-line tools to work on Linux servers in the cloud. They already had their tool chains, applications, and scripts that worked with services like Docker, GitHub, Jenkins, Ansible, Chef, and TravisCI. So how to bring those developers to Windows?
The first step was to bring Unix to the familiar Windows desktop in a seamless way. MacOS had an intrinsic advantage for Unix users, because it’s built on a microkernel implementation of BSD Unix, accessed via the Terminal app on every Mac.
But Windows’s NT kernel has a heritage that goes another direction, back to DEC, with a history of being able to run multiple personalities. Instead of having to build new versions of familiar tools, then recompiling them for Windows, why not run Linux binaries on Windows directly? Using the work in Project Astoria that had been done to deliver a cancelled Android compatibility layer for Windows Phone and Windows 10’s pico-process model, Microsoft could deliver a new OS subsystem that can translate Linux system calls to Windows, allowing code to run without any changes.
An initial release in partnership with Ubuntu offered a Bash shell running in Windows’s familiar terminal (as used by both cmd and PowerShell). The first test builds for Windows Insiders were, unsurprisingly, limited, but as the Windows 10 Anniversary Update got nearer release they quickly improved, allowing complex console applications to run, with support for Ubuntu’s apt-get installer for quick access to a library of tools and services. With the Creators Update, Microsoft and Canonical were able to move WSL to Ubuntu’s most recent long-term support release, version 16.04.
WSL: Linux binaries in a Linux console
Technically, WSL is for console-only applications, providing shell support for developer tools and remote access to Linux servers running on-premises and in the public cloud. But it’s turned out to be a lot more flexible, and although this is not officially supported, users have installed and run X-based GUI applications, using Windows X Servers to bring a full Linux desktop experience to WSL.
Working with any of the WSL personalities is like working with native Linux. You’ve got access to a shell, and through it the command line. Installing applications is as simple as using apt-get on Ubuntu or yast and zypper on Suse. When Fedora makes its way to Windows, you’ll use yum.
Early WSL builds had problems running some applications, because the key dependencies weren’t supported. But since the Windows 10 Anniversary Update release, it’s been a lot easier, and now even complex packages like Docker install and run.
That, of course, is what WSL should be all about: getting the tools you need to do cross-platform development and management on your PC.
With native Linux containers coming to Windows Server later this year, WSL will become increasingly important as a key component of your enterprise systems tool set. In fact, you should already be installing it on your development and operations Windows PCs as a matter of course. (WSL on Windows Server won’t support large-scale Linux workloads or servers, but it will give you a direct management connection to hosted Linux containers, supporting existing management scripts and tools.)
How to integrate the Linux and Windows tool chains
Microsoft has made it easy to go from WSL to Windows and vice versa. You can call Linux binaries from the Windows command line, using the WSL default user. You can call Windows binaries from Bash (and there’s access to Bash from the terminal inside Visual Studio Code, letting you test Unix code without leaving your development tools and without leaving Windows).
Tip: WSL does treat Windows directories as a mounted file system, so you may want to set up symlinks to commonly used files or add the Windows program files directories to your Bash path.
It’s good to see tools like Visual Studio Code supporting WSL. If Microsoft is to succeed at bringing its platform to where the developers are, its tools need to work with Windows’s Linux personality directly, offering a hybrid way of working that brings the best of Windows and Linux together. It’s easy to imagine a future release of the full Visual Studio hosting Linux terminals and calling out to webhooks and other APIs on services running inside WSL.
WSL is expanding the Linux distros that Windows runs
A promised expansion of the Windows Subsystem for Linux recently took a new step forward, with the release of two new Linux distributions to run alongside the existing Ubuntu release: OpenSuse and Suse Enterprise Server. Both Suse releases are in the Windows Store, available for users in the Insider program.
Adding more variants of Linux is a good thing; not everyone likes how Ubuntu does things. With Suse and, soon, Fedora joining WSL, there’s scope for you to use the Linux tools, services, and ways of working you’re familiar with, bringing scripts and binaries over from existing tool chains to Windows PCs. WSL even can host several Linux personalities at once, each in a separate terminal.
Supporting many different Linux distributions makes a lot of sense. Over the last few years, different vendors and teams have focused on different use cases, building different platforms from the same virtual kit of parts. Older distributions like Fedora and Ubuntu are very much general-purpose operating systems, and using them makes sense from a developer perspective. Where things will get interesting is if in future WSL supports more specialized releases, like the container-focused CoreOS.