So there’s a good number of comments, I’ll try to address them:

- Yes, these issues persist with WSL2.

- WSL2 allows mounting between the system/subsystem, but there is considerable overhead.

- Using WSL for remote workspaces from the host is very much a mixed bag.

- Attempting to use WSL entirely with graphical applications has very limited/poor support.

- If you wish for VM acceleration, you have to use Hyper-V, not all toolchains work with Hyper-V and this heavily restricts the host machine.

- If you wish to do anything that crosses the subsystem and the host, line delimiters and platform detection are very error prone.

- If you accidentally misconfigure WSL2 (which is quite easy to do) the WSL userspace can have substantial access to the host files, often beyond what may be initially apparent.

- Of compatibility issues, non-standard socket implementations have caused a lot of incompatibilities with software for me.

This is great and all... Except I’ve long given up on WSL. I really tried to make WSL work for many things, only to find the entire experience (reliability, performance, and beyond) was simply better in every way without Windows.

No matter what you do, there will always be some weird platform detection or line termination that pops up somewhere. And if it isn’t that, it’s degraded performance or kernel-level incompatibility.

It’s hard to elaborate just how wild this model might be if it performs as claimed. The claims are this can perform close to Sonnet 4.5 for assisted coding (SWE bench) while using only 3B active parameters. This is obscenely small for the claimed performance.