6 ms·

This is true if you put your code in the Hyper-V managed WSL2 VM but now you have the reverse problem of WSL1, i.e. access via Windows P9 is slow and things lik

This is true if you put your code in the Hyper-V managed WSL2 VM but now you have the reverse problem of WSL1, i.e. access via Windows P9 is slow and things like symlinks do not resolve whatsoever (on the Windows side). In WSL1, access to files on the Windows host is far quicker than WSL2 and symlinks work everywhere. To try to counteract this, I opted in to the insiders dev channel recently to try the upcoming X11 support, i.e. run IDEA inside WSL. While the performance is quite good, it's broken, e.g. try using find in project, the window disappears immediately 9 times out of 10. In many ways, I found WSL1 more useable as I could use one shell for both the Windows and WSL filesystems with reasonable performance. I now use cygwin if I want to use gnu linux type tools on Windows. Once the X11 support matures it will be a pretty good experience overall if people are willing to install things like IDEA in WSL, I'm looking forward to that.

Tenoke 5y ago
>In WSL1, access to files on the Windows host is far quicker than WSL2 and symlinks work everywhere. I find this pretty annoying, as I need to access Windows files from WSL more often than the opposite (e.g. get stuff from my Windows Downloads folder, or use bash to quickly interact with a Windows folder). Do you know if access to Docker volumes is faster or slower on WSL2 by the way? I wouldn't switch back to WSL1 since some nix/cabal stuff didn't work on WSL1 at all but I am curious as that's the other point where my windows/wsl filesystems touch in ways I've never looked into.
- andrewmackrodt 5y ago
  > Do you know if access to Docker volumes is faster or slower on WSL2 If your files are stored within the VM itself, WSL2's access to them is effectively native. However accessing the files from Windows requires going through the \\wsl$ (P9) network share. This presents problems as Windows isn't going to receive file notification events if you do something like `git checkout`. Additionally, if your project utilizes symlinks, Windows only sees them as an empty file. Users of VS Code largely will not encounter these problems as running `code` from within the WSL layer will start a remote server, it's seamless, that's genuinely very cool. However, if you use anything else, I've found it to be problematic. The "best" solution I arrived at (other than dual-booting Linux, which is totally worth it!) is to install `xorg-server` from cygwin, install my IDE of choice in WSL2 (IDEA) and use X11 forwarding. This way the IDE has a relatively real-time view of the filesystem, receives notification events, symlinks work, chmod is preserved if using safe-writes etc. If you need to use bash (and other tools not provided by Git Bash), cygwin is a useful addition. You can also use `mklink` from cmd/powershell to create a directory hardlink to the \\wsl$ folder if you need to copy things into WSL (although it's easier to access /mnt/drive from WSL2). Either way, I've found any direction of crossing Host/VM filesystem boundaries to be slower than WSL1's approach.
  - lugged 5y ago
    "wsl is real Linux" Why don't ya'll just use Linux? This just sounds so much more difficult than using the real thing.
    - Tenoke 5y ago
      I mostly don't do the extra stuff they do (as they mention Code works seamlessly and thankfully that's good enough for me and obviously emacs/vim do, too), the rest is just slower cross-OS file access and I need to tinker with it only roughly as much as with my Linux installs while getting the benefits of a native Windows install on top. If you need anything Windows-related (e.g. to use a specific game or software) using WSL on top is actually really nice (I do all my real work from there fine when not on my Linux machine currently) and less hassle than dual-booting. If I decide not to use anything Windows related or do GPU-based ML (which I assume is worse on WSl) outside of the cloud I'll install Linux on another drive on this machine and go back to it fully. I honestly never expected to stick to Windows with just WSL on this machine when I put it on for trying some games.
      - krinchan 5y ago
        UEFI has really made it difficult to dual boot, especially off the same drive. Windows 10 overwriting your GRUB install every major update is just pure hell. Then if you opt for separate physical disks, you must forego fastboot features so you can use your UEFI Boot Menu to select between separate Win10 and Linux physical disks. That’s why I put up with WSL2. I hate dealing with bootloaders.
        Tenoke 5y ago
        Even if you are fine with fixing bootloaders it's also just a bit much to have to do a full restart to switch between software, and to not be able to use some things side by side.
    - benbristow 5y ago
      You can use software that doesn't work on Linux (without WINE/hacks anyway) but still use the power of GNU/Linux for development style tasks when necessary. It's easier now to just maintain a single installation of Windows than setup a dual boot and continuously switch between whenever you want to edit an image in Photoshop or play a commercial game.

