Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

231–240 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#231
post #54

Earlier quoted context omitted.

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.

You can ssh into your remote and start a tmux session then. If you are disconnected you ssh back then tmux attach. :-)

Re: Windows Subsystem for Linux: The lost potential

#232
post #201

Earlier quoted context omitted.

The individual process inside the vm might not consume much, but the vm itself might reserve some GBs of memory. Try looking at how much memory `vmmem` process used in task manager.

Also: https://www.reddit.com/r/bashonubuntuonwindows/comments/d8x7... "So, I was copying a 8GB file to my Debian home folder using Windows Explorer, via $wsl network. The copy process made my CPU's fan runs like a jetplane, and it stop copying when at 95%, then I opened up Task Manager and saw this. even after it finish copying, Vmmem process still hold 13GB RAM and not release any . Why? I have to shutdown WSL after…

Check the other comments on the link? Solution c) is already there?

Re: Windows Subsystem for Linux: The lost potential

#233

Earlier quoted context omitted.

Is that an upper bound? My Ubuntu 20.04 console sessions on WSL2 consume a couple tens of Mb.

The individual process inside the vm might not consume much, but the vm itself might reserve some GBs of memory. Try looking at how much memory `vmmem` process used in task manager.

I can't find that process in my system, nor a significant difference in physical RAM usage before and after starting Ubuntu in WSL2. Digging a little it seems like memory is dynamically allocated and reclaimed when freed. I'm not defending WSL2, just trying to understand how is it supposed to consume 8GB of my 16Gb of RAM.

https://devblogs.microsoft.com/commandline/memory-reclaim-in...

Re: Windows Subsystem for Linux: The lost potential

#234

Earlier quoted context omitted.

Is that an upper bound? My Ubuntu 20.04 console sessions on WSL2 consume a couple tens of Mb.

Look for a 'vmmemory' entry in your process list, it'll likely be in the hundreds of megs, if not a gig or so.

I don't have that process while running WSL2 in my machine. I have vm-agent and vm-agent-daemon, but I'm using a virtual desktop, so this might or not be related to WSL2. Both of these processes consume less than 10 Mb combined. In my other comment [0] I referenced a link from Microsoft that says RAM is dynamically allocated and reclaimed when freed.

0. https://news.ycombinator.com/item?id=25161769

Re: Windows Subsystem for Linux: The lost potential

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

not just the dentry cache:

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

Re: Windows Subsystem for Linux: The lost potential

#236
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.

Actually for that special case WSL2 works. I'm currently experimenting with `sshd -i` on WSL2; not sure why it doesn't work on Ubuntu 20.04 but does on OpenSUSE 15.2…

Re: Windows Subsystem for Linux: The lost potential

#237
post #67

Earlier quoted context omitted.

WSL1 hasn't gone away for those who prefer it. But we're talking about an extra gigabyte. It's still cheaper than a full VM.

It's even cheaper to only use what you need with msys2! bash inside mintty gives me all I need, with minimal overhead. Eventually, I'd like to see bash inside Windows Terminal made easily available - complete that with busybox, and you cover 90% of the Linux usecases without having to download anything (a bit like how starting Terminal.app offers most of what you need on MacOS) Add an option to install packages using…

main draw for wsl2 for my team was IO performance. how is git on huge projects under msys2?

Re: Windows Subsystem for Linux: The lost potential

#238
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.

?? we do this all day long on WSL2.

Re: Windows Subsystem for Linux: The lost potential

#239

Earlier quoted context omitted.

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

Isn't the only reason that it didn't take off because it was so incomplete?

Incomplete and nobody really knew it existed.

Re: Windows Subsystem for Linux: The lost potential

#240

Earlier quoted context omitted.

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

You can ssh into your remote and start a tmux session then. If you are disconnected you ssh back then tmux attach. :-)

Remote machine is Windows. tmux is not available on Windows. That's the whole issue.

This could be done with WSL, but WSL is too heavy for a task like that.

Post reply on HN