On Fri, 12 Nov 2021 at 16:01, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Adam Dinwoodie <adam@xxxxxxxxxxxxx> writes: > > But yes, the (lack of) speed of running the Git test suite on Cygwin > > is one of the reasons I run the tests on high-spec Azure VMs rather > > than my own systems. Unfortunately the Cygwin compatibility layer plus > > the overheads of NTFS mean things are unlikely to get significantly > > quicker any time soon, and between WSL and Git for Windows, I expect > > interest in improving Cygwin's performance is going to continue to > > wane. > > Out of curiosity, are the use cases and user base of Cygwin waning, > or are there still viable cases where Cygwin is a more preferred > solution over WSL (the question is not limited to use of Git)? No formal research here, just impressions as someone who has used Cygwin for a long time and who hangs out on the Cygwin mailing list: for a lot of use cases, WSL is at least as good, if not better, than Cygwin. There are a few areas where Cygwin is still a better solution, though: - WSL requires essentially installing an entire operating system. Disk space is relatively cheap, so that's not nearly the obstacle it used to be, but it is an obstacle. This is more relevant for people who want to distribute packaged installers to Windows users: most non-technical users won't want to get WSL working, but if you've written code for *nix and don't want to port it manually to Windows, it's relatively straightforward to compile it using Cygwin and bundle the cygwin1.dll file with the installer. That'll mostly get your code working with a user experience that doesn't differ too much from a fully native Windows application. (This is essentially what Git for Windows is doing, albeit with an increasingly distant Cygwin fork.) - There are some functions that Cygwin offers that WSL doesn't. The key one for me is the ability to access Windows network file shares, which WSL doesn't support (or at least didn't last time I checked). I expect some of these gaps will disappear as WSL gets more features, but I expect some of them are fairly fundamental restrictions: Cygwin applications can have code specifically to handle the fact that there's a Windows OS there, so they can -- with care -- interact with the Windows OS directly to (say) use Windows file access APIs or the Windows clipboard. WSL applications generally don't have that ability; if I install something from apt on my Debian WSL installation, it'll pull exactly the same binary as if I'd installed it on a normal Debian system. I guess in theory people could write code to detect that they're running in WSL and handle that specially, in the same way that it's normally possible to detect and handle when you're running in a VM versus running on bare metal. I expect that'll be much less common, though, just as Git has code for handling Cygwin specially but doesn't have code for handling Linux-within-WSL specially, even though both could be used to access a Git repository stored in the same Windows NTFS directory. I expect some folk who historically have used Cygwin will shift over to WSL, some will stick with Cygwin, and a small number (as I do) will use both in parallel for slightly different jobs. tl;dr IMO both is true: WSL is better than Cygwin for some use cases so the user base is waning, but Cygwin is still a very viable preference over WSL for other use cases.
