Using the Windows Subsystem for Linux, as a Linux Lover

Even for a Linux lover, there are reasons to keep Windows, if only due to the expectation by various partners that everyone has the latest version of MS Office, or simply to benefit from automatic configuration of printers, shared drives, daily backups, etc. from your IT department.

I used to work solely on Linux, and search for a Windows machine in those rare cases where using Windows was unavoidable (looking at you, Excel spreadsheets full of useless macros). I never found dual boot worth the hassle.

Since Windows 10, there is an alternative to Dual Boot (painful and waste of space) or Virtual Machine (awkward and wasting resources): the Windows Subsystem for Linux, which is a feature of Windows 10 where one can run a (pseudo) Linux kernel alongside windows, in a way that is supported by Microsoft! Microsoft’s documentation usually refers to it as “being able to run Linux from the comfort of Windows”, but if you are like me, you can also see it as “being able to run Windows while keeping most of the comfort of Linux” ;-).

The following is a list of the tips, tricks and limitations I discovered along the way. Do not hesitate sharing additional insights in the comments.

Activating the WSL

WSL is not activated by default, but the procedure is as simple as running one PowerShell command as admin and rebooting:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Installing a Distribution

The online documentation mentions installing from the Windows Store, but that did not seem to be part of my employer’s Windows installation, so I had to download the installer myself here. As far as my understanding goes, Ubuntu is recommended, as Canonical (the firm behind Ubuntu) collaborates closely with Microsoft on that feature.

Once that is installed, you should have a “Ubuntu” item in your start menu, that will start a terminal running Ubuntu.

Improving Filesystem Interoperability

The home directory of Linux distribution lies in a special file, similarly to what happens in VMs. This means that it is not accessible to Windows (at least not easily, and there are reports online of this stopping to work after WSL updates).

On the other side, all Windows shares are automatically mounted under /mnt/<drive>/ (for instance /mnt/c/). Due to the difference between rights management in Linux or Windows, it is a bit awkward by default, though. Fortunately, there is a way to fake Linux permissions in a windows drive, by storing them in a special metadata file. To enable that feature automatically, create a file at /etc/wsl.conf in your linux distribution, with the following content:

[automount]
enabled = true
options = "metadata,umask=22,fmask=11"

This makes sure that the metadata option is enabled, and sets the default permissions for new files and directories to something closer to what a Linux user would expect.

Running Graphical Applications

The above already allows to work quite nicely from the command line, but you might also want to run graphical applications (if only to get a proper terminal emulator that supports tabs and clear background…). This is possible by installing one of the implementations of X Server for Windows. I installed CygwinX, and did not (yet) notice any big issue. Make sure to install the X11-related packages when prompted. To start the X server, you need to execute the following command, which starts the X Server with the proper settings:

C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin -- -listen tcp -nowgl"

You can create a shortcut to it by creating a new shortcut somewhere on your filesystem (right click, new, shortcut) pointing to:

C:\Windows\System32\cmd.exe /c C:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin -- -listen tcp -nowgl"

Now, two things need to be done in Linux before having it all set: first, copy the .XAuthority configuration file to your Linux home directory (not needed every time, but I found myself needing to do this again once in a while, probably after updates; it might be a good idea to create an alias or script that does this for you, or even add it to your .bashrc, so that it happens every time you open a session…):

cp /mnt/c/cygwin64/home/<username>/.Xauthority   ~/.Xauthority

Second, set the DISPLAY environment variable to :0 (you can put that line in your .bashrc to make it permanent):

export DISPLAY=:0

You can now start any Linux graphical application from the command line.

Tips and Tricks

Visual Studio Code

If you use the Visual Studio Code IDE, just installing the Windows version will also install a VS Code server in WSL. Typing code . in a Linux directory will start that server, open the Windows version of VS Code, and connect it to the server. You can then switch back and forth between developing in Linux or Windows from the same VS Code session using the selector on the bottom left. Really nice if you need to test interoperability.

Starting Windows Programs from the Linux Command Line

Any executable on the Windows path can be executed from the WSL by adding .exe at the end. For instance, to start the windows file explorer in the current directory:

explorer.exe .

Lots of windows commands are actually not executables, but you can still execute them by invoking cmd.exe /C <some command>:

cmd.exe /C start https://thibaut.dubernet.ch

will open the homepage of truly yours in your default windows web browser. start something is roughly equivalent to xdg-open in Linux: it opens something (URL, .docx file…) using the default application. It is so useful I have the following aliases defined in my ~/.bashrc:

# Open with Linux
alias o=xdg-open
# Open with Windows
alias wo="cmd.exe /C start"

Note that this is not without issues:

• this does not work with absolute paths as arguments (so no cmd.exe /C start /mnt/c/Users/johndoe/something.pdf), because (as you noticed) a word starting with a forward slash means something else for Windows. I did not find a nice trick to make this work nicely.
• this does not work with paths on the linux part of the file system either (anything that is not under /mnt/<drive>/). This is not a problem if you work mostly in the Windows filesystem, but can be annoying in some cases.

SSHFS

sshfs is a very useful command in linux, that allows to mount arbitrary directories of a remote ssh host to local directories. Unfortunately, it relies on some low-level machinery that is not available in WSL (fuse). Alternatives are:

• using scp in simple cases
• using WinSCP (windows utility to explore and copy files on a remote), if no control from linux is acceptable
• connect to drive using SFTP Net Drive in windows and then mount that windows drive in WSL. (not tested yet, closest to standard linux workflow)

Conclusion: is it Worth It?

So now comes the ultimate question: after a few months of this setup, do I think that it was worth it? My opinion is nuanced.

First, by using Windows, I was expecting a much smoother experience in interacting with the rest of my workplace’s IT infrastructure (WiFi networks, printers, network shared drives…). This ended up not being much better than on Linux. Sure, I had less googling to do to configure the printer, but I still had to configure it by hand, and different applications still used different printing dialogs, for instance (which I thought was due to the open-source and organically evolving nature of Linux). Overall, the Windows experience was much less hassle-free than I expected, the only benefit really being to be able to open and modify MS-Office documents without everybody getting angry at me for destroying the formatting.

Second, although quite close to “the real thing”, there were some annoying limitations to WSL:

• not having sshfs available was a huge pain, and completely broke my workflow when working with remote machines.
• although one can use graphical applications, they are managed by Windows window manager, which feels like coming back 15 years (already!) in the past for me, after having been spoiled by Xmonad over the course of that period. In particular for multi-screen setup, I just cannot get used to anything else.
• even with the hacks mentioned above, directories tend to be created with weird permissions, which are mostly annoying due to how they get highlighted in the terminal. No big deal, but a constant reminder that you are just faking it.

So overall, I think that WSL is a good alternative to dual boot, if you absolutely need Windows. In any case better than either dual boot or running Linux in a virtual machine. But as far as I am concerned, I am looking forward to go back to the simple comfort of a pure Linux box as soon as I get the opportunity to do so.