Earlier quoted context omitted.
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.
It's great that gaming on Linux has gotten a lot better over the last several years but let's not pretend like Windows still isn't far ahead on this Also how can drivers be easier to install than on Windows when updating my GPU driver is one click?
WSL 2 is getting faster Windows file system access
71–80 of 178 posts
Re: WSL 2 is getting faster Windows file system access
#72Proton, 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…
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, an…
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.
Re: WSL 2 is getting faster Windows file system access
#73I switched from WSL (reconn'd to WSL1) to WSL2 because I thought that WSL1 would be abandoned. However, the shell for WSL2 runs in a window that grabs things, such as ^V. So, ssh from WSL2 (to AWS for example) is awkward. For exampl, Emacs on the AWS box is almost unusable.
https://github.com/microsoft/terminal
winget install --id Microsoft.WindowsTerminal -eRe: WSL 2 is getting faster Windows file system access
#74I 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.
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.
But if you need containers, you need WSL2.
Re: WSL 2 is getting faster Windows file system access
#75Re: WSL 2 is getting faster Windows file system access
#76Earlier quoted context omitted.
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.
Sounds like you were just doing it wrong 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
Re: WSL 2 is getting faster Windows file system access
#77Earlier quoted context omitted.
Sounds like you were just doing it wrong 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
My memory is murky here, but I don't think WSL even had two different file systems at the time.
Re: WSL 2 is getting faster Windows file system access
#78I 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 Def…
Are there a lot of Microsoft operating systems that feature NTFS without filesystem drivers and Windows Defender?
Re: WSL 2 is getting faster Windows file system access
#79I don't get how people are so comfortable with dev tooling being as busted as it is.
Re: WSL 2 is getting faster Windows file system access
#80Earlier quoted context omitted.
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 Def…
> 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?
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?