Hacker News Reader

Comment by nsteel | Hacker News Reader

I work in an industry where there's critical Windows-only software. Since WSL it's so much less painful since we can do everything except the specialist software under WSL (including git, SSH etc) and access the files seamlessly from both. I guess there is some unfortunate reason why they can't do the same here, it doesn't give specifics.

View on HN

> I guess there is some unfortunate reason why they can't do the same here

Because they want to support Git for Windows which is built upon Cygwin/msys. And this is fine because Cygwin is much faster than WSL and a good Windows integration is so much easier. Would be a total PITA if Git would only be available through WSL.

Cygwin is still the best thing ever happened to Windows (or to Linuxers who are forced to work with Windows).

> Because they want to support Git for Windows which is built upon Cygwin/msys

I read that, but I was wondering why they wanted that because they don't say. I've never noticed git to be slow under WSL but I guess that very much depends on your repo size and exactly what you are doing. It all sounds like a tremendous amount of hassle otherwise.

I agree, Cygwin did enable us to work productively for many years. But Cygwin's drive mounting modes caused lots of pain. And the Xserver is simply awful. It is/was a constant source of issues, the worst being the incredibly frustrating crashes. Maybe they were due to underlying issues in the applications themselves but those apps work fine under WSLg (of course there are other bugs but we can still work with those).

Git is very slow under WSL2 when working with our medium-sized repos hosted on Windows filesystems (required by our Windows-only tooling). It's not unusable, but 'git status' under WSL1 was almost instant, whereas it takes a good few seconds under WSL2.

It’s due to what is effectively a network file system. You have the same issue with nfs, 9pfs, parallels prl_fs, etc. It has to stat every file in the repo and that gets expensive on ang RPC protocol. Even local ones apparently.

This is made worse because git uses the os-specific file statistics including inode number to track file changes. These change over most such file systems types which triggers it to rebuild the entire file cache every time you switch OS running git commands. Which if you have shell integration is constantly.

I share my git repos between MacOS and a Linux volume and it hurts on any repo with 100s of thousands of files or more. Ceph, Linux kernel, etc.

Turns out you guys are right. I tried a bigger repo and it was slow. I tried our large monorepo and it was utterly unusable (literally minutes for git status).

I've found this thorough explanation https://github.com/microsoft/WSL/issues/4197#issuecomment-60...

I have git for windows installed and then alias git=git.exe so git from WSL just calls windows git which is much faster and I've never noticed any issues with this.

I also use WSL1 though so maybe my setup is weird.

The github link I posted elsewhere explains why WSL1 is far more performant, most don't need that hack in the WSL1 case (but doesn't hurt).

I damn agree. Especially older cygwin stuff is very very fast. I personally still use my own fork of cygwin-1.3 DLL for my old windoze.

Works like a charm and I can use cool terminal (bash) with all CLI tools I love so much.

> Cygwin is much faster than WSL

Is it? I'm pretty sure WSL is much faster if your workflow allows putting files on Linux filesystem, but I also recall that perf in shared Windows folders felt about the same (bad, but not even worse) when I switched from msys git to WSL. But haven't used Windows in years, so memory could be bad.

I have heard elsewhere that WSL is much faster with fork().

Cygwin is roughly 100x slower with forking than Linux on the same hardware.

I understand that Postgres benefits greatly in running under the WSL for this reason.

Ironically, I still prefer using Cygwin to WSL despite the impedance mismatch with Windows. I really wish that Microsoft had been able to make WSL1 work better instead of giving up and going with the VM route with WSL2.

Manager prematurely distrusting developers syndrome, WSL1 had serious MMAP issues that was delayed as "low-prio" that wasn't fixed until late in the cycle (probably long after the decision to go with WSL2 was taken). Once those were fixed a ton of "weird" bugs magically got fixed.

Sure WSL1 could never have handled docker as-is, but general software would've been mostly fine and given us damn good windows application integration. (And I'm sure some Docker shims would've appeared fairly quickly to satisfy most basic developer needs).

Most likely - just like shims popped up to share PuTTY's ssh-agent with WSL1.

These days I'm just running a full blown Linux DE in a VirtualBox VM since its graphic console isn't objectively terrible like Hyper-V. If for some reason I need to copy/sync files with the Windows host - well that's just an rsync away thanks to Cywgin.

It's been about 4 years since I tried WSL (really hoping to replace macOS as a unix workstation with a robust commercial software market) but my file access and socketed-app experience then was definitely anything but seamless.

Presumably if only 4 years ago that would still have been WSL2, but they have done a lot of improvements over the years. The audio and graphics WSLg stuff is pretty cool. Maybe worth giving it another try.

not sure about your requirements, but pretty happy over here that nowadays i can just mount sshfs within wsl and access this from windows explorer without any special hacks.

WSL is only available in pro windows editions.

I don't know about WSL2 but WSL1 was also available in home editions.

Untrue. I use it with Windows 11 Home edition.

> WSL 2 is available on all Desktop SKUs where WSL is available, including Windows 10 Home and Windows 11 Home.

https://learn.microsoft.com/en-us/windows/wsl/faq#wsl-2

Reply on news.ycombinator.com