Microsoft just shipped a Linux kernel to a billion PCs—and most owners never noticed.

That quiet shift, culminating in the Windows Subsystem for Linux 2 (WSL2), marks the end of a decades-long war and the start of an operating system that treats the open-source kernel as infrastructure, not a threat. Alongside the home-grown Azure Linux distribution powering its cloud and the Debian-based SONiC networking OS running its data-center switches, the company now depends on Linux to build, host, and connect Windows itself.

Here is exactly what changed, what it means for your machine, and the few clicks that let you tap into it today.

The Linux Kernel Gained a Windows Address

WSL2, first bundled with Windows 10 version 2004 and refined in every feature update since, runs a genuine, Microsoft-tuned Linux kernel inside a lightweight virtual machine. It is not an emulation layer. It is not a recompilation of GNU tools against the Windows NT kernel. It is Linux—its process table, its filesystems, its syscall surface—sitting next to Windows, managed by the same hypervisor that secures Credential Guard and Windows Sandbox.

Concrete details matter. As of Windows 11 24H2, wsl --install provisions the 6.6.x long-term support kernel by default, with automatic servicing through Windows Update. The kernel ships as a Windows driver package (lxss) and consumes about 130 MB of memory when idle. A companion WSLg component gives Linux GUI apps native rendering on the Windows desktop via a Weston-based compositor, without the user ever seeing an X server window.

Users who prefer a different kernel can load custom builds through a .wslconfig file, but the default is a Microsoft-maintained branch hosted on GitHub, patched monthly with upstream stable fixes and Microsoft-specific enhancements—faster networking via virtio-net, direct storage passthrough, and USB/IP support for connecting physical devices.

The distribution experience has also moved. WSL itself is now a Store-delivered app—Microsoft.WSL—decoupled from the OS image. That enables faster feature iteration: kernel updates arrive outside the annual Windows release cadence, and the wsl --update command pulls the latest kernel, GUI stack, and user-mode tools from the Store. The canonical distributions—Ubuntu, Debian, Kali, SUSE, and others—are likewise Store packages, each running in its own lightweight VM namespace, sharing the kernel and hardware with Windows but isolated otherwise.

For enterprises, WSL2 gained systemd support in version 0.67.6, allowing services like Docker, microk8s, and snap packages to run without custom init scripts. Group Policy controls now let IT administrators disable WSL, block kernel debuggers, or restrict distribution installation, while Microsoft Defender for Endpoint can inspect WSL processes and mounts.

What It Means for You

For the everyday user

If you never type bash, WSL2 is invisible—and that’s the point. The kernel fires up only when a distribution is launched and suspends after eight seconds of terminal inactivity. There is no performance tax at boot. The only trace you might encounter is a WSL optional component check box, pre-selected on some OEM images.

The GUI integration, however, now reaches casual users. Install a Linux app from the Store (think GIMP, Inkscape, or Audacity via their native Linux packages) and its icon lands in the Start menu. Click it, and the app opens its own window as if it were native, complete with taskbar pinning, Alt+Tab integration, and a matching Windows 11 rounded-corner title bar. Copy-paste between a Linux editor and a Windows document just works, thanks to a shared clipboard bridge.

Performance-conscious users should note: WSL2’s virtual disk is a VHDX file that grows dynamically but never shrinks automatically. If you compile large codebases inside Linux, the ext4.vhdx can balloon. The wsl --manage command, added in version 2.0.0, lets you compact it with wsl --manage <distro> --compact-disk, reclaiming unused space. Regular housekeeping prevents a surprise 40 GB consumption.

For developers and power users

WSL2 has quietly become the local development backend for Visual Studio Code, IntelliJ, and the new Windows Terminal. The Remote – WSL extension in VS Code runs the editor’s UI on Windows while its language servers, compilers, and debuggers execute inside Linux, giving full access to the Linux filesystem’s case sensitivity and symlinks. Docker Desktop leans on WSL2’s kernel to host containers without Hyper-V overhead, which means docker-compose environments launch in seconds on a laptop.

A less-advertised capability: GPU compute. WSL2 supports NVIDIA CUDA, DirectML, and TensorFlow through a paravirtualized GPU driver that maps physical hardware into the Linux VM. That allows the same machine to train machine learning models on its discrete GPU while Windows renders the desktop—no dual-boot required. The driver ships via Windows Update for supported GPUs (NVIDIA driver 510.xx and later, AMD 22.Q4+).

The filesystem bridge is now bidirectional. Windows directories mounted under /mnt/c perform at near-native speed for metadata-heavy operations thanks to the 9P protocol improvements, and a new wsl --mount command attaches physical EXT4 and Btrfs disks directly to a WSL instance, making recovery and cross-OS access trivial without third-party tools.

For IT administrators

WSL2 is manageable at scale. Enterprises that standardize on Windows 11 can deploy a single PowerShell script: wsl --install --distribution Ubuntu --web-download during Autopilot provisioning. Configuration is stored in /etc/wsl.conf and a global .wslconfig in the user’s Windows profile, both manageable through Intune custom profiles.

Network controls are granular. WSL2 creates a virtual Ethernet adapter with its own IP behind a NAT. Starting with kernel 5.15.90, a mirrored networking mode (opt-in via .wslconfig) gives the Linux instance the same IP as the Windows host, simplifying cross-platform server development and VPN routing. Firewall rules applied to Windows Defender Firewall now automatically apply to WSL traffic in mirrored mode.

Security teams should be aware: WSL2 bypasses some Windows audit policies because processes run in a separate kernel. To mitigate, Microsoft recommends enabling the “WSL” policy under Computer Configuration > Administrative Templates > Windows Components > Windows Subsystem for Linux to restrict usage to authorized users. The kernel itself is built with kernel address space layout randomization (KASLR), and distributions can be encrypted with Windows’ own BitLocker when the VHDX resides on a protected drive.

How We Got From “Linux Is a Cancer” to Linux Inside Windows

Microsoft’s relationship with Linux pivoted dramatically when Satya Nadella became CEO in 2014 and declared, “Microsoft loves Linux.” That statement was backed by action: the company joined the Linux Foundation, shipped a Linux kernel for its Azure Sphere IoT microcontroller, and built Azure Kubernetes Service into the fastest-growing compute service.

The internal Linux distribution, Azure Linux (formerly CBL-Mariner), is a minimal, RPM-based OS now hosting Azure’s software-defined networking stack, Open vSwitch, and the Azure Kubernetes Service node images. Its source code lives on GitHub under an MIT license. In 2023, Microsoft made Azure Linux generally available as a container host for AKS, making it the default OS for newly provisioned clusters—replacing Ubuntu in that role.

SONiC (Software for Open Networking in the Cloud) rounds out the dependency. This Debian-based network OS runs on tens of thousands of switches inside Microsoft’s data centers and is now an open-source project governed by the Linux Foundation, with contributions from Broadcom, Cisco, and Dell. Microsoft’s own network—the one carrying Bing, Microsoft 365, and Xbox traffic—is built on Linux switches.

The WSL journey itself began with the Windows 10 Anniversary Update in 2016, which introduced a full Linux syscall translation layer. It was clever, but slow. WSL1 translated file-system calls into NT kernel operations, creating an uncanny valley where some tools worked and others—Docker, FUSE, high-throughput networking—did not. WSL2, announced at Build 2019, abandoned translation for virtualization. A Linux kernel source tree, maintained by Microsoft and tagged linux-msft, became a Windows component. The first production kernel, 4.19.84, arrived in May 2020. Every subsequent Windows feature update brought a newer LTS kernel branch; today’s 6.6.x is the eighth generation.

What to Do Now: A Five-Minute Setup

Open PowerShell as Administrator and run:

wsl --install

That single command enables the Virtual Machine Platform and Windows Subsystem for Linux optional features, downloads the latest kernel, and installs the current Ubuntu LTS distribution. Restart when prompted. After reboot, a terminal window opens into a fully-functioning Ubuntu environment. The default username and password are whatever you choose at first launch.

To see which distributions are available:

wsl --list --online

To install, say, Debian alongside Ubuntu:

wsl --install -d Debian

Switch between distributions with wsl ~ -d Debian or use the Windows Terminal dropdown.

To access Linux files from Windows, open File Explorer and type \\wsl$ in the address bar. Each distribution appears as a network share, allowing drag-and-drop between systems.

For GUI applications, no extra setup is required. Install a package that includes a .desktop entry—for example, sudo apt install firefox—and a “Firefox (WSL)” shortcut appears in the Start menu under the distribution’s folder. Launching it brings up a native-looking browser window.

If you are an IT administrator deploying Windows 11 Enterprise, add the WSL2 provisioning command to your deployment task sequence and consider enforcing the group policies mentioned earlier. Microsoft’s WSL documentation includes sample scripts for Intune.

To explore Azure Linux for container workloads, pull the publicly available container image:

docker run -it mcr.microsoft.com/azurelinux/base/core:3.0

This provides a minimal Linux environment identical to the one running Azure infrastructure, useful for testing cloud-native apps locally without WSL.

Outlook

Microsoft’s dependency on Linux will deepen. The forthcoming Windows Subsystem for Android—powered by a Linux kernel inside the same Hyper-V architecture—proves the model is not a one-off. Internal roadmaps, glimpsed through job postings, suggest tighter integration between Windows and Linux security boundaries, possibly allowing Linux processes to enroll in Windows Hello authentication.

What won’t happen: a unified kernel. The company’s bet on a hypervisor-mediated dual-kernel architecture preserves Windows’ backward compatibility while giving Linux equal footing for cloud and developer workloads. For the user, the practical result is a machine that runs the world’s two dominant operating systems with a shared clipboard, a shared GPU, and no more cognitive overhead than switching between browser tabs.

The war is over. Linux won a seat at the table—not by replacing Windows, but by becoming a feature inside it.