Mutt on Windows Without WSL
blog.djhaskin.com
blog.djhaskin.com
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.
WSL1 was great and I loved it better on many aspect, until you needed to touch the filesystem.
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.
[0] https://learn.microsoft.com/en-us/windows/wsl/wsl-config#exp...
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.
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.
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.
The author uses MSYS2 which is based on Cygwin: https://www.google.com/search?q=msys2+based+on+cygwin
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.
The author probably prefers the MSYS2 way, but Mutt should work fine under Cygwin without requiring jumping through the hoops the author describes.
Yes, this fragment is what my reply was about.
>it is not Cygwin (as opposed to how, say, Ubuntu is based on Debian).
I agree and that was not what my reply was claiming.
Instead, I interpreted the gp's comment as being unfamiliar with MSYS2 and how it's related to Cygwin to fill the use case for a UNIX-POSIX-emulator.
Extra trivia... as for whether "MSYS _is_ or _is not_ Cygwin" is a matter of context and particular person's perspective for comparison. Examples:
"MSYS is not Cygwin": https://news.ycombinator.com/item?id=11390890
"MSYS is Cygwin": https://news.ycombinator.com/item?id=11390961
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.
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.
https://learn.microsoft.com/en-us/powershell/module/microsof...
This made me very, very sad in my last job as the de facto PowerShell expert.
For others, it really is just as easy as `ls | clip.exe` to pipe into your clipboard on WSL.
`ls | tee clip.exe` if you want to print as well as copy.
And of course you can just set an alias if you want to shorten clip.exe to clip.
Great tip! Thank you!
If so, that sounds terrible, and very Microsoft.
So good then.
And there's no unclip.exe. You'd have to use `powershell.exe get-clipboard`, which is pretty slow.
I use this simple alternative: https://github.com/equalsraf/win32yank
`echo caña | win32clip.exe -i` and `win32yank.exe -o`
I managed to run unix tools in cmd, so I can run both windows & unix commands togheter. It required adding msys2 into the environment variable.
How good is the community repo?
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.
[1]: https://github.com/microsoft/vscode/issues/123205#issuecomme...
[2]: https://github.com/ScoopInstaller/Scoop/issues/3691#issuecom...
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.
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.
Configuration -> Preferences -> Display/Summaries -> Message List -> Displayed in From Column: Name | Address | Name and Address
https://pimalaya.org/himalaya/cli/latest/configuration/outlo...
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.
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.