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.
>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.
> 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.
It is more difficult, and no, WSL2/WSL is not linux. You see how much it is not linux when you try to do things like install a job scheduler, or a development environment (hint, try to use vscode gui in WSL2, watch the message you get).
Real desktop linux has been, and is, a thing. I've been using Linux as my primary business desktop for more than 20 years. Yes, really.
Now, in the industry I'm in, I am forced into a windows 10 environment. Which I do the best I can to push out of the way, so I can have a real machine. MobaXterm to provide a single root X window. XFCE4 for windowing, Plank for a dock. WSL2 (unfortunately) underneath, running an older RHEL (not my choice). Looks/feels mostly like a linux box.
I use it for dev/testing/analytics/data science. File access is still as slow as sin, network performance is terrible. Windows apps are unstable, and will take down the machine from time to time.
I am pushing for a linux laptop/desktop as I am far more productive in that desktop environment. Since most of our work is linux based, this makes sense.
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.
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.
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.
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.
You're sacrifing the exact same amount when using WSL2. The difference is that Windows is only useful for Photoshop and 3% of video games, while as a developer you're using Linux all day.
You're not sacrificing any resources, in both cases you're running a full Linux and a full Windows.
As far as GPU acceleration it's just as much of a pain inside of WSL2 than in a regular VM.
Fwiw I only use Windows for Genshin Impact now. Photoshop works well enough usig Wine, the installer won't run but that's not an issue.
>You're sacrifing the exact same amount when using WSL2.
Not really. For one, you are mostly fine running Linux terminal-only so it's really light and you are using less resources with Windows+WSL than Linux + full VM Windows.
Second, if you need both Linux and Windows you typically need Windows for something heavy - e.g. a Game, Photoshop, whatever, so having Windows in the VM is typically more limiting.
Photoshop isn't heavy nowadays. Games are, yes, but the vast majority just work natively.
Also you really miss a lot of Linux if you're running it terminal only without a GPU. Being unable to use the Jetbrains IDEs on Linux is the biggest one for a developer that's universal to any field.
Also if you have to do something heavy, it's almost universally better to do it on Linux, ie, higher speed and better reliability.
I actually had many serious issues with Photoshop and Lightroom in Windows, random crashes, etc..., the only solution being to rollback drivers and once uninstall windows and not do an update.
GPU acceleration in WSL2 is useful for ML, but also accelerated video encode/decode, and some simulations I had to work on. It's also very useful for anything using a GUI, as all the major UI toolkits in Linux use native GPU acceleration.
Can you now use WSL2 together with other hypervisors like VirtualBox or VMWare? A while back WSL2 required use of HyperV and that removes possibility to run other VM software.
Big no go for anyone who also want to test software in other VMs
Yes. I don't recall which version support was added in, but a recent Windows 10 release build using WSL 2 can coexist with both VirtualBox and VMware Workstation.
I'd bet it was network access. It's a bizarre and common problem (I see more people commenting on the issues all the time) which you can kind of fix by forcing 8.8.8.8 or a different nameserver into /etc/resolv.conf but it's unclear to me why this doesn't work out of the box.
yes that was 100% it! I use WSL to do web dev in a windows machine so I can use all my favourite tools. So no WSL2 for me (though that work around is worth a shot).
