Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

171–180 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#171

Starting my development journey on Windows many years ago, discovering Linux and eventually daily driving MacOS for years - WSL1 has enabled me to once again make Windows 10 my daily driver for both work and play for the last year. I spent several months using WSL2 but because the implementation attempts to hide virtualization behind a curtain, it was unclear where the magic successfully blended the guest with the ho…

>The WSL2 guest can't connect to services (tcp, ports, whatever) running on the Windows host I assume you're talking about how you need to use the hosts ip rather than localhost? Because you definitely can access host ports. I'm even connecting WSL2 to an X server running on windows.

This is actually a good point I glossed over and is completely correct.

You can access the host via its IP but you can fall into application level "not localhost" security checks (Chrome for example).

You also have to know that the guest has a different IP to the host and while I can lean on my experience with virtualisation to understand and maybe find a way around the issue, it's an example of the incongruence of WSL2. What you see is definitely not what you get.

It's not a fair bar to set for most engineers, especially those who have recently entered the industry or are trying Linux (bash via WSL) for the first time.

Re: Windows Subsystem for Linux: The lost potential

#172
In reverse, on Linux I'd surely prefer to use Wine to run Windows programs, instead of using a VM.

> But keeping WSL 1 running is a monumental effort due to the need to keep up with Linux changes.

That's what Wine has been doing for years - keeping with up with Windows changes. And it's indeed a monumental effort for such compatibility layers.

Re: Windows Subsystem for Linux: The lost potential

#173

Earlier quoted context omitted.

FYI to any WSL2 users, in it's migrated configuration the WSL VM can request as much RAM as it needs, but has no means to free this back. There's an option to use .wslconfig to specify a limit. https://github.com/microsoft/WSL/issues/4166

Does "wsl --shutdown" work?

Yes

Re: Windows Subsystem for Linux: The lost potential

#174
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…

Your point about the dentry cache seems like a non-sequitur. The cache isn't the bottleneck; the bottleneck is that NTFS is a crappy filesystem.

Yes, I've read this comment: https://github.com/microsoft/WSL/issues/873#issuecomment-425...

The argument about Windows not having a single, central dentry cache doesn't hold water. For one thing, there's no reason to think that a two-level cache would significantly decrease performance. More importantly, the fact that on Windows most VFS work occurs in the filesystem driver itself only proves that Windows could have implemented an EXT4 driver with better dentry and other semantics and permitted WSL1 environments to keep most of its files on an EXT4 volume, which is what happens with WSL2, anyhow.

WSL1 could have been better in every way. It would have required them to track a moving target, but they already accomplished semantic parity with seemingly minimal resources. Improving performance was certainly possible, and keeping up would have required significantly less work on its own. At the end of the day, I think the reason WSL1 was canned is obvious: the decision to ship WSL1 was probably accidental. Why accidental? Because anyone with the slightest business acumen would realize that a WSL1 environment with feature and performance parity to open source Linux would mean there'd be little reason to target Windows' native environment at all for new software development. And while Microsoft has done relatively well for itself with Azure and other ventures, its revenue still principally derives from Windows and Office, and the last thing Microsoft needs is to accelerate movement away from those products.

WSL2 means that Microsoft can keep its Linux environment a second-class citizen without being blamed for it, while still providing all the convenience necessary for doing Linux server application development locally. Integration with the native Windows environment will be handicapped by design and excused as an insurmountable consequence of a VM architecture. For example, with WSL1 and some obvious and straight-forward improvements it would have been trivial to run a Linux-built Electron app with identical performance, responsiveness, and behavior (not to mention look & feel, given the web-like UI). With WSL2 Microsoft will likely only ever provide GUI integration over RDP, which will never have the same responsiveness (not because it's theoretically impossible, but because nobody would ever demand it, and in any event it would require tremendously more effort than the comparable WSL1 approach).

Re: Windows Subsystem for Linux: The lost potential

#175
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…

Correct, but... this is not WSL. This is a VM. Let's see this from the opposite point of view: WSL1 is to WSL2 what WINE is to a VM running Windows. Two completely different approaches. The thing that would have allowed the WSL1 to do was to really integrate between Windows and Linux: imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command. Imagine sending a…

imagine writing running a Linux command, piping its output in a Windows command to pipe it again in a Linux command.

But that's not most of us want to do with WSL. We just want to run the team's React app with its rube goldberg npm monstrosity that falls over when you try to run it on windows.

That use case covers 90% of us. No need to ask for anything more.

Re: Windows Subsystem for Linux: The lost potential

#176
Correct me if I'm wrong, but this article makes it sound like WSL might be taking notes from WINE. It's Not an Emulator, because that would be slow and error-prone. Instead, it finds a way to abstract the appropriate functionality within the existing system.

Talk about irony. But I share the author's desire to see WSL share resources transparently between the W and the L. USB serial devices are a good example: it took forever for WSL1 to sort of support them, and it's still spotty with WSL2.

This is an area where WSL could be very appealing: many embedded workflows rely on one or two legacy Windows applications, but most of the core tooling works fine in Linux. But if you can't easily pass your USB debugger between OSes, you can't easily split your workflow across OSes.

Re: Windows Subsystem for Linux: The lost potential

#177
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

Another interpretation is that Linux has been trying to re-implement Unix for 30 years, when the point of Unix in 1970 was a simple portable operating system that can be coded in like half a year.

Re: Windows Subsystem for Linux: The lost potential

#178
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…

What are the trillion other problems? Honest question, some I heard this a lot, but in reality I only ever saw people complain about the speed of the filesystem. So that would just mean 1 (hard) thing to fix.

Re: Windows Subsystem for Linux: The lost potential

#179
post #174
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…

Your point about the dentry cache seems like a non-sequitur. The cache isn't the bottleneck; the bottleneck is that NTFS is a crappy filesystem. Yes, I've read this comment: https://github.com/microsoft/WSL/issues/873#issuecomment-425... The argument about Windows not having a single, central dentry cache doesn't hold water. For one thing, there's no reason to think that a two-level cache would significantly decrease…

> the bottleneck is that NTFS is a crappy filesystem.

Care to explain why do you think NTFS is crap?

From my experience it's usually bad assumptions about files under windows and every application or library tries to stick to posix interface when dealing with files (open, read/write, close) which tends to block for longer periods on windows than on linux counterparts which results in significant perfomance loss .

Linux first software will always outperform windows implementation and Windows first software will outperform Linux implementations unless you provide separate code paths to properly handle underlying OS architecture and assumptions.

On Windows closing the file handle is extremely costly operation due AV checks and file content indexing [1]

[1] https://www.youtube.com/watch?v=qbKGw8MQ0i8

Re: Windows Subsystem for Linux: The lost potential

#180
> Can you imagine how cool it would be to manipulate Windows services from the WSL session?

It is a cool integration trick and might even be useful for some people like the author and their role with Azure. But it isn't remotely interesting for most WSL users who just want a local Linux to run containers in, or Linux tools, or just do server related stuff.

Post reply on HN