Live data from Hacker News

File System Improvements to the Windows Subsystem for Linux

blogs.msdn.microsoft.com

11–20 of 108 posts

Re: File System Improvements to the Windows Subsystem for Linux

#11
post #8

I wonder if they have plans to add other emulation features, most importantly the ability to passthrough USB devices (or even graphic cards?). I don't need or want the Linux graphical interface of my VM, it's pretty much redundant, but I do need to make devices available to the Linux software. Otherwise it's a bit like emulating a microcontroller - sure, Turing says the thing can compute everything, but in a very pra…

Seems like you might be better served with a linux desktop and windows in a VM then. The use case for WSL right now is someone like a web developer. They can develop and debug node apps locally in their native environment.

That only works because they provide emulation for AF_INET, AF_UNIX and AF_NETLINK sockets. It's not an automatic freebie.

Re: File System Improvements to the Windows Subsystem for Linux

#13

Earlier quoted context omitted.

It does seem to work with USB serial devices, but only because those drivers on windows in turn emulate a serial port. So we have the USB driver pretending to be a serial port to Windows pretending to be a TTY to the Linux subsystem. It's a bit silly, but then I imagine TTY is a whole lot easier to emulate (even with all the cruft on that) than a USB chipset.

Tangential, but there was a recent HN article (I think) (that for the life of me I cannot find a link to) that referenced a Microsoft DSL for describing finite state machines that was principally developed to implement MS's USB driver. Closest link I could find (which is not the correct one) is: https://www.microsoft.com/en-us/research/project/model-based...

Perhaps it was this one from 13 days ago, about Prolog and Windows NT network configuration? https://news.ycombinator.com/item?id=14046420

Re: File System Improvements to the Windows Subsystem for Linux

#14
post #3

Does it suffer from similar quirks as Cygwin (.exe suffix removal, symlinks, permissions mapping)? - https://cygwin.com/cygwin-ug-net/using-specialnames.html - https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlin...

Cygwin (64bit) didn't work for me in the latest creators update (actually I think it broke even before that). Now I am trying things using WSL itself, so far it has been a productive move.

File permissions and security descriptors proved to be quite a hassle when removing Cygwin requiring multiple takeown and cacls hacks to remove some of the files.

On the flip side I saved some disk space too.

Re: File System Improvements to the Windows Subsystem for Linux

#15
post #13

Earlier quoted context omitted.

Tangential, but there was a recent HN article (I think) (that for the life of me I cannot find a link to) that referenced a Microsoft DSL for describing finite state machines that was principally developed to implement MS's USB driver. Closest link I could find (which is not the correct one) is: https://www.microsoft.com/en-us/research/project/model-based...

Perhaps it was this one from 13 days ago, about Prolog and Windows NT network configuration? https://news.ycombinator.com/item?id=14046420

No, that wasn't it.

Re: File System Improvements to the Windows Subsystem for Linux

#16
post #10

I was going to make another comment, but just found out while searching that WSL is //supposed// to be based on Ubuntu (20)16.04 now (instead of 14.04) I guess the next time I work with those systems I'll have to run down some upgrade / re-install directions. I wonder if that will fix the issue where I was unable to mv folders around the c:\ drive within the /mnt/c FS. (It more or less locked up to the point that I h…

FWIW, I haven't had any issues moving files before or after upgrading from 14.04 -> 16.04. I use Git in WSL, but interact with the files in both Windows and WSL without any special considerations.

Re: File System Improvements to the Windows Subsystem for Linux

#17
post #8

Earlier quoted context omitted.

Seems like you might be better served with a linux desktop and windows in a VM then. The use case for WSL right now is someone like a web developer. They can develop and debug node apps locally in their native environment.

That only works because they provide emulation for AF_INET, AF_UNIX and AF_NETLINK sockets. It's not an automatic freebie.

I understand. Nonetheless they did to the work to enable straightforward client networking (which works because Windows' own networking layer is basically Berkeley sockets under the hood).

Writing an emulation of the Linux USB sysfs and device node API on top of Windows' very different USB driver layer is a rather bigger task. I'm sure they'll get to it eventually, but it's not something you can demand as an "obvious" feature.

Re: File System Improvements to the Windows Subsystem for Linux

#18
post #9

I haven't dug deep into it yet. But, I'll say that I've been having fun compiling (command line) Linux apps with Clang and visually debugging them with GDB all through the UI of VStudio Community Ed and without a VM. /shill mode Linux is not a target for the code I'm working on. But, I like to keep my code as cross-platform as possible. Between this setup and prototyping code on several compilers via goldbolt.org, st…

https://godbolt.org/ ? Goldbolt.org seems to be fax sw.

Re: File System Improvements to the Windows Subsystem for Linux

#19
Network filesystems! That's the last big feature I've been needing for regular use of WSL for light tasks. There's still enough weird behavior I wouldn't look at WSL as a complete Linux replacement, but it sure is a lot nicer than Cygwin/msys2.

They don't say anything about FUSE, I wonder if this work is at all related?

Re: File System Improvements to the Windows Subsystem for Linux

#20
post #14
post #3

Does it suffer from similar quirks as Cygwin (.exe suffix removal, symlinks, permissions mapping)? - https://cygwin.com/cygwin-ug-net/using-specialnames.html - https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlin...

Cygwin (64bit) didn't work for me in the latest creators update (actually I think it broke even before that). Now I am trying things using WSL itself, so far it has been a productive move. File permissions and security descriptors proved to be quite a hassle when removing Cygwin requiring multiple takeown and cacls hacks to remove some of the files. On the flip side I saved some disk space too.

OTOH when I wanted to have pretty pictures on my lock screen but without the Microsoft ads, I needed to rely on Cygwin to blow away the folder that caches the pictures deep in ProgramData/.../SystemData/*/ReadOnly - the lock screen image setting API has a lot of bugs. Without Cygwin, I was fiddling with cacls and takeown in an elevated prompt trying to blow away the folder. An elevated Cygwin prompt and it was just rm -rf.

(Bugs: https://www.google.co.uk/search?q=lock+screen+windows+10+ima...)

Post reply on HN