I hate dual-booting, and I'm not a fan of VMs either. These things take a lot of resources, or they require a lot of work to set up properly. When Microsoft announced WSL way back, it helped me stop doing both of these, and with WSL2, Microsoft changed how Linux is introduced, learned, and used.

Earlier generations of developers often learned Linux by installing Ubuntu or another distro on bare metal. That meant configuring drivers, troubleshooting boot issues, and managing partitions when you didn't even need most of these things. If you only use Linux to run commands and for development purposes, WSL is more than enough.

It lets you access Bash, apt, SSH, Docker, Python, Node.js, Git, and most Linux dev tooling directly inside Windows without replacing the host operating system. This, in fact, allowed me to work in a Linux environment every day without fully understanding Linux itself.

WSL2 removes the need for Linux on bare metal

WSL has everything you need

WSL2 is so widely adopted because it solves a very practical problem. Devs often need Linux tooling for work, but many 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.

WSL2 is functionally sufficient for a lot of development workloads. It supports most command-line workflows developers interact with daily, including package managers, scripting environments, compilers, SSH, Git, Docker, Python tooling, and even remote server management. Thanks to WSL2, 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 acting 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 remain under Windows.

WSLg is another example of how far WSL has come. Being able to launch Linux GUI apps directly inside Windows is genuinely useful, especially for development tools, Linux-native utilities, and quick testing workflows. A few years ago, setting that up required third-party X servers and a lot of manual configuration. Now it mostly just works.

Systemd support also made a huge difference because a lot of Linux software expects it to exist. 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.

WSL2 lets you use Linux without really learning Linux

The experience is not the same as running Linux on bare metal

I learned Bash, Docker, SSH, Git, package managers, and remote workflows through WSL. What I did not learn was Linux itself, as an operating system. Earlier generations of Linux users learned Linux 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.

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, Linux owns the machine completely. The operating system 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 I never really learned while using WSL.

Linux is more than just a terminal

WSL never teaches you the Linux desktop ecosystem

One thing WSL never really exposed me to was the Linux desktop ecosystem itself. For years, Linux existed as a terminal window inside Windows, which meant I never spent much time thinking about how people actually use Linux as their primary operating system.

Once I started running Linux directly on hardware, I 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.

That doesn't necessarily make Linux better. In fact, the amount of choice can sometimes be overwhelming. But it was another reminder that my understanding of Linux had been shaped almost entirely by WSL.

WSL is good enough

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 I think 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.