I ran Linux for two years without actually understanding it, and WSL2 made that possible

At a glance:

• The author used WSL2 daily for two years, relying on Bash, Docker, SSH, Git, Python, Node.js, and apt without ever learning Linux as a full operating system.
• WSL2 abstracts away networking (NAT behind a virtual adapter), filesystem quirks (/mnt/c vs. native Linux paths), and hardware ownership — all of which behave differently on bare-metal Linux.
• While WSL2 covers most development workflows, the author argues that installing Linux on bare metal is the only way to truly understand how Linux handles storage, services, permissions, and networking.

How WSL2 replaced dual-booting and VMs for everyday development

For years, the default way to run Linux on a Windows PC was either dual-booting or running a full virtual machine. Both approaches came with real friction: dual-booting meant partitioning drives, configuring bootloaders, and risking a broken Windows install every time you updated a kernel. Virtual machines, meanwhile, consumed CPU cycles, RAM, and disk I/O that many developers would rather spend on actual work. When Microsoft first introduced the Windows Subsystem for Linux, it offered a third path — one that let you open a Linux shell inside Windows without ever touching a bootloader or hypervisor setting. WSL2 took that idea further by running a real Linux kernel inside a lightweight utility VM, giving developers access to Bash, apt, SSH, Docker, Python, Node.js, Git, and most of the tooling they needed on a daily basis, all while keeping Windows as the host operating system.

The author, Anurag — a journalist who has covered Windows, Android, and Apple for five years across Android Police, Neowin, Dexerto, and MakeTechEasier — describes himself as someone who "hates dual-booting" and "is not a fan of VMs either." That aversion drove him to WSL2 almost immediately. He found that he could work in a Linux environment every single day without ever configuring a bootloader, without troubleshooting a Wi-Fi driver, and without worrying that an update would brick his boot sequence. Earlier generations of developers often learned Linux by installing Ubuntu or another distro on bare metal, which meant configuring drivers, troubleshooting boot issues, and managing partitions — tasks he never had to perform under WSL2.

What WSL2 actually supports — and where the gaps are

WSL2 has become widely adopted because it solves a very practical problem: many developers need Linux tooling for work, but they do not want to abandon Windows for gaming, commercial software compatibility, or hardware support. WSL2 allows both environments to coexist without the overhead traditionally associated with virtual machines or dual-boot systems. Functionally, it supports most command-line workflows developers interact with daily — package managers, scripting environments, compilers, SSH, Git, Docker, Python tooling, and even remote server management. You can open a Linux shell inside Windows and work with almost the same toolchain you would use on Ubuntu or Debian running directly on hardware.

Windows continues to act as the host operating system while Linux operates as an integrated development environment. Hardware compatibility, GPU drivers, display management, device support, Office applications, gaming, and recovery all remain under Windows. That separation is one of WSL2's biggest selling points: you get the tooling without losing the ecosystem. WSLg, introduced as another example of how far the subsystem has come, lets you launch Linux GUI apps directly inside Windows — development tools, Linux-native utilities, and quick testing workflows all render without needing third-party X servers or hours of manual configuration. A few years ago, setting up graphical Linux apps on Windows required significant elbow grease; now it "mostly just works."

Systemd support has also made a huge difference. A lot of Linux software expects systemd to exist, and earlier versions of WSL were incomplete because many services and workflows simply did not behave the same way they would on a normal Linux installation. That gap is much smaller now, but it is not gone. The author notes that WSL2 is "functionally sufficient for a lot of development workloads," but stops short of calling it a replacement for a full Linux installation.

The learning trade-off: convenience versus understanding

The core tension the author describes is that WSL2 lets you use Linux without really learning Linux. He learned Bash, Docker, SSH, Git, package managers, and remote workflows through WSL — but what he did not learn was Linux itself as an operating system. Earlier generations of Linux users learned differently because Linux was the host machine. If the audio broke, you fixed it. If Wi-Fi stopped working after an update, you figured out why. If the system failed to boot, you learned very quickly how Linux handled storage, services, permissions, and networking because you had no choice.

A lot of that learning is honestly tedious. Sometimes learning Linux means spending hours debugging suspend behavior, GPU drivers, broken packages, or networking issues you never wanted to deal with in the first place. WSL avoids most of that friction entirely, which is exactly why it became such a practical solution for developers. But that convenience also changes what you actually learn. The author writes that once you move to Linux on bare metal, you start noticing how much WSL abstracts away. Even something as basic as networking behaves differently. WSL runs behind a virtual network adapter using NAT, so services inside WSL do not behave exactly like services running on a normal Linux machine connected directly to your local network.

File systems also behave differently. Projects stored inside the Linux filesystem are noticeably faster than projects stored under /mnt/c, and permissions between Windows and Linux do not always translate very well. The same thing applies to hardware access: in WSL, Windows still controls most devices directly. On bare-metal Linux, the operating system owns the machine completely — it is responsible for everything from hardware behavior to system stability — and you start understanding how all those layers interact because you are forced to troubleshoot them yourself. That was the part the author "never really learned while using WSL."

Linux is more than just a terminal

One thing WSL never really exposed the author to was the Linux desktop ecosystem itself. For years, Linux existed as a terminal window inside Windows, which meant he never spent much time thinking about how people actually use Linux as their primary operating system. Once he started running Linux directly on hardware, he realized how much variety exists beyond the command line.

Different desktop environments completely change how the operating system feels. GNOME, KDE Plasma, Cinnamon, XFCE, and others all offer very different approaches to workflows, customization, resource usage, and design. Unlike Windows or macOS, there isn't a single Linux desktop experience. The author notes that the amount of choice can sometimes be overwhelming, but it was another reminder that his understanding of Linux had been shaped almost entirely by WSL — a terminal-centric, headless experience that never touches the desktop layer.

WSL is good enough — but not complete

The author's conclusion is that WSL is good enough for most use cases, so much so that many people never need to install Linux at all, especially if they just need something for running commands and handling a typical development workflow. If you genuinely want to learn Linux, which the author thinks you should if you work in this field, you should install Linux on bare metal at some point. That gives you a kind of learning experience that WSL simply cannot replicate because you are forced to interact with Linux as a full operating system rather than just a development environment.

Windows Subsystem for Linux (WSL) remains a built-in Windows feature that lets you run a full Linux environment directly on your PC. For day-to-day command-line work, it covers the vast majority of needs. But the author's two-year experiment makes clear that there is a meaningful difference between using Linux tools and understanding Linux as an operating system — and WSL2, for all its polish, keeps those two experiences separated.