Unpopular opinion: Microsoft was afraid that WSL 1.0 would "Embrace, Extend, Extinguish" the Windows OS.
Windows Subsystem for Linux: The lost potential
51–60 of 250 posts
Re: Windows Subsystem for Linux: The lost potential
#52I'm extremely ignorant about OS design, but based on this it sounds like WSL1 could be fairly described as basically Linux for the Windows kernel, whereas WSL2 is more like a really fancy VM. Is that the gist of it?
Without making a value judgement, that is pretty much spot on
Sweet, thanks!
Re: Windows Subsystem for Linux: The lost potential
#53I 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 solves nothing for me. Like the author I am very skeptical that WSL 1 will be maintained going forward but I hope it is.
Re: Windows Subsystem for Linux: The lost potential
#54Earlier quoted context omitted.
Even within Explore to mount a remote linux server over ssh?
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...
Re: Windows Subsystem for Linux: The lost potential
#55Contra 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…
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.
Re: Windows Subsystem for Linux: The lost potential
#56WSL 1 (haven't tried 2 if they have some sort of magic for this, guess not) can actually run windows applications.
So you can run "ipconfig.exe | cowsay" for instance.
I'm not in front of a windows machine now but you could do stuff like list windows processes with a windows command, filter it with linux command and take the result to kill a process. All in a short line.
And honestly, more integrated than that I'm not sure I want. I like isolation and knowing that my linux command won't touch windows processes etc.
But an utility that can list and kill both Linux and windows processes can be done in a short shell-script.
Re: Windows Subsystem for Linux: The lost potential
#57Earlier quoted context omitted.
Even within Explore to mount a remote linux server over ssh?
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.
OpenSSH both client and server has been a Windows feature for sometime in Windows 10 and the client has been auto-enabled in Dev Mode for slightly less but nearly as much time. (It's the OpenSSH Client provided as a Windows 10 feature that also provides sftp now.)
Re: Windows Subsystem for Linux: The lost potential
#58Earlier 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…
I apologize if I'm missing something here, but if casual users don't care about performance, what's the overhead here?
IIRC WSL 2 use 50% of your memory in Windows, or 8GB (whichever is smaller) by default.
Re: Windows Subsystem for Linux: The lost potential
#59I'm extremely ignorant about OS design, but based on this it sounds like WSL1 could be fairly described as basically Linux for the Windows kernel, whereas WSL2 is more like a really fancy VM. Is that the gist of it?
More or less. Though I'd rephrase your description of WSL1 as "Linux for the NT kernel".
In that sense "Win32" (the API used by Windows programs) could also be described as "Win32 for the NT kernel". They are both subsystems that translate their APIs into NT kernel calls.
Windows NT used to have a number of these subsystems but all except Win32 were deprecated and eventually removed.
Re: Windows Subsystem for Linux: The lost potential
#60Contra 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…
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…
> (Linux is of course the best designed and implemented among the non-realtime, not provably correct and not secure kernels)
That is a coffee-spewing statement. Linux generally has a reputation of approaching new features by coming late to the party, seeing the mistakes everyone else made in the feature, and then implementing it somehow even more poorly than everybody else.
An example of a particularly bad Linux subsystem is ptrace, which interacts poorly with threads, relies on signals (itself a bit of a mess of a feature), and is notorious for all the races you have to do to actually properly set up a debugger. The Windows debugger API is much simpler, and even includes some features I'd love to have in Linux instead (hello, CreateRemoteThread!). I was going to write to the parent comment that implementing ptrace to let you run gdb (or, worse, rr!) in WSL1 would have been something that every NT kernel programmer would have "NOPE"d at because the impedance mismatch is just that high.