A massive set of changes to the Windows Subsystem for Linux (WSL) was rolled into Windows Insider build 15002, which started shipping to Windows 10 users yesterday.
Microsoft’s plans for WSL remain mainly provisional and experimental, but the company is improving and expanding WSL at the pace of a first-class feature. If this is any hint, Microsoft’s goal is nothing short of making it a credible alternative to other Linux distributions.
[ Give yourself a technology career advantage with InfoWorld's Deep Dive technology reports and Computerworld's career trends reports. GET A 15% DISCOUNT through Jan. 15, 2017: Use code 8TIISZ4Z. ]
But WSL still a ways from being a production environment--as seen in one of the big bugs that slipped into this build.
Construction zone, hard hats required
The most recent version of WSL, called Bash in Windows, rolls up many specific fixes for Bash (a popular Linux command-line interface) to provide “even more compatibility, performance and stability of your favorite Linux tools and technologies.”
Some of the fixes also implement functionality that wasn’t available before to Linux apps in WSL, such as support for kernel memory overcommit and previously omitted network stack options. Other changes enhance integration between WSL and the rest of Windows. For instance, if Windows-side auditing is enabled, any Linux processes created in WSL have their names logged in the audit log.
The most intriguing changes--the ones likely to prove the most complex going forward--involve interactions between both operating systems, like the logging function. If you have a metered network connection on the Windows host, the latest WSL build will not perform scheduled task checking for packages as a way to avoid high bandwidth bills.
Sometimes these interactions aren’t easy to predict, and one major issue in build 15002 is that Ctrl-C in a Bash session no longer works. Microsoft provided an uncommon level of detail for how this bug crept in, saying it had to do with synchronization between the Windows and Bash development teams. The next Insider build should have a fix. But for people doing serious work with Linux command-line apps, not having Ctrl-C is a little like driving a car when only the front brakes work.
Linux inside
The way guest and host OSes interact with each other in a VM system like Hyper-V provides Microsoft with a model for dealing with cross-OS issues in future. But WSL isn’t hosted in a VM--in some respects, it’s more ambitious: It uses an emulated Linux kernel interface that in turn talks directly to the Windows NT kernel. Thus, you could perform certain tasks that would be clunky and difficult in a VM, but it would also be more difficult to turn WSL into a full-blown production environment for Linux users on Windows--which, after all, seems to be the long-term goal.
Speculation has swirled for many years that Microsoft might one day produce its own Linux distribution or purchase one and rebrand it, building in links to Microsoft proprietary software. But with WSL, Microsoft seems to be germinating Linux support from within Windows itself.
Building WSL is potentially a rockier road than a Microsoft-branded Linux, but the payoff could be larger. WSL gives users the ability to be comfortable in the Linux command line, the Windows desktop, and PowerShell all at the same time. And it provides Microsoft with yet another way to capture and keep users on Windows, no matter the workload.
[Addendum: Rich Turner, senior program manager at Microsoft, noted on Twitter that "Bash/WSL is NOT a Microsoft Linux distro: In fact, WSL is designed to be distro-agnostic. We currently run a standard Ubuntu distro, and aim to support other distro's in the future."]
[This article has been amended to provide a better explanation for the way Linux system calls are handled by Windows.]
