Hacker News Reader

Comment by chris_money202 | Hacker News Reader

You’re not supposed to work out of the /mnt/c. A lot of people make this mistake and then complain that WSL is slow. On the native linux file system WSL is 100x faster for everything

View on HN

On my work laptop I made the lazy/naive mistake of mounting my projects from macOS into devcontainers running in Colima.

vscode extensions using ripgrep in parallel in the background (there are many!) are killing the vm.

I now decided to follow Mitchell Hashimoto choice and use VMware Fusion and simply do all my work inside of it.

That's the entire appeal of WSL (for me). A single source checkout I can work on from both sides; no inconsistency of forgetting that I need to apply changes twice.

Without it, I can just as well ssh into another box.

Trust me, its not worth the performance cost. Just use git push and pull across the /mnt/c boundry

I do this on wsl1 without issue. wsl2 has an experimental new virtual (or just remote?) fs you can enable but I have not tested it.

I've generally found it better to do it other way around - keep all the stuff in Linux partition and from Windows side access that over the virtual network share \\wsl.localhost\<Distro>\home\me\whatever

I do not really follow how you would avoid this if you are using WSL containers with dev containers. Wouldn't this be the default?

From the perspective of user empathy, wsl seems to be designed for that use case. but the implementation/defaults can be improved

On top of the performance issue you mentioned, /mnt/c will be case-insensitive and trip up lots of Linux software!

> You’re not supposed to work out of the /mnt/c

That's why i need WSL: to deal with files Windows is not able to.

>You’re not supposed to work out of the /mnt/c.

Source?

Microsoft now launches a pop-up discourging this, so that is my source. Also my own personal experience using WSL for 8 years.

You can very easily measure this as well, use any disk benchmark

Reply on news.ycombinator.com