Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

121–130 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#121
post #46
post #35

Earlier quoted context omitted.

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/m…

Amusingly enough, I just watched a talk about this topic earlier today:

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

Re: Windows Subsystem for Linux: The lost potential

#122
This article is entirely wrong about why it's called the Windows Subsystem for Linux and not the Linux Subsystem for Windows (not surprising, since his argument makes no sense). The real reason is that Microsoft can't name something leading with a trademark owned by someone else. Here it is straight from the horse's mouth, senior PM of WSL Rich Turner: https://twitter.com/richturn_ms/status/1245481405947076610

Re: Windows Subsystem for Linux: The lost potential

#123
post #54

Earlier quoted context omitted.

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.

There is a native ssh client in windows 10. https://docs.microsoft.com/en-us/windows-server/administrati...

Now I want screen or tmux. Otherwise you can't really run anything on a remote Windows machine over SSH on spotty connections.

Re: Windows Subsystem for Linux: The lost potential

#124
post #118

Earlier quoted context omitted.

Yes this feature is only available on Insiders builds for right now!

Thank you for your work on this project. Although like the author I have some reservations about moving to a virtualization-based approach, nonetheless I am grateful attention is being paid to these kind of technologies at all. WSL has totally changed my development workflow for the better.

I'm so glad you're enjoying it! And yes we totally hear the community's reservations about moving to a virtualization based approach and we take this into account as we plan the next overall steps for WSL :)

Re: Windows Subsystem for Linux: The lost potential

#125
post #85

Earlier quoted context omitted.

I see, that makes sense! This is a really interesting design and seeing it this way gives me more respect for the Windows operating system generally. Is this subsystem concept something that has a parallel on the *nix/BSD side of the fence? Or is it unique to the NT architecture?

The closest example outside Windows I can think of is the idea of "zones" in Solaris/Illumos/SmartOS. You can have a "LX branded zone" where the OS will respond to linux syscalls. I don't know if the native solaris syscall interface is itself a zone, while Win32 is a subsystem on Windows.

This is a cool example, and now that you mention it docker as well seems to provide similar functionality. I guess what's striking about WSL1 then (and maybe what the author was saying) is that it's a mix between a docker container and like wine.

Re: Windows Subsystem for Linux: The lost potential

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

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

My problem was that the ram was never released back when I didn't use it anymore and it started to kill windows itself. Had to hard limit it from the link you provided.

Re: Windows Subsystem for Linux: The lost potential

#127
post #122

This article is entirely wrong about why it's called the Windows Subsystem for Linux and not the Linux Subsystem for Windows (not surprising, since his argument makes no sense). The real reason is that Microsoft can't name something leading with a trademark owned by someone else. Here it is straight from the horse's mouth, senior PM of WSL Rich Turner: https://twitter.com/richturn_ms/status/1245481405947076610

You can see a similar comment from Rich Turner here on Hacker News too, under the username bitcrazed: https://news.ycombinator.com/item?id=13697918

I'd never actually read it with the apostrophe as pointing out in that tweet so the name makes a lot more sense now. Perhaps Windows Subsystem for (running) Linux would be clearer hah

Also, according to his profile, Rich is former Product Manager for WSL and currently "Sr. PM for the Windows Command Line, Windows Terminal"

The interpretation in the article was still interesting nonetheless

Re: Windows Subsystem for Linux: The lost potential

#128
post #104
post #100

I have zero insight obviously but I still believe it was ptrace that broke the camels back. And yes, I had so much hope for WSL1. > ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted) Issues also exist for PTRACE_O_TRACEEXIT, PTRACE_O_TRACEEXEC, PTRACE_OLDSETOPTIONS, PTRACE_SYSEMU.

It seems like those bugs were fixed some time ago. See: https://github.com/microsoft/WSL/issues/555

The big one is https://github.com/microsoft/WSL/issues/2028 which is "fixed-in-wsl2"

This makes lldb and dlv both just not work in wsl1 and that's just the languages I dabbed in, I think the Swift debugger had issues as well.

Re: Windows Subsystem for Linux: The lost potential

#130
post #128
post #104

Earlier quoted context omitted.

It seems like those bugs were fixed some time ago. See: https://github.com/microsoft/WSL/issues/555

The big one is https://github.com/microsoft/WSL/issues/2028 which is "fixed-in-wsl2" This makes lldb and dlv both just not work in wsl1 and that's just the languages I dabbed in, I think the Swift debugger had issues as well.

Interesting, you are right I can repro the bug in issue 2028 although 555 claims to be fixed.
Post reply on HN