My WSL Setup
If Windows Subsystem for Linux had existed about five years ago (say 2016), I wonder if I would have even bothered switching my full-time desktop to Slackware Linux?
Gaming
I’m glad I made the switch in every single way except one: PC gaming. Linux gaming has made huge strides in the last couple years (thanks to Wine and Proton and other efforts) and when it works, it works beautifully. I also love GamerOS, which runs Steam as the main UI (which I have installed on one of the family computers).
But when things (especially hardware) don’t "just work", the pain is tremendous. The final straw for me was when Steam suddenly started crashing my PC when I attempted to launch it. (My theory is that a Steam update may have included something new which activated the kernel module-level bug I experienced with my Radeon video card. [Note to self to upload my notes for my solution to that].)
My setup
(Note that some of this setup description has changed now that I’m mostly SSHing into a Linux machine from WSL and managing my setup with Git repos and GNU Stow.)
I installed/activated WSL (microsoft.com) and installed the Debian (microsoft.com) WSL "app".
On the Debian instance, I used apt update and then apt install to get some of the
basic tools I’m used to having (like Vim). I’m used to Slackware which comes with
everything, so having to install even things like man is funny - but makes absolute
sense in terms of keeping the base WSL distros as light as possible.
Next, I installed
Syncthing
(sudo apt install syncthing) and used
my neat little SSH port forward trick
to access the Syncthing web interface for both the local (running on Debian WSL) and remote (a headless FreeBSD file server elsewhere in the house) and setup my standard ~/sync directory.
Once that was done, all my files were available in the Debian WSL instance as they would be on any of my Linux desktops.
Then I ran my little sync/dotfiles/setup.sh script that creates symlinks to the "dot files" (e.g. .bashrc) I keep synced across machines.
One of the dotfiles is .bash_profile (login shell) which contains my neato Syncthing startup script).
So every time the Debian WSL starts up, Syncthing is also started.
Poof! Like magic, now I’ve got everything setup just like I like it.
I’m editing this very web page in Vim on a Debian WSL instance.
In a moment, I’ll run the script (Bash) that converts the page (another script, Ruby this time)
and uploads the changes to ratfactor.com with rsync.
Then I can switch over to Steam and play some Kerbal Space Program.
After a while I forget I’m even on Windows.
SSHFS for Windows
One of the few things I can’t do at a WSL terminal and SSH session (besides Steam games), is edit graphics. My favorites are Inkscape (inkscape.org) for vector drawing and Krita (krita.org) for raster drawing.
Managing this has been a pain. Windows file management UIs are an abomination.
Thankfully, there’s WinFsp (github.org) and SSHFS-Win (github.org) to map "network drives" to SSH hosts.
Download builds for both from the official website: http://www.secfs.net/winfsp/
Then following the instructions on the SSHFS-Win README:
In Windows Explorer select This PC > Map Network Drive and
enter the desired drive letter and SSHFS path using the
following UNC syntax:
\\sshfs\REMUSER@HOST[\PATH]
Note that I did not have any luck with the instructions on the WinFsp quick
start guide to map a drive to \\memfs64\share. That gave me a "Windows cannot
access \\memfs64\share" error. I may have missed something. But the SSHFS
connection worked perfectly.
By default, files created or modified in Windows will end up with 0700 permission, which gives execute permission for the owner and no permissions for non-owner. You can fix the permissions in a terminal on the Linux side, but, of course, that’s annoying after the first couple times.
Thankfully, there’s an easy fix:
Open up the Windows registry editor (sigh) and go to
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs
and edit the CommandLine value to include the create_file_umask option.
Here’s what mine looks like:
svc %1 %2 %U -o create_file_umask=111
You’ll need to reconnect any mapped network drives before you’ll be able to see the change, of course.
Before: -rwx------ 1 dave users 789970 ... After: -rw-r--r-- 1 dave users 789970 ...
(You can also add a create_dir_umask option, but I don’t create
directories on my Linux filesystem through Windows enough to even bother.)
SSHFS-Win is awesome and we are blessed that it exists.
Mute the terminal bell!
Having Bash and Vim bells producing a "Windows error" sound ever few minutes while using WSL got old real fast. Muting the console host worked beautifully for me as per the suggestion on this issue. Scroll down to the screenshot that accompanies this quote:
"Open Volume Mixer by right clicking on the Volume Control in the Windows taskbar and mute the Console Window Host."
Mute the terminal bell in Windows Terminal in the year 2022
I’ve switched to Windows Terminal (wikipedia.org), which is actually excellent.
The must have changed the settings menus at some point because most references to muting the insanely annoying terminal bell speak of doing the dropdown arrow in the tab area and clicking Settings. That’s almost right.
To edit the Windows Terminal settings JSON file, you hold down SHIFT while clicking on Settings.
The setting to mute the terminal bell is
"bellStyle": "none", as in this example snippet for all profiles:
...
"profiles":
{
"defaults":
{
"bellStyle": "none"
},
...
}
...
(Terminal appears to be watching for changes to the file because they’re applied immediately when you save and exit your text editor. Nice!)
Really happy with this setup
For a multi-use "family" computer, this really is a "best of both worlds" situation. I feel like I can do absolutely anything on this desktop.
My other computers will continue to run Linux.
Access WSL Filesystems
In the Windows File Explorer, enter the location \\wsl$. Any WSL distros will be listed. Open 'em up and there’s the root of the Linux filesystem. Nice!