Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

41–50 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#41
post #22
post #11

I remember NT was to have an OS/2 subsystem, probably because it started out as OS/2 3.0, with a New Technology (NT) kernel. I know there was a POSIX system, but I never saw or interacted with it and, legend says, it was only used to check a box in government contracts.

The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lo…

> wasn't 100% GNU compatible

But, but... GNU's Not UNIX!

Re: Windows Subsystem for Linux: The lost potential

#42
post #11

I remember NT was to have an OS/2 subsystem, probably because it started out as OS/2 3.0, with a New Technology (NT) kernel. I know there was a POSIX system, but I never saw or interacted with it and, legend says, it was only used to check a box in government contracts.

There were so many of these - the original POSIX subsystem, MKS, Interix, a bunch I'm surely forgetting, Cygwin, etc.

None of them quite lived up to the design promise of a frictionless 'personality' OS layer on top of the existing OS. If anything, I'm curious how Microsoft, organizationally and technically, decided to give this yet another go with WSL1 - perhaps 'fail fast' and switching to virtualization was something they'd considered as a plausible escape hatch from the start.

Re: Windows Subsystem for Linux: The lost potential

#44
post #35
post #9

Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely b…

The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels). For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux ap…

> Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels

Citation needed.

Re: Windows Subsystem for Linux: The lost potential

#45
post #24

Earlier quoted context omitted.

I agree with the sentiment but, some scenarios have become orders of magnitude more complicated on WSL2 like connecting to a daemon on Windows or vice versa. I understand clear cut security boundaries and separate network interfaces, but it's extremely hard to get them running smoothly now. Everything was on localhost on WSL1. Memory usage has also gone bonkers with the VM approach, causing unnecessary overhead for c…

I apologize if I'm missing something here, but if casual users don't care about performance, what's the overhead here?

[deleted]

Re: Windows Subsystem for Linux: The lost potential

#46
post #35
post #9

Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely b…

The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels). For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux ap…

As I understand it, it's not really possible to "improve" Win32 I/O performance -- both the fundamental I/O APIs and the NTFS on-disk storage format make high performance infeasible.

Not without either abandoning all extant FS drivers, or abandoning NTFS compatibility, anyway.

Edit: Here are the WSL 1.x's team members original comments on this subject. It sounds like a deeply intractable problem.

https://github.com/microsoft/WSL/issues/873#issuecomment-424...

https://github.com/microsoft/WSL/issues/873#issuecomment-425...

The second link explains why a dentry cache just isn't feasible.

The short version is that the NT IO APIs seem to have been very, very ill-considered. It's just not possible to make it fast. Even win32 operations are extremely slow, so win32 applications go out of their way to avoid doing any file I/O. Linux applications were not written with those constraints in mind.

Re: Windows Subsystem for Linux: The lost potential

#47

I'm extremely ignorant about OS design, but based on this it sounds like WSL1 could be fairly described as basically Linux for the Windows kernel, whereas WSL2 is more like a really fancy VM. Is that the gist of it?

Without making a value judgement, that is pretty much spot on

Re: Windows Subsystem for Linux: The lost potential

#48

Earlier quoted context omitted.

Even within Explore to mount a remote linux server over ssh?

why would you need that if you have the command line functionality already? Windows has shipped with sftp for a while now. about the only think missing is a stand alone ssh client on the windows side but for that there is putty.

It would be nice to be able to mount a remote linux data share as a drive without using SMB due to all the EternalBlue Ransomware issues. Having that convenience in windows file explorer like nautilus would be helpful for people who aren't necessarily power users.

Re: Windows Subsystem for Linux: The lost potential

#49
post #37
post #26

Earlier quoted context omitted.

On XP and 7 (and 8, perhaps) I used Cygwin to have a Unix-like environment. Does it still work on Windows 10? I remember I could call Windows programs from it and manipulate Windows files.

Cygwin is definitely still around, but most people are using msys2/mingw and its bash prompt nowadays, especially with Git for Windows making it nearly ubiquitous.

[deleted]

Re: Windows Subsystem for Linux: The lost potential

#50
post #35
post #9

Contra opinion: the VM option reduced the service interface between Windows and Linux to a single kernel implementation and a few drivers, rather than every possible userspace program ever written. It's an amazing and obvious trade off. My inner architecture astronaut appreciates all the ideas in this post, but I've been trying to kill that guy for over a decade now. The bottom line is WSLv1 design SUCKED precisely b…

The actual advantage of working on something like WSL1 is that it would ensure that the NT kernel is as capable as the Linux kernel (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels). For instance, the complaints about I/O performance are because the NT kernel has a worse implementation, so they should have improved it for both Win32 and Linux ap…

I find IO on windows is fine, the problem with WSL1 was that the standard windows model doesn't line up well with Linux (fairly fundamental things like in Linux you can delete open files, which you can't do in Windows).

You couldn't switch Windows to a more linux-like model, it would break all existing windows programs.

Post reply on HN