That's why you trash WSL2 and just stick with WSL1. I'm surprised they didn't mention it at all.
Keep MSYS2 around for where WSL1 doesn't suffice, but that should be fairly infrequent.
[0] https://learn.microsoft.com/en-us/windows/wsl/wsl-config#exp...
WSL2 is also pretty good at giving RAM back to the host Windows. I guess you're really running thin on resources if this doesn't do enough.
I have fond memories of using msys2 for gcc but I’ve never used it for more than that.
WSL1 was great and I loved it better on many aspect, until you needed to touch the filesystem.
I moved all my ML training and finetuning stuff (OSS LLMs, TTS, STT, Text2Img) to WSL2 and have only minimal overhead. A clean Win11 host eats away less than 2GB and I love how you can just use your cuda devices on WSL2, use something like micromamba and cmake your wheels while still being able to switch to Win tools whenever necessary. Idle Cuda devices use around 0.5GB vRAM.
Especially the two new experimental features in the last update of WSL2 added a nice QoL improvements:
- autoMemoryReclaim – Makes the WSL VM shrink in memory as you use it by reclaiming cached memory
- Sparse VHD – Automatically shrinks the WSL virtual hard disk (VHD) as you use it
Once i moved over; 99% of my (non time SKU related) quirks went away, and it's only vaguely heavier. Honestly, as a terminal-creature, I prefer WSL2 + Apt to OSX + Homebrew as my macs always tend to turn into a local package nightmare and I'd end up wasting a day/mo untangling. My WSL feels pristine still ~20mo later, and I know i could wipe and recreate it in ~30m if I needed to (but i haven't felt a need).
It still works for me on Windows 10. No idea what it'll be like beyond then.
My understanding from documentation is that WSL1 is "feature complete" but not "maintenance ended": they think they hit a strong Pareto Principal 80/20 for features in WSL1 and realize it won't support everything but often supports "enough" and any further compatibility issues are out of scope both because the tail is extremely long and the risk/reward of time invested into long tail issues are rarely worth it.
I don't think WSL1 will be "abandoned" any time soon, but the list of "Known Issues" will only continue to grow and a lot of people get pointed to WSL2 simply because the long-tail Kernel compatibility is hard to beat if you are directly running the Linux kernel.
But the many tools that work brilliantly in WSL1 still work brilliantly in WSL1 and there are still benefits to its barer/stranger metal approach.
I'm much happier for general browsing and dev - both have much fewer spontaneous crashes with reboot, and enjoy lower chance of OOM crisis thanks to the lighter OS and WM.
My windows requirement, Rhino 3D 7, runs in a Win11 VM with 5GB RAM and 25 GB of storage. The VM can crash violently without taking down my host OS, so CAD BSODs impact me like a regular app crash. The VM RAM use is a bit higher than WSL, requiring me to close the browser when I do CAD to reduce the risk of OOM. But in windows I often had to close WSL2 and the browser, for the same reason.
OOM will still lead to a gut wrenching lockup that require a reboot with 30% likelihood. That's probably because I don't run swap, out of a possibly unwarranted worry about NVME wear. To improve this, I'm looking at 3 solutions:
1) 4 GB of swap might give me a gradual OOM failure mode with plenty of time to kill apps as things slow down. It might even lower NVME wear by letting the OS swap static memory pages for pages of heavily used disk write cache.
2) CGroups can kill the Browser and VM if the system is near OOM. This is my favorite solution, since it would be nice to have this OOM behavior even if I adopt solutions 1 and 3.
3) A cheap upgrade to 32GB RAM would fix the problem, and also double my memory bandwidth. I can probably live without this, though.
TLDR; Even with ample room for improvement, my best "Windows + WSL2" experience comes from Linux + a Windows VM! The most mysterious crashes are so rare it's a little freaky, and the remaining crashes have clear solutions. I am happy!
If you are doing anything vaguely interesting, the time you are spending is costing a lot more than the drive would.
tbf; your problem is you're running a buggy app that wants more hardware than you have and handles it poorly. I spend 90% of my day at a unix prompt; but you'd likely see similar HostOS stability irmprovement going Windows -> Windows VM` as you did `Linux -> Windows VM`.
A few comments: 1) Ignore NVME wear; the drive controllers are smart enough nowadays to wear level; it will likely die sooner, but still outlive any machine you'll probably want to keep it in. 3) Buy the Ram. Whatever your motherboard fits, max it out.
tldr; Your time is more valuable than dealing with pain to try and min/max your hardware life cycle (and honestly, your wallet). The time you lost switching Base OS is likely worth more than the cost of a ram upgrade; not counting that you're still dealing with (30%?%??!) crashes over it. Value yourself and your time.