I'm a bit of a WSL fanboy, but this is the right advice if you're not a windows user normally.

When it works, it's great, but some things just don't work and you're stuck.

I've found the WSL devs to be fairly responsive, but not to everything.

However, I've found open source projects to be pretty responsive to bug reports of their projects running on WSL; it's far easier for them to support that than support a native windows build.

There are often workarounds for issues, but their coverage is certainly not where we would all like it to be yet.

For the good of the world, I hope no one except Windows has to deal with WSL specific code. When programs start to have to include WSL specific code, the 'extend' part of EEE has begun. While it would be foolish to believe a few programs here and there including support for WSL means doom, it is certainly not the right direction.

Usually it's issues with assumptions about the completeness of the platform; e.g. ZeroMQ assumes that if it's on a UNIX-ey platform it should use UNIX sockets rather than TCP and doesn't check to see if it's actually supported.

I'm not very familiar with OSX, but I'd be surprised if there weren't differences between it and mainline Linux that needed special care and I see this as similar.

To be honest Microsoft has a habit of layering on functionality on top of existing functionality in a piece meal approach so that you end up with a solution which is 75% compatible with the standards but not quite.

Despite being a software company (or because of it), I think innovating on the internals of Windows and its APIs and cleaning house on the software front will be the real challenge for them - making incredibly beautiful hardware might prove to be the easy part!

what you are saying may be true for now, but Microsoft is really trying to achieve 100% userspace compatibility, ( they set the line clear it is about user space programs ).

I couldn't cross compile simple toy kernel (xv6) in OS X (because I needed to have i386-elf-gcc, which need to compile whole binutils , which really cumbersome, and brew doesn't support it -as far as I looked into it ) but in BashOnWindows , it just works, it maybe a little slow (specially file system operations) but it works like charm. I actually tried to compile linux kernel and running it on qemu, It worked, but compilation (which is a lot of file system operation) was so slow it hadn't worth it.

Nadella (MS CEO) aimed perfectly, instead of introducing some limited amount of support for linux apps, his company tries to port whole ubuntu user space. After this project matures enough, rest assured, it will be equivalent of using linux workstation (which is dream of most developers).

> Microsoft is really trying to achieve 100% userspace compatibility

> After this project matures enough, rest assured, it will be equivalent of using linux workstation

Didn't Microsoft say WSL wouldn't support graphical apps? That's a big portion of userspace; and without that, it simply can't be a linux workstation

The biggest issue I have had with their subsystem is that of the file system (NTFS). The fact that I can't have long paths and can't soft link seem ridiculous.

NTFS has a functional equivalent to soft links in the form of reparse points, although I don't know to what degree that feature is exposed in the UI, if at all. Last time I looked into it (admittedly, years ago) they could only be created via the command line. Not sure what you mean by "can't have long paths" though, NTFS allows you to programmatically create paths up to 32,767 code points long:

https://msdn.microsoft.com/en-us/library/aa365247.aspx

Windows seems to have a certain hard limit on file path characters (a max of 160) which they seem to have recently removed [0] - So while my point is technically moot it's not enabled by default.

As for soft links, a lot of linux tools create soft links (ln -s from to) and generally that fails on NTFS (I tried installing a bunch of npm modules and all had this specific issue)[1].

[0] - https://mspoweruser.com/ntfs-260-character-windows-10/

[1] - https://stackoverflow.com/questions/8232778/nodejs-npm-insta...

It's a max of 260, and it's a Win32 subsystem limitation, not the limitation of NT OS or NTFS file system - and even in Win32 there are escape hatches for it, it's just that you need to know of them and use them explicitly to get such support.

With respect to symlinks - NTFS supports them, but there are subtle semantic differences with POSIX. WSL does actually support symlinks (i.e. you can do ln -s), it's various other behavior around them that breaks, like trying to untar a file that contains symlinks.

The team said that they're working on a custom implementation of symlinks that would provide proper behavior (but wouldn't be seen as a symlink from Win32).

I think the problem here is that Linux NTFS drivers are all a pile of reverse-engineered hacks, so obscure features are overlooked or not fully implemented.

Now, Microsoft should be in a position to put something better into their WSL, but that might entail the risk that someone else will hack that implementation and provide good drivers for everyone, something they clearly don't want (or they would have provided open specs for NTFS support by now).

Correct me if I'm wrong, but you should be able to loopback-mount a "proper" file system (e.g. ext4) from a file on NTFS, and then you'll have no limits other than what ext4 imposes. Of course, you then lose easy interop with the filesystem from Windows side, but that is the inherent trade-off here.

WSL doesn't actually run a Linux kernel; it emulates the syscalls and process environment Linux offers and provides a binary loader. It's WINE in reverse.

So there's no ext4 driver, and no concept of loopback mounts.

Ah, indeed (although it's not quite WINE in reverse, since WINE emulates userspace calls, not kernel syscalls).

I see that there's considerable demand for this exact thing in their bug tracker already. If they go for a low-hanging fruit here, it'd be FUSE support - and that should give us ext2, at least.

>> I discovered a whole bunch of unimplemented features that prevented this.

I'd be very interested in a blog post about your problems and I don't think I'm alone.