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 withsed
). 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 inCMD.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.
Researching several helpful Internet sources, I:
- 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.
UPDATE: More on how syscalls work.
UPDATE: Slightly dated (Microsoft is moving very fast on WSL—kudos!), this is a good video presentation on what happens under the hood.
No comments:
Post a Comment