Proton, Copilot, and literally this single issue are what pushed people to Linux. If I were in charge there would be a team devoted to fixing this a decade ago.
WSL singlehandedly stemmed much of tide of developers moving away from Windows, but WSL native filesystem performance gave devs that magical experience when they boot into Linux the first time and see that the filesystem doesn't have to be ass. There's always been hacks around this, but for many devs the easiest hack was to ditch Windows.
They should have moved heaven to fix this on day one, there's really no engineering excuse. Linux is open source.
Just a comment on Proton... I've recently shifted to linux (garuda ) as a native OS for gaming (still dual booting, but linux is my main OS now, I used to run linux VMs in windows). My experience with Proton is that only ~30% of my games work out of the box. Some games like dota2, and factorio are native linux and work MUCH better (faster/higher fps) in linux. A bunch of windows games work fine, other's semi work, and I have to spend a bunch of time investigating why I'm getting the issues I'm getting. Others just aren't really supported (it seems anti cheat software is a big blocker) or I just can figure out what is going wrong quick enough that I just abandon it. Overall, everything seems better in linux world, everything is really snappy. I'm hoping more game companies treat linux as a first class citizen as more people switch. It is definitely a great platform for gaming but really just needs game creators to ensure their games work, ideally native, but even just using Proton would be good.
Isn't Garuda an arch distribution? It could be that (less common, so more issues). Running SteamOS likely has better chance of running games, but yeah the linux experience is not streamlined at times (but it is functional!)
It's very very rare for me that games don't work. It's almost all competitive games, where the game specifically does not allow anti-cheat.
There's very little fiddling around or configuring. 30% sounds god awful terrible; my success rate definitely >85%. In the rare case something doesn't work right away, https://www.protondb.com/ usually has advice in the top or second comment that works great.
I don't really think the windows vs Linux native debate is worth pursuing. Windows games run better than they do on Windows 4 times out of 5, and that's more than good enough.
> Proton, Copilot, and literally this single issue are what pushed people to Linux.
This isn't the only issue. I think another big issue is pushing more and more integration with Microsoft cloud services (e.g. Microsoft accounts), advertising, etc, which Microsoft has made increasingly difficult to opt-out of. They could fix every single technical limitation anyone has ever complained about, but if they don't change their corporate culture on forced cloud/advertising/etc, many won't care about those fixes.
Yeah, my switch to Linux and Mac for most things is more about just finding Microsoft's policies so obnoxious and hostile that I just won't deal with them anymore, even if I have to deal with more technological hassles. The only reason I haven't completely nuked my Windows partition is because I can at least use Rufus to turn off the worst stuff. But frankly, the amount of software that keeps me on Windows is dwindling fast, and every time Windows update resets my browser to fucking Edge or signs me into a Microsoft account system wide without my consent I just get that much closer. It feels like malware at this point.
Tangentially , I was a heavy used of wsl and moved to linux a few months ago and LLMs made most of the downsides of using linux as a desktop go away for me. I chatted with claude about the migration to find the best distro, decided on Fedora. After the install I asked everything I wanted to configured and got straight answers. In 3 or 4 hours I had an even more comfortable experience than I had on windows. AI made the annoying parts of trying to figure out how to edit all the config files to have linux behave the way you want very easy. I also had claude code write a bunch of scripts that I could have done but would probably never bring myself to actually do it . WHen you have a coding agent readily available , having an open source desktop environment makes a lot more sense. I encourage everyone to try it.
On the other side, I am a lifelong Linux user, and even with advanced LLMs, trying to get Microsoft Windows to behave sanely takes hours every month for years on end (thanks, day job). Things Linux figured out in 2003 are still magic or completely undoable on Windows.
I also did this as well as learned pfSense then OPNSense when pfSense went bad. Also made a pretty complicated XCP-ng setup. Learned all this with the ancient ChatGPT 3.5-4.0 models.
I can hear a subset of people cringe saying "but LLMs are BS machines and you aren't learning anything!" I heartily disagree on both fronts. The main thing holding users like me back from linux was always the snarky RTFM community and the fact that everything has 25 different answers (depending on distro, window manager, and many other factors). LLMs take care of all this friction for you very nicely.
I did this too, made switching my desktop to Linux so much smoother. I have a Windows laptop for my Windows needs and most of my gaming is fine on the Steam Deck, so I realized I didn't need to always boot into Windows only to use WSL.
This. It is hard to exaggerate how easy Claude Code (or, I'm sure, any number of other harnesses of choice) makes it to migrate to a new operating system.
It is truly a Star Trek-level experience. Nobody who doesn't want to run Windows (and who isn't forced to run it) needs to run Windows anymore.
/mnt/c is a mounted C: drive in WSL2, that allows WSL2 guests to read/write files on the Windows host.
The mount is fine and speedy enough, but the underlying reads/writes turn into native NTFS reads/writes through Windows. NTFS file API is incredibly slow - high fixed overhead for initial file access.
So patterns like node_modules with many small individual files (or compiling code in general) are much much slower on Windows or WSL2 /mnt/c due to the fixed overhead adding up over a large number of files.
It's a ridiculous problem that has plagued Windows for years.
Could you expand? I never understood why this was considered acceptable, how is windows filesystem so slow compared to linux?
I am familiar with the issue, doing any sort of ruby development is a nightmare on windows because each require loads a file becoming increasingly slow at boot time
One example is that if you have a node modules folder on Windows and you try to delete it from WSL it can take 10 plus minutes whereas if you deleted it directly in Windows it would have just taken a few seconds
Also if you try running Next js from files on Windows from WSL it takes minutes for each page to compile to the point that any local development is impossible so you would have to either run the Next JS server on Windows or move the files to WSL
Anything with node_modules takes ages on my Windows machine, whether it is through WSL, Docker or direct, largely in part due to corporate filters, checks, anti-virus and malware protectors and endpoint control.
WSL2 is a VM based on a Windows virtual disk file (VHD). inside that VHD IO is quite fast , a couple degrees worse than native. /mnt/c is how you access your windows files, but it's slow like NFS (socket based). anything needing high IOPS will be dog slow e.g. compiles, file scanning, etc.
the rule of thumb without the newest features is to copy work to/from /mnt/c into $HOME as needed.
Same here, though I went to Linux first for several years. WSL file speeds, especially when running npm install, were the impetus that ultimately got me to switch off of Windows.
Either you run npm install from Windows if you are operating on the Windows file system or you run it on WSL if you are operating on the WSL file system both cases will be very fast
Well before Windows I spent years with both Linux and Mac and I found Windows to be a good mix of stability and suitability for development now that WSL is a thing. Also for gaming it's the best by a long shot so just all around I've found it to be best and WSL made me never miss Linux.
Unlikely due to the better and more stable NVIDIA drivers available to Windows and the greater compatibility with every game without having to mess around with configuration files or other hacks. But you do you.
Of course just a personal experience, but I feel like I'm getting a much more stable experience with AMD in arch+sway/i3. Some of my friends with RTX5080s and such frequently crash on alt-tab or just simply from opening Steam overlay in their W*ndows setup.
Even with tiled windows I haven't had any game crash like that once. "alt-tab" equivalent takes 1ms and it just works. I can throw around the game window between workspaces, resize etc.
It's worth giving it a try. Unfortunate if games with certain AC setups are wanted, like GTA:O or LOL, but I can live without them.
> better and more stable NVIDIA drivers available to Windows
Huh? It's the same driver. It works the same on every platform. There's no consistent difference in performance (at least not between FreeBSD and Windows, it's been a while since I ran Linux).
Linux drivers are now first class and are faster and easier to install than any Windows drivers. There's no bullshit extras with them. They just work. Plus steam launches games in containers so there's zero configuration. If you don't know what you're talking about it is in fact better to say nothing than to just make shit up.
Here's a pre-configured Fedora based distro that is zero clicks. You sign into Steam and go. Drivers are preinstalled. You literally sign into steam and hit play.
Oh yes, I distinctly remember having to use an outdated driver from a third-party repository to fix some sort of compatibility issue. Never had to do that on Windows
Believe it or not, there's plenty of people that specifically choose windows, not just out of fear of getting fired or inertia. The idea that all devs use a mac and that windows is garbage for any kind of development is purely a silicon valley bubble thing.
And there's still a big niche that Windows is your only choice since the move to Apple silicon. If you need both a dGPU and access to commercial software, its literally your only choice. Game dev especially comes to mind if you're jumping between maya, after effects, etc. Windows is also huge in finance.
Windows _is_ garbage for a lot of modern development (except thise targeting Win32). But that does not matter to the ICT department tasked with controlling and securing all endpoints, preferring a single, very well known and controllable OS over freedom and performance.
Yea bro totally. Totally. I'm gonna copy 2TB of media into the WSL virtual disk just so ffmpeg can run a little faster but still way slower than simply running linux.
(I beta tested the shit out of WSL1 and 2) before I wised up and just installed Gentoo forever.
But either way yeah most people aren't dealing with large media libraries that's obviously a little more difficult. But if you are primarily operating on them with WSL then you would just keep them in the WSL file system and you could access them from Windows whenever you need to...
Indeed. I have my agent edited files in podman in Lima, under two layers, and it's fine, because I do most stuff within my podman VMs. (I have shared volumes so I can review things before pushing the changes to my forge in separate containers that the agent can't access. When I need stuff on my mac, which is the exception, not the rule, I just copy them, putting them in a tar or zip if it's a lot of files.
Nice to see a bit of good news here, WSL is an underrated component in enterprises, and quite often the only way you can get close to Linux. Windows and Macs feel like trading one cancer for another with different logos.
I was trying WSL years ago and this is one of the reasons I just moved to a full linux server instead. We still have way too many problems interfacing across filesystems. I hope with AI we will see an iteration on ExFAT that has all the journalling, versioning etc. magic of modern FS' and can be adopted across all 3 OSes. Probably a long shot but I can dream :)
it's kinda shocking how both WSL2 file perf and Docker for Mac file perf are so horrendously bad that you can just tank performance and have a 3x better local dev setup on most projects by using "normal" Linux.... and yet it's been the status quo for so long.
I don't get how people are so comfortable with dev tooling being as busted as it is.
I was always disappointed with the design of wsl2. The wsl1 design of a syscall layer atop NT had greater architectural purity. They way I heard it, they introduced a virtual machine into the design specifically in order to bypass poor NT filesystem performance. I'm sure it's easier said than done, but it would have been nice if they instead fixed the issues on the NT side, rather than side step them with a VM.
My (possibly uninformed) understanding at the time was that it was Docker, not solely filesystem performance.
WSL1's file performance is pretty much as good as it gets on Windows, since open(2), read(2), etc are all translated directly in-kernel from Linux to Windows API calls. It's still slower than a real Linux kernel since Windows' filesystem filter drivers add a lot of overhead to every operation, and Windows Defender and its realtime scanning in particular makes it 10x worse. (NTFS itself is fine.)
WSL1's filesystem situation is now "fixed" by Dev Drive, which is just a new partition with most filters disabled and Defender is put in to a different mode where scanning is asynchronous instead of blocking every open(2).
WSL2's mounts of Windows disks still has to deal with all of the above, plus the overhead of serializing every operation over a VM socket, which is largely fixed by what this article describes. So even if you've enabled virtiofs to speed up WSL2's cross-VM transfers, you're still going to hit the same Windows filesystem caveats that apply to WSL1 and native Windows apps.
On the other hand, the WSL2 in-VM ext filesystem (ie, the / mount) will be the fastest to Linux apps since it never touches the Windows side, but accessing those files from Windows sucks since they're buried in a VHD image, accessed over a slow 9p (I think) network-like mount on \\wsl.localhost\distro\
All of that to say filesystem perf may or may not have been a factor in the switch from WSL1's very cool NT persona architecture to WSL2's decidedly more boring VM design, but it was pretty clear that Docker was the real showstopper.
Devs needed to run containers, and WSL1 couldn't (and still can't) do it.
I imagine Microsoft took a look at what it would take to implement container support in the NT kernel to the point that Docker would work, and decided it was simply too much work when they could just slap a VM in and get the entire Linux kernel API surface for free. So thus we got WSL2.
I still use WSL1 for light work like running ssh, since there's basically no overhead at all (5 MB of RAM total to run ssh), compared to needing to run an entire second OS in WSL2. And as long as you don't need any containers, even heavier work runs nicely on WSL1 since there's no VM overhead or network NAT shenanigans.
> Windows' filesystem filter drivers add a lot of overhead to every operation, and Windows Defender and its realtime scanning in particular makes it 10x worse. (NTFS itself is fine.)
Are there a lot of Microsoft operating systems that feature NTFS without filesystem drivers and Windows Defender?
It's the filesystem filter drivers that slow things down, not the filesystem drivers (ie NTFS) themselves.
Filter drivers sit a layer above the filesystem driver and allow you to hook file operations to do things like antivirus scanning, transparent encryption and compression, realtime backups, and implement virtual files (à la Dropbox and OneDrive cloud files that are deleted from local storage and JIT downloaded when accessed).
Those are all useful features, but you pay for the extensibility with performance.
To answer your question, obviously no—at least not in a default configuration—but all that stuff can be disabled if you're so inclined, which would leave you with a Microsoft operating system featuring NTFS without the filters and Defender.
But I'm not sure what point you're trying to make. Different operating systems make different trade-offs?
Nice, FWIW this is currently pretty easy to solve by just keeping your stuff on a separate EXT4 volume and then mounting that under Windows. Windows accessing a mounted EXT4 volume through WSL is much faster than the other way around.
9P is in the kernel and provides a simple, fast networked VFS without many of the drawbacks of NFS. In particular, 9P-over-virtio is already used in Linux virtualization environments to expose parts of the host file systems to the guest. Since this solution was widely adopted and lying around, Microsoft's WSL2 solution also used 9P-over-virtio to expose the Windows file system to the guest Linux.
WSL singlehandedly stemmed much of tide of developers moving away from Windows, but WSL native filesystem performance gave devs that magical experience when they boot into Linux the first time and see that the filesystem doesn't have to be ass. There's always been hacks around this, but for many devs the easiest hack was to ditch Windows.
They should have moved heaven to fix this on day one, there's really no engineering excuse. Linux is open source.
reply