Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

141–150 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#141

I tend to agree with the article. What does WLS2 provides that a regular VM (VirtualBox for example) doesn't? Or a Docker container that I run with "C:" mounted as a volume?

Ease of use and ease of setup - both of which are important. If I want to setup an Ubuntu VirtualBox, I have to download the VirtualBox software, find the Ubuntu ISO, and run through the setup process. Then I've got to work through any quirks with the setup to get it working seamlessly within the larger windows environment.

With WSL? I hit the install button on the windows app store. That simplicity is important and vastly increases the immediate utility of something like WSL, especially if you just want to try it out.

Re: Windows Subsystem for Linux: The lost potential

#142

I tend to agree with the article. What does WLS2 provides that a regular VM (VirtualBox for example) doesn't? Or a Docker container that I run with "C:" mounted as a volume?

Ease of use and ease of setup - both of which are important. If I want to setup an Ubuntu VirtualBox, I have to download the VirtualBox software, find the Ubuntu ISO, and run through the setup process. Then I've got to work through any quirks with the setup to get it working seamlessly within the larger windows environment. With WSL? I hit the install button on the windows app store. That simplicity is important and…

I'm pretty sure those who would actually use WSL are also able to install a regular VM or Docker.

Re: Windows Subsystem for Linux: The lost potential

#143

Earlier quoted context omitted.

Ease of use and ease of setup - both of which are important. If I want to setup an Ubuntu VirtualBox, I have to download the VirtualBox software, find the Ubuntu ISO, and run through the setup process. Then I've got to work through any quirks with the setup to get it working seamlessly within the larger windows environment. With WSL? I hit the install button on the windows app store. That simplicity is important and…

I'm pretty sure those who would actually use WSL are also able to install a regular VM or Docker.

WSL launches near-instantly, consumes few resources, runs programs very fast, has seamless access to my Windows drive, etc. It's nice and light where a VM is bulky.

It does everything I want as a Linux terminal on Windows. I'm completely indifferent to the stuff mentioned in this blog post, as I'm not a Windows sysadmin.

Re: Windows Subsystem for Linux: The lost potential

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

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.

I think WSL1 is there for transitional purposes and will be thrown away eventually. It was already incomplete, it didn't support forwarding any ICMP packets other than ping, so traceroute didn't work for example. I don't expect it to stay as an option for long.

Re: Windows Subsystem for Linux: The lost potential

#145

Starting my development journey on Windows many years ago, discovering Linux and eventually daily driving MacOS for years - WSL1 has enabled me to once again make Windows 10 my daily driver for both work and play for the last year. I spent several months using WSL2 but because the implementation attempts to hide virtualization behind a curtain, it was unclear where the magic successfully blended the guest with the ho…

I made Windows 10 my daily driver for the same reason. I share your sentiment about hoping wsl1 sticks around

Re: Windows Subsystem for Linux: The lost potential

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

Not having binary compatibility with Linux is not a big deal

But it is, because there is actually lots of proprietary software available on Linux as binary-only --- many of it very specialised and expensive --- and Microsoft wants to be able to run that too.

Re: Windows Subsystem for Linux: The lost potential

#147

Looking forward to the next LTS version of windows 10 that can support WSL2. As of right now WSL2 only works on Windows 10 versions 1903 or newer so it's a no go on LTSB/LTSC.

I pestered my IT department enough and they let me have it.

Re: Windows Subsystem for Linux: The lost potential

#148
post #24
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…

> connecting to a daemon in Windows

That doesn't seem impossible to implement. Can't you connect to some port on your gateway to access the host? Even if you currently can't, it still seems pretty easy to implement in the grand scale of things, than trying to make WSL1 work.

I'd imagine it is in some todo list somewhere in Microsoft

Re: Windows Subsystem for Linux: The lost potential

#149
post #78

Earlier quoted context omitted.

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?

Linux and Unix in general seems to love huge writeback caching, which is great for speed but horrible for consistency and reliability to power failure and such; on the other hand, Windows flushes the caches more often, providing greater reliability but without as much speed.

That's been my experience, in any case; doing lots of small file operations barely causes any disk activity in Linux, but far more in Windows. Moreover, abruptly cutting power in the middle of that would likely result in far more writes lost on Linux than on Windows.

Re: Windows Subsystem for Linux: The lost potential

#150
post #22
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…

> 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 really call a UNIX(-like) "weird" for using it?

The UNIX standard doesn't mandate any particular executable file format. macOS uses Mach-O. z/OS uses GOFF. Both are certified UNIX. (Interix/SFU/SUA never was, but there was nothing stopping Microsoft pursuing UNIX certification for it if that had been a priority for them.)

Post reply on HN