I jumped ship from Windows a couple of years ago after having used it since the early 90's. One of the primary reasons was how much I had to fight with WSL2 in my day-to-day work. But now it's becoming even more apparent that Microsoft does not care about its operating system. I don't even know what they could do to get me back. Trust continues to be a huge problem in the AI era of Microsoft.
I'm a hardcore Linux user, but it's a fact of life that laptops are not very well supported. There are some that are very compatible, but generally speaking, I need to trade off software (Linux compatibility) for hardware (laptop choice) or viceversa.
WSL allowed me to choose any laptop I want and run the subset of Linux that matters for me. For my use case (that is, not quickly accessing huge amounts of files, performance was ok - as a matter of fact, the author of the article got a very reasonable performance loss on realworld tasks (-4% ~ -16%).
The only thing that I found truly irritating is attaching USB storages, but I ended living with that.
Honestly the performance hit of WSl even being alive and running in the background of my XPS was so bad I just ssh into a workstation and do everything on there instead. Trying to get windows to just be usable is such a massive pain in the ass.
It's the same thing. Seems like the major version bump is to advertise WSLc, which is like Apple containers - an SDK for launching Linux containers as part of a Windows app.
That is quite relevant, and compose ability is on the way, or for some workloads Aspire would be an alternative I guess.
Unfortunately most companies are too cheap to pay for Docker Desktop, and having Windows containers depend on a third party tool has been a problem in such customers.
Because using Rancher Desktop or Podman isn't also a given, due to similar issues.
You’re not supposed to work out of the /mnt/c. A lot of people make this mistake and then complain that WSL is slow. On the native linux file system WSL is 100x faster for everything
9P is very slow for certain operations (such as, for example, git from either direction).
virtio is not enabled by default because its buggy in certain corner cases, and will be enabled by default when it stops doing that. That said, I do have that enabled, it is certainly faster.
And yet I had results perfectly within the range of "good enough" having an ai harness muck about in a work folder in a docker mount on a 9P mapped drive under permanent observation by an intelliJ instance on the Windows side before some buggy Windows update made it occasionally lock up under `npm i` sized filesystem loads. Crazy how far we've come.
Despite the container support getting most of the attention, I discovered a measurable performance improvement with WSL3 by accident. Luckily I had another machine to upgrade so I ran an AB test comparing WSL 2 to WSL3 .
If you want a real bump in performance, I have a clever trick . Hardware isn’t cheap these days, so we demand the most of our software.
> If you want a real bump in performance, I have a clever trick . Hardware isn’t cheap these days, so we demand the most of our software.
Good trick: get rid of the superfluous Windows layer which stands between that expensive hardware and your target OS. It takes up valuable memory, CPU time and storage space, introduces latency where you don't want it, exfiltrates data to unknown destinations and can decide to "upgrade" itself without warning.
Good tricks need catchy names to succeed so how about NoSL?
ok great benchmark! I work with herdr/pi for dev work and need to use a windows machine from my company. WSL currently unfortunately lags so much when typing, not sure why when using herdr... Using powershell, some features are missing, so i can't wait to try WSL3 and hope for improvements.
... does it lag on the shell or does it lag when you are in some vibecoded "TUI" njs monstrosity? Because if the latter, the issue is probably not cause of wsl...
herdr might be the culprit there, it can significantly slow down tui apps with its terminal capture. This happens on mac/linux, WSL will surely make it worse.
Unfortunately that acquisition option isn't available in most physical stores, where normies buy their computers, even though there isn't a single OEM not running some distro on their data centers.
You can get a refund for that useless Windows licence but that is a bridge too far for most "normies" whether they buy their computers in brick-and-mortar stores or online. If that process could be streamlined somehow..
everything I use it for executes virtually instantly, 60% slower than virtually instantly is still virtually instantly.
If something is slow on WSL, but not on bare metal linux, it means that the application is slop that only works when MAXING OUT your CPU, it's slop, the app is the slop
Most of the overhead in virtualisation of the sort used by WSL2+ is not CPU throughput, but other hardware access (mostly IO, but for GUI apps display access can have a significant penalty). Things that are just spinning a couple of CPU cores doing number-crunching work and similar see significantly less penalty in VMs than those that perform much IO, unless of course there is much competition for host resources or for some other reason they get passed around cores so see many more L1 cache & TLB misses.
Some things need to max out the CPU, certain compile steps for instance, that is not slop that is code doing its job. Others need significant IO, often random IO, certain other compile/link steps for example, that is not slop. Sometimes if you knew your code was likely to be run in a VM rather than on bare metal you might design it slightly differently to reduce its sensitivity to the detrimental effects, but not having done so doesn't make your code slop. There might be some room to blame slop for UI slowness as a lot of code out there updates their display in an in inefficient manner that is actually noticeable on bare metal too, especially when it unnecessarily uses 3D accelerated compositing or similar and something causes that to fall back to software rendering, but even then if it works well enough in the intended environment calling it slop is perhaps unfair.
For me, Claude bypassed my sudo security by executing `wsl.exe -u root`. The Claude does not need any sudo password :)
I'm a hardcore Linux user, but it's a fact of life that laptops are not very well supported. There are some that are very compatible, but generally speaking, I need to trade off software (Linux compatibility) for hardware (laptop choice) or viceversa.
WSL allowed me to choose any laptop I want and run the subset of Linux that matters for me. For my use case (that is, not quickly accessing huge amounts of files, performance was ok - as a matter of fact, the author of the article got a very reasonable performance loss on realworld tasks (-4% ~ -16%).
The only thing that I found truly irritating is attaching USB storages, but I ended living with that.
But everyone knows that performance of WSL is nowhere near native linux on the same machine.
I still use Win10 for a few things, including testing stuff works there too, via java. I switched to Linux in 2004 or so, though.
Now there is virtio support, finally no need to depend on external CLI tools for what should have been in the box on day on.
Until now, even for Windows containers, we needed some Docker compatible CLI tool.
EDIT: stumbled on the previous HN post here: https://news.ycombinator.com/item?id=49970507
Unfortunately most companies are too cheap to pay for Docker Desktop, and having Windows containers depend on a third party tool has been a problem in such customers.
Because using Rancher Desktop or Podman isn't also a given, due to similar issues.
I found that seems like anything under /mnt/c goes through 9P
vscode extensions using ripgrep in parallel in the background (there are many!) are killing the vm.
I now decided to follow Mitchell Hashimoto choice and use VMware Fusion and simply do all my work inside of it.
virtio is not enabled by default because its buggy in certain corner cases, and will be enabled by default when it stops doing that. That said, I do have that enabled, it is certainly faster.
Agents take more time than building Docker images.
If you want a real bump in performance, I have a clever trick . Hardware isn’t cheap these days, so we demand the most of our software.
Good trick: get rid of the superfluous Windows layer which stands between that expensive hardware and your target OS. It takes up valuable memory, CPU time and storage space, introduces latency where you don't want it, exfiltrates data to unknown destinations and can decide to "upgrade" itself without warning.
Good tricks need catchy names to succeed so how about NoSL?
If something is slow on WSL, but not on bare metal linux, it means that the application is slop that only works when MAXING OUT your CPU, it's slop, the app is the slop
Some things need to max out the CPU, certain compile steps for instance, that is not slop that is code doing its job. Others need significant IO, often random IO, certain other compile/link steps for example, that is not slop. Sometimes if you knew your code was likely to be run in a VM rather than on bare metal you might design it slightly differently to reduce its sensitivity to the detrimental effects, but not having done so doesn't make your code slop. There might be some room to blame slop for UI slowness as a lot of code out there updates their display in an in inefficient manner that is actually noticeable on bare metal too, especially when it unnecessarily uses 3D accelerated compositing or similar and something causes that to fall back to software rendering, but even then if it works well enough in the intended environment calling it slop is perhaps unfair.
The Year of Desktop Linux is delivered on VMs.