Your next Linux distrubtion: Windows 10?

I’ve been hoping to write up here some of my experiences moving to Linux as my daily driver after nearly two decades of moving to a Mac, but that journey is yet to reach a suitable conclusion, however I felt brief discursion to one side was worthy of note: I was surprised to discover that Windows 10 (at least on the current Insider previews) is actually a pretty usable Linux development environment these days.

Now, whilst Windows 10 is a lot better than what has gone before, and I used to be a Windows dev back in the 90s, I’ve been very much a unix person for the last couple of decades, so it wasn’t something I thought about as a daily driver as I decided to move my laptop to something not from Apple. The clear alternative to macOS for me was Linux, which has come a long way in some aspects since I last used it in anger (though it’s good to see anger is still an emotion required when trying to use Linux on a laptop in 2020, but I digress). However, I decided to take another look at the Linux on Windows world when my former employer Simon Crosby (and someone who’s always looking forward with open eyes) retweeted this comment:

“The @surface with WSL will the MacBook Pro of the next decade.” - @nickagerace

I’d tried to use the Windows Subsystem for Linux when it first came out, back when I was working on cloud services at Bromium, and then I didn’t find it particularly usable. The main issue was that, as with the early POSIX personality that Windows NT shipped with, it was very isolated in its own little world: your little Linux enclave couldn’t really interact with the rest of Windows to act as a seamless part of your workflow. In particular, the main frustration was not being able to run the Docker CLI commands from in bash on WSL, which meant you were back to Powershell, and might as well just do everything from in Windows anyway.

Things are very different now.

Thanks to WSL2 being better integrated with both Windows in general and with Docker for Windows specifically, thanks to Visual Studio Code letting you work within WSL just as if you were running things in Windows, and thanks to the improved Windows Terminal client as a place to run your shell, it now feels just like a slightly unusual Linux distro from the purposes of writing, running, and deploying code. I now have on Windows 10 literally the exact same development environment I’ve been setting up in my Linux distributions in terms of using the terminal to manage my code and docker containers, using Visual Studio Code to edit my files with its built in support for pylint etc. to make code navigation easier, and I can test everything in Firefox. And to top it all, unlike the Linux distros I’ve tried thus far, it works with my AMD Thinkpad without issue.

If you want to see how to set this all for yourself, I’d strongly recommend starting with Scott Hanselman’s article How to set up Docker Within Windows Subsystem for Linux (WSL2) on Windows 10 - this has links to lots of other resources about installing WSL2, installing the new Windows Terminal app, and how to properly set up Docker to work with WSL2 (and he has a lot of other useful posts on the topic too).

If you have Visual Studio code installed, you just add it to your $SHELL’s PATH, and bam, you can do “code [FILENAME/DIRNAME]” in your $SHELL and it’ll open up just as if you’d done so from Powershell. If you’re using Python, be sure to install pylint inside WSL (I use the Ubuntu distro in WSL so I can just apt install it), and VSCode will install the pylint extension and then it’ll start highlighting your code, flagging linter errors, etc.

As a concrete example of just how robust this working environment is, to get the above screenshot without showing any client code, I quickly grabbed a Go project I’d contributed a while back and set out to run its full test suite (which I knew used docker-compose behind the scenes, so make it more of a realistic test of day-to-day usage). To do this, in a few minutes I had done the following:

• Used the git command line to checkout gomigrate (a small Go library that I made patches to a while back)
• Installed the latest Go compiler Linux amd64 binaries downloaded from golang.org into /usr/local
• Kicked off the docker test environment that tests gomigrate with all the popular DB backends (MySQL, Postgres, etc.)
• Let VSCode install all the Go tools it wanted in WSL to make code checking, etc. work

Note step 2 in particular: I didn’t take a version of Go built for Windows or WSL, I took the official Linux build of the latest Go release from golang.org and just followed their Linux install instruction from within WSL and these binaries Just Worked™ as it really does offer full syscall compatibility for Linux binaries. Whilst I understand this from a theoretical point of view, to have it just work is kinda mind blowing to me.

As good as WSL is it won’t stop me searching for a Linux distro that works well on my laptop, as I have other reasons for wanting to play with Linux, but I have to confess to being very glad that I took a second look at Linux on Windows to see how much its evolved, and just how usable the WSL2 setup is to get my Python/Go web services work done. I’m not sure I agree that this will de-throne the MacBook Pro for web work, it certainly is a very real and credible alternative.

If you want to understand more about how WSL works under the hood then I can also recommend reading chronologically through the now archived WLS blog, and some of the posts on the Microsoft Command Line blog, which explains about how the managed to make the interop between the two realms work.