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.
Those machines generally come locked down, so you need permission to install stuff like WSL. I had such a machine and asked if they could unlock WSL, and their answer was no, because Security was busy enough keeping the Windows installs reasonably secure. Which makes sense tbf. Would be surprised if that was much different in other places.
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.
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?
I think that because the majority of people in HN work building SaaS, they tend to do Linux server related work heavily. The ones that dont, do iPhone work, so they are in a worst place (with Windows).
Other than that, I believe the productivity tooling is better on Windows.
I myself fall in the SaaS category, so Windows doesn't give me anything. On the contrary for whatever reason after mainly using Linux/OSX for 15 years, Windows just feels clunky and like it "gets in the way". WSL is a good hack/workaround, but unless I MUST have Windows as OS (because of a work provided Laptop that cannot be Linux), i dont see a point of using 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.
Yeah, WSL was the gateway to daily driving for me. I'd played with Linux as a kid, came back via WSL, and quickly came to the conclusion I'd be best off without Windows.
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.
Windows Containers, owing to how NT itself is put together, are incredibly awkward to use. Container images have to go all the way down to smss.exe (the NT equivalent to init), which ties you to a particular kernel patch level.
Upgrade the container host? Re-bake your container images. It's a massive pain in the ass.
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.
My memory is a bit foggy, but the original WSL promised a much more ambitious integration with Windows, sort of container-like. It had a lot of rough edges when I first tried it, but they promised they'd work on it. That, together with their promise that W10 would be the 'last' Windows and they'd switch to a more OSX-style rolling release model was what pushed me to adopt Windows in ~2016. In the first years of Nadella it really felt like MS would listen to developers. Within less than two years iirc they'd given up on the WSL ambition, with WSL2 being a mere VM with noticeably worse performance for some of my workloads, and completely reneged on their W10 promise, even vowing to make my newly purchased hardware obsolete.
In summary, I really couldn't care less what improvements they make to WSL, and neither should anyone else, imho. If you want Linux, for the love of god just use Linux. Emulation works great the other way round by now.
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.
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.
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.
But everyone knows that performance of WSL is nowhere near native linux on the same machine.
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.
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.)
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.
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.
Other than that, I believe the productivity tooling is better on Windows.
I myself fall in the SaaS category, so Windows doesn't give me anything. On the contrary for whatever reason after mainly using Linux/OSX for 15 years, Windows just feels clunky and like it "gets in the way". WSL is a good hack/workaround, but unless I MUST have Windows as OS (because of a work provided Laptop that cannot be Linux), i dont see a point of using WSL.
Maybe those are interesting as teenager hobbies as well.
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.
Haven't regretted it for a second.
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.)
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.
Upgrade the container host? Re-bake your container images. It's a massive pain in the ass.
They're missing things like winget as well, but that's mostly an inconvenience rather than a blocker.
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.
In summary, I really couldn't care less what improvements they make to WSL, and neither should anyone else, imho. If you want Linux, for the love of god just use Linux. Emulation works great the other way round by now.
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.
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
For me, Claude bypassed my sudo security by executing `wsl.exe -u root`. The Claude does not need any sudo password :)
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.