Hacker News Reader

Comment by cryptonector | Hacker News Reader

Eh, many OSes have been down this road, but the problem is that you end up having to emulate the Linux ABO, but the Linux ABI is large and fast-evolving and underdocumented, and you'll need to be compatible with it, and that's ETOOHARD. Even Microsoft has given up on emulating the Linux ABI.

View on HN

> Even Microsoft has given up on emulating the Linux ABI.

Then what's this Linux subsystem that Windows ships?

> Linux ABI is large and fast-evolving and underdocumented

You don't have to keep up with the latest ABI. You don't need to match tip-of-tree. You only need to match some version of Linux that programs still target, and that version can be pretty old, since enterprise customers scream bloody murder when you force them up upgrade kernels to run new programs.

A VM

WSL2 operates in a Hyper-V environment, there's too many issues with trying to do syscall emulation that WSL1 attempted - while both will remain supported for a while the writing is already on the wall.

Ugh. I hadn't heard that. WSL2 being a VM is a huge disappointment. There's the technically-cowardly Microsoft from the Ballmer era. Just when I thought Microsoft had rediscovered how to do technically interesting things, they wave the white flag and run away.

Using a VM for WSL means that it'll never be possible to write a program that's simultaneously a good win32 GUI citizen and a Unix API user. WSL1 (AFAIK) didn't allow this use case, but there was a path to get there. There's no path from a VM to a native USER32 process.

The bright side is that at least Cygwin won't die. Cygwin allows for precisely this use case.

Technically interesting isn't the same as the best technical choice

As far as I'm concerned, using a VM is a poor choice technical choice: a VM closes off lots of potential integration opportunities and creates all the system-resource-use coordination problems that all non-container system partitioning approaches have.

The point of WSL isn't to just run some Linux code on Windows. You've been able to do that for literally decades. The point is to create a tightly integrated environment that gives you Linux and Windows views onto the same workspace and that makes Linuxy and Windows processes peers.

Using a VM here feels like a "safe" and "sustainable" uninspired corporate choice that gives Windows a checkbox feature without expanding the bounds of what's possible. You can tell me all day that switching from innovation to crank-turning is right for the business, but I personally want nothing to do with crank-turners.

Could you give a specific example of what kind of integration you're looking for (that can only be addressed by WSL0/1)?

I'm not a Windows developer but I have a Windows laptop that I'd like to be able to run linux on and WSL2 scratches that itch, so your complaint doesn't register for me.

It was cool how WSL1 allowed named pipes to be shared between Windows and Linux apps, giving the possibility to have a shared SSH agent, efficient X11 support, etc. Does WSL2 support that? I'm not sure but I don't think so.

for NaNoGenMo [1] 2015, I wanted to run Racter [2] against Eliza, but 1) I run Linux and 2) I had an MS-DOS executable for Racter. I thought I would use DosBox to run Racter and pipe input/output to Eliza running under Linux natively, but DosBox didn't allow that. I ended up having to write enough of an MS-DOS emulator [3] to run Racter under Linux so I could pipe input/output. It barely functioned.

[1] National Novel Generation Month

[2] https://en.wikipedia.org/wiki/Racter

[3] https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos...

A light-weight solution would have been nice. Something like containers.

But again, the problem is that Microsoft wanted to have binary compatibility. That would mean containers w/ Linux ABI emulation, or a proper VM. Well, Linux ABI emulation has been tried by many people:

  - Sun (twice)
  - Joyent (once, based on earlier tech from Sun)
  - FreeBSD
  - Microsoft (WSL1)
  - probably others

and... it's just too difficult. It's ETOOHARD. So they all failed.

Microsoft knows full well how to do technically interesting things, that's why WSL1 worked as well as it did. The problem is that, being a company and not a grad student, "works 100% of the time" is more worthwhile to them than "works 99% of the time and sounds really cool."

> Cygwin allows for precisely this use case

Yeah, and WSL1 did not.

So... Looks like WSL1 wasn’t needed (Cygwin), nor is WSL2 (VirtualBox).

> Just when I thought Microsoft had rediscovered how to do technically interesting things, they wave the white flag and run away

You might want to look up all of the reasons why they made this choice, including but not limited to the amazing impedance mismatch between Linuxy I/O operations and Windowsy I/O operations.

Running the Linux kernel in a VM and doing all sorts of integration tricks ends up being a better end-user experience, even if it's not as cool and clever as what WSL0 and WSL1 are.

> You might want to look up all of the reasons why they made this choice, including but not limited to the amazing impedance mismatch between Linuxy I/O operations and Windowsy I/O operations.

Yeah, this right here is the most problematic. It's fairly easy to implement the proactor pattern of the Windows asynchronous IO APIs using reactor implementations common on Linux, the opposite is not so true. Seeing as this is a fundamental design choice of the NT kernel itself, and not just the Win32 subsystem it's rather difficult to properly emulate the Linux API's without a similar amount of indirection that a hypervisor layer adds.

> You might want to look up all of the reasons why they made this choice, including but not limited to the amazing impedance mismatch between Linuxy I/O operations and Windowsy I/O operations.

Could you provide a link to this?

As someone who is using WSL2 and had used Cygwin in the past, WSL2 is awesome and way better than the original WSL. I highly recommend you give it a shot.

It may be a less pure design, but it solves my needs better than anything else out there.

I think MSFT folk probably concluded that the Linux ABI being so difficult to emulate correctly was "a huge disappointment" :)

But yes, I was referring precisely to WSL2 being VM-based.

> Then what's this Linux subsystem that Windows ships?

It's now a full Linux kernel running in a hypervisor.

Reply on news.ycombinator.com