alt Hacker NewsThis is great and all... Except I’ve long given up on WSL. I really tried to make WSL work for many things, only to find the entire experience (reliability, performance, and beyond) was simply better in every way without Windows.
No matter what you do, there will always be some weird platform detection or line termination that pops up somewhere. And if it isn’t that, it’s degraded performance or kernel-level incompatibility.
Replies
I guess your YMMV. I switched from developing in Linux VMs to WSL about 3 years ago and have used it daily for development.
I don't do much OS level engineering these days though and would probably fire up some VMs for that.
> (reliability, performance, and beyond)
Considering it's just a headless linux vm with some integration with the host, I don't understand what reliability, performance or beyond it could possibly introduce beyond what any VM solution provides?
There are few gotchas with WSL. I hate how by default it includes your Windows path in your default linux path out of the box. It's easy to turn off and my init scripts for any VM always do that anyway, but it's the main thing I have seen people who are new to WSL get tripped by. It's useful to be able to run windows programs from within WSL. Like all the cli tools that pop up a browser to make you login, but that's about where its usefulness ends for me.
> No matter what you do, there will always be some weird platform detection
In my experience, unless you're running a very mainstream distro (read Ubuntu) there will always be a weird "platform detection" issue. I run openSUSE on most of my devices, and used to scripts not working because "uhhh, this is not Ubuntu or Debian or Fedora". The only time I run into "platform detection" issues are scripts that assume `uname -r` of a very narrow format.
> or line termination that pops up somewhere.
That goes back to my original comment about running Windows programs from linux, or moving files to/from linux. I never run into this issue because, just like on a linux desktop, I only interact with linux through the commandline. Even on a full linux desktop, I have this mental separation between GUI apps and terminal apps.
> it’s degraded performance or kernel-level incompatibility.
The only "kernel-level incompatibility" I run into is that WSL kernel doesn't have /dev/kvm. Granted I don't do a lot of kernel module specific development, so I don't know how something like a USB device or a PCIe interface can be passed to the WSL instance. But again, I'm thinking of it, and treating it like a user-mode development VM, not a full host.
Yes, I since embraced pwsh for terminal stuff on Windows. For everything else I switched back to proper VMs or remote hosts.
I've transitioned from linux back to windows for workstation usage, and it's one of the main features that allowed me to do so, I haven't had major problems, so I would be interested to know what issues you faced. Of course direct linux is better than WSL, but I found the product to be of very high quality and well integrated with windows.
100% agree. If anything WSL is a Linux onboarding experience at best.
maybe it was WSL1 ? WSL2 IO is excellent as long as you stay within the FS. And with VS Code WSL support , all IO & commands are remoted into WSL so there are no Windows/Linux compatibility issues.
I already given up on dual booting around 2010.
The only difference bettween 2010 and 2026, it that nowaday instead of having a mix of Virtual Box/VMWare Workstation depending on my work system, I have WSL 2.
However my Windows develoepr experience goes back to Windows 3.1, thus I mix and match my needs, between Windows and Linux sides.
WSL 2.0, and Virtualisation Framework are really the Year of Linux Desktop. /s
So there’s a good number of comments, I’ll try to address them:
- Yes, these issues persist with WSL2.
- WSL2 allows mounting between the system/subsystem, but there is considerable overhead.
- Using WSL for remote workspaces from the host is very much a mixed bag.
- Attempting to use WSL entirely with graphical applications has very limited/poor support.
- If you wish for VM acceleration, you have to use Hyper-V, not all toolchains work with Hyper-V and this heavily restricts the host machine.
- If you wish to do anything that crosses the subsystem and the host, line delimiters and platform detection are very error prone.
- If you accidentally misconfigure WSL2 (which is quite easy to do) the WSL userspace can have substantial access to the host files, often beyond what may be initially apparent.
- Of compatibility issues, non-standard socket implementations have caused a lot of incompatibilities with software for me.