4 ms·

Except it didn't work and had awful performance as soon as you did any syscall (this is especially apparent for filesystem access). It's a neat idea, but Linux

Except it didn't work and had awful performance as soon as you did any syscall (this is especially apparent for filesystem access). It's a neat idea, but Linux has over 300 syscalls with varying levels of complexity in their behavior.

WorldMaker 3y ago
It worked fine, a lot of people are still using WSL1 and the Windows Android Subsystem is still closer to WSL1 than WSL2, and in that case in Windows 11 Microsoft is even selling that to ordinary users in the Microsoft Store. The performance was never that bad, depending on your use cases is all. Admittedly a lot of use cases for developers are heavily file I/O bound or deal with dark details and edge cases of syscalls rather than the happy paths (because developers gonna develop), so of course developers felt the performance sting there. (I'm very curious if WSL1 on the soon-to-come Dev Drive has good performance, because it will bypass a lot of the file I/O filter drivers that caused some of the worst WSL1 performance for developers. That seems like an obvious and interesting win, if the case.)
- TeMPOraL 3y ago
  I wonder how much of the WSL1 I/O performance had to do with the syscalls, and how much with them being visible to Widnows Defender and other anti-malware software, which all like to hook into every single file I/O operation userspace programs do. WSL2 I believe, being a full-fledged VM, gets to hide from those checks. In my experience, WSL1 was fast enough even on large git repos with lots of files (after tweaking some Git settings), but performance crashed once corporate nuked my Defender exclusion lists, making both the repo and the entire WSL1 filesystem suffer from "real-time checks" on every file write.
  - WorldMaker 3y ago
    Anecdotally, I never felt like syscall performance was an issue, it was always File I/O (and yes "real-time" A/V is always a massive issue for File I/O on Windows). The issues with syscalls to me always seemed to be more around obscure compatibility than performance. Apps would crash that shouldn't because they relied on a weird POSIX edge case (that they maybe shouldn't). It always seemed more to me on the general syscall front beyond File I/O that "app just doesn't work at all" rather than "app works slowly". That said, I've never been a heavy WSL user so my experiences may have been limited in some of the syscalls people were complaining about. WSL1 was "fast enough" for my use cases. I'm very curious if WSL1 on the incoming Dev Drive which takes a different approach to A/V exclusion among other things and file I/O in general would be as good or better than WSL2 performance.
    - TeMPOraL 3y ago
      I never experienced those syscall issues, despite being a heavy WSL1 user, but that's probably because my uses are pretty narrow - I use it to run Emacs, and do all the usual stuff stuff you do with Emacs, which mostly involve reading and writing text files, and occasionally shelling out or running git. Well that, and a C++ language server, which mostly involves file I/O and some in-memory data reshaping. Within those use cases, I hardly had any trouble with anything - the worst things so far was 1) clipboard occasionally breaking, which I'm now 95% convinced is a problem with PowerToys, not WSL, and 2) Emacs leaking memory, which is what you get when you build it from sources at the tip of the main branch. I haven't had anything bad happen I could clearly attribute to WSL1. RE Windows Defender, this is not a problem on my personal machine - as long as you can set up exclusion rules for real-time scans, it barely registers. Unfortunately, at work, security policies got updated, erasing my exclusions and preventing any changes to it. WSL2 doesn't seem to be affected - I suspect simply because its VFS is opaque to Defender - but it's not without problems. Most annoying of them is that network traffic to/from WSL2 gets blocked by the company VPN, which isn't the case with WSL1. I'm yet to find a workaround for this. (And yes, the VPN maker has plenty of support issues opened about WSL2 issues, and it's addressing them about as eagerly as Microsoft is addressing WSL2 tickets on Github.)
      - WorldMaker 3y ago
        Yeah, most of my use cases involve Ruby in some way or another, with a little bit of C/C++ testing (comparing/contrasting the MSVC and more open source compilers). Ruby is the only language I can never get to work properly "raw" on Windows, it makes far too many Linux-based assumptions and lacks a lot of cross-platform niceties that for instance Python and Node more regularly provide out of the box. It's mostly been random Ruby tools I've seen crash to syscall oddities. (It manages to keep my expectations low for results from Ruby tools in general.) (In regard to your WSL2 VPN issue, that seems to be expected given it is running in a VM. It's possibly just as simple as enrolling the network interface WSL2 is using like you would any other Hyper-V network interface for your VPN. To my understanding, it should be auto-bridged to your main network interface, but is still its own network interface and some VPN software is too smart for its own good and ignores Windows' bridges to charge more. If so, it may even be likely your tickets are just languishing in the "won't fix" of "please pay us more to upgrade to a SKU that 'better' supports VMs", ie "a SKU that doesn't intentionally ignore VM network interfaces, because we can charge for that".)

WorldMaker 3y ago

It worked fine, a lot of people are still using WSL1 and the Windows Android Subsystem is still closer to WSL1 than WSL2, and in that case in Windows 11 Microsoft is even selling that to ordinary users in the Microsoft Store. The performance was never that bad, depending on your use cases is all. Admittedly a lot of use cases for developers are heavily file I/O bound or deal with dark details and edge cases of syscalls rather than the happy paths (because developers gonna develop), so of course developers felt the performance sting there. (I'm very curious if WSL1 on the soon-to-come Dev Drive has good performance, because it will bypass a lot of the file I/O filter drivers that caused some of the worst WSL1 performance for developers. That seems like an obvious and interesting win, if the case.)

TeMPOraL 3y ago
I wonder how much of the WSL1 I/O performance had to do with the syscalls, and how much with them being visible to Widnows Defender and other anti-malware software, which all like to hook into every single file I/O operation userspace programs do. WSL2 I believe, being a full-fledged VM, gets to hide from those checks. In my experience, WSL1 was fast enough even on large git repos with lots of files (after tweaking some Git settings), but performance crashed once corporate nuked my Defender exclusion lists, making both the repo and the entire WSL1 filesystem suffer from "real-time checks" on every file write.
- WorldMaker 3y ago
  Anecdotally, I never felt like syscall performance was an issue, it was always File I/O (and yes "real-time" A/V is always a massive issue for File I/O on Windows). The issues with syscalls to me always seemed to be more around obscure compatibility than performance. Apps would crash that shouldn't because they relied on a weird POSIX edge case (that they maybe shouldn't). It always seemed more to me on the general syscall front beyond File I/O that "app just doesn't work at all" rather than "app works slowly". That said, I've never been a heavy WSL user so my experiences may have been limited in some of the syscalls people were complaining about. WSL1 was "fast enough" for my use cases. I'm very curious if WSL1 on the incoming Dev Drive which takes a different approach to A/V exclusion among other things and file I/O in general would be as good or better than WSL2 performance.
  - TeMPOraL 3y ago
    I never experienced those syscall issues, despite being a heavy WSL1 user, but that's probably because my uses are pretty narrow - I use it to run Emacs, and do all the usual stuff stuff you do with Emacs, which mostly involve reading and writing text files, and occasionally shelling out or running git. Well that, and a C++ language server, which mostly involves file I/O and some in-memory data reshaping. Within those use cases, I hardly had any trouble with anything - the worst things so far was 1) clipboard occasionally breaking, which I'm now 95% convinced is a problem with PowerToys, not WSL, and 2) Emacs leaking memory, which is what you get when you build it from sources at the tip of the main branch. I haven't had anything bad happen I could clearly attribute to WSL1. RE Windows Defender, this is not a problem on my personal machine - as long as you can set up exclusion rules for real-time scans, it barely registers. Unfortunately, at work, security policies got updated, erasing my exclusions and preventing any changes to it. WSL2 doesn't seem to be affected - I suspect simply because its VFS is opaque to Defender - but it's not without problems. Most annoying of them is that network traffic to/from WSL2 gets blocked by the company VPN, which isn't the case with WSL1. I'm yet to find a workaround for this. (And yes, the VPN maker has plenty of support issues opened about WSL2 issues, and it's addressing them about as eagerly as Microsoft is addressing WSL2 tickets on Github.)
    - WorldMaker 3y ago
      Yeah, most of my use cases involve Ruby in some way or another, with a little bit of C/C++ testing (comparing/contrasting the MSVC and more open source compilers). Ruby is the only language I can never get to work properly "raw" on Windows, it makes far too many Linux-based assumptions and lacks a lot of cross-platform niceties that for instance Python and Node more regularly provide out of the box. It's mostly been random Ruby tools I've seen crash to syscall oddities. (It manages to keep my expectations low for results from Ruby tools in general.) (In regard to your WSL2 VPN issue, that seems to be expected given it is running in a VM. It's possibly just as simple as enrolling the network interface WSL2 is using like you would any other Hyper-V network interface for your VPN. To my understanding, it should be auto-bridged to your main network interface, but is still its own network interface and some VPN software is too smart for its own good and ignores Windows' bridges to charge more. If so, it may even be likely your tickets are just languishing in the "won't fix" of "please pay us more to upgrade to a SKU that 'better' supports VMs", ie "a SKU that doesn't intentionally ignore VM network interfaces, because we can charge for that".)