@Gabriele: We hear you, esp. regarding updates - know that we're on it and that improvements to the update mechanism and UI are on their way and will show up in Win10 Insiders builds first, before being delivered in Win10 Creator Update due spring 2017.
Also note that we're keen to strike a decent balance between providing you THE most productive environment in which to get all your work done, and running a business.
Do PLEASE be sure to share your feedback via the Feedback Hub - it gets routed directly to the teams responsible for each of the features in Windows and is your best way to effect change.
We carefully examined this and many other requests posted to our UserVoice page and decided that just delivering a few of the GNU/*NIX tools wasn't enough - instead, we decided to deliver a genuine Linux-compatible kernel subsystem which could run many, then many more, and one day most *NIX command-line dev tools, to enable developers build and run the tools they need to get their work done.
We're part-way through the process of creating this infrastructure and can already run a great many of the *NIX tools that many developers tell us they need/want. We have more work ahead of us yet before we can support USB devices, mounting of external/networked storage devices, CUDA/GPU support, etc. that many developers are asking us for, but we'll do our best to prioritize this work appropriately.
@buenos:We only support 14.04 in this version. It's HIGHLY recommended that you do NOT upgrade to 16.04 at this time: We simply haven't had time to work on improving our WSL implementation to support the new changes in 16.04 yet.
How did you get fork(2) (or clone(2)) working well enough to support Linux binaries?
By implementing a new "PicoProcess" infrastructure within the Windows kernel that allows us to create secure, lightweight PicoProcesses lightning quick!
So, if you're in a mood to share details, I would like to know how you implemented fork(2) and clone(2) under the NT process model (which, due to CreateProcess(), mandates that no process will ever have access to any state of its parent as an implicit operation), how the memory management works, whether it properly implements shared/copy-on-write pages, the whole works.
Yes, our fork() implements true copy-on-write semantics. You think we'd half-bake this thing? ;)
I'd beg you to open-source the kernel driver that implements the Subsystem for Linux
No plans to do so at this time, but we have hear the frequent request.
I'm sorry that I can't choke down the bitterness, here. Microsoft has ill-served the communities that have wanted to migrate from other platforms for a long time, and it continues to do so. It has dropped technologies and left its developers in the lurch many times over its history, and it continues to do so by abandoning the support of those technologies without open-sourcing them. I wish that I could have the benefits of Windows (like real ACLs on processes instead of relying on POSIX abandoned-draft permissions, or service logins that are sane instead of relying on systemd or its predecessor of init scripts, or a more solid driver architecture) as incremental improvements to what Linux has created thus far
... but I'm too afraid of Microsoft's old "embrace, extend, abandon" approach to ever be fully comfortable with it.
In case you've not noticed, Microsoft today operates almost entirely differently to Microsoft of old, and is run by entirely different people.
So another "Interix" or "Posix for windows services". A bit annoying to see you two pretend like world has never seen this techonology, and apeing over it like it's best thing after sliced bread.
No, this is not like POSIX/Interix/SFU - they didn't run unmodified *NIX binaries - they required apps to be built from source. This is often an issue when one has a system but not all the code or the configuration to build it.
Anyway cool that MS is getting it back. Would be even nicer if they didn't focused on a certain distro, and instead been more generic so that users themslve can configure system more fine grained (for example I prefer Arch :)).
WSL has been built to be distro-agnostic, but we had to start somewhere, so we chose one of the dev community's most popular distro's, Ubuntu. We are open to exploring other distro's in the future, once we've got a really solid base and way to support multiple syscalls abstractions, etc.
Anyway, most of *nix/userspace applications this days exist natively for windows so I see no real advantage to run elf-binaries instead of native windows binaries when those exist. However in some cases where those does not exist being able to run linux binaries might be a positive thing.
We're deliberately focusing on developer scenarios because this is a major pain point: How do you build and test Ruby/node/Java/etc. code and/or packages that depend on Linux binaries and behaviors? And, as you recognize, how do we support Linux tools that aren't available on Windows?
While there are plenty of advantages to enabling your project/library/tool to work well on Windows as well as *NIX, we simply can't expect all *NIX code to be ported to directly support Windows.
POSIX / Interix / SFU required code to be rebuilt locally in order to run. This was a challenge for systems where the source is unavailable and/or no longer builds.
Similarly, Cygwin's tools are compiled to Win32 executables, and so integrates well with the rest of Windows, but often struggles to sufficiently mimic Linux' behavior resulting in many OSS developer tools and projects, particularly those with hard dependencies on Linux behaviors or binaries, failing to work correctly on Windows.
This is where WSL provides value - because WSL natively runs unmodified Linux ELF binaries , within an environment that behaves just like Linux user-mode environment does, many projects that currently fail to build and/or run on Windows, work as expected when run on Bash on WSL.
@Karl Botts:Cygwin is a great toolset that, because the tools are compiled to Win32 executables, integrates well with the rest of Windows.
However, Cygwin often struggles to sufficiently mimic Linux' behavior resulting in many OSS developer tools and projects, particularly those with hard dependencies on Linux behaviors or binaries, failing to work correctly on Windows.
This is where WSL provides value - because WSL runs unmodified Linux ELF binaries natively, within an environment that behaves just like Linux user-mode environment does, many projects that currently fail to build and/or run on Windows, work as expected when run on Bash on WSL.
PowerShell is a fabulously powerful command-line shell and toolset. It is capable of doing things that Bash is just not able to because PowerShell tools and commandlets can exchange collections and graphs of objects rather than serializing text. Also, PowerShell integrates deeply with Windows platforms and technologies, making it a very powerful tool for administering and configuring most things in the Microsoft platform & cloud ecosystem.
While PowerShell's script is a little different from Bash script, it's not a million miles away - learning PowerShell doesn't take long if you already know Bash. PowerShell users often miss some of the capabilities of PowerShell when moving to Bash, however.