tag
32 posts
Each WSL2 distro lives inside a dynamically-expanding .vhdx file that grows with use but never shrinks back down automatically after deletions.
WSL distros reduce to a root filesystem tarball plus small registration metadata, which is exactly what makes import, export, and custom distros work.
Working through the specific, common causes of post-update WSL permission errors instead of reflexively reaching for chmod 777 or broad workarounds.
Why WSL2's internal VM clock falls behind Windows after sleep or hibernation, and the specific steps to force it back into sync reliably.
Working through Windows features, firmware virtualization, kernel version, and disk space in order to find why a WSL distro hangs or refuses to start.
Working through Docker Desktop's specific WSL2 integration points, from backend mode to per-distro toggles, when containers fail with confusing errors.
Diagnosing whether high vmmem usage is a genuine leak or reclaimable page cache, and setting a deliberate .wslconfig memory ceiling that actually fits your workload.
Isolating whether a WSL2 networking failure is DNS configuration, VPN interference, or the networking mode itself, before reaching for a fix.
Confirming that /mnt/c's cross-filesystem overhead is the actual cause of slow WSL2 file I/O, then moving the project to fix it structurally, not cosmetically.
Deleting files inside WSL2 does not shrink the Windows-side .vhdx automatically. That is expected dynamic-disk behavior, fixed with diskpart compaction.
Exporting a WSL distro's entire state to a portable file, and restoring it later on the same machine after a problem or on an entirely different one.
A complete diskpart walkthrough for shrinking a WSL2 distro's .vhdx file after deleting large data, since Windows never reclaims that space on its own.
Configuring Docker Desktop to use WSL2 as its backend, integrating specific distros, and verifying containers run on WSL2's real kernel, not a separate VM.
Turning on systemd support in a specific WSL2 distro, applying the required restart correctly, and verifying services actually manage correctly afterward.
Both directions of WSL file access, plus the performance-driven rule for deciding which filesystem a given project's files should actually live on.
Setting up an NVIDIA GPU for CUDA-accelerated machine learning in WSL2, from Windows-side driver installation through verifying real acceleration.
Switching between WSL2's default NAT networking and mirrored networking mode, and verifying which one actually solves your specific reachability problem.
Edit and debug code inside a WSL distro from Windows VS Code without copying files across operating systems or sacrificing Linux filesystem performance.
Setting memory, CPU, swap, and networking behavior for every WSL2 distro on your machine from the one central, global .wslconfig file.
The specific interop layer that lets a WSL shell launch Windows executables and Windows shells launch Linux commands, translating paths and streams both ways.
WSL2 runs Microsoft's own open-source Linux kernel fork, patched for its virtualized environment and updated independently of any distro's kernel package.
Microsoft's Build 2020 GPU compute announcement, followed by NVIDIA's CUDA preview, let machine learning frameworks use a physical GPU from inside WSL2.
Microsoft and Canonical's September 2022 announcement closed one of WSL's longest-standing gaps: software expecting systemd as PID 1 finally worked.
Windows 11's October 5, 2021 launch made Linux compatibility via WSL2 part of the platform's core story, not an optional add-on developers had to seek out.
At Build 2019, Microsoft revealed WSL2, an entirely different architecture running a genuine Linux kernel inside a purpose-built lightweight virtual machine.
WSL distros ran without systemd for years, breaking software expecting PID 1 init. Here is why that gap existed and how it was architecturally closed.
WSL's cross-OS file access translates between Linux and Windows filesystem semantics at the protocol level, and that translation has a real performance cost.
The specific GPU paravirtualization mechanism, built jointly by Microsoft and NVIDIA, that lets WSL2 run CUDA workloads at near-native performance.
WSL2's VM claims memory dynamically as Linux needs it and has historically been slow to release it back, plus what .wslconfig actually lets you control.
WSL2's original NAT networking isolates it from your LAN by default; mirrored mode, added later, takes a fundamentally different approach with real tradeoffs.
First revealed via Windows 10 Insider Preview Build 14316 on April 6, 2016, WSL let Windows run real Linux binaries for the first time.
How WSL2 differs fundamentally from WSL1's syscall translation, running an actual Linux kernel in a lightweight, tightly-integrated VM.