Well not if you aren't using other parts of Windows :-) but if you are constrained to using Windows for other reasons then the advantage is you get all the tools with a much lighter weight system than say running a virtual machine.

There are also some systems where kernel support for the devices is lagging, either because they are proprietary and poorly documented or because they have insufficient market penetration to get someone interested in writing good driver support. For example support for the pen on the Surface Pro 4 line is really horrible (IMHO) on Linux.

So these devices need real kernel drivers? Windows doesn't provide some kind of emulation through its own drivers? I guess that makes sense although it didn't occur to me.

If that's true, will those new drivers also work on a regular non-Windows Linux install? That would be really great news, and pretty ironic, if device manufacturers or even Microsoft itself were suddenly writing more/better drivers for the Linux kernel. :-)

The grandparent is saying that if you run plain Ubuntu directly on a device, Ubuntu (or really, the Linux kernel) might not have drivers that work reasonably well for some hardware on that device, while Windows most certainly does have decent drivers for that hardware.

When you run Ubuntu on top of windows, windows replaces/emulates the Linux kernel - at least the part it needs to run the subset of Ubuntu that windows currently can - this emulation provided to run Ubuntu is done on the interface between the kernel and userspace, it is not done on a device/driver level.

Drivers are OS specific, the drivers in question here are either windows drivers, which works only on windows, or they are linux drivers which work only on linux. (Noone is writing drivers for windows which could also work on linux)

It's not an emulator. The NT kernel really does support the necessary system calls.

Sure, but there's a layer that emulates the linux syscalls. Though perhaps it's more appropriate to call it "translates" instead of emulate.

Its not a layer on top of the NT system call infrastructure. Its brand new NT system calls that do exactly what the equivalent Linux ones do. There is no combination of win32 NT system calls that will get you the behavior of fork().

Aren't the NT system calls also just a personality module above the actual NT kernel? The kernel was originally designed to provide multiple kinds of user spaces so that it could run OS/2 programs alongside Win32 ones.

No. win32 is a personality, the underlying ntdll calls are not part of that.

Of course not! It's quite the opposite. With more and more people ditching 'real' Linux for WSL (which is a 'Linux kernel API layer' for the Windows kernel, there is actually NO Linux kernel involved), support for the relevant hardware is never going to happen in Linux proper.

The big advantage is that it runs within Windows, so you can use your Windows and Linux tools at the same time. It's also not done as a virtual machine, so the Ubuntu running on Windows can access and manipulate files on your Windows system very easily.

Albeit very slowly. Unless they fixed it recently, writing to a vast amount of files is very slow compared to native Linux. Anyone who has cloned a large repository I'm sure is aware of this.

I felt like file speed sped up quite a bit in the Fall Creators Update, though of course that notion is entirely anecdotal.

Also, the native Windows git is still your best bet for git operations. That's one of the cases where I will have a PowerShell and an Ubuntu bash window side-by-side, working in the same /mnt/d/... | D:\... directory. git operations in PowerShell and Jekyll (or whatever) operations in Ubuntu bash.

Does it make a difference if you run your git operations through cmd from the bash command line? If so, is there a simple way to automatically get the current windows path from pwd? If it's the same speed as native git running in a separate window (I think it should be), it might be worth coming up with some kind of script to do this automatically. Not sure how to get that working with using Linux tools within git, though (editing commit messages, diffing, etc). Also, how does file speed within the Linux environment (/home/username) compare to that outside (/mnt/C/whatever)?

Also, they _really_ chose a poor name for that executable; it should have been wsl.exe or some such, not bash.exe. At least lxss.exe isn't already in use by other software in my path...

We just released a tool to do the right path translation -- wslpath. Unfortunately we haven't added built in usage info yet. Here's a link[1] to usage info in recent Windows Insider flights.

Also, totally fair feedback about the naming. In FCU, we added wsl.exe in addition to bash.exe. It launches into your default shell rather than /bin/bash.

[1] https://github.com/Microsoft/WSL/issues/2715

* I work at Microsoft on WSL

I hadn't thought about that (I use PowerShell for most tasks so that is still my "home" shell and it's bash that's the rare one), but I half remembered something to that effect, so I went to the docs:

https://docs.microsoft.com/en-us/windows/wsl/interop

Calling Windows EXEs from bash will automatically retain the current working directory under /mnt/c/*, so it should just work out of the box. Looks like you might be able to get away with just adding native Windows git to your bash path.

Yeah for example I have composer only installed in Windows (EXE) and not within WSL and it works fine within the bash prompt.

That you can keep using Windows seamlessly?