Skip to main content

Linux on Windows

Running Linux tools inside Windows used to mean a virtual machine, a dual-boot partition, or Cygwin — each carrying trade-offs that pushed serious developers toward one platform or the other. The Windows Subsystem for Linux changed that calculus. What began as a compatibility translation layer (the LXSS subsystem mapping Linux syscalls onto the NT kernel) evolved into a full virtualisation-backed Linux kernel running natively within Windows, with GPU passthrough and GUI application support through WSLg. The progression from WSL 1 to WSL 2, and from headless terminal usage to graphical desktop applications, is one of the more consequential platform shifts in recent Windows history.

This topic page connects content from across the site that addresses Linux-on-Windows from different angles — practical how-to guides, technical notes on subsystem behaviour, and operational details for anyone maintaining a WSL-based development environment. The scope covers the full lineage: LXSS/LxRun, the WSL 2 lightweight VM, WSLg's Wayland and X11 forwarding, and the filesystem interop that determines how cleanly Linux tools integrate with the Windows host. If you have spent time debugging DNS resolution inside a Debian instance, coaxing Intel graphics drivers into cooperation, or wondering whether a destructive command in WSL can reach your Windows filesystem, the pages here address those situations directly.

Subsystem history and architecture​

Understanding the current state of WSL requires knowing what came before it and why the architecture changed. The original subsystem worked differently from the current one in ways that still cause confusion — particularly when older documentation or forum answers reference tooling and behaviours that no longer apply.

LXSS and LxRun​

This technical note documents the LXSS subsystem and the lxrun management tool that shipped with the original WSL implementation. LXSS was the kernel-mode driver translating Linux syscalls into NT equivalents — a fundamentally different approach from WSL 2's lightweight virtual machine. The lxrun command handled installation and removal before Microsoft replaced it with the wsl command-line tool.

The note matters because a significant volume of WSL troubleshooting advice still references LXSS-era behaviour and lxrun commands that no longer exist. Knowing what these tools were, when they were deprecated, and what replaced them saves debugging time with outdated guidance. The architectural distinction also explains performance characteristics that affect everyday work — particularly filesystem I/O, where the two architectures behave very differently depending on whether files live on ext4 or the NTFS mount.

Practical configuration guides​

The Linux-on-Windows experience is mostly smooth until it isn't. DNS resolution, graphics drivers, display server configuration, and filesystem permissions all have failure modes that are specific to the WSL environment and not covered by standard Linux or Windows troubleshooting. The guides collected here address the configurations that most frequently cause problems in practice.

X11 and GUI Applications on WSL​

Getting graphical Linux applications to display on a Windows desktop has been a persistent friction point in WSL adoption. Before WSLg, it required an external X server, firewall exceptions, and environment variable configuration that broke across Windows updates. WSLg baked Wayland and X11 support into WSL 2, but the transition introduced its own edge cases — GPU acceleration, multi-monitor setups, and applications that assume a traditional X11 session.

This guide covers the working approaches for both eras, identifies where older advice now breaks configurations, and documents the display server mechanics that determine whether a GUI application renders correctly. If you have encountered blank windows, connection-refused errors, or rendering artefacts, this is the starting point.

Debian DNS and resolv.conf​

DNS resolution inside WSL has a well-deserved reputation for breaking in confusing, intermittent ways. The root cause is the interplay between Windows DNS management, WSL's automatic generation of /etc/resolv.conf, and the distribution's own network manager — three layers that disagree about which nameserver to use. Debian-based distributions are particularly affected because their defaults do not account for WSL's synthetic networking.

This guide covers the failure modes, fixes that persist across reboots, and the /etc/wsl.conf changes needed to prevent WSL from overwriting manual DNS settings.

Newer Intel Graphics on Debian​

GPU support in WSL 2 relies on a virtualised GPU device mapped through a paravirtualised driver model. For Intel integrated graphics — the majority of laptop GPU hardware — the WSL environment needs driver support matching the host-side capabilities. Debian's stable repositories lag behind the versions needed for recent Intel generations, creating a gap between what the hardware can do and what the WSL guest can access.

This guide covers the repository configuration, driver packages, and verification steps to confirm GPU acceleration is working rather than falling back to software rendering.

Filesystem and safety boundaries​

One of the most important and least intuitive aspects of WSL is how the Linux and Windows filesystems interact. The /mnt/c mount that exposes the Windows C: drive inside the Linux environment creates a bidirectional bridge that has real consequences for both productivity and safety. Understanding where the boundaries are — and where they are not — is essential for anyone using WSL as a primary development environment.

rm -rf in WSL​

What happens when you execute destructive filesystem commands inside WSL that target paths accessible through the Windows interop layer? This note documents the observed behaviour of rm -rf against /mnt/c paths — the protections (or lack thereof) that WSL provides, and the practical risk model for developers working across both filesystems.

The WSL filesystem interop is not sandboxed. Changes through /mnt/c are real, immediate, and not subject to the Windows Recycle Bin. For developers accustomed to the safety of a virtual machine, that direct host access is a meaningful difference — particularly relevant for scripted operations and any workflow using recursive deletion patterns.

What readers usually need​

Readers arriving at this topic page typically have one of these questions:

  • How to get GUI applications working in WSL → X11 and GUI Applications on WSL covers display server configuration for both the pre-WSLg and WSLg eras
  • DNS breaking inside a Debian WSL instance → Debian DNS and resolv.conf addresses the resolv.conf auto-generation problem and persistent fixes
  • What LXSS and lxrun were → LXSS and LxRun documents the original subsystem architecture and deprecated tooling
  • Whether destructive Linux commands can affect Windows files → rm -rf in WSL documents the actual behaviour of cross-filesystem operations
  • Getting Intel GPU acceleration working → Newer Intel Graphics on Debian covers the driver gap and repository configuration

Navigating related content​

This topic page is one of several cross-section hubs on the site. The topics index provides the full list of available topic clusters. If you are looking for content organised by editorial type rather than by subject, the section hubs are:

  • How-To Guides for practical walkthroughs and working configurations
  • Tech Notes for behavioural observations and subsystem documentation
  • Security for investigations and protocol analysis
  • Web Development for server and front-end notes
  • Development for scripting, tooling, and extension work
  • Reviews for product and service assessments
  • Journal for reflective commentary

The Linux-on-Windows theme spans several of these sections, and the pages linked from this topic hub are the ones most directly relevant. WSL continues to evolve with each Windows release, and as new content is published addressing subsystem changes, configuration shifts, or interop behaviour, it will appear here alongside the existing coverage.