I'm a Principal at ThoughtWorks, classical composer, and physics amateur.

Thursday, April 13, 2017

WSL, first experiences

I first tried Windows Subsystem for Linux in December 2016, but was not
successful in installing, so I held off.

After getting the Windows 10 Creators Edition update, I saw how
much work and love went into improving WSL, and decided to try again.
I was rewarded.

On the whole, the installation was smooth, brief, you might even say trivial. There
were Windows reboots to enable Developer Mode, and after installing WSL,
but much solid effort has gone into making Windows reboots quick and
painless, and with a regular Linux distro I'd have rebooted anyhow after
upgrading, so no disgruntlement.

And what did I get for my efforts? WSL bash is bash. Just bash. Really, it
is just plain old bash, with all the command line tools I've grown
accustomed to over 30 years. The best praise I can give a tool: It
just works. And WSL just works. (But see Almost
there, below.)

Out of the box WSL runs Ubuntu 16.04 (Xenial), the official LTS
distribution (long-term support). This is a sane choice for Microsoft.
It's stable, reliable, secure, tested, trusted. For anyone wanting a
working Linux command line, this is a go-to choice. Still, I updated
it.

Things I changed

Even with all the goodness, there were some things I had to change:

The terminal

I immediately installed Mintty
for WSL. I've grown to love Mintty on Cygwin, trusting it as a
reliable and featureful terminal emulator without going overboard.
It's a tasteful balance, well executed. And CMD.EXE,
though much improved, still is not there (but may head there; we'll
see if PowerShell wins out).

DBus

Not to get into flamewars, I just accept that Ubuntu uses DBus. By
default it doesn't run on WSL, but this was easy to fix, and it made
upgrading Ubuntu smoother. Using sudo, edit /etc/dbus-1/session.conf
as
others
have suggested (I did it by hand, not with sed).
You may have to repeat after upgrading Ubuntu.

The Ubuntu version

It seems trivial, but I was unhappy that diff --color
didn't work. Am I shallow—color? Some of the scripts I write for
open source provide colorized diff output, and I'd like to work on
them in WSL without disabling this feature. Microsoft made much hay over
24-bit color support in CMD.EXE. So I
updated to Ubuntu 17, which includes diffutils 3.5 (the
version in which --color was added). Microsoft does not
official support upgrading Ubuntu, but I ran into no real problems.

Upgrading WSL Ubuntu

Caveat coder — there is a reason this is
unsupported by Microsoft at present. I just never ran into those reasons
myself. For example, I used DBus to make upgrading happier; I am not using
any Linux desktop (graphical) programs, so maybe this could be a reason.

Edited /etc/update-manager/release-upgrades to use "normal"
releases, not just LTS

Fixed /etc/dbus-1/session.conf

Ran sudo do-release-upgrade to move to 16.10 from 16.04

Re-fixed /etc/dbus-1/session.conf

Ran sudo do-release-upgrade -d to move to 17.04 from
16.10

(Pay attention: there are many "yN" prompts were the default is to abort:
you must enter "y" to these!)

When I am prompted to reboot, I quit the upgrade, close all WSL terminals,
and start a fresh one. There is no actual kernel
to reboot: it remains 4.4.0-42-Microsoft throughout. The kernel is
emulated by Windows, not an actual file to boot, so upgrades only change
the packages bundled with the kernel, not the kernel itself. The
underlying abstraction is quite elegant.

Almost there

Can I drop Cygwin and make WSL my daily development environment? Not quite
yet. For shell script work, WSL is excellent. But for my Kotlin, Java,
Ruby, et al, other projects, I rely on IntelliJ IDEA as my editor (though
Emacs might return into my life again). Filesystem interop between Windows
programs (such as java.exe) and WSL is good but
not perfect.

Other options

Cygwin on Windows

This is and has been my solution for bash on Windows for many years. I
will move to WSL when I'm ready, but I'm not ready yet. I need my
regular development cycle to work first. (See Almost
there.) There are downsides to Cygwin, for example,
coping with line endings, but it's been reliable for me.

Homebrew on Mac

This is work. My company issues me a Mac laptop, and I use it. For the
most part, it is fine for work with colleagues and clients, though at
times the Mac is a
little strange, and much of the user experiences feels
counterintuitive. Still, the software mostly works, and the hardware
is incredibly good.

But why not just use Linux? Well, my daily machine at home is a
Windows box. Because it's my gaming rig, and games I play don't run
well in Linux, and getting a Mac desktop is not currently a
pretty story.