Tenoke 5y ago

>In WSL1, access to files on the Windows host is far quicker than WSL2 and symlinks work everywhere. I find this pretty annoying, as I need to access Windows files from WSL more often than the opposite (e.g. get stuff from my Windows Downloads folder, or use bash to quickly interact with a Windows folder). Do you know if access to Docker volumes is faster or slower on WSL2 by the way? I wouldn't switch back to WSL1 since some nix/cabal stuff didn't work on WSL1 at all but I am curious as that's the other point where my windows/wsl filesystems touch in ways I've never looked into.

andrewmackrodt 5y ago
> Do you know if access to Docker volumes is faster or slower on WSL2 If your files are stored within the VM itself, WSL2's access to them is effectively native. However accessing the files from Windows requires going through the \\wsl$ (P9) network share. This presents problems as Windows isn't going to receive file notification events if you do something like `git checkout`. Additionally, if your project utilizes symlinks, Windows only sees them as an empty file. Users of VS Code largely will not encounter these problems as running `code` from within the WSL layer will start a remote server, it's seamless, that's genuinely very cool. However, if you use anything else, I've found it to be problematic. The "best" solution I arrived at (other than dual-booting Linux, which is totally worth it!) is to install `xorg-server` from cygwin, install my IDE of choice in WSL2 (IDEA) and use X11 forwarding. This way the IDE has a relatively real-time view of the filesystem, receives notification events, symlinks work, chmod is preserved if using safe-writes etc. If you need to use bash (and other tools not provided by Git Bash), cygwin is a useful addition. You can also use `mklink` from cmd/powershell to create a directory hardlink to the \\wsl$ folder if you need to copy things into WSL (although it's easier to access /mnt/drive from WSL2). Either way, I've found any direction of crossing Host/VM filesystem boundaries to be slower than WSL1's approach.
- lugged 5y ago
  "wsl is real Linux" Why don't ya'll just use Linux? This just sounds so much more difficult than using the real thing.
  - Tenoke 5y ago
    I mostly don't do the extra stuff they do (as they mention Code works seamlessly and thankfully that's good enough for me and obviously emacs/vim do, too), the rest is just slower cross-OS file access and I need to tinker with it only roughly as much as with my Linux installs while getting the benefits of a native Windows install on top. If you need anything Windows-related (e.g. to use a specific game or software) using WSL on top is actually really nice (I do all my real work from there fine when not on my Linux machine currently) and less hassle than dual-booting. If I decide not to use anything Windows related or do GPU-based ML (which I assume is worse on WSl) outside of the cloud I'll install Linux on another drive on this machine and go back to it fully. I honestly never expected to stick to Windows with just WSL on this machine when I put it on for trying some games.
    - krinchan 5y ago
      UEFI has really made it difficult to dual boot, especially off the same drive. Windows 10 overwriting your GRUB install every major update is just pure hell. Then if you opt for separate physical disks, you must forego fastboot features so you can use your UEFI Boot Menu to select between separate Win10 and Linux physical disks. That’s why I put up with WSL2. I hate dealing with bootloaders.
      - Tenoke 5y ago
        Even if you are fine with fixing bootloaders it's also just a bit much to have to do a full restart to switch between software, and to not be able to use some things side by side.
  - benbristow 5y ago
    You can use software that doesn't work on Linux (without WINE/hacks anyway) but still use the power of GNU/Linux for development style tasks when necessary. It's easier now to just maintain a single installation of Windows than setup a dual boot and continuously switch between whenever you want to edit an image in Photoshop or play a commercial game.