WSL experiences in early 2018

"ver" reports Microsoft Windows [Version 10.0.16299.192]

Over the last month I’ve started trying to use WSL again for more than just ssh and other standard command-line tools. This article describes my recent experiences with important applications, as well as a sanity check against my initial experiences back in 2016, when too many interesting things wouldn’t work.

Octave

I’m using Octave for Andrew Ng’s Machine Learning course. Installation of the Windows version wasn’t reassuring, even after bypassing a “Publisher: Unknown” error:

Trying out the Ubuntu build was the natural next step. The version in the default Ubuntu repo, 4.0.0, wasn’t recommended for the course, but 4.2.1 is available in the Octave PPA. After adding that PPA using the normal Ubuntu/Debian commands, Octave has worked “mostly” fine under WSL. I did encounter one problem, when saving a plot to an image file. Octave pipes data to Ghostscript as part of saving a plot to a file, and Octave and Ghostscript both hang during this task under WSL. Searching the ‘net you’ll find various issues with such hangs due to application bugs, but this particular test case works on an Ubuntu system and fails using the same Ubuntu binaries under WSL:

>> t = [0:0.01:0.98];
>> y1 = sin(2 * pi * 4 * t);
>> y2 = cos(2 * pi * 4 * t);
>> plot(t, y1);
>> hold on;
>> plot(t, y2, 'r');
>> xlabel(‘time’);
>> ylabel('value');
>> legend('sin', 'cos');
>> title('my plot');
>> print -dpng 'myPlot.png';

(Those of you who have taken this course may recall this example in the Octave tutorial.)

I didn’t find any WSL-specific issues with Octave and Ghostscript on the ‘net, so it would be fun to investigate if I have time. First, I’d collect an strace of the Octave and Ghostscript processes on both WSL and real Ubuntu and see if I can find any differences. As an example, maybe some ioctl() call fails on WSL, and I can then look for references to that ioctl() call failing on WSL for any application. If nothing like that pops up, it should be possible to trace the data flow between Octave and Ghostscript and see if that differs between WSL and real Ubuntu, in order to focus further investigation on only one of those.

Standard ML of New Jersey

I’m using this particular ML for Dan Grossman’s Programming Languages course. But Octave is a 32-bit binary, which is not supported under WSL.

Frankly I hope they don’t add code to support 32-bit binaries, as we’d all suffer one way or another. (A lengthy digression about the author’s uninteresting legacy API support trauma has been deleted. — Editor) Meanwhile, Apple is moving rapidly towards removing 32-bit app support on MacOS, so in practical terms the lack of 64-bit support is an application “bug.”

X

The native Windows app VcXsrv appears to work fine with WSL applications. I’ve used it with Octave and Emacs.

Ubuntu builds of Octave and Emacs on WSL displaying to VcXsrv

PostgreSQL

I was surprised recently to find an old install of PostgreSQL in the Windows task list. I didn’t remember installing it, and certainly didn’t apply any fixes since doing so. That’s a general problem for me with software on Windows, unless an application comes with its own polling mechanism for updates (which has its own drawbacks). With popular Linux distributions I can install and maintain almost all the applications I use via a single update mechanism.

Fortunately, the Ubuntu-delivered PostgreSQL now works on WSL, and can serve Windows clients over a TCP socket, so I’m now using that when developing Django apps on Windows.

Caveat:

The Ubuntu startup scripts don’t run, so PostgreSQL and other services must be started manually (e.g., /etc/init.d/postgresql start).

APR 1.6 test suite

APR is “Apache Portable Runtime,” a portability library for native code, used by Apache HTTP Server, Subversion, and more. A lot of effort has been expended in APR over the years to use the most appropriate interfaces for the system APR is being built for instead of just using generic Unix APIs wherever they will work, or even limiting the use of the Linux API to support the widest range of kernel and libc versions with a single build. Thus it is interesting to run the test suite on WSL to check the behavior of some Linux interfaces that a lot of portable software wouldn’t bother using.

I ran the test suite a year and a half ago on an early version of WSL and noted some failures of the suite on WSL. Now, the errors related to Sys V semaphores and sendfile() have apparently been resolved, but other issues remain. A worthwhile task would be to see precisely what is failing and try to match that with existing WSL bug reports. Then if no match is found, create a small test case and open a new bug.

So why bother?

For zillions of reasons, Ubuntu server is where I deploy most of my work, but I spend about half of my computer time on Windows. Given that:

WSL has garbage-collected the last 3-4 ways to get Unix-y stuff running on Windows, and has made the installation and update effort for such tools largely disappear (via apt, if you’re using Ubuntu on WSL).
WSL allows me to use the same binaries in a development environment for more accurate testing and elimination of some frustration, and of course with a system administration overlap between my development environment and production.
Even when an application available on Linux has a reasonable Windows version, I prefer using the Ubuntu build on WSL to avoid introducing an extra update delivery mechanism/notification, or manual process, to keep the Windows version maintained.

VMs have been an accurate way to run Linux tools on Windows for years, but they are heavier weight than WSL and not closely integrated with Windows applications.

Next steps

Gather and report diagnostic information about some of the errors I have seen, to help ensure that WSL keeps improving.
Investigate integration between Windows IDEs and the WSL environment. That is the major factor on whether or not Windows could be my preferred development platform in the future, instead of a platform I use for certain applications which also supports a subset of my development tasks.

Long-term concerns

Windows filesystem performance is poor when operating on many small files (which we like to do in the *ix world), and WSL doesn’t make it better.
Bridges between Windows development tools and Linux processes (e.g., easy and full integration between JetBrains IDEs and Linux processes, to avoid separate copies of the code and mechanisms for testing) - A good start: CLion 2018.1 EAP allows you to configure use of the WSL toolchain.
Microsoft has to continue improving the Linux kernel emulation forever, to meet current needs as well as to track new Linux APIs. I think I see why that would be valuable to them, but industry changes or just different personalities setting priorities at Microsoft may result in WSL failing to become much beyond “Bash on Windows.”

Emptyhammock