There are a few annoyances with WSL2. For me the most important are:
1. You can't connect to a port listening on WSL localhost like in WSL1, you have to figure out the WSL IP address and use that.
2. From WSL you can't connect to a Windows TCP port on localhost, you must figure out the Windows IP (cat /etc/resolv.conf) and use that.
3. The WSL remote interpreter on PyCharm is not working anymore. The suggested workaround is "use SSH remote interpreter" but given #1 you can't connect to localhost (and the WSL IP changes every time you restart it)
In order to use the SSH remote interpreter in my favorite IDE I'm using this script (on Windows):
import subprocess
import re
output = subprocess.check_output('wsl.exe ifconfig')
match = re.search(r"\sinet\s+(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s", output.decode('utf-8'))
if match:
ip = match.group(1)
with open(r"C:\Windows\System32\drivers\etc\hosts") as i:
content = i.read()
new_content = re.sub(r"(172.\d+\.\d+\.\d+)\s+wsl", f"{ip} wsl", content, re.M)
if new_content != content:
try:
with open(r"C:\Windows\System32\drivers\etc\hosts", "w") as o:
o.write(new_content)
except PermissionError:
print(new_content)
First I use the Windows Scheduler to start SSH (wsl service start ssh) on logon. Then this script is executed on logon with elevated privileges to update the hosts file. Instead of "localhost", I use "wsl" and it works well enough for me while I wait for the fixes.
Despite the above, the combo Windows 10 + WSL2 is the best "Linux Desktop" for me.
I'll add the separate filesystems problem. I generally need to access files from both windows & linux. WSL 2 may have made file access faster within the vhd, but it seems to be slower to use those files from Windows, or impossible with tools that don't yet support the network file paths provided by the 9p server. VS Code's solution with the remote extension is really nice, but every Win tool would have to do something similar to make the experience truly seamless.
For the record I was used to SFTP NetDrive for my remote host (map a sftp target to a local drive on windows), and I just started using that to make sure all my windows tools can access it just fine.
Doesn't solve the speed issue, but at least you're never blocked by a software that only work with a local/non-network path.
That's a pretty nice idea for the net paths issue. I'll borrow it, thanks.
I'd guess all significant Windows developer tools will add support for the wsl paths over time. VS Code obviously leads the pack with its remote extensions. I hope Jetbrains will do something similar with IntelliJ Idea - the piecemeal approach doesn't work as well IMO.
I'll be interested to see what Microsoft can do about the speed of access to the windows file system. It's painfully slow right now.
It (like most every OS) used the BSD TCP/IP stack because it worked and didn’t have license encumberances. They switched to their own stack in Vista though.
Ahhh, the eternel dilemna they face. Either recreate the wheel and get complaints about that, or re-use the wheel and have people "crack up" about you doing that.
The irony is that “etc” makes no sense whatsoever in Windows, and particularly in that place. It probably came about because it was easier to have it there than to patch whatever bit of code they borrowed, and it’s now likely vestigial, but probably there is too much stuff relying on it to change things. The irony is in an OS trying extremely hard to not be a unix, ending up with unixy folder names because laziness.
I know you probably don't want to give up your editor, but FWIW if you can find an acceptable collection of bindings and python extensions for VSCode the remote development extensions work amazingly well with WSL. I was able to set up a full haskell IDE using haskero in under ten minutes with zero configuration.
A solution to the IP address problem might be to write the IP address to the Linux file system when Linux boots, then read it from Windows as part of your SSH launch.
For local development in WSL my solution is to simply run a ssh server from WSL and connect to that from Windows, forwarding any ports I need. I've found the Chrome SSH app [0] to work really well (aside from needing to run Chrome), as it can forward ports and supports tmux w/ mouse control and copy paste nicely. But any decent ssh client will work.
You don’t need any of that if you use VS Code’s “remote development” extensions. It has a few issues with agent forwarding and suchlike, but is getting there.
1. You can't connect to a port listening on WSL localhost like in WSL1, you have to figure out the WSL IP address and use that.
2. From WSL you can't connect to a Windows TCP port on localhost, you must figure out the Windows IP (cat /etc/resolv.conf) and use that.
3. The WSL remote interpreter on PyCharm is not working anymore. The suggested workaround is "use SSH remote interpreter" but given #1 you can't connect to localhost (and the WSL IP changes every time you restart it)
In order to use the SSH remote interpreter in my favorite IDE I'm using this script (on Windows):
First I use the Windows Scheduler to start SSH (wsl service start ssh) on logon. Then this script is executed on logon with elevated privileges to update the hosts file. Instead of "localhost", I use "wsl" and it works well enough for me while I wait for the fixes.Despite the above, the combo Windows 10 + WSL2 is the best "Linux Desktop" for me.