Not just performance issues. WSL1 had so many limitations that it was silly.

WSL2 gives you pretty much the whole linux environment. A truly future of Linux of desktop...

Also interested in the response to the parent (loeg)

> facing many of the same difficulties that prompted the Windows team to just run Linux in a hypervisor

If by difficulties, you mean implementing system calls, this is being kept tabs on here: https://wiki.freebsd.org/Linuxulator

One that comes to mind is FreeBSD's kqueue, which opens a file descriptor for every file watched [1]

So inotify, inotify_add_watch, inotify_rm_watch isn't started. Lots of applications need watching of changes on directories. Even plain old FreeBSD gets messed since a large webpack project is going to chew up way too much.

If you're interested in this type of system call across operating systems check out https://github.com/emcrisostomo/fswatch

On WSL1/2:

Namely in WSL1, there were serious issues with package systems like npm, node_modules/ would have file descriptors get clogged, and it took a full system reboot to get WSL working again: https://github.com/microsoft/WSL/issues/1529. WSL2 Fixes it.

[1] https://emcrisostomo.github.io/fswatch/doc/1.8.0/fswatch.htm... See Freebsd -> kqueue -> Peculiarities

Sure, "BSL" doesn't have all the same difficulties as Windows WSL1 had. There are still design mismatches between FreeBSD and Linux that make implementing Linux features difficult (just for example, compare Linux clone() to FreeBSD fork()), and there are many, many features that remain unimplemented (inotify, cgroups, namespaces, ...).

I agree it's largely "just" a matter of implementing the missing functionality, which has a large surface area and requires building novel infrastructure in the FreeBSD kernel.