Microsoft released the Windows Subsystem for Linux (WSL) in 2016, providing users who preferred or needed to work with a Linux environment the ability to do so right there within Windows 10. As a user who works a lot with Unix, I was quite intrigued by what WSL could do. Here’s a quick review of WSL.
Previously, before WSL was available, the only way to run Linux in Windows was to do so inside a virtual machine. That means you would need to run some sort of hypervisor like VMware or Virtual Box. Linux would then live inside the virtual world, pretty much isolated from the Windows environment on the outside.
WSL brings Linux to Windows, on a level that runs somewhat alongside Windows. Microsoft describes this as running Linux directly on Windows, without using a hypervisor. You can even choose your favourite Linux distribution. You can read Microsoft’s WSL installation instructions. Or just read on here to see how it’s done, in case you want to give it a try right now. It’s quite easy. This has to be on Windows 10.
First, run PowerShell with administrator privileges. (Press Win+X, then A.) Click Yes in the UAC dialog box.
In the PowerShell window, type:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
You’ll need to reboot your computer. After it comes up, go to the Windows store, and search for a distribution like, say Ubuntu. There are quite a few to choose actually.
Pick whichever distribution you fancy. I go with Ubuntu, in case you’re wondering. Then, install the Ubuntu app and launch it. A command prompt console opens to finish up the Ubuntu installation and user configuration.
With these simple steps, you have Ubuntu Linux installed and running inside Windows.
Yay, seems really fun.
But… wait, no. It’s not quite the same thing. I don’t want to compare with a real Linux system because, of course, it isn’t the same thing at all. However, as a long time Mac user and loving macOS because how it is built on Unix, the Linux experience in WSL is nothing at all like what macOS offers.
I griped a little about WSL in a previous post about me trying out Windows 10. The filesystem is a mess, not just how drives are organised, but how the WSL and the Windows world are different, yet joined, and then joined in such a clumsy manner.
The Mac has the benefit of macOS being rooted on an underlying Unix environment, so right from the start, there was no mess with drive letters and how Unix organises its filesystem namespace.
However, inelegant as it may be, I can make some compromises. I can tolerate /mnt/c and /mnt/d sort of madness. This is about how files in the Windows world are accessed from inside WSL. How do we go about accessing files inside WSL from the Windows world?
It’s not so bad if the answer to that question is simply non-obvious. Something that is merely non-obvious can be learned, and once you know it, you can work with that and eventually get familiar. Unfortunately, this is not the case with WSL. Your WSL files, inside the Windows world, are located under:
C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\
It’s not something easy to remember. Non-obvious is one thing; this is obscure.
Mind you, this wasn’t the directory location before the Fall Creator’s Update of Windows 10, though the prior location wasn’t easier to remember anyway. I’m sure Microsoft has more work to be done on WSL, and things like this will remind us that WSL is very much a work-in-progress.
The Windows world, and WSL, it seems, are meant to live separate lives. You can try to have them both work together, but there are several caveats. You can read some of them from Microsoft’s WSL interop documentation.
There are many more signs that WSL’s existence inside a Windows 10 system is a clumsy kludge. The ps command shows only the processes under that shell environment. It doesn’t show anything happening in the Windows world.
The netstat command inside WSL doesn’t show any network connections (i.e. netstat -an), not even though inside WSL, although interestingly it can show you the route table (i.e. netstat -rn). The tcpdump command doesn’t work at all.
WSL is so different you almost might be better off running Linux inside a proper virtual machine.
One of the reasons I like the Mac so much is that all the knowledge and expertise I’ve picked up on Linux and other Unix platforms largely applies in macOS. In fact, that’s the reason why many people who work with Unix-type systems, including programmers, web developers, system administrators and network administrators, are very happy Mac users.
I can poke around the system and troubleshoot problems on the Mac by applying the knowledge I’ve brought over from working with other Unix systems. I can’t say the same with WSL. I can, hopefully, be productive inside WSL itself, but I will continue to be somewhat clueless trying to deal with components outside of WSL.
However, there is one area that some people may be better off with WSL. With WSL, you can opt to install a familiar Linux distribution like Ubuntu. If, for example, you’re a web developer who’s not terribly familiar with Linux, and you simply want a Ubuntu environment because all the documentation you have assumes a Ubuntu environment, and you mostly ever need to deal with applications above the OS, then good for you, WSL probably works very well for you.
The Mac, on the other hand, may be a flavour of Unix that is too foreign for some users. There is no apt command in macOS, not out-of-the-box anyway. Some things work differently, just like there are always differences between variants of Unix environments.
If you need step by step instructions to work in a Linux environment, unfortunately macOS isn’t Linux. WSL might work better for you in this case. For my blog-related work, I have workflows that involve processing photos with ImageMagick as well as other automation scripts, and sure enough WSL works fine for these jobs.
In summary:
- If you are a developer who works only on apps above the OS, WSL is probably fine for you.
- If you are a system/network administrator, and/or wants to work with the OS, and/or expect some legit Unix-type environment, WSL will likely drive you crazy.
I expect that most discrepancies in the WSL environment can be remedied. Perhaps, we could even come to a consensus on how to deal with C: and D: sort of drives in the WSL environment.
In the meanwhile, I am pleased to report that I have survived a few exercises of frantic system and network troubleshooting from a Windows 10 computer. Actually, all the Windows 10 computer needed to do was to give me a working network and many SSH windows. It’s a big change in the user experience for me.