Quite good and improving regularly. Jupyter finally works right out of the box.
People are right that it's mostly just like a VM, however, a VM which doesn't eat up all your memory and is actually fast since there's no VM layer is actually a pretty nice thing. I run WSL on my laptop with 8GB of RAM, whereas running VMs is something I generally avoid.
They have started improving the integration a little; you can call bash from windows and windows executables from bash, if that's useful to you.
The main questions I have are:
a) Will VS Code support WSL? I don't need to edit the files inside the linux filesystem, but things like running python from an IDE inside WSL don't work atm. I have to treat it like a remote system.
b) Will we ever get OpenGL/CUDA support?
c) Will developers treat WSL as a first class platform the same way they do OSX, so that it's not the end user who has to come up with workarounds?
Having said that, I'm a huge fan and I use it a lot. But I also keep real linux machines around since not everything is handled by WSL.
A) VS code supports WSL in the newer versions of Windows Insider Builds.[1] Support for individual IDEs is now available [2] but will take time for individual IDEs to implement.
B) This is something that we are actively looking at but it is not an easy problem and will take time.[3]
Thanks for the work you're doing, it's pretty exciting! I hope MSFT remains committed to this project.
A) This is only a terminal, which isn't really more useful than opening a WSL window, I want to be able to debug python easily. I don't really know how the python debugging protocol works, so I'm not sure if stdin/out is enough, but even if it is enough there's some glue code missing to make this trivial, I need to have a binary that can take the same arguments as python and translate windows paths to WSL paths. And then the Python VS code tools also have some pretty cool Jupyter/IPython integration; I'm not sure that will just work with an executable that pretends to be python. Would be cool if the people working on VS code bits were thinking about WSL, rather than users having to come up with individual hacks.
2) Cool, I assumed backlog meant "not going to happen", will be great if it gets anywhere. Though I'm also interested in OpenGL for graphics; I wanted to run OpenAI's gym project, but that needed OpenGL for rendering. Not necessarily expecting you to write an X server, but would be cool if you could cooperate with or fund a project like Xming or https://github.com/kpocza/LoWe or something.
I agree with KirinDave. I've been using it since the first insider preview that had it. Back then, most of the workflows I use (mostly frontend development, npm/gulp/webpack/php, that kind of stuff) ran into some sort of problem. Right now, I use Bash for about 90% of my commandline needs, only occasionally reverting to cmd. Bugs are few and far between (though still breaking in a lot of cases, so we're firmly in beta territory yet). In the latest builds it's possible to use windows executables from Bash (for me that's mainly Atom), which has upped my use by a few more percent.
One annoying thing is that PHP's built-in webserver (which is also used by Laravel for it's development server) causes file read errors under WSL. Easy enough to avoid until they fix it though, by setting up Apache in Ubuntu or a local LAMP stack on the Windows side.
It's good, although "beta" is a fair description. Many things work, but there are a few sharp edges. For example, gradle doesn't work well yet, and if you go backwards into lxrun (rather than out via /mnt/c) you run into this bug.
It's surprisingly good for an initial implementation, but it's far from perfect.
I love it; I do Pebble development using it and they have a Linux SDK. The compiler works, all the tools, and even the QEMU Pebble emulator via a Windows X server. The workflow is very seamless.
I do my editing on Windows and compile/test from the command line.
Wrong direction of layering, and thus of limited use imho.
Of the two OSes, the weaker link, security-wise, is definitely Windows 10 rather than Linux. Putting Linux programs under a Windows 10 abstraction layer means that any malware, bugs or "bugs" (remember, this is proprietary software) in Windows 10 have the ability to transparently subvert or surveil the Linux programs.
In this aspect, WSL is just like putting a Linux VM on a Windows host (albeit more performant and convenient, yes).
Evidence? Windows has continuously made improvements in security and there has been a lot of emphasis there in the last ~10 years. If you have some reasoning, I want to see it, because I just can't find any studies/blogs/anything one way or the other.
Also note that this isn't intended as a security feature - it is a convenience to get Linux userland programs on Windows without a resource-hogging VM.
This is a very loose definition of "security" you're using. You implied "malware" and other extra-vendor bad actor software then immediately switched back to policy decision w.r.t. the Microsoft store apps.
While I appreciate you're upset about this issue, what you just did is hard to view as anything short of disingenuous. If you're genuinely trying to hide something from government surveillance then NO simple OS decision will help you since only a few countries in the world allow you to actually say "no" to a court demand for access.
Please don't raft terms together to make your rhetorical device more seamless when it's strictly wrong to say. Security professionals do not define in-app telemetry as malware and this community will not, either. What's more, you even subtly hint open source software is more secure and free from bugs. I've got news for you: sourceless security hole propagation is 20 year old technology invented by open source people to discuss their concerns with the idea that open source means we don't need security audits.
