Windows Subsystem for Linux: The lost potential

Post by rfoo » Fri, Nov 20, 2020, 5:09 AM UTC

1_player wrote: post #152

cbdumas wrote: post #53

I too was really sad to see WSL 1 be replaced by what seems to be just a built-in VM. One of the great things about WSL 1 is that I can run Linux tools on my laptop without the memory overhead of a VM. My laptop only has 8GB of ram which is not enough for Windows and a Linux VM to comfortably share, but plenty to run the Linux tooling I want under WSL 1. On my desktop with 16GB of ram I can just run Virtualbox. WSL 2…

While still being a VM, WSL2 works much better than a Virtualbox VM: boots in 1 second (!) on my machine, as attested by uptime and dmesg, has dynamic memory reclamation, out of the box file sharing through \\wsl$, VSCode integration. Same technology, yeah, but much more ergonomic.

    $ systemd-analyze
    Startup finished in 76ms (firmware) + 38ms (loader) + 461ms (kernel) + 967ms (userspace) = 1.544s

Post by hapless » Fri, Nov 20, 2020, 5:31 AM UTC

skissane wrote: post #150

hapless wrote: post #22

Earlier quoted context omitted.

The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lo…

> SUA was still a pretty weird UNIX though. PE-COFF binaries PE-COFF comes from UNIX originally – COFF was the executable format introduced by AT&T in Unix System V, up to and including SVR3 – in SVR4, it was replaced with ELF. PE-COFF is simply Microsoft's variant of COFF. There are other variants, such as IBM's XCOFF (used on AIX). Given that COFF originated on UNIX and has a long history of use there, should we re…

Post by lostmsu » Fri, Nov 20, 2020, 6:14 AM UTC

Iwan-Zotow wrote: post #160

lostmsu wrote: post #123

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.

well, this thing sometimes works https://docs.microsoft.com/en-us/windows/terminal/panes

  ssh user@windows-pc run long job

Post by gfody » Fri, Nov 20, 2020, 6:38 AM UTC

hapless wrote: post #22

rbanffy wrote: post #11

I remember NT was to have an OS/2 subsystem, probably because it started out as OS/2 3.0, with a New Technology (NT) kernel. I know there was a POSIX system, but I never saw or interacted with it and, legend says, it was only used to check a box in government contracts.

The original POSIX subsystem was not very useful -- a minimal set of system calls, plus a Microsoft re-branded MKS Toolkit to provide shells and utilities. Microsoft ended up buying Interix, who offered a much more pleasant UNIX-on-Windows setup. That was supported for many years as "SFU" and later "SUA" SUA was still a pretty weird UNIX though. PE-COFF binaries, and a linker that wasn't 100% GNU compatible, and a lo…

Post by blahyawnblah » Fri, Nov 20, 2020, 6:45 AM UTC

month13 wrote: post #110

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