I work at Microsoft (though not on the WSL team), and my opinion is that this article (and, in particular, this title) has undesirable and somewhat misleading i

I work at Microsoft (though not on the WSL team), and my opinion is that this article (and, in particular, this title) has undesirable and somewhat misleading implications. It is important, I think, to view this as something closer to a _Linux-flavored development environment_ rather than a stand-in replacement for the Linux kernel, or the OS that sits around the Linux kernel. It is closer to being a much better version of Cygwin or a version of Docker that (e.g.) can access parts of the Windows filesystem than it is to being a stand-alone, full-featured version of Linux that can run Linux executables. This might seem like a trivial distinction until you look at what WSL is not going to be good at. One example, at one extreme, is pretty much anything that depends on gritty systemsy programming, like a database. To understand why, consider how WSL is implemented vs a more traditional type of hardware virtualization that the hypervisor provides. At a high level, the goal of a hypervisor is provide an API that looks mostly like what guest OSs would use if they were interacting directly with the hardware, but in a virtualized setting, so that many guest OSs can run on the same box. The trade off is, a database gets to run on the actual implementation of Linux, which it is optimized for; the downside is, you basically have 2 OSs to go through: the guest OS, and the hypervisor it sits on. WSL is different. Basically it ships the Linux API, which is largely the syscall table. One way to think about it is as a syscall table whose implementation is mapped to very low-level Windows kernel primitives; notably this is different than the Cygwin, which maps Linux syscalls to Windows syscalls. WSL actually starts with a process that has a completely blank memory space, and populates it with largely kernel ABI-compatible memory space, and maps syscalls like `fork` (which are incompatible with the Windows process model) to deep, non-public kernel APIs. Since Linux does not ship libc, this is actually reasonably tractable to do, because the API surface is quite small (comparably). The trade-off of this is that the implementation of WSL's "Linux" is _different_. But systemsy code like databases are optimized for the Linux implementation of the Linux syscall table, which means they will be distinctly less performant on WSL than real Linux. If you want to understand the gap in performance and capabilities, consider that Solaris largely did this with Linux-branded Zones. If you've ever tried to run server stuff on something like Joyent's container cloud, you'll notice that it's great for some things and awful for others. The key here is, Solaris is a POSIX, so the mapping is relatively easy. The Windows team, to their credit, have a problem that is several orders of magnitude harder, and so you should plan for the gap accordingly.