5 ms·

This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road

by haolez 1y ago

This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road.

pjc50 1y ago
WSL1 mapped Linux file API calls directly to NTFS file API calls. Unfortunately this was cripplingly slow for use in e.g. Git, so they moved to a model which is more of a VM.
- jandrese 1y ago
  Is this why Cygwin is such a dog at disk access? It seems like anytime a Cygwin binary needs to open a file it suffers from 100ms of stall.
  - heftig 1y ago
    Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
- moomin 1y ago
  Yeah, WSL1 was a great idea but there were so many edge cases. e.g. allocating a gig of memory you’re not actually using is fast in Linux, not so on Windows.
mikepurvis 1y ago
Yes WSL2 is a mini-VM. Having used both, I don't think it's a slam dunk that 1 was better, really just different. Particularly for the more complex cases of container APIs, GPU access, desktop integration, etc. Those are solved problems in the VM space and reinventing new solutions at a slightly different layer is not necessarily wise or realistic.
- apatheticonion 1y ago
  but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM. For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux. A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need. The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage. WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.
  - amiga386 1y ago
    The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other. For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead. So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally. See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8
    - adgjlsfhk1 1y ago
      I do think that talk is way too kind to the windows design. they're trying to make the argument that windows filesystem isn't slow, but the talk is how fixing the problem took 3 months of optimization and direct help from Microsoft. all of this could be avoided if Microsoft made their filesystem not ridiculously slow
emulio 1y ago
> it was too complex to maintain and Microsoft decided to take the easy road. This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft. This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that
- lproven 1y ago
  > both WSL1 and WSL2 continue to be developed I have had a 'Softie deny, in person to my face at the Ubuntu Summit, that any further development would occur on WSL1, in 2022. So I have to call [[citation needed]] on that.
wvenable 1y ago
> but it was too complex to maintain and Microsoft decided to take the easy road. The insurmountable problem was file system semantics. In Linux, files are dumb and fast. On Windows, files are smarter and therefore also slower. Linux applications expect dumb fast files and they produce a lot of them. Mapping Linux file system calls to Windows file system calls is doable but you can't overcome that difference. At that point, simply virtualizing the Linux kernel itself is an obvious better solution long term.
lproven 1y ago
> it was too complex to maintain Nah. It was fine. Filesystem access was slow. That meant that Git was slow. And every Linux techie thinks they're the next Torvalds and hacks on code and uses Git, so Git needed to work well.

by haolez 1y ago

This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road.

pjc50 1y ago

WSL1 mapped Linux file API calls directly to NTFS file API calls. Unfortunately this was cripplingly slow for use in e.g. Git, so they moved to a model which is more of a VM.

jandrese 1y ago
Is this why Cygwin is such a dog at disk access? It seems like anytime a Cygwin binary needs to open a file it suffers from 100ms of stall.
- heftig 1y ago
  Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
moomin 1y ago
Yeah, WSL1 was a great idea but there were so many edge cases. e.g. allocating a gig of memory you’re not actually using is fast in Linux, not so on Windows.

mikepurvis 1y ago

Yes WSL2 is a mini-VM. Having used both, I don't think it's a slam dunk that 1 was better, really just different. Particularly for the more complex cases of container APIs, GPU access, desktop integration, etc. Those are solved problems in the VM space and reinventing new solutions at a slightly different layer is not necessarily wise or realistic.

apatheticonion 1y ago
but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM. For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux. A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need. The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage. WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.
- amiga386 1y ago
  The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other. For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead. So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally. See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8
  - adgjlsfhk1 1y ago
    I do think that talk is way too kind to the windows design. they're trying to make the argument that windows filesystem isn't slow, but the talk is how fixing the problem took 3 months of optimization and direct help from Microsoft. all of this could be avoided if Microsoft made their filesystem not ridiculously slow

emulio 1y ago

> it was too complex to maintain and Microsoft decided to take the easy road. This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft. This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that

lproven 1y ago
> both WSL1 and WSL2 continue to be developed I have had a 'Softie deny, in person to my face at the Ubuntu Summit, that any further development would occur on WSL1, in 2022. So I have to call [[citation needed]] on that.

wvenable 1y ago

> but it was too complex to maintain and Microsoft decided to take the easy road. The insurmountable problem was file system semantics. In Linux, files are dumb and fast. On Windows, files are smarter and therefore also slower. Linux applications expect dumb fast files and they produce a lot of them. Mapping Linux file system calls to Windows file system calls is doable but you can't overcome that difference. At that point, simply virtualizing the Linux kernel itself is an obvious better solution long term.

lproven 1y ago

> it was too complex to maintain Nah. It was fine. Filesystem access was slow. That meant that Git was slow. And every Linux techie thinks they're the next Torvalds and hacks on code and uses Git, so Git needed to work well.