WSL2 - Run Linux on Windows Without Wanting to Die

WSL1 was a hack - it tried to translate Linux system calls to Windows and mostly failed. WSL2 just runs real Linux in a VM. Simple concept, way better execution.

Real Linux, Real Performance

The biggest difference is that WSL2 runs an actual Linux kernel instead of pretending to be Linux. Microsoft builds their own kernel from Linux sources, which sounds sketchy but actually works well. Everything that runs on regular Linux runs on WSL2 - no more "this tool doesn't work because WSL1 doesn't support X syscall."

In my testing, it's about 90-95% of native Linux performance for most dev work. File operations between Windows and Linux are slower due to the translation layer, but anything within the Linux filesystem is basically native speed. I've seen NPM installs go from 45 seconds on Windows to 8 seconds in WSL2 just by moving the project to /home/username.

The VM That Doesn't Suck

WSL2 runs in a lightweight VM that boots in under 2 seconds and goes to sleep when you're not using it. None of the pre-allocation bullshit that VirtualBox or VMware makes you deal with. It starts around 200MB RAM and can eat 50% of your system memory if you let it (there's a config for that).

Key things that make it work:

• Instant startup: No waiting for a VM to boot
• Dynamic memory: Takes what it needs, gives back what it doesn't (eventually)
• File sharing: Access Windows files from Linux and vice versa
• systemd support: Finally works properly as of 2022

File System Reality Check

You can access Windows files from Linux at `/mnt/c` and Linux files from Windows at `\\wsl$`. Sounds great in theory, has gotchas in practice.

The Golden Rule: Keep your code in the Linux filesystem (/home/username), not on the Windows side. Cross-filesystem operations are slow enough to be annoying. If you keep a React project on your Windows desktop and run npm start from WSL2, file watching barely works and hot reload takes forever.

What actually works well:

• Linux tools operating on Linux files: Fast
• Windows editors (VS Code) editing Linux files via WSL extension: Fast
• Linux tools operating on Windows files: Slow but functional
• Windows tools operating on Linux files: Usually works, sometimes doesn't

The performance difference is real - I've measured 5-10x slower build times when projects live on the Windows filesystem versus the Linux filesystem. Microsoft acknowledges this limitation in their docs.

Microsoft says WSL2 is for development environments, not production workloads. That said, it's solid for dev work and we've been using it for local development for years. Enterprise teams love it because developers can finally use Linux tools without IT departments freaking out about dual-boot setups.

Docker Without Docker Desktop Licensing Hell

You can run Docker CE directly in WSL2 instead of paying for Docker Desktop licenses. Saved us thousands when Docker changed their licensing terms. The setup is straightforward:

## Install Docker CE in Ubuntu WSL2
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
sudo apt-get update && sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo usermod -aG docker $USER

What Actually Works:

• Docker Engine: Full Docker daemon, no weird Desktop wrapper
• Docker Compose: Multi-container setups work fine
• Kubernetes: k3s and minikube work, though resource usage can be rough
• Registry Access: Pulls from private registries just like normal Linux

Performance Reality: In my testing, Docker containers in WSL2 run about 5-10% slower than native Linux. For development work, you won't notice the difference. Official benchmarks confirm similar results.

systemctl Actually Works Now

They added systemd support in 2022, and it took them long enough. You can enable it by editing /etc/wsl.conf:

[boot]
systemd=true

Then wsl --shutdown and restart. Now you get:

• Service Management: systemctl works like on real Linux
• Database Services: PostgreSQL and Redis start on boot instead of manual startup scripts
• Web Servers: Nginx actually stays running between sessions
• Software Compatibility: Stuff that expects systemd doesn't break anymore

Caveat: systemd adds about 50MB to idle memory usage and slows boot time by a few seconds. Worth it for the convenience.

GPU Access for Machine Learning (When It Works)

CUDA works in WSL2 through GPU passthrough, though setup can be a pain:

## Install NVIDIA drivers on Windows first
## Then install CUDA toolkit in WSL2
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.0-1_all.deb
sudo dpkg -i cuda-keyring_1.0-1_all.deb
sudo apt-get update && sudo apt-get install cuda

What Works:

• TensorFlow/PyTorch: GPU training works, similar performance to native Linux
• CUDA Development: nvcc compiler and runtime work fine
• Data Science: Jupyter with GPU acceleration

What's Annoying:

• Driver Hell: Windows NVIDIA drivers must be recent enough
• Memory Limits: GPU memory shows up weird in monitoring tools
• Docker + GPU: Extra complexity with --gpus all flag

Used this setup for training models and it's decent. Not as smooth as native Linux but works for development.

IDE Integration That Actually Works

Visual Studio Code: The Remote-WSL extension is legitimately good. VS Code runs on Windows but executes everything in the Linux environment. IntelliSense works, debugging works, terminal integration works. It's the closest thing to magic Microsoft has made.

JetBrains: IntelliJ and PyCharm have WSL2 support but it's clunkier than VS Code. File indexing can be slow on large codebases, and sometimes the remote interpreter gets confused.

Windows Terminal: Use this instead of the old command prompt. Supports tabs, proper Unicode, and decent copy/paste. Add your WSL2 distributions as profiles.

Git Gotcha: Git works across Windows/Linux but line endings will bite you. Set up .gitattributes properly or you'll have CRLF/LF issues when switching between Windows and Linux tools.

## One-time setup to avoid line ending hell
git config --global core.autocrlf input
git config --global core.safecrlf true

Enterprise Deployment and Reality

Group Policy: You can control WSL2 through Group Policy, but most IT departments just disable it entirely because they don't understand it.

Windows Updates: WSL2 kernel updates come through Windows Update. Sometimes this breaks things when a kernel update changes behavior without warning.

Microsoft Store: Enterprise deployments often can't access the Microsoft Store. You'll need to sideload Linux distributions or use `wsl --import` with custom images.

Corporate Networks: WSL2 plays reasonably well with corporate proxies and VPNs, but expect some debugging. VPN software often breaks WSL2 networking, and you'll get familiar with wsl --shutdown as a fix.

Real Deployment Tip: Set up a base WSL2 image with your company's tools pre-installed, then distribute it as a .tar file. Much easier than having every developer configure their environment from scratch.

The open-sourcing in 2025 helps with enterprise adoption because IT can actually audit the code instead of trusting Microsoft blindly.

The wsl --install command works great until it doesn't. If you get weird errors, you probably need to enable virtualization in BIOS first.

Quick Installation That Usually Works

Open PowerShell as Administrator and run:

wsl --install

This should:

• Enable Windows features (WSL and Virtual Machine Platform)
• Download the WSL2 kernel
• Install Ubuntu by default
• Force a reboot

Reality Check: Half your problems will be "virtualization disabled in BIOS" and you'll spend 20 minutes in UEFI settings. The other half will be Windows Update being broken.

After reboot, create your Linux username. Don't use the same name as your Windows user or you'll have permission weirdness later.

When the Easy Install Breaks (It Will)

If wsl --install shits the bed, you're stuck with manual installation. Here's the pain you're in for:

First, enable WSL (this will probably require a reboot):

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Then enable the VM platform (another reboot incoming):

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Download the WSL2 kernel update from Microsoft's site, set WSL2 as default, then pray the Microsoft Store actually works to install your Linux distro. Half the time the Store is broken for enterprise accounts anyway.

Distribution Management

WSL2 supports running multiple Linux distributions simultaneously. Common management commands include:

## List available distributions for installation
wsl --list --online

## Install specific distribution
wsl --install -d <DistributionName>

## List installed distributions
wsl --list --verbose

## Set default distribution
wsl --set-default <DistributionName>

## Start specific distribution
wsl -d <DistributionName>

Ubuntu 22.04 LTS is the safe choice - it's what everyone uses and what Microsoft actually tests. Debian works fine too. Kali is for security people who want to feel dangerous. SUSE Enterprise costs money and nobody uses it on their laptop.

Most companies just stick with Ubuntu because IT departments hate supporting multiple Linux flavors and Ubuntu has the longest support cycle.

Performance Optimization (Actually Important)

Memory Limits: WSL2 will eat your RAM if you let it. Create `%USERPROFILE%\.wslconfig` to set limits:

[wsl2]
memory=8GB
processors=4
swap=2GB
localhostForwarding=true

Without this, my 'idle' Ubuntu instance sits at 800MB after installing dev tools and can grow to consume 50% of system RAM during large builds.

File System Performance: This is critical. Keep your code in /home/username/, not /mnt/c/. Cross-filesystem operations are dog slow:

• My builds went from 45 seconds to 8 seconds moving code to Linux filesystem
• npm install takes forever when reading from Windows filesystem
• File watching (like webpack dev server) barely works cross-filesystem

The Golden Rule: Code lives in Linux, tools run in Linux. Use Windows just for browsing and Slack.

Development Environment Setup

Here's how we set up our WSL2 environments (after some trial and error):

Install the basics (do this or spend your weekend fixing missing dependencies):

sudo apt update && sudo apt upgrade -y
sudo apt install build-essential git curl wget vim nodejs npm python3 python3-pip

Git credential sharing (so you don't type your password 50 times a day):

git config --global credential.helper \"/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager-core.exe\"

VS Code Integration: Install the Remote-WSL extension to edit WSL2 files directly from Windows VS Code.

Troubleshooting (Your Weekend Plans)

\"WSL2 randomly loses network connectivity\": This happens all the time, especially with VPN software. wsl --shutdown fixes it 90% of the time. The other 10% requires rebooting Windows.

\"Can't connect to localhost from Windows\": WSL2 networking is complicated. Try:

## In WSL2, find your IP
ip addr show eth0
## Connect to that IP from Windows instead of localhost

\"File permissions are fucked\": Windows and Linux have different permission models. If you created files in Windows, they might have weird permissions in Linux:

## Nuclear option - fix ownership of everything
sudo chown -R $USER:$USER /home/$USER

"WSL2 uses all my disk space": The virtual disk auto-grows but never shrinks. Clean up with:

## Clean Docker if you use it
docker system prune -a
## Or export/import to reclaim space
wsl --export Ubuntu ubuntu-backup.tar
wsl --unregister Ubuntu
wsl --import Ubuntu C:\WSL2\Ubuntu ubuntu-backup.tar

"My VPN breaks WSL2": VPN software often conflicts with WSL2 networking. Cisco AnyConnect and some enterprise VPNs are notorious for this. Try mirrored networking mode or suffer.