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.
What is "real work" in this context? I'm guessing from the context it's Linux kernel or driver development? Or perhaps bioinformatics workflows which use linux-only programs in some cases, especially with CLI-driven workflows?
Being exactly in GP situation, I would give a more charitable take.
We are not talking about a properly configured Windows workstation. We are talking about corporate PCs configured by an IT department that is completely oblivious to the needs of developers, most likely because developers are not their bosses. WSL is effectively an escape hatch.
Usually the stated reason is "security", and developers tend to do the greatest sin of corporate security: they run arbitrary code, and they even have the nerve to call it "their job"!
I don't work in corp IT, but I am convinced that people there are not stupid and they are fully aware of the "shadow IT" aspect of WSL, but they give it a pass because they are also aware that people have "real work" to do that would be impossible otherwise, given company policies.
> I don't work in corp IT, but I am convinced that people there are not stupid...
No, not stupid, per se. I generally don't like to blame people for the situations in which they find themselves. But there is something else going on.
I find the folks in such IT departments are generally not very good at their jobs. One potential reading of this is that it is not the people working in the jobs' fault, it's the design of the corporate leadership by not paying well enough for the job to get better people.
But the knock-on effect would be, if corporate paid better, at least my IT department would look completely different. The people we have now would be replaced by much more competent people. These more competent people would also generally be folks who shower and wear clothes that fit, that they don't let one corner of their shirts hang out the waist of their pants, that didn't show up to a service call wreaking of cigarette smoke. I'm not expecting people to spend more money on nicer clothes, I already established they don't have that money. I am expecting people to take care of their basic hygiene and present themselves as best they can. That they don't is a signal they don't really care about their own professional development. If corporate paid better, IT wouldn't be staffed by a bunch of literal slobs.
Though they are in a bad situation, I don't have a lot of respect for the folks in my IT department, because the only job they have, the one they have been sticking to for some time, they are only doing the bare minimum. I've been poor. I've been in jobs I hated. The only way out was to suck it up, present myself well, get better at my job, and go somewhere better. I have a hard time respecting anyone who just gives up.
(To be fair, there actually are a few who do appear to be doing this, but they are few and far between. They also don't last long, because again, they go on to something better. I'm talking about the kind of people who don't put in the effort and then complain they never get anywhere.)
>I find the folks in such IT departments are generally not very good at their jobs.
Because their job is keeping their job, not making the 50 developers in the 5000 person org happy, as those are not their bosses.
You judge their competency from the perspective of a dev in the trenches, but the way management judges their performance is vastly different: keeping IT cost center spending as low as possible(hence a lot of IT offshoring) and security as tight as possible (hence MFA, EDMs and MDMs shoved everywhere that don't led you run anything besides notepad and Edge). Whether this hampers the devs or not is irrelevant for them or for management (outside of purely tech companies) since this is the devs' problem to deal with, not IT's problem. The moral is as long as it's seen as a cost center and not a profit center, there will never be right incentives to have a competent IT department staffed by competent people.
And keep in mind that a lot of the hidden champion engineering companies that make the world go round still function on excel sheets with VBA scripts as their "tech stack", and as long as that runs, management is happy. If you tell them you want to run linux, python, node, docker on your notebook, they'll probably laugh in your face thinking it's some hacker alien gobbledygook.
I spend most of time in meetings and updating excel sheets.
Recently I needed a certain agent to help me automate some Excel stuff. Getting it to work in Windows was significantly harder if not impossible compared to WSL.
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.
Not even UNIX System V userspace obeys a mythical rule that only exists on a worshiped book by the FOSS community, most of which never used anything besides GNU/Linux.
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.
They finally fixed the networking thing a while back.
In current WSL2, Windows owns the IP address, the NIC, DHCP, ARP, etc, and it’s shared with the Linux VM.
It’s really kinda magic… Linux sees the same IP address as windows does, and you actually get address-in-use errors if Linux tries to listen on a port Windows is already listening on, and vice-versa. So there’s no NAT going on or any internal 172.x net within the Linux VM, you just run “ip addr show” and you see the same real IP addresses that “ipconfig” shows you in windows.
(I no longer have a windows installation but WSL2 got noticeably better with networking some time before I gave up on windows.)
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.
This is great, this is some good work. But, like an issue I described before with Linux kernel io-uring[1], this fails to test and demonstrate performance with a healthy server load.
This obviously fails to depict a healthy server load because it's just way too specific.
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.
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.
WSL has been god send for corporate employees who get a windows laptop but need to do real work.
But everyone knows that performance of WSL is nowhere near native linux on the same machine.
What is "real work" in this context? I'm guessing from the context it's Linux kernel or driver development? Or perhaps bioinformatics workflows which use linux-only programs in some cases, especially with CLI-driven workflows?
Delightful way to write off an enormous cohort of people and huge variety of work.
Being exactly in GP situation, I would give a more charitable take.
We are not talking about a properly configured Windows workstation. We are talking about corporate PCs configured by an IT department that is completely oblivious to the needs of developers, most likely because developers are not their bosses. WSL is effectively an escape hatch.
Usually the stated reason is "security", and developers tend to do the greatest sin of corporate security: they run arbitrary code, and they even have the nerve to call it "their job"!
I don't work in corp IT, but I am convinced that people there are not stupid and they are fully aware of the "shadow IT" aspect of WSL, but they give it a pass because they are also aware that people have "real work" to do that would be impossible otherwise, given company policies.
> I don't work in corp IT, but I am convinced that people there are not stupid...
No, not stupid, per se. I generally don't like to blame people for the situations in which they find themselves. But there is something else going on.
I find the folks in such IT departments are generally not very good at their jobs. One potential reading of this is that it is not the people working in the jobs' fault, it's the design of the corporate leadership by not paying well enough for the job to get better people.
But the knock-on effect would be, if corporate paid better, at least my IT department would look completely different. The people we have now would be replaced by much more competent people. These more competent people would also generally be folks who shower and wear clothes that fit, that they don't let one corner of their shirts hang out the waist of their pants, that didn't show up to a service call wreaking of cigarette smoke. I'm not expecting people to spend more money on nicer clothes, I already established they don't have that money. I am expecting people to take care of their basic hygiene and present themselves as best they can. That they don't is a signal they don't really care about their own professional development. If corporate paid better, IT wouldn't be staffed by a bunch of literal slobs.
Though they are in a bad situation, I don't have a lot of respect for the folks in my IT department, because the only job they have, the one they have been sticking to for some time, they are only doing the bare minimum. I've been poor. I've been in jobs I hated. The only way out was to suck it up, present myself well, get better at my job, and go somewhere better. I have a hard time respecting anyone who just gives up.
(To be fair, there actually are a few who do appear to be doing this, but they are few and far between. They also don't last long, because again, they go on to something better. I'm talking about the kind of people who don't put in the effort and then complain they never get anywhere.)
>I find the folks in such IT departments are generally not very good at their jobs.
Because their job is keeping their job, not making the 50 developers in the 5000 person org happy, as those are not their bosses.
You judge their competency from the perspective of a dev in the trenches, but the way management judges their performance is vastly different: keeping IT cost center spending as low as possible(hence a lot of IT offshoring) and security as tight as possible (hence MFA, EDMs and MDMs shoved everywhere that don't led you run anything besides notepad and Edge). Whether this hampers the devs or not is irrelevant for them or for management (outside of purely tech companies) since this is the devs' problem to deal with, not IT's problem. The moral is as long as it's seen as a cost center and not a profit center, there will never be right incentives to have a competent IT department staffed by competent people.
And keep in mind that a lot of the hidden champion engineering companies that make the world go round still function on excel sheets with VBA scripts as their "tech stack", and as long as that runs, management is happy. If you tell them you want to run linux, python, node, docker on your notebook, they'll probably laugh in your face thinking it's some hacker alien gobbledygook.
It’s been blocked a companies I have worked at. In one case it briefly worked but thereafter WSL lost network access.
Having a dress code would help filter out those who don't fit in.
Why on earth are devoting more attention to their clothes and smoking habits than their IT skills? I can believe those are bad too, but come on.
I spend most of time in meetings and updating excel sheets.
Recently I needed a certain agent to help me automate some Excel stuff. Getting it to work in Windows was significantly harder if not impossible compared to WSL.
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.
Some of us also do real work on Windows, ask Valve.
Is the excuse of teenagers every August when they ask for the latest and greatest laptop?
I can provide other examples of real work done on Windows, like Photoshop, DAW, and so on.
Maybe those are interesting as teenager hobbies as well.
Sure and there are billion dollar systems at every bank that runs entirely on VBA macros in excel doesn't mean its not structurally flawed.
Worse is better, isn't that the UNIX motto?
Usually when it's misunderstood
Yeah, it only applies when it is convenient.
Do one thing, and do it well.
Not even UNIX System V userspace obeys a mythical rule that only exists on a worshiped book by the FOSS community, most of which never used anything besides GNU/Linux.
Luckily I'm allowed use Hyper-V for Linux work
Guess where WSL runs on?
I had the opposite experience.
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.
Did you work out of /mnt/c?
My problems weren't performance related, aside from the occasional catastrophic memory leak; most of my biggest headaches were related to networking.
They finally fixed the networking thing a while back.
In current WSL2, Windows owns the IP address, the NIC, DHCP, ARP, etc, and it’s shared with the Linux VM.
It’s really kinda magic… Linux sees the same IP address as windows does, and you actually get address-in-use errors if Linux tries to listen on a port Windows is already listening on, and vice-versa. So there’s no NAT going on or any internal 172.x net within the Linux VM, you just run “ip addr show” and you see the same real IP addresses that “ipconfig” shows you in windows.
(I no longer have a windows installation but WSL2 got noticeably better with networking some time before I gave up on windows.)
Also no, I didn't.
I suspect they did. 100% of cases where people complain WSL2 was slow and I helped debug was this specific incorrect usage.
For me Win11 was the final stop.
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.
WSL2 is a different product from WSL1, not a different version. Is WSL3 now a different version of WSL2 or another separate product?
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.
I guess windows containers where dead on arrival?
Not dead on arrival, just extremely expensive on arrival for commercial/production use-cases, unless you're using Windows Containers on Azure.
They're missing things like winget as well, but that's mostly an inconvenience rather than a blocker.
Not dead, but they are ridiculously buggy. Much like WSL.
Looks like a different version of WSL2 with a newer kernel and newer VM host software
An evolution, better said.
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.
Great job in benchmarking! I wasn't even aware of the WSLc (WSL3) release. For others, the release info is available here: https://github.com/microsoft/WSL/releases/tag/3.0.1
EDIT: stumbled on the previous HN post here: https://news.ycombinator.com/item?id=49970507
Is it accurate to call this WSL3? WSL 2 was released in 2019, but WSL 2.0.0 was released in 2023 https://github.com/microsoft/WSL/releases/tag/2.0.0
No I think it's more accurate to call it WSL Containers, or WSLc, but the release is indeed WSL 3.0.*.
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.
Dockefile is still a thing.
And?
syscall/basic getppid() throughput 1,474,691 ops/s 1,533,399 ops/s +3.98% Entry/exit latency 0.6781 µs/op 0.6521 µs/op -3.83% sched/pipe 100k process ping-pong 48,445 ops/s 54,589 ops/s +12.68% Context switch latency 20.64 µs/op 18.32 µs/op -11.25% sched/messaging Hackbench (20 groups, 800 tasks) 14.507 s 13.047 s -10.06% mem/memcpy glibc default bandwidth (1GB) 7.84 GB/s 12.64 GB/s +61.35%
This is great, this is some good work. But, like an issue I described before with Linux kernel io-uring[1], this fails to test and demonstrate performance with a healthy server load.
This obviously fails to depict a healthy server load because it's just way too specific.
1.https://news.ycombinator.com/item?id=44604793
Lot of the WSL2 lag is not the VM itself, it's the 9P file sharing and interop.
I found that seems like anything under /mnt/c goes through 9P
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
On my work laptop I made the lazy/naive mistake of mounting my projects from macOS into devcontainers running in Colima.
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.
From the perspective of user empathy, wsl seems to be designed for that use case. but the implementation/defaults can be improved
There is virtio support now, and to be fair 9P was never an issue for me.
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.
Since nowadays I use WSL to run immutable containers, and not really classical Linux Desktop, it isn't something that bothers me.
Agents take more time than building Docker images.
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.
I am not sure about WSL in general right now - no matter if WSL3 is more performant.
For me, Claude bypassed my sudo security by executing `wsl.exe -u root`. The Claude does not need any sudo password :)
Isn't this just WSL2 v3?
I find that stuff that it offers over a normal Hyper-V VM is stuff that I don't need, leaky abstractions galore.
Nowadays I use it mostly for Linux containers.
Well, you can use linux-tools on windows too. I kind of compiled most of LFS/BLFS on it, and it works. So it just gives you more options.
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...
The TUIs alone work fine, so something must be done by herdr to make it slow...
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.
WSL is one of the few good ideas Microsoft had in the last ... 5000 years or so.
Amazing they managed to make virtualisation that slow in WSL2
And yet it's still factors faster without a whole Windows around it.
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.
Yeah, I haven't dual booted in decades, it started with Windows 7 and VMWare Workstation for me.
The Year of Desktop Linux is delivered on VMs.
Links to benchmarks?