@Ezrem: I take it that you mean mounting network drives? If so, not yet: We're keen to get onto implementing device and network drive mounting, but we've been busy getting more fundamental things working well thus far.
If mounting is important to you, please upvote these (and any other asks) here to help us prioritize:
Linux / open source allows viewing of all bug fixes in said update but Microsoft Updates only summarize as "Fixed stability" or tries to keep it obscure as possible and trying to sneak useless items in, such as telemetry intrusion, into the system. Goodhart's Law; once you measure something, it changes. One should only enable telemetry / tracing if and when it is needed to find an underline issue.
While I hear ya, understand that Windows is a vast, VAST product and detailed feature changes across every aspect of the OS would not only run to hundreds of pages per release, and with releases coming weekly, quickly grow into an unmanageable mountain of data, but it's also interest a relatively small audience.
We do hear you though and I know that more teams are starting to publish increasginly detailed release notes for their areas/features, as, for example, we, the WSL team do.
I have no trust in Microsoft and will no longer bare-metal load the OS if it is needed to perform some task that WINE cannot do. Even all cross-platform programming is done on Linux, while Windows or Mac OS X is just used to compile for their platform OS.
Sorry to hear that, but glad that you have somewhere to be happy and productive. Each unto their own.
BASH has been on Windows for years, Cygwin, and yet strange Linux is more effective development and troubleshooting wise because it allows for using console, SSH, base analytical tools. gdb works in scenarios where Visual Studios Debugger cannot, since it is console and or GUI while not requiring a back-end service to tie remote debugging with debugger. gdb is not just for desktop or server debugging but also for embedded debugging.
I don't think you quite understand what Bash/WSL is: It's not a Win32 port of some of the GNU tools (which msys/Cygwin are), and its not a bash shell, ironically; it's a distro agnostic implementation of the Linux kernel ABI & syscalls, enabling unmodified Linux ELF64 binaries to run natively on Windows. Canonical provide an Ubuntu userland distro and you can clone & build and/or download/apt packages you need to get your stuff done.
A person has full control over their Linux while Microsoft deems what one can or cannot do or one can or cannot disable with Windows. Why run an OS that requires useless features to always be running? How does one strip away Windows to run in just 16 MB RAM, can't but Linux and BSD can! Both can go from Desktop to Server to Embedded, something Windows cannot do.
FWIW, Windows can, and has been stripped back to run on IoT devices, Raspberry Pi's, ATM's, PoS devices, phones & tablets, desktops/laptops, nano-servers, containers, servers and clouds
While Windows may not suit your needs, it satisfies the needs of a very large number of end-users, businesses, and developers.
@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.