This doesn't look like WSL1. They're not running Linux syscalls to the macOS kernel, but running Linux in a VM, more like the WSL2[0] approach.

[0] https://devblogs.microsoft.com/commandline/announcing-wsl-2/...

In the end they're probably run into the same issues that killed WSL1 for Microsoft— the Linux kernel has enormous surface area, and lots of pretty subtle behaviour, particularly around the stuff that is most critical for containers, like cgroups and user namespaces. There isn't an externally usable test suite that could be used to validate Microsoft's implementation of all these interfaces, because... well, why would there be?

Maintaining a working duplicate of the kernel-userspace interface is a monumental and thankless task, and especially hard to justify when the work has already been done many times over to implement the hardware-kernel interface, and there's literally Hyper-V already built into the OS.

Yeah, it probably would be feasible to dust off the FreeBSD Linux compatibility layer[1] and turn that into native support for Linux apps on Mac.

I think Apple’s main hesitation would be that the Linux userland is all GPL.

[1]: https://docs.freebsd.org/en/books/handbook/linuxemu/

If they built as a kernel extension it would probably be okay with gpl.

There’s a huge opportunity for Apple to make kernel development for xnu way better.

Tooling right now is a disaster — very difficult to build a kernel and test it (eg in UTM, etc.).

If they made this better and took more of an OSS openness posture like Microsoft, a lot of incredible things could be built for macOS.

I’ll bet a lot of folks would even port massive parts of the kernel to rust for them for free.

My impression is they’re basically trying to end third party kernel development; macOS has been making it progressively more difficult to use kexts and has been providing alternate toolkits for doing things that used to require drivers.