[setquk]

I don't buy the usability argument of WSL. The thing isn't anywhere near a useful Linux environment other than for some noddy stuff that cygwin can already handle. Try running a background process, a service, use a serial port or drag some half decent performance out of it and you'll see.

It is ultimately backed with NTFS and NT's buffer cache. Running a VM is still several orders of magnitude more productive. And you can't fix NTFS and NT now. It's impossible.

[rcarmo]

Serial ports work fine with my Arduinos. I regularly flash stuff using ESP tools from WSL.

[setquk]

Is this a recent change with 1803?

I was attempting to use AVR-gcc toolchain and some SCPI over serial stuff with WSL unsuccessfully.

[cube2222]

That's… completely false. At least for me. You should really stop and think before accusing people to have noob workloads.

Even cronjobs work… The performance is sometimes better than on native linux, as a few of the syscalls are better implemented on windows. The file performance is abysmal, but that only hurts if you're using npm (and there you're in a world of pain already anyways).

The only thing lacking, is that some debuggers don't work, which is a pity, but then I just start a docker container and mount it on my filesystem.

I am using services on it too actually, everything works as expected. I can actually create windows bat files to redirect to linux binaries, which lets me do for example OCaml development, with the linux toolchain, on a system that actually works reliably. (my experience is, that as of windows 10, desktop linux environments crash way more often than windows ones)

[setquk]

Grep 150,000 source files on Linux and on WSL and come back to me. That's a pretty standard console load. It kills git operations, package managers, compilers, the lot. ALL the tools I use it for. Well USED it for.

Real data:

linux -> 1.3 seconds, all from buffer cache on a cranky old 10 year old HP desktop with 8 gig of RAM and bottom end SSD.

wsl -> over a minute on a 12 core i7 with high end m2 SSD, every time.

This is because of NTFS's awful performance on small files. The whole of Unix is file based and uses huge numbers of small files, as does source code generally so this is an end game scenario for the platform. It simply sucks!

This goes back to when we had SVN which would take 6-7 minutes to check a repo out onto NTFS versus 20-30 seconds onto ext4 on the same rust disks. SVN was treated like cancer by the organisation for what is fundamentally a platform limitation.

[burntsushi]

As the maintainer of ripgrep, I pay attention to these sort of things. I will say that I noticed a similar performance problem in my tests as well, but further investigation revealed that Window's antimalware process was severely throttling file reads. Once I disabled that, performance on Windows is nowhere near an order of magnitude worse than Linux.

[setquk]

Thanks for commenting. I have disabled windows defender on the machine and tweaked the filesystem with fsutil and it is still running at over 40 seconds on the same workload.

[cube2222]

Source code files are small... but hardly a lot though. I've usually been doing extensive search on big files, and ripgrep is great for that (and available for windows).

[nailer]

I just use `git grep` which isn't as fast as ripgrep (https://github.com/BurntSushi/ripgrep), but is still damn fast (on Windows).

[setquk]

  $ find ~/src | wc -l
  242341

Maybe, maybe not.