Windows First Dev Setup with WSL2: Native Linux Tools on Windows

For years the accepted script for serious development read like a manifesto: run Linux on your primary machine, dual‑boot if you must, and keep Windows for gaming or creative apps. That script is fraying. A growing number of developers are finding that a well‑tuned Windows 11 environment — anchored by WSL2, a modern terminal, container support, and a declarative package manager — gives them the best of both worlds: native Windows productivity and a real Linux development environment without the constant reboot tax or the battery and performance penalties of running full VMs. This piece examines that shift, verifies the technical claims behind it, and lays out a practical, reproducible roadmap to build a robust developer workstation on Windows while honestly weighing the downsides and edge cases you need to watch for.

Background​

For the last decade developer workflows evolved around trade‑offs. Linux offered a minimal surface area, native toolchains, and predictable production parity for server workloads. Windows offered a vast native application ecosystem — creative suites, desktop applications, gaming — but historically lagged in terminal quality, package management, and native Linux compatibility.
That imbalance narrowed significantly with the arrival and maturation of Windows Subsystem for Linux (WSL) — especially WSL2 — and a wave of developer‑focused improvements to Windows: a sleek Windows Terminal, Visual Studio Code’s Remote - WSL tooling, Docker Desktop’s WSL2 backend, and an improving Windows package ecosystem led by winget. These changes make the argument “just use Linux” less prescriptive and more personal: the right OS is the one that reduces friction and increases delivery speed.

---

Why dual‑booting and VM workflows often fail developers​

The reboot tax and context switching​

Dual‑boot setups carry a repeated, measurable cost: every OS switch interrupts flow. For developers who split time between code, design, and media, that interruption is more than inconvenience — it is lost context. Rebooting, opening files, reconfiguring window layouts, and reconnecting devices can eat ten minutes or more per switch. Multiply that by multiple switches per day and the cumulative productivity loss is significant.

Virtual machines introduce resource and battery costs​

Running a full Linux virtual machine alongside Windows is a pragmatic compromise, but it brings two major tradeoffs:

• VMs consume CPU and memory even when idle, reducing battery life and squeezing resources on laptops.
• I/O and GPU passthrough can be awkward to configure, sometimes limiting the user experience for graphics‑heavy or I/O‑sensitive tasks like building large projects or video editing.

For many modern laptops these overheads directly impact the developer experience and the ability to work untethered.

---

What changed: WSL2, Windows Terminal, VS Code and Docker​

WSL2: a real Linux environment inside Windows​

WSL2 runs a real Linux kernel in a lightweight utility VM, giving near‑native syscall compatibility and substantial performance improvements over the original WSL. That means package managers, shells, language runtimes, shell scripts, and Linux‑native debugging and build tools run as expected, without the clunky translation layers of the past.
Key practical benefits:

• True Linux userland with popular distros available (Ubuntu, Debian, Fedora, etc..
• Filesystems inside WSL use an ext4 image, with fast Linux I/O for files kept in the WSL filesystem.
• Integrated GUI support for Linux GUI apps and GPU acceleration in more recent releases (useful for machine learning and GPU‑accelerated workflows).

Benchmarks and field reports show that for many development tasks WSL2 can approach or match native Linux performance, though results vary by workload and how filesystems are used.

Windows Terminal: modern, extensible and fast​

Windows Terminal replaced the old, limited Console Host with a modern terminal that supports tabs, panes, Unicode, GPU‑accelerated rendering, multiple profiles, and deep customization. For developers who live in shells — bash, zsh, PowerShell, or fish — this is a huge QoL improvement over the old Windows command prompt.

VS Code + Remote - WSL: “open folder in WSL” is real​

Visual Studio Code’s Remote - WSL extension installs a small server inside your WSL distro and connects the VS Code UI to that environment. The result:

• Code editing runs against the Linux filesystem and language servers run where the runtime and dependencies live.
• Debugging, IntelliSense, linters, and terminals execute inside WSL, avoiding many cross‑OS path and permission quirks.
• You keep VS Code’s UI and integrations on Windows while running toolchains natively in Linux.

This combination is one of the most pragmatic and friction‑free ways to get a native Linux dev experience on a Windows host.

Docker Desktop on WSL2: container workflows that match Linux​

Docker Desktop’s WSL2 backend runs the Docker engine integrated with WSL, enabling Linux container workflows with less overhead and faster startup times than older Hyper‑V backends. Developers can run docker commands from WSL, mount project folders, and use the same containers that will run in CI or production, minimizing “it works on my machine” surprises.

winget: declarative, scriptable, and reproducible environments​

Microsoft’s Windows Package Manager, winget, gives Windows users the ability to script installs, upgrades, and exports of installed package lists. You can:

• Export a machine’s list of installed packages and import it on a fresh machine.
• Automate toolchain installs in provisioning scripts.
• Combine winget with config management to reproduce dev environments in minutes.

That brings Windows closer to the declarative provisioning experience long enjoyed by macOS and Linux users.

---

Real‑world strengths of the Windows‑first developer setup​

• Streamlined daily flow. No more reboots or juggling VMs when you need to quickly open a Photoshop file, test a Windows‑only installer, or debug with Windows tooling.
• Native app access. Use Adobe Creative Suite, Windows native debugging tools, Visual Studio for .NET, and games without compatibility layers.
• True Linux dev environment. WSL2 provides a genuine Linux runtime for package managers, container orchestration, and server‑targeted builds.
• Simplified provisioning. winget plus configuration scripts reduce new‑machine setup from hours to minutes.
• Container parity. Docker on WSL2 runs Linux containers natively, aligning local development with Linux servers.

These are not theoretical benefits; they are the day‑to‑day productivity gains many developers report when consolidating to Windows with WSL2.

---

Caveats, gotchas and real risks you must accept​

The Windows‑first workflow is not a panacea. Several real weaknesses remain and deserve honest attention.

1) You are operating in two namespaces​

Even with WSL2 there are two distinct environments — Windows and Linux — and the boundary can create subtle bugs:

• File system differences. Line endings, executable permissions, and case sensitivity can cause problems when files traverse the Windows and Linux boundaries.
• Path and environment differences. Build scripts or tools that assume paths, symlink behavior, or specific environment variables may fail unless you standardize execution inside WSL.
• Edge‑case behavior. Some low‑level networking, kernel ioctls, or platform‑specific features might behave differently in WSL than on a production Linux host.

Mitigation: keep your project files inside the WSL filesystem and run builds/tests inside WSL whenever possible.

2) File placement matters — performance and correctness​

A common pitfall is editing or running code stored on the Windows filesystem (for example /mnt/c or C:\projects) from inside WSL. That can be slower and introduce permission mismatches. Best practice:

• Keep active development files inside the WSL distro (e.g., /home/username/project).
• Use the Windows Explorer integration (\wsl$) or VS Code’s Remote - WSL to access those files from Windows without moving them to the Windows filesystem.
• Avoid editing WSL files with Windows tools directly; prefer Windows tools that are WSL‑aware or use the VS Code remote workflow.

3) Windows updates still break things — and the telemetry concern remains​

Windows has matured as a developer platform, but feature updates and security patches occasionally break workflows or drivers. Recovery tools, peripheral drivers, or specific enterprise features can break in certain configurations after updates. Additionally, Windows continues to include telemetry and cloud features that some developers find intrusive. Mitigation strategies include deferring non‑urgent updates, maintaining robust backups, and using group policy / configuration tooling to harden a dev workstation — but those are not perfect and require maintenance.

4) Resource overhead on low‑spec machines​

Windows itself requires more baseline resources than a minimal Linux distro. On older or low‑RAM machines, this overhead matters. If you need the lightest possible footprint, or you’re running on very resource‑constrained hardware, Linux is still the better choice.

5) Occasional WSL quirks: networking, mounts, and compatibility​

WSL2’s lightweight VM model uses virtual networking and mounts that are usually seamless — yet there are documented oddities: transient networking issues, filesystem mount edge cases, and small differences in behavior compared to a full Linux VM. These usually have workarounds but can cost time in debugging.

---

When Linux still makes more sense​

Despite the attractions of a Windows‑first setup, Linux remains the right choice in several scenarios:

• You require the absolute minimal host overhead for performance‑sensitive tasks or servers.
• Your production environment relies on kernel features or distributions not available under WSL.
• You need maximum control over system components, low‑level security hardening, or deterministic update behavior.
• You are running older hardware with limited RAM and CPU.

The decision is about tradeoffs, not allegiances. For many developers, combining WSL2 with Windows delivers the best practical tradeoff; for others, Linux remains the optimal platform.

---

Reproducing the dream setup: practical recipe​

Below is a concise, repeatable plan to build a modern Windows‑first developer workstation that preserves a real Linux environment and minimizes friction.

Prerequisites​

• A Windows 11 machine with virtualization enabled in firmware (VT‑x/AMD‑V).
• At least 8 GB RAM (16 GB recommended).
• Recent Windows updates (Windows 11 22H2 or later recommended for best WSL support).
• Administrative privileges for initial setup.

Step‑by‑step​

• Open an elevated PowerShell prompt and install WSL with a chosen distro:
• wsl --install -d ubuntu
• Restart if prompted.
• Configure WSL resource limits (optional, for better performance on laptops):
• Create C:\Users\<User>.wslconfig with:
  [wsl2]
  memory=8GB
  processors=4
  swap=2GB
• Then run: wsl --shutdown
• Install Windows Terminal from the Microsoft Store (or ensure it's the latest version).
• Install Visual Studio Code, and then add the Remote - WSL extension.
• Inside your WSL distro: cd ~/projects; code .
• VS Code will install its server component inside WSL automatically.
• Install Docker Desktop and enable the WSL2 backend:
• In Docker Desktop settings, enable "Use WSL 2 based engine" and integrate your distro.
• Set up winget for package automation:
• Use winget to install common utilities:
  winget install --id Git.Git -e --source winget
  winget install --id Microsoft.VisualStudioCode -e --source winget
  winget install --id Docker.DockerDesktop -e --source winget
• Export your package list:
  winget export -o C:\users\<User>\winget-packages.json
• Keep your active projects inside WSL (e.g., /home/<user>/projects). Use VS Code’s Remote - WSL for editing and debugging.
• Set up dotfiles and tooling inside WSL to standardize shell, editors, and language runtimes:
• Install nvm, pyenv, rbenv, or apt/pip/npm equivalents inside WSL.
• Optional: configure backups and image snapshots for your Windows install and WSL distributions (export critical data regularly).

Automating new machine setup​

Create a provisioning script (PowerShell) that installs winget packages, enables WSL, and optionally restores dotfiles. Use winget import to load a saved packages.json to reduce machine setup to a single command.

---

Troubleshooting checklist: common problems and fixes​

• If builds are slow, check whether sources are on /mnt/c; move them to the WSL filesystem and re‑run.
• If a Windows update breaks a tool or driver, try the Windows Update Catalog or the Update Assistant to reinstall/repair, and keep a restore point before major changes.
• If Docker containers fail to access files, verify Docker‑WSL integration and ensure the Docker daemon is running inside the WSL backend.
• For file permission issues, ensure file modes and ownership are set inside WSL and avoid editing WSL files from Windows editors that are unaware of Linux permissions.

---

Critical analysis: what this shift means for developers and organizations​

There are three broad implications to consider.
1) Productivity over purity: The modern Windows+WSL setup reflects a pragmatic shift from ideology to outcomes. Developers who value uninterrupted flow and immediate access to creative/Windows‑only tools will benefit. Organizations should measure developer throughput rather than mandate OS choices from first principles.
2) The convergence of platforms reduces vendor lock‑in, but increases the maintenance surface. Windows now offers Linux compatibility, but that means teams must maintain knowledge across both ecosystems. That’s not intrinsically bad, but it requires discipline: consistent CI environments, standardized container images, and clear documentation about where builds must run.
3) Security and manageability tradeoffs. Windows has improved manageability with declarative tooling and package management, but its telemetry and update cadence still require conscious governance. Enterprises may need to harden developer machines, centralize update control, or integrate endpoint protection that understands WSL components.

---

Final verdict: a pragmatic path, not a one‑size‑fits‑all mandate​

Moving your primary development environment from Linux to Windows — or choosing to stay on Windows and use WSL2 as your Linux runtime — is a defensible, modern choice for many developers. The productivity gains from eliminating the reboot tax, the convenience of native Windows applications, and the maturity of WSL2 plus Docker and VS Code remove many of the historical technical objections.
That said, the Windows‑first approach is not flawless: it demands attention to file placement, acceptance of occasional update‑related breakages, and a willingness to troubleshoot cross‑platform edge cases. For those running older hardware, or who require absolute parity with production kernels, native Linux may still be the superior option.
The right strategy is to design your environment around deliverables: where do your tests run, what environment does your CI expect, and which tools are non‑negotiable for your day‑to‑day work? If those answers align with Linux server targets but require sporadic use of Windows apps, a Windows host with WSL2 often hits the sweet spot: fast, flexible, and — above all — designed around getting work done instead of proving an operating system ideology.

---

If you want a checklist to reproduce the exact setup described here — including a sample winget packages.json, a recommended .wslconfig, and a VS Code settings.json tuned for Remote - WSL — it can be provided as an actionable script to copy and run.

---

Source: MakeUseOf I built my dream developer setup — and it's not on Linux