WSL2 is for the most part totally usable for everyday development, but it does have a handful of issues that either need workarounds or are just infeasible.

USB passthrough isn't yet supported, so it's necessary to make use of something like VirtualHere[1] or some another TCPIP tunneling daemon running on the windows depending on what you're trying to do.

There seems to sometimes be issues with resuming from S0ix sleep where the VM process is still "running" but it gets stuck in a state where new processes just will not spawn. It's been a while since I messed with it, but my "solution" was disabling a VM security measure, launching Process Hacker 2 as admin, searching for "lxss" in the process list and terminating the corresponding svchost.

The actual linux kernel running inside WSL2 is interesting, it's microsofts own custom kernel[2] with some magic sauce for making everything play nice. Unfortunately, it (still?) lacks a fully-functional SystemD so making some programs work can be a chore. Also all the kernel modules compiled in, and it doesn't allow loading them dynamically with modprobe. There are some alternative kernels out there that solve some of these issues, though I haven't bothered to try any since whenever I run into these sorts of issues it's less of a hassle to just switch to a dedicated linux box.

For all of the issues that come with Windows 11, having WSLg make running graphical programs "just work" out of the box with rock-solid copy/paste, alt+tab, etc., really makes it a joy to work with.

[1] - https://www.virtualhere.com/

[2] - https://github.com/microsoft/WSL2-Linux-Kernel

WSL2 runs a Linux VM via Hyper-V at close to native performance.

However, it slows down if you do any type of cross-os file system communication. So you need an IDE that knows how to work around this (eg: VSCode with WSL2 plugin runs a server in the VM to avoid cross-os fs comm)

WSL2 runs at close-to-native or native speed when you limit your work to terminal. However beyond that: - I oftentimes need to run some GUI linux apps from inside the WSL2 -> and scaling (needed on a 4K screen) is really troublesome. No need to say that fractional scaling is nonexistent. - when logging to a remote machine (from WSL2) via ssh with X forwarding, and launching GUI apps remotely, the lags are so bad that it is hardly workable even on an ultra-fast network connection to the remote machine. Different from that, everything is butter smooth from a native Linux. - when I needed to create a user with a specific user ID (not 1000) I found that it somehow does not work full in WSL2, whereas it is just a stanard thing for a dedicated Linux. - there are very few, if any, any answers on the Internet about the issues above, I guess because the community of people using WSL2 the way I need is minuscule. The best tactics is to reach the WSL team directly ... and hope they fix some of the issues in the next build. So I fiddled with WSL2 for about a month and ditched it for a regular dual boot with Linux (and didn't boot into Win11 since then)

The only real remaining problem is low level hardware access. MS developed some very clever workarounds for giving WSL2 access to the GPU, but what about everything else?

For example, USBIP is great in many situations, and MS has worked to make it robust, but what I really need is the ability to assign a hardware device directly to the WSL VM - this is possible with Hyper-V, but WSL2’s hyper-v.

Until something like this is possible, for me it’s simpler to have a tiny linux box under my desktop and just use that.

I use WSL2 at work every day, and in fact I try to do as much work in it as possible. It's absolutely riddled with problems. Here are a few I can remember without getting out my work computer to look at my notes. Some of these issues might not ‘belong’ to Windows, but they're all things which could come up for you on WSL2 that are unlikely or impossible to encounter elsewhere.

  - there's a showstopping memory leak in WSL2 that absolutely destroys your computer in terms of CPU and RAM usage, and makes your WSL machines completely unresponsive whenever you spin up a bunch of Docker containers
  - the PATH passthrough feature of WSL2 sometimes causes ‘.’ (the CWD) to get added to the user's PATH if your login shell is Fish (????)
  - `systemctl status` is broken with WSL for systemd 251 and newer
  - enabling systemd support (and using syschemd to run systemd-based distros without leveraging Microsoft's support for it) causes issues where launching WSL in an unprivileged instance of Windows Terminal means you can't access WSL in elevated Windows Terminal Windows and vice-versa
  - using hardware PGP tokens or other smartcards sucks ass, because forwarding your GPG agent to WSL guests is a huge pain (apparently WSLg runs its own `ssh-agent` process, and I don't know whether it has access to USB devices¸but I'd bet not)
  - WSLg has random and repeated crashes which spam you with popups for some distros sometimes, and it can only be resolved by shutting down ALL of your WSL VMs
  - WSLg's RDP crap gives you the wrong cursor (and one that's way too small)
  - WSLg's window management doesn't show mouse cursor changes correctly, so you have to *guess* when your cursor is in the right place to resize a window
  - resizing windows with Super+Click or Alt+Click doesn't work (either ‘natively’ to the WSL2 VM or via, e.g., AltSnap)
  - sizing and moving WSLg windows sometimes breaks completely. I think somewhere in the stack there's confusion about the positions of windows, which may be related to multimonitor setups
  - window maximization for WSLg apps doesn't work right when you have more than one monitor
  - OpenGL acceleration randomly decides it won't work for unknown periods of time with WSLg
  - basically any VPN completely fucking breaks networking inside WSL, so have fun using it at work
  - random crashes and freezes (not super frequent), so sometimes you come back to your machine after the weekend and none of your WSL sessions are usable and you can't open new ones
  - the `wsl.exe` has some weird encoding issue or doesn't respect the encoding set for the terminal emulator. Piping `wsl --help` into a pager doesn't work right (either natively on the system or from inside an instance via interop)
  - case sensitivity differences across filesystems sometimes breaks git repos, depending on which side of the OS divide they live on and where/how you cloned them
  - access to the Windows filesystem from WSL is so slow that it can take literally multiple seconds for a basic git prompt to draw
  - access to the Windows filesystem from WSL is so slow and so limited because of Windows behavior with file locking that sometimes you run into locking issues where running git commands from WSL is just broken
  - when your virtual disk, which is sparsely allocated, fills up, it takes up additional space on your machine forever, unless you intervene. Enjoy permanently losing dozens or hundreds of GBs of disk just for experimenting with Docker, until you shut your WSL VM down, locate the disk somewhere in $env:LOCALAPPDATA, and shrink it manually
  - for some absolutely unfathomable reason, WSL2's new built-in systemd support completely breaks TRAMP sudoedit in Emacs (just hangs, no log output that I could generate). the old, third-party syschemd hack for running systemd does not produce this mysterious issue. (this one was quite a puzzle)
  - unusable Linux binaries located on your Windows PATH from Docker GUIs like Rancher Desktop, Docker Desktop, or Portainer can cause your in-WSL Docker client to think it should use them for password management, making it impossible to use `docker login`

It's janky as all hell. I imagine users who report unproblematic experiences are simply not attempting to replicate a very substantial fraction of what an engineer might typically do on an actual Linux workstation.

And of course, you have to deal with the usual Windows bullshit. I have to manually kill `dwm.exe` every day because after being logged in for a day or two, window management causes a form of input lag that renders the mouse completely unusable if I don't.