Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

Post reply on HN
Print view View original

101–110 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#101

Post by craigaloewen »

lrae wrote: post #21
agustif wrote: post #5

I've dedicated 2 solid work hours to help a co-worker migrate from wsl1 to wsl2. Such a PITA. I couldn't get the linux tab to appear on his explorer.exe like in mine but oh well everything else worked fine!

Wait, I didn't even know that was a thing. I am on WSL2 and don't have that either, nor do I think I ever saw it in Microsoft's docs. Interesting, thanks. Let's see if I get it to work for me. For now I always went with \\wsl$. Edit: Wait, are you on an insider build by chance? https://blogs.windows.com/windows-insider/2020/04/08/announc... Seems like this isn't in yet otherwise.

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

Re: Windows Subsystem for Linux: The lost potential

#102

Post by 1996 »

shawnz wrote: post #96
1996 wrote: post #93

Earlier quoted context omitted.

WSL1 tries to do too much. WSL2 tries to do even more. msys2 mostly cares about running your textmode software. For example, someone talked about processes. Here's all that I see in msys2: # ps xwau PID PPID PGID WINPID TTY UID STIME COMMAND 480 479 480 18796 pty1 197611 14:13:13 /usr/bin/bash 479 1 479 16872 ? 197611 14:13:12 /usr/bin/mintty 1118 480 1118 16496 pty1 197611 17:00:32 /usr/bin/ps Most of the time, I do…

WSL1 also doesn't show windows proceses in 'ps', only the WSL processes. For example: shawnz@ShawnsPC:/mnt/c/Users/shawn$ ps xwau USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 8936 184 ? Ssl Nov17 0:00 /init root 6 0.0 0.0 8936 96 tty1 Ss Nov17 0:00 /init shawnz 7 0.0 0.0 18588 2708 tty1 S Nov17 0:00 -bash shawnz 252 0.0 0.0 18880 1984 tty1 R 18:04 0:00 ps xwau

But in your example, I can already see you have a init system and multiple users - neither of which will be needed in most cases.

Re: Windows Subsystem for Linux: The lost potential

#103

Post by mixmastamyk »

trilinearnz wrote: post #10

This is a really interesting article, and WSL 1 was a testament to Dave Cutler's vision for the NT architecture re: support for multiple operating environments (read 'Showstopper!' for more background). Also, as someone hacking with a custom OS kernel in their spare time, I found this quote illuminating when it comes to understanding the lower level: > A user-space process is a collection of binary instructions that…

It's a shame the author didn't mention the original POSIX and OS2 subsystems. I guess the idea didn't pan out and contributes to poor performance.

Re: Windows Subsystem for Linux: The lost potential

#104

Post by shawnz »

chx wrote: 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

Re: Windows Subsystem for Linux: The lost potential

#105

Post by shawnz »

1996 wrote: post #102
shawnz wrote: post #96

Earlier quoted context omitted.

WSL1 also doesn't show windows proceses in 'ps', only the WSL processes. For example: shawnz@ShawnsPC:/mnt/c/Users/shawn$ ps xwau USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 8936 184 ? Ssl Nov17 0:00 /init root 6 0.0 0.0 8936 96 tty1 Ss Nov17 0:00 /init shawnz 7 0.0 0.0 18588 2708 tty1 S Nov17 0:00 -bash shawnz 252 0.0 0.0 18880 1984 tty1 R 18:04 0:00 ps xwau

But in your example, I can already see you have a init system and multiple users - neither of which will be needed in most cases.

The "init" process is just a stub used by WSL, it is not a "real" init system. And Cygwin also allows the creation of multiple users within the Cygwin environment, doesn't it? It's just a matter of populating /etc/passwd. If you want to use WSL1 with a single user then you could just set the default user to root.

Re: Windows Subsystem for Linux: The lost potential

#106

Post by alerighi »

ralph87 wrote: 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 signal to a Linux process from a Windows process. Or imagine accessing physical hardware from the Linux subsystem. With the WSL2 is impossible to even use a serial port!

WSL1 had performance problems. That thing about the filesystem performance could have been the occasion to optimize NTFS and even to add to the NT kernel the support for other filesystem, natively. Or why not add to the NT kernel other Linux functionality, to make them available both in the Linux and Windows subsystems.

Of course not everything would have been possible to map on the NT kernel. That is fine. But for most application really the WSL1 was usable.

Maybe the real problem with the WSL was only having called it "Widnows subsystem for Linux". They should really have made WSP: Windows Subsystem for POSIX. Drop the binary compatibility with Linux requirement and just make it an environment in which you can compile code that uses the POSIX API and interface with Windows. Not having binary compatibility with Linux is not a big deal, thing about it but is what macOS does and nobody seems to care, and users would have created a package manager just like there is brew in macOS to easily install software.

Re: Windows Subsystem for Linux: The lost potential

#107

Post by ASalazarMX »

shawnz wrote: post #80
ASalazarMX wrote: post #71

Earlier quoted context omitted.

At work we develop on Windows virtual machines, and WSL1 won't run on a VM. Fortunately WSL2 does, so at least I can enjoy Linux tooling I sorely missed.

Interesting, I would expect the opposite problem since WSL1 doesn't use virtualisation in any way. Do you have more details about the error you experienced?

Unfortunately I tried WSL1, didn't work, and left it at that for months. When WSL2 was out, it just worked and I had forgotten by then what kind of error WSL1 gave me.

I can only recall it was a dialog box, not a crash, and that it had to do about virtualization.

Re: Windows Subsystem for Linux: The lost potential

#108

Post by moron4hire »

alerighi wrote: post #106
ralph87 wrote: 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…

Windows Subsystem for POSIX was already tried. It didn't take off.

Re: Windows Subsystem for Linux: The lost potential

#109

Post by jhallenworld »

j0057 wrote: post #78
ralph87 wrote: 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…

NTFS performance leaves much to be desired on Windows too, it really hurts for workloads dealing with lots of small files, such as programming.

I was wondering if Wine on Ubuntu is faster than Windows native. I found this OSBench near the end of this page (look for "Test:Create Files"):

https://www.phoronix.com/scan.php?page=article&item=wine-ubu...

Ubuntu native is much faster. It's odd that Wine is so slow.. I wonder why?

Re: Windows Subsystem for Linux: The lost potential

#110

Post by month13 »

sedatk wrote: post #24
ralph87 wrote: 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…

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

Post reply on HN