Hacker News new | ask | show | jobs
by jstarks 1365 days ago
We work very closely across the file system, kernel, and virtualization teams, so I don’t think we can blame Conway’s Law for WSL2. And actually our WSL1 fork performance wasn’t too bad IIRC—we have real fork at the Windows kernel level, it’s just not something that can realistically work with the Win32 programming model. I also think we will eventually resolve the file system performance issues.

No, the most important reason to choose a VM instead of a reimplementation of the Linux ABI is long tail compatibility. You can’t realistically replicate and then keep up with every corner of the Linux kernel’s interface. And so with WSL1, software will randomly not work, or it will randomly break after an apt upgrade, and users will get frustrated and switch to a VM anyway. Might as well get perfect compatibility and still have nice integration with Windows via the WSL2 approach.

6 comments

I think most people understand why the WSL2 approach eventually won out, and its saved my bacon more times than I can count when I had to demo something and it breaks on my Mac only for me to quickly switch to "real" linux on my personal windows machine running WSL2.

However, with WSL1, implementing the Linux ABI was such a wicked flex.

> when I had to demo something and it breaks on my Mac only for me to quickly switch to "real" linux on my personal windows machine running WSL2.

How's that any different than running a virtual machine on your Mac with a real Linux in it?

Seamless mounting, launching code editors in Windows from Linux, issuing docker commands in the Linux OS while the docker engine and its mounts are hosted on Windows.

Doing things with something like Vagrant on Mac sometimes cuts it, sometimes doesn't. Either way, if I'm not shelling out money I could be stuck using a subpar solution like VirtualBox.

Seconding that. WSL1 is an impressive achievement. I use WSL every day and switched to WSL2 a long while back but I still kinda wish WSL1 were the way forward.
Thanks for the detailed explanation! You folks have actually tried to implement an ABI compatible Linux kernel, so I'll definitely take your word for it :)
WSL2 is better. I'll take correctness over a slight loss in performance.

Also Linux is very fast. So it's not like there is a huge performance loss in most cases, I am guessing.

You can’t realistically replicate and then keep up with every corner of the Linux kernel’s interface

Didn't Linus famously say they'll "never break userspace"?

Yes. But user space can take dependencies on features we didn’t implement yet or we implemented incorrectly or that have bugs in combinations with other features. E.g., more software is starting to depend on namespace features that we implemented incompletely in earlier versions of WSL1. So Docker worked for a while until they starting using a different subset of kernel features, for example.

At another point, glibc started depending on more precise behavior of CLONE_VFORK, which we originally didn’t implement fully. So essentially all of user space was broken. We fixed it as soon as we could, but I think glibc may have added a workaround, too. I feel bad that the community had to work around our bugs.

New syscalls and flags get added. The Linux ABI is huge though, even if you snapshot at some “old” 4.x version, say. WINE has similar problems with coverage, and Win32 is famously “stable” too.
> No, the most important reason to choose a VM instead of a reimplementation of the Linux ABI is long tail compatibility. You can’t realistically replicate and then keep up with every corner of the Linux kernel’s interface.

As far as we the public know, Google Cloud Run is based on gVisor, which emulates Linux system calls with userspace code. Seems to work great for the usual container workloads.

Doesnt ReFS do exactly that? I have been surprised they do not try to push it more - the fact it cannot (or maybe it can now but in the past it could not) be used for a boot drive seemed strange.