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.
Windows Subsystem for Linux: The lost potential
231–240 of 250 posts
Re: Windows Subsystem for Linux: The lost potential
#232Earlier 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…
Re: Windows Subsystem for Linux: The lost potential
#233Earlier 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.
https://devblogs.microsoft.com/commandline/memory-reclaim-in...
Re: Windows Subsystem for Linux: The lost potential
#234Earlier 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.
Re: Windows Subsystem for Linux: The lost potential
#235Contra 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…
https://github.com/microsoft/WSL/issues/873#issuecomment-425...
Re: Windows Subsystem for Linux: The lost potential
#236Contra 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…
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
#237Earlier 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…
Re: Windows Subsystem for Linux: The lost potential
#238Contra 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…
?? we do this all day long on WSL2.
Re: Windows Subsystem for Linux: The lost potential
#239Re: Windows Subsystem for Linux: The lost potential
#240Earlier 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. :-)
This could be done with WSL, but WSL is too heavy for a task like that.