Hacker News Reader

Comment by jstarks | Hacker News Reader

I'm sorry that we don't provide a way to access the Linux portion of the file system directly from Windows yet. It's annoying, and we are working to improve it.

For many use cases it suffices to symlink a Windows directory (e.g. /mnt/c/Users/myuser) into your WSL $HOME directory somewhere and do your source work, builds, etc. in that path. This breaks down if you need certain features that aren't supported on these files yet (e.g. chmod), though.

I assure you that we find this annoying too and are working toward a better solution.

View on HN

I know this probably goes well beyond the scope of your department but here is my wishlist that would convince me to buy windows:

1. Support for ZFS (and future open source filesystems as they appear)

2. The ability to control every service running, and good honest descriptions of what each service does. The ability to control all the servers my computer is connecting to and a transparent view of the information they are sending

3. Ability to turn off having to use Microsoft Accounts, store, etc. Leave it on by default to make your money but offer a developer version/option.

What do you use now?

win7 & debian. I don't ever plan on going to win10, so my next computer will be full linux.

Shh don't tell them about ZFS. That's FreeBSD's killer feature!

#3 is already available, and always has been. I personally create a non-MS local account when I first install the OS, and then convert it to my MS account to get the features I want from that. I do this to make sure my user account has the name I want it to have.

I think OP was being needlessly rude, it really isn't that painful. And to claim that network filesystems work seemlessly is laughable in my opinion. Though they are right, it does break the continuity a Linux subsystem in Windows could provide.

It blows my mind that Windows engineers are building (and keeping up-to-date) an entire Linux compatible subsystem. That's a huge investment, and a pile of hairy legacy code if the project should ever die.

BlackBerry worked on running Linux binaries on QNX for quite a while before coming out with Android application support in BB10. Microsoft could be looking to do something similar.

WSL was the result of Microsoft looking to run Android apps in Windows Mobile. Eventually they dropped the effort, and rescue it to execute docker containers on Windows.

Network filesystems are not perfect but they sure try very hard in a far more challenging environment than two subsystems on the same machine to give a "unified" access to the filesystem.

Considering that multiple efforts by others[1][2][3][4][5], some of them working alone, have gotten quite far in running Linux binaries on Windows without any of the deep knowledge of Windows internals that Microsoft would have, maybe it's not all that huge of an investment... then again, the edge-cases are the hard part and MS does tend to like overcomplicating things.

[1] https://github.com/wishstudio/flinux

[2] https://cowlark.com/lbw/

[3] https://github.com/hackpascal/line-is-not-emulator

[4] http://wezfurlong.org/blog/2004/jan/linux-on-windows/

[5] https://0xef.wordpress.com/2012/11/17/emulate-linux-system-c...

> For many use cases it suffices to symlink a Windows directory (e.g. /mnt/c/Users/myuser) into your WSL $HOME directory somewhere and do your source work

that's what I'm doing for quite a while now and works well for my workload: fast IDE on Windows 10 for coding, reasonably fast building on WSL side.

sure, file access in WSL is slower that native, but still way faster than any other combination I've tried in the last few years (VM + Shared Folders, VM + SMB, VM + file sync, ...) when lots of files are changed at once, for example when switching between project branches.

Reply on news.ycombinator.com