
Bash on Windows Is Becoming Microsoft's Linux - happy-go-lucky
http://www.infoworld.com/article/3155994/microsoft-windows/bash-on-windows-is-becoming-microsofts-linux.html
======
antics
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.

~~~
bcantrill
I'm the CTO at Joyent; totally agreed on all points (especially that we in
SmartOS have it easier by being Unix), but I would also be curious about the
stuff that you found not to work on LX: some stuff we know about (e.g., things
that depend on Linux subsystems for which we don't have complete
implementation like namespaces -- or on Linux kernel subsystems that we will
never implement like eBPF or btrfs), but if you can provide any detail on what
didn't work for you, we'd appreciate the opportunity to fix it. Over the past
two years, we have made considerable strides in making LX a first-class
interface to the system (and virtually all system calls are in-kernel now),
and we've gotten to the point where it's amazingly good -- but we know that
there's still a last (rocky!) mile to conquer.

------
serge2k
That's gonna be kind of hard if it doesn't actually use Linux.

