There’s no perfect OS in this universe — but if there were, it wouldn’t be Windows, with its mixed metaphors and legacy baggage. Flaws aside, I’m a Windows fan. I grew up at the DOS prompt and programmed on the Microsoft stack through good times and bad. I love the good stuff (Visual Studio and the .NET developer ecosystem) and I’ve adapted around the pain points. There might even be a tiny bit of Redmond DNA lodged somewhere deep in my heart.

And I’m telling you this: If you’re a Windows developer, there’s no better skill to have than a little Linux.

The best part is that it’s not even difficult. Switching between Windows and Linux used to involve a dual-boot setup and some ambition. There was inconvenience aplenty. But today, authentic Linux functionality is just a few clicks away. But before we get to that, let’s recap why hands-on Linux experience is so valuable, even if you’re satisfied with Windows.

Destination Linux

Many of the most common arguments for Linux don’t move me. I know it’s free (Windows often is, too). I’ve heard that it runs on the oldest of hardware, but my attempt to rehabilitate an obsolete Windows Netbook with a slim Linux distro didn’t work any miracles. I’m often told that Linux users can hack anything, even the kernel (have fun with that). I know that Linux fans sometimes have a skewed view of Windows, and think it needs daily reboots and a hefty chunk of antivirus software to make it through a day — which thankfully isn’t my experience.

But I can’t question the success of Linux in production environments. Linux is the destination for a staggering share of deployed code, and it’s not just about web servers and open-source databases. If you’re writing something that isn’t a native desktop or mobile app, the odds are high that you’ll consider deploying it to some flavor of Linux. The operating system that powers less than 2% of the desktops in the world is responsible for 95% of the top million websites, 100% of the top 500 supercomputers, and one International Space Station. Even on Microsoft Azure, the many-billion-dollar cloud business built by the company with the window frame for a logo, Linux usage outstrips Windows and continues to rise every year.

Of course, you don’t need to develop on the same type of system you deploy on, but there are genuine advantages if you can reduce the gap between the two environments. For example, Linux has a different file system structure, different command-line tools, and a directory separator that leans the other way (c:\Program Files meet /usr/bin). All of these details are unnecessary stumbling blocks if you’re only comfortable on Windows.

Just as importantly, Linux command-line tools still set the standard for what you can do with tiny, composable bits of text. Yes, modern Windows has closed the gap with PowerShell and Windows Terminal, but no developer should face a bash command prompt without having some practical skills in their back pocket.

And thanks to the modern trend of containerization, the production world is a lot closer to the development world than it used to be. Maybe you’ll be building Linux images in Docker, and deploying them to clusters running today’s cool-kid Kubernetes. And no matter what your deployment environment, today’s developer rarely gets the luxury of shipping out completed code for someone else to deploy, manage, and maintain.

WSL: the best of Linux, from the comfort of Windows

Remember using Windows phones? Me neither, but one of the modern Windows’ most important technologies stems from a long-ago project to get Android apps running on Windows Mobile. This eventually evolved into WSL, the Windows Subsystem for Linux.

WSL began as a lightweight interface layer that could translate Linux system calls into Windows ones. It was successful, but still sluggish. Then came the even more ambitious WSL 2, which smuggled a full Microsoft-managed version of the Linux kernel into Windows. (And the WSL 2 kernel is open source!) Today, Windows users who are signed up in the Windows Insider program have the ability to go one step further and install WSLg, which extends the Linux support to graphical applications, complete with GPU acceleration.

Don’t even ask me to explain Electron

How to get started with WSL

Installing WSL 1 is just a few clicks in the Program Features window. But the whole process of getting set up with WSL 2 is a bit longer, and includes updating WSL and then installing a Linux distribution. (That’s the kit with the shell and command-line utilities that sit on top of the WSL 2-powered Linux kernel. Usually, you’ll install Ubuntu, but you can install something else or even several at once.)

The absolute easiest way to get WSL installed and configured is with this nifty command:

wsl --install

But for that to work, you’ll need to lean forward with the Windows Insider program to get Windows 10 build 20262 or later. Either way, Microsoft has the full setup steps (simplified single-command, or the full WSL, upgrade, and distro setup process) in its installation guide.

Once you’re set up, what should you do next? Launch Windows Terminal, fire up bash, and take a look around. (If you’re a bash newbie, here’s a good overview of Linux shell basics.)

PowerShell and bash, side by side

WSL 2 gives you a separate walled-off Linux playground on your file system. When you’re at the command prompt or running a Linux application, it looks like a typical Linux file system, but it’s actually a virtual hard disk (VHD) that uses the Linux-standard ext4 file system. The VHD is stored in a single file named ext4.vxdh in a Windows file system location like this:

%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79xxxx\LocalState\ext4.vhdx

This file is resized automatically based on your usage, with an initial maximum size of 256 GB. (But you can change that, too.)

Using VS Code across the Windows-Linux divide

One of the ground rules of WSL 2 is that Linux apps talk to your Linux virtual hard drive, and Windows apps talk to your Windows file system. This complicates certain tasks, but some solid solutions have evolved.

For example, you could install the Linux version of VS Code on your Linux VHD. But you could also use VS Code’s Remote-WSL extension, which runs on the Windows side of your computer and lets you open a project from the Linux side. That’s a major convenience if you’re developing a containerized app for a Linux-based Docker image, because you can compile real Linux binaries form the comfort of a Windows-based cockpit, complete with all the themes, extensions, and tools you’ve grown accustomed to.

VS Code uses a client-server architecture to talk across the divide

You can even use this setup to develop a graphical Linux application, once you install the WSLg extensions. Or, if you’re still getting your mind around the big picture, watch Scott Hanselman demonstrate the dev environment.

The final word

If there’s a final piece of advice I can give, it goes something like this: don’t wait. If you’re not already deploying to Linux or developing with Linux technologies, the odds are high that someday you will. The influence of Linux flows into countless corners you may have overlooked, like science and research fields, embedded systems, and the behemoth that is AWS. And by stepping outside of your familiar OS environment, you just might gain some new insight. As Matthew Broberg paraphrases in his article about switching from Mac to Linux, “The real voyage of discovery consists not in seeking new lands but seeing with new eyes.” Such is the work of the developer.

WSL won’t solve every problem