There is an experimental flag[0] in the .wslconfig which let's you set autoMemoryReclaim to gradual or dropcache. On my laptop I had good success with dropcache and on my countryside desktop with gradual.
WSL1 just doesn't work well enough. I'd never recommend WSL1 for anything. The extra nines in compatibility matter in development work if you have any dependencies in your projects.
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.
There is an issue between WSL/Hyper-V and the cache system on linux, WSL2 might LOOK like it needs 8GB but in reality if you check under it most of it is used by cache, if you lower the amount of ram dedicated it will do just fine.
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
I'm using wsl2 and noticed general responsiveness drops way down during finetuning (comparing to any other heavy cpu+gpu usage natively) . How's that working in your setup?
WSL1 was what made me stick to Windows at the time, when I had a new laptop and didn't want to mess much with it. WSL2 was what convinced me to switch back to Linux, since I felt that WSL1 was going to be abandoned. What is its current situation? Is it still maintained?
WSL1 was kind of amazing, IIRC it attempted to map all unix calls to their windows equivalencies. But there were edge cases and bugs when it just had serious problems. WSL2 came in, and is basically a simple local container. it isn't a buggy mapping, it is Ubuntu (or whatever you want to run).
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).
I've heard indirectly and off hand that some Microsoft PMs still regret calling it WSL1 and WSL2 instead of something like WSL-A and WSL-B.
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.
WSL2 is Linux, running a kernel tweaked to co-exist with the Windows kernel instead of being a pure vm. It's a VM with some container-like features like using the host's gfx drivers (which are like 100x better validated than Linux, except for compute workloads).
3 months ago I trashed windows and hopped over to Ubuntu Budgie for my CAD and Dev workstation running 16GB RAM, after 18 months of somewhat hating life in Win11+WSL2. This dropped my full crashe requiring reboot - from 5/week to less than 1/week.
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!
> my best "Windows + WSL2" experience comes from Linux + a Windows VM
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.
Are you worried about swap in the guest os? You can configure the swapiness of the OS, if you set it to 10 or something it will only swap when you're out of memory or when an application explicit says it wants swap memory (pretty rare). That can preserve your SSD and prevent your hard crashes.
I wonder if this author has tried Justin Tuney's Cosmopolitan to run Linux tools on Windows. Her last releases are shipping full set of multiplatfom compiled GNU tools.
They do work on windows. Even bash works. They do break sometimes but work when they do still. I used cosmopolitan's rsync on windows to copy stuff from sdcard but it was terminating randomly sometimes and I ended up using wsl.
This comment just made me realize Cosmo rsync might fix my weird issues with getting Vagrant to sync files over to my Unix VMs on my corporate Windows laptop. Thanks!
Am I the only one who said screw it, I'm getting 64GB of ram? The amount of concern about ram, it's not that much more expensive atm to get double or 4x if your already buying a laptop.
I dropped Windows instead. I decided to splurge on RAM when I built my PC a couple years ago, because I like to run lots of VMs simultaneously to test things out. I also use source based package managers which can use a lot of RAM when compiling things in parallel. I have half as much RAM as you, and it feels endless.
Yup. I've even debated 128. Though not because of WSL, i just do some work with high ram needs and having it for when i want it is worth it's cost, easily. Same for storage that isn't Apple based.
This. It's not that expensive; it's not worth your time dancing around over time. I Know it's an entitled view point, but engineers are also generally entitled.
Yes, since I can afford it. I feel bad for all the people out there who are students or otherwise under budget constraints. I go on Reddit or Discord and hear stories from people who are stuck on computers with 4GB RAM dating back to 2015 or earlier.
These people are being left behind, which is a shame. Part of the justification is that anyone who has such old hardware can’t afford to buy your products or services anyways, but that’s a very narrow capitalist lens. These are motivated, intelligent people who could better contribute to our society if we made sure that you could do good development work on old hardware.
EDIT add : >I wonder why that is not an option anymore.
In the particular context of the blog, the author deliberately wants to make MSYS2 the main environment when he wrote: "These prerequisites are not just to use mutt, but to use msys2 successfully in any capacity for development or other work."
Therefore, installing Cygwin separately for Mutt would work but it contradicts the goal of him wanting to use MSYS2.
Busybox for Windows is a great shell for people who want Linux look and feel on Windows.
Chocolatey may also cover more stuff than scoop.
Most developers should also be using Windows 2022 with Desktop. What you trade in one time agitation with i210 drivers you gain forever in zero cruft, and maybe more with file deduplication.
In terms of exciting stuff to program, it would be nice if Triton supported Windows.
The general case here would be that to be POSIX compliant doesn't demand the underlying OS is unix, only that the API/ABI and commands work in very narrow limits.
If you write to libc and a small set of dependencies and if you are in C, it should be possible to do things. If you want curses, you are walking into hairy areas.
I don't see how curses is an extra problem - it is written against libc like the regular programs and the windows terminal(s) are supported by terminfo.
I wish. "The Send-MailMessage cmdlet is obsolete. This cmdlet doesn't guarantee secure connections to SMTP servers. While there is no immediate replacement available in PowerShell, we recommend you do not use Send-MailMessage. For more information, see Platform Compatibility note DE0005."
This made me very, very sad in my last job as the de facto PowerShell expert.
re: using Unix tools on Windows, I do like that you can pipe the output of a program in WSL to the Windows clipboard (clip.exe). I was really surprised by this! I use pbcopy on the Mac for this all the time.
It's implimented as a magic filename? Not a virtual or real file that actually appears in a filesystem? You don't have to do something like mount a virtual fs that maps to your host windows fs like a bind mount or nfs mount, and also add that fs to PATH?
The entire point of WSL is seamless integration. Windows drives are automatically mounted as /mnt/c, the Windows PATH is added to the Linux one, and it can run Windows .exe files and communicate with their standard I/O.
The biggest advantage of WinGet is that it is installed out of the box with Windows 11, recent versions of Windows 10, and auto-installed into Windows 10 by update processes deeply back down (I think all the way back to the original Anniversary Edition).
A smaller advantage is WinGet's default installed sources use Microsoft CDNs for package metadata which are often whitelisted in firewalls or at least gentler in their MITM attacks, and WinGet's primary source (the "winget" source) uses canonical installer URLs rather than repackaging (pulls the same EXE/MSI installer that you would if you went to a download page manually). That combination of well known URL patterns generally means WinGet has a kinder experience with corporate firewalls and corporate anti-virus tools than scoop can provide.
Where scoop differs, which might be good or bad depending on your point of view, is that it installs software to its own location, and self-updating apps don't self update. So, tutorials and programs have to take Scoop into account[1] since they won't be installed to their usual locations (bonus: scoop itself can be installed to your users home directory, or to C:\ProgramData\scoop).
Another wart is that maintainers of scoop recommend using scoop + winget[2].
I think it's neat, but personally, I just use winget to install things, and a variety of portable apps on a secondary drive (in fact, winget supports installing one-off programs to random locations). Another nice thing about winget is being able to update and manage software that wasn't installed with it too.
Just want to weigh in and say that scoop is fantastic.
The genius insight behind Scoop is that Windows doesn't need a dependency manager because pretty much all programs ship with their dependencies included. So all you need is a way to download & run installers automatically, from the command line, into a Scoop-controlled directory.
Mutt is exactly something that would be nice to rewrite in Rust, moreover, splitting into various crates of working with email, so that it will be possible to reuse the same code for both TUI and GUI clients.
> so that it will be possible to reuse the same code for both TUI and GUI clients.
Why must a generaly good improvement these days always start on HN with "rewrite in rust" like it's the only language which still matters. Leave that up to the developer to what they prefer for the job.
> Why must a generaly good improvement these days always start on HN with "rewrite in rust" like it's the only language which still matters.
I'm guessing so that its likely to 1) be safer by default, 2) likely to get more contributors, 3) more likely to work cross-platform, and 4) more likely to get attention and survive as a project.
"memory safe by default" but not necessarily "safer" by default. A code base that has been battle tested in production for decades will likely be safer in every other way than an entirely new project that has got thrown up on a git repo yesterday.
It took only a second to see what I would miss as like on most of the mail clients: why isn't it possible to configure the list of mails to see not only the sender but the e-mail address? I only know three e-mail clients where I can configure it: mutt, betterbird and evolution.
But maybe I'm old and no one would like to see that "bill gates <fake@bad.boy>" is not from bill gates before opening the mail (and render the contents). The phisher are thankful.
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.