5 ms·

If you gonna do dev on WSL then make sure all of it is on Linux. Don't mix and match. They still haven't corrected the SEVERE disk read speed when accessing a

• judge2020 5y ago
  > The WSL IP Address changes on every restart.... ALWAYS. So trying to setup a local web server for testing becomes a hassle. This should only be true if you're doing funny network stuff. On my machine, exposing WSL2 with 127.0.0.1:8080 allows me to connect on my Windows browser: https://i.judge.sh/shocked/Punch/WindowsTerminal_whYLqVLsIM.png https://i.judge.sh/shocked/Punch/WindowsTerminal_whYLqVLsIM....
• NegativeLatency 5y ago
  Could you get mDNS setup?
• kyriakos 5y ago
  That's wierd. Any server I run on wsl side can be accessed via localhost from Windows side. Been like this since the beginning of wsl if I'm not mistaken.
  • Mogzol 5y ago
    One issue that I've run into is that if you only bind to IPv6 in WSL, then you will only be able to access the service using IPv6 on the Windows side (i.e. ::1 works, but 127.0.0.1 doesn't). OSs usually automatically bind to IPv4 whenever you bind to IPv6, but that's not the case with WSL (actually, it does bind to both, but only inside WSL, not on the Windows end). Lots of programs (like node) bind to IPv6 by default, so this can catch people off guard and they wonder why 127.0.0.1 or localhost isn't working. Here's the github issue about it: https://github.com/microsoft/WSL/issues/4851 https://github.com/microsoft/WSL/issues/4851
• jayflux 5y ago
  > cd into a git repo on your Windows side: cd /mnt/c/repos/example_git and expect a minimum of a 1 minute wait for simple repos. Yes that will be slow, don’t use /mnt, anything under that directly will crawl. Use /home or somewhere else and save your work there. In VSCode you can access any dir and now there’s gui support so there’s no excuse to be using /mnt now. I believe some docs on WSL do tell you this > The WSL IP Address changes on every restart.... ALWAYS. So trying to setup a local web server for testing becomes a hassle. That’s weird, I’ve never had any issues relating to running a web server. Listening on a port in WSL automatically exposes it on Windows. I’ve not had to configure anything when restarting etc.
  • abdusco 5y ago
    I occasionally run into an issue that breaks localhost port forwarding. I can access the service that's running inside WSL2 via its actual IP (172.#.#.#) when 127.0.0.1 breaks. But that IP address changes every time WSL instance restarts. I've had to set up a scheduled task[0] to update an entry in my hosts file every time WSL is assigned a new IP address, which works well enough. [0]: https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/ https://abdus.dev/posts/fixing-wsl2-localhost-access-issue/
    • jayflux 5y ago
      Excuse my ignorance here but why are you using its actual IP instead of just localhost or 127.0.0.1? When starting up a local server inside of WSL I’ve never needed to do that (unless it needs to be accessed somewhere else in the network) I know the blog post says localhost redirection “often fails” but that’s just never been the case for me, and the citation it uses is just a link to the WSL issues page rather than a specific issue.
      • abdusco 5y ago
        Localhost mostly works, and I use localhost when it does work. But when it fails (once a week or so, and this keeps happening on 3 different machines running the latest/a recent Insider build), usually after the PC wakes up from sleep, I have to restart the PC to access via localhost again, which is undesirable for me because I have to spend 10 min restoring all apps & windows back to how they were. Or I can use the IP address directly and map it to a friendly hostname, in my case `wsl` and keep working. This is done behind the scenes with a scheduled task, so when I see `localhost:PORT` doesn't work, I just retry it with `wsl:PORT`. The reason I haven't linked to a specific issue is that there's just so many [*], and localhost sharing is still buggy and hasn't been fixed even after 2 years. [0]: https://github.com/microsoft/WSL/issues/5298 https://github.com/microsoft/WSL/issues/5298 [1]: https://github.com/microsoft/WSL/issues/7492 https://github.com/microsoft/WSL/issues/7492 [2]: https://github.com/microsoft/WSL/issues/6725 https://github.com/microsoft/WSL/issues/6725 [3]: https://github.com/microsoft/WSL/issues/4885 https://github.com/microsoft/WSL/issues/4885 [4]: https://github.com/microsoft/WSL/issues/5439 https://github.com/microsoft/WSL/issues/5439 and many more.
• DeathArrow 5y ago
  I do all my dev on Windows side and I use WSL from time to time to quickly test builds.
• withinboredom 5y ago
  `localhost` always resolves both machines without issue, it’s when you hard code 127.0.0.1 or ::1 instead of localhost, you end up with shenanigans.
• test1235 5y ago
  >They still haven't corrected the SEVERE disk read speed when accessing a Windows directory. I got this when I tried to npm install a project and it was taking forever. https://stackoverflow.com/a/68974497/3983822 https://stackoverflow.com/a/68974497/3983822
  • sterlind 5y ago
    unfortunately there's fundamental issues with file operations on NT: * you can't delete an opened file, which means every folder delete/move operation has to enumerate all descendents to acquire exclusive locks. * every file operation goes through a filter driver (think virus scanners) * the kernel parses path names, and (I think) maybe dispatches one operation per path element. all of the above can't be fixed due to compatibility apparently. that's why WSL2 moved off of NTFS.