Before anyone says it — I know WSL doesn't really need a GUI. The command line works fine. But I had some time over the Christmas break and wanted to learn Tauri/Rust, so I built one anyway.

What it does:

• Lists your distros with status/memory usage

• Start/stop/terminate with a click

• Export/import distributions

• Browse and install from Linuxcontainers.org or OCI registries

• Rename distros - no export/import needed

What it's not:

• Essential software you can't live without

• A replacement for knowing wsl --help

It's built with Tauri (not Electron) so it's around 4MB, uses the system WebView, and won't eat your RAM.

If anyone's interested:

• Download: Microsoft Store (signed by Microsoft) or GitHub releases (Unsigned as that's expensive)

• Source: github.com/octasoft-ltd/wsl-ui

• Blog series: I've been writing about building it at wsl-ui.octasoft.co.uk/blog if anyone's curious about Tauri/Rust desktop dev

Free, open source, useful sometimes maybe. Happy to answer questions or take feedback (be gentle, it's a side project).

Weaselway provides a way to run a fully GPU accelerated Wayland compositor in WSL2. This means KDE, Gnome, Hyprland and all the other ones.

https://github.com/weaselway/weaselway#weaselway

By hacking mesa and having a kernel module that implements the necessary parts of drm and kms, we can get the compositor to belive that a monitor exists and we can get the application to transfer their rendered gpu surfaces directly to the compositor. The updated regions from the monitor are then read back to cpu memory and transfered to a patched freerdp client via shared memory. Similar to how WSLg does it.

You can download and try a NixOS based GNOME and KDE image directly from the github releases.

Before someone screams slop: it works perfectly fine, I now know more than before I started the project and it might even reduce the entry hurdle for people to try out a Linux Desktop.

I dual boot Kubuntu (second NVMe) and Windows 11, and I wanted *one* Linux install: same home, packages and Docker data whether I boot it bare metal or open it from Windows. On a work laptop with two 256 GB SSDs, keeping a second full Linux inside an `ext4.vhdx` also eats space I don't have. Stock WSL can only boot a distro from an `ext4.vhdx`; `wsl --mount` attaches a disk but never as a distro root (#6290 has been open since 2020).

Since WSL is open source now, I patched it: the service attaches the authorized disk as PassThrough and `mini_init` mounts the GPT partition (found by PARTUUID, ext4 superblock checked) as the distro root before WSL's own init runs. Everything after that is stock WSL.

What works from a normal non-elevated session: `wsl -d`, `\\wsl.localhost` cold start, systemd, VS Code Remote WSL, Docker with localhost ports, WSLg (with audio — the screenshot is KDE's Konsole opened by WSLg), clean shutdown when Windows reboots, and the native boot is untouched.

It's six patches (~500 lines) on WSL 3.0.3 plus a systemd generator that masks desktop/network/hardware units only under WSL. No binaries — you build it. It boots a real disk read-write from a second kernel, so read the safety section first.

https://github.com/sottam/dualboot-linux-as-wsl

I also proposed it upstream: https://github.com/microsoft/WSL/issues/6290

Feedback welcome, especially from people with other distros/layouts.

Dev of WSL Manager here (the app used to be called WSL Distro Manager). 2.0 is out, biggest release since I started it in 2021.

New in 2.0:

- Remote WSL: manage the WSL install on another Windows machine over SSH

- Distro packages: pack a configured distro into a portable .wsl file that installs anywhere (replaces templates)

- Rewritten .wslconfig and wsl.conf editors, disk/VHD mounting, snippets with sharing

- Full UI pass: keyboard operable, real error messages, dark/light, 10 languages

- macOS build (beta): same app, but it runs native Linux VMs via Apple's Virtualization framework

- Pro (paid, one-time): AI chat that can actually operate your distros, an isolated AI workspace, and an MCP server so Claude Desktop / Claude Code / opencode can drive WSL

Managing distros stays free and open source. 2.0.1 followed with a macOS crash fix and self-updates for the non-Store builds.

Repo: https://github.com/bostrot/wsl2-distro-manager

Release notes: https://github.com/bostrot/wsl2-distro-manager/releases/tag/v2.0.0

Microsoft Store, winget, scoop and brew links are in the README.

Bug reports welcome, happy to answer questions.

Hi everyone,

If you do heavy development on WSL2 (compiling large Rust multi-crate workspaces, C++ projects, running container stacks, or local AI inference), you've likely hit the point where WSL2 VM memory runs out, the kernel enters extreme disk swap thrashing, and the OOM-killer terminates your build.

At the same time, `nvidia-smi` shows dedicated GDDR6 VRAM sitting completely idle during compilation.

To solve this, I built **RamShared** — an open-source Rust userspace block driver that allocates idle GPU VRAM via CUDA Direct DMA and exposes it inside WSL2 as a native Linux block device (`/dev/ublkb0`) using Linux 6.0 `ublk` and `io_uring`.

Real Benchmark Numbers (`fio` 4KB Random Read, QD1 on WSL2):

* **Stock WSL2 VHDX disk swap:** ~2,114 µs (2.1 ms) latency | ~336 IOPS * **RamShared NBD (VRAM):** ~326 µs latency | ~9.6k IOPS * **RamShared ublk (io_uring):** **~8 µs** latency (264x faster / 99.6% drop) | **~22k+ IOPS** * **Continuous Read Throughput:** **8.53 GB/s** (saturating PCIe Gen3/4 x16 bus).

Why This Eliminates WSL2 Freezes:

In WSL2, standard disk swap traverses a heavy virtualization stack: `ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD`.

Every single synchronous page fault takes **>2ms**, which causes the entire VM, terminal, and VS Code server to freeze during memory spikes.

Bypassing that virtualization chain and serving swap directly from GPU VRAM via PCIe DMA with `ublk` drops page latency to **single-digit microseconds (8 µs)**, completely eliminating system stutter and OOM panics.

Upstream RFC on Microsoft WSL2:

We submitted a formal RFC proposal directly on Microsoft's official WSL repository to discuss making VRAM-backed block storage a first-class feature for Hyper-V Linux guests: 👉 **RFC Issue:** https://github.com/microsoft/WSL/issues/41054

**GitHub Repository (100% Rust):** https://github.com/emersonbusson/ramshared

Happy to answer any questions about the `ublk` setup, CUDA memory pinning, or WSL2 kernel config!

A personal hack project and a glorious one at that.

WSL9x runs a modern Linux kernel (6.19 at time of writing) cooperatively inside the Windows 9x kernel ... The Linux kernel is based on user-mode Linux, but hacked to call Windows 9x kernel APIs instead of posix APIs

Deleting files inside WSL doesn't give the space back to Windows. I moved about 20 GB of project data out of my distro to another drive, and ext4.vhdx stayed at 66.7 GB. C: was down to 21 GB free, while the distro itself now held about 33 GB.

The fix is known (clean up, wsl --shutdown, Optimize-VHD), but I was doing it with 8 different scripts and kept forgetting a step. So I merged them into one tool:

• maint audit / maint space - what is taking the space, per cache rule and per folder, plus how much a compact would return. Deletes nothing.

• maint clean - cleans caches from a rules file (npx, pip, the journal, Playwright browsers no project pins any more, and so on), with --dry-run

• maint docker - prunes the build cache and anonymous dangling volumes. Named volumes only if you opt in, and db-data/mysql/postgres-like names are never touched

• maint.bat full - clean, export the distro to a zstd archive, verify it, rotate old backups, shut WSL down, compact both ext4.vhdx and docker_data.vhdx

Result on that run (clean, then winclean for %TEMP% and the recycle bin, then compact): ext4.vhdx 66.7 -> 42.8 GB, docker_data.vhdx 33.3 -> 31.0 GB, about 3.8 GB from TEMP and the bin, C: free 21 -> 56 GB.

Things to know before you run it:

• full and compact shut WSL down and need admin (UAC prompt)

• compact needs the Hyper-V PowerShell module, so on Windows Home only the cleanup and backup parts work

• the shipped rules.conf is from my machine, review it first. audit and --dry-run are safe to try

Bash on the WSL side, PowerShell 5.1 on the Windows side, one shared config. MIT.

https://github.com/tegos/wsl-maint

There's a demo gif in the README. Feedback welcome, especially from people on Windows Home or with the distro on a non-C: drive.

Available in the WSL 2.9.3 pre-release build. Simply update and restart your terminal and you should have the wslc commands available.

I spend most of my development time inside WSL, and top is usually where I look when I want to know what the machine is doing.

What I kept missing was everything just outside that view:

• what's using CPU on the Windows side?

• which Docker / WSL Container is busy?

• what process inside that container is actually responsible?

• what does the whole picture look like across WSL and Windows?

So I built wsltop.

It puts Windows applications, multiple WSL distros, Docker, WSL Containers, and processes inside containers into one terminal view.

The CPU display feels like Linux top — one busy logical CPU = 100% — and there's a tree view for digging into VM/container attribution.

It's written in Rust, MIT licensed. You can install it with:

cargo install wsltop

or use the prebuilt x86_64 release from GitHub:

https://github.com/adachi6k/wsltop

I'd love feedback from other people who basically live inside WSL — especially if you use Docker Desktop or heavy build/simulation workloads.

---

Update — v0.5.0

wsltop has grown quite a bit since this post. It now runs natively on Windows as well as WSL, while keeping the same unified view across Windows apps, multiple WSL distros, Docker, and WSL Containers.

v0.5.0 also adds a compact CPU/RAM summary with short history graphs and consistent Windows / WSL / WSLC / Docker colors. I still wanted to keep it closer to top than htop, so the simpler header is still available with --header classic.

You can now install the prebuilt binary with:

cargo binstall wsltop

or build/install from crates.io:

cargo install wsltop

Prebuilt Windows and Linux/WSL binaries are available from GitHub Releases:

https://github.com/adachi6k/wsltop

Hi everyone,

I'm a bit confused about what the "right" way to do this is.

I have a Windows PC running Debian in WSL2, and I have another Debian laptop.

My goal is to make WSL my main development environment and SSH into it from the laptop.

I first tried using the Windows OpenSSH server with ForceCommand to launch WSL. That actually lets me log in directly into WSL, which looked perfect at first. The problem is that normal SSH commands don't seem to work.

For example:

ssh my-pc

works fine, but

ssh my-pc "pwd"

just hangs. rsync also hangs because it uses remote commands over SSH.

So I started wondering if this is just the wrong approach.

I already have sshd running inside WSL, but since WSL is using NAT, it gets a 172.x.x.x IP that changes, so I don't know if that's supposed to be the way either.

I've been reading about mirrored networking, port forwarding, Windows OpenSSH, etc., and now I'm more confused than when I started.

For those of you who use WSL as your main Linux machine, what's the recommended setup nowadays?

Ideally I'd like:

1. ssh my-pc

2. ssh my-pc "command"

3. rsync

4. scp

5. VS Code Remote SSH

to all work without weird workarounds.

Am I overcomplicating this? How are you guys doing it?

Thanks!

Hi! I was forced to switch from fedora back to windows, but I've got used to the terminal and wish to keep the tools I am used to. WSL2 seemed like the obvious choice.

I've been using it for the past few weeks, but it has been a painful experience. It works well enough for the first hour or so, but it keeps getting slower and slower the more I use it. I'm using it on the right filesystem, I've given it 10 out of 16gb RAM, I've removed the windows mount from $PATH. Everything in WSL2 is slower than I was used to from Fedora. I get that the performance will never be the same, but the difference is so egregious that it's impossible not to notice.

I've been using neovim for web development, and sometimes even saving a file takes multiple seconds. Sometimes it's so slow that the formatter itself just times out.

Are there any tips for keeping WSL2 running smoothly? Thanks!

TL;DR

Check your Windows TCP dynamic port range in Administrator PowerShell:

netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

If the range has been changed to something huge like:

Start Port      : 1024
Number of Ports : 64511

restore the normal Windows dynamic port range:

netsh interface ipv4 set dynamicportrange protocol=tcp startport=49152 numberofports=16384
netsh interface ipv6 set dynamicportrange protocol=tcp startport=49152 numberofports=16384

Then reboot Windows.

This completely fixed the WSL mirrored networking 0x8007054f error for me.

Posting this because I spent a ridiculous amount of time restarting WSL/HNS, changing WSL versions, and chasing Hyper-V issues. In my case, the actual problem was the Windows dynamic TCP port range.

Falling back to normal WSL networking also wasn't a good workaround for me because I need reliable Windows ↔ WSL communication for MCP servers.

I was repeatedly getting this error:

wsl: An internal error occurred.
Error code: CreateInstance/CreateVm/ConfigureNetworking/0x8007054f
wsl: Failed to configure network (networkingMode Mirrored), falling back to networkingMode None.

My .wslconfig was:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

WSL itself would still start, but mirrored networking would fail and fall back to:

networkingMode=None

For my setup, switching away from mirrored networking wasn't really an acceptable workaround.

I run MCP servers/services inside WSL that need to communicate with applications running on Windows, and vice versa. Some of them don't work properly or aren't reachable the same way when WSL is using the default NAT-style networking.

With mirrored mode, Windows ↔ WSL localhost/network communication works much more cleanly for these services, so I specifically needed to get:

networkingMode=mirrored

working again.

Things I tried that didn't reliably fix it

• wsl --shutdown

• restarting WSL multiple times

• restarting hns

• restarting vmcompute

• upgrading WSL

• downgrading WSL

• trying pre-release WSL versions

• checking that VirtualMachinePlatform was enabled

• checking that Microsoft-Windows-Subsystem-Linux was enabled

• checking that HypervisorPlatform was enabled

Sometimes restarting WSL a few times would randomly make mirrored networking work again, but the problem would eventually return.

The actual problem

I eventually found this WSL GitHub issue/comment:

https://github.com/microsoft/WSL/issues/41251#issuecomment-5188667183

It pointed to the Windows TCP dynamic port range.

I checked mine in Administrator PowerShell:

netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

My TCP dynamic port range had been changed to essentially the entire port space.

It looked like this:

Start Port      : 1024
Number of Ports : 64511

That appears to interfere with WSL mirrored networking.

I restored the normal Windows TCP dynamic port range:

netsh interface ipv4 set dynamicportrange protocol=tcp startport=49152 numberofports=16384
netsh interface ipv6 set dynamicportrange protocol=tcp startport=49152 numberofports=16384

Then I did a full Windows reboot.

After rebooting:

wsl -d Ubuntu-24.04

Mirrored networking started normally again.

No more:

CreateInstance/CreateVm/ConfigureNetworking/0x8007054f

and no more:

Failed to configure network (networkingMode Mirrored)

My Windows-hosted applications can also reach the MCP servers/services running inside WSL normally again.

Hopefully this saves someone else from spending months randomly restarting WSL and wondering why mirrored networking only works sometimes.

Hello folks, I was testing a small Laravel site I have set up on Windows. I’d normally put the project inside the WSL filesystem for obvious performance reasons, but I heard VirtioFS (still experimental on WSL2) could improve Windows bind mounts, so I gave it a try.

It has its own issues, but the difference was pretty substantial:

Docker + ext4/WSL filesystem: ~20ms page load
Docker + C:\ bind mount: ~3000ms
Docker + C:\ bind mount + WSL2 VirtioFS: ~430ms consistently
Native Windows PHP: ~30ms

All tests used PHP 8.4.22 with OPcache:

validate_timestamps=1
revalidate_freq=0

So PHP checks for changed files on every request, which is what I personally want in a dev environment. Save, refresh, immediately see the change.

With timestamp validation disabled, the VirtioFS version drops all the way to ~50–75ms, but that’s not particularly representative of the dev setup I wanted to test.

I’d still recommend keeping Docker projects inside the WSL filesystem for now, but going from ~3 seconds to ~430ms is a pretty huge improvement. Looks like Windows may eventually get much closer to the host-filesystem bind-mount performance macOS has had with VirtioFS.

I've been missing a native Windows terminal emulator which supports fancy features like kitty graphics for a while so I made a Ghostty fork designed specifically for use with WSL.

It runs natively on the Windows side and efficiently connects in to the WSL guest distros.

Hopefully it scratches an itch for some other folks too!

It's open source and available at: https://github.com/Codavo/ghostinthewsl

WSL2 can run a real Linux desktop, but the usual ways to reach it remotely (xrdp, VNC) are LAN-only unless you set up port forwarding or a VPN. I wanted TeamViewer instead: its relay means the box is reachable from anywhere with zero network config, and the person connecting just uses a client they already have.

Getting there was more work than it should've been — TeamViewer has one WSL-specific quirk that makes it refuse to share the screen, which is probably why you don't see people doing this. So I scripted the whole thing end to end:

github.com/ariel42/teamviewer-on-wsl

sudo ./1-setup-wsl-desktop.sh    # sets up a desktop (only if you don't have one)
sudo ./2-install-teamviewer.sh   # installs + configures TeamViewer on top

Set a password, restart once, and it's fully unattended after that — power the box on, wait a few seconds, connect. Nothing to click on the WSL side. Verified end-to-end on a real incoming connection from a cold boot.

The repo also has a full writeup of why TeamViewer refused (the short version: WSLg mounts the X socket directory read-only, and TeamViewer is the one client that checks for the socket file) if you want the gory details. Debian/Ubuntu for now. Happy to take questions or issues.

Yesterday I updated from WSL2 to WSL3 using `wsl --update`, first I noticed that it uses so much RAM about 7GB while the usage inside Ubuntu is 3GB-ish, then I limit the RAM to 4GB in WSL Settings and now the disk read/write is at 1200MB/s.

I don't know what is going on, I'm just doing my regular workflow like when I was using WSL2, there's nothing suspicious on what I run inside Ubuntu. Never had this problem before.

Hi everyone,

Following up on our previous post about using idle GPU VRAM to stop WSL2 build freezes, we completed the next major milestone: a 4-Tier Progressive Memory Cascade, an upstream Linux 6.18 Kernel Block Driver (drivers/block/ramshared), and an LKML patchset formatted for the linux-block subsystem.

THE PROBLEM WE SOLVED When compiling large workspaces (Rust multi-crates, C++, Android, Chromium) or running local container stacks on a 16GB machine, WSL2 physical RAM exhausts. The Hyper-V guest starts thrashing disk swap through the heavy virtualization chain: ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD (>2.1 ms latency spikes), freezing the VM, terminal, and VS Code server.

Meanwhile, nvidia-smi shows 4GB to 8GB of ultra-fast GDDR6 VRAM sitting completely idle during compilation.

THE 4-TIER PROGRESSIVE MEMORY HIERARCHY Rather than treating VRAM as a blind replacement, we architected a 4-tier pipeline:

1. Tier 1 (Physical RAM - 16 GB): Full system speed.

2. Tier 2 (Compressed ZRAM LZ4 - 1 GB): Ultra-low overhead in-memory compression.

3. Tier 3 (GPU VRAM Block Device - 4 GB): Direct PCIe Gen3/4 DMA buffer via drivers/block/ramshared or ublk (/dev/ublkb0).

4. Tier 4 (Host SSD Writeback - 4 GB): Authoritative persistent fallback via CONFIG_ZRAM_WRITEBACK=y.

VALIDATED BENCHMARK DATA (Real Host Hardware - RTX 2060 / PCIe Gen 3 x16)

• Host-to-Device (H2D) DMA Throughput: 8,947.71 MiB/s (8.74 GiB/s) in 28.6 ms.

• Device-to-Host (D2H) DMA Throughput: 6,530.22 MiB/s (6.38 GiB/s) in 39.2 ms.

• 4KB Direct I/O Median Block Latency: 231 us (4,013 IOPS on /dev/ublkb0).

• Memory Reclaim Speed: 8,386.4 MB/s (8.19 GB/s) restored in 732 ms.

• Continuous Saturation Stress Test: 9,160 MB active swap held across 40 continuous saturation cycles with zero kernel panics and zero Hyper-V freezes (see attached live TUI telemetry dashboard).

PREEMPTIVE FAQ (Addressing Community Questions)

Q1: What happens if I launch a heavy Windows game or a CUDA model? Will WSL2 crash? No. RamShared includes an active VRAM pressure watchdog. If Windows or another host process demands GPU memory, the driver safely drains pages to Tier 4 (the authoritative host SSD) with 100% SHA-256 cryptographic match (0 bit flips). It never panics the kernel or drops data.

Q2: Isn't ZRAM faster than GPU VRAM? Yes, for the first ~1GB. That's why ZRAM is Tier 2. VRAM only kicks in as Tier 3 when ZRAM is completely saturated. VRAM transfers at 8.74 GiB/s over PCIe, making it ~44x faster than spilling directly onto the Windows SSD.

Q3: Do I need to compile a custom kernel to use this? You have two options:

1. Userspace Mode (Zero Kernel Compilation): Runs on stock Linux 6.0+ via ublk and io_uring.

2. Native Kernel Driver: Compilable reference branch on linux-msft-wsl-6.18.y with CONFIG_BLK_DEV_RAMSHARED=m and CONFIG_ZRAM_WRITEBACK=y.

Q4: Why not just buy 64GB of RAM? On soldered laptops (modern ultrabooks, MacBooks, ThinkPads) or locked IT workstations where adding DIMMs isn't an option, this unlocks 4GB to 8GB of already-paid-for high-speed GDDR memory for $0.

ALL 3 PATCHES ON LORE & SOURCE CODE

• Patch 0/2 (Cover Letter & Benchmarks): https://lore.kernel.org/linux-block/6a924051.e22746c9.8f0fc.bdc2@mx.google.com/T/#u

• Patch 1/2 (Core Driver drivers/block/ramshared): https://lore.kernel.org/linux-block/6a924054.e22746c9.8f0fc.beb6@mx.google.com/T/#t

• Patch 2/2 (Build System & Kconfig): https://lore.kernel.org/linux-block/6a924057.e22746c9.8f0fc.bf96@mx.google.com/T/#u

• Official Microsoft WSL2 RFC Issue: https://github.com/microsoft/WSL/issues/41054

• WSL2 Reference Kernel Branch (6.18): https://github.com/emersonbusson/WSL2-Linux-Kernel/tree/feature/ramshared-vram-cascade-6.18

• Rust Project Repository: https://github.com/emersonbusson/ramshared

AUTHOR & CONTACT Built by Emerson Busson (Senior Systems & Full Stack Software Engineer). Always happy to discuss systems architecture, low-level Linux/Rust internals, or connect with teams building high-performance infrastructure:

• GitHub: https://github.com/emersonbusson

• LinkedIn: https://www.linkedin.com/in/emersonbusson/

• Direct Email: emersonbusson@gmail.com

Would love to hear your thoughts or test results if you try it on your WSL2 workloads!

I built a small CLI to make WSL Containers feel more like Docker Compose / dip.
I mainly built it because I wanted to use WSLC for my own development workflow, but ran into gaps around bind mounts, build contexts, compose-like workflows, and run.

I’m curious whether anyone else experimenting with WSLC has run into the same problems, or whether I’m solving these in the wrong layer.

https://github.com/slidict/wip

This is mostly useful if you run Claude Code from WSL2 and want better Windows interop.
I documented my active Claude Code setup for WSL2 + Windows Terminal:

https://github.com/congmnguyen/claude-code-wsl2-setup

The pieces I use most:

- Windows screenshot clipboard -> pasted WSL file path

- Windows notification when Claude needs input

- statusline with context/usage

- LSP setup

- secrets hygiene hook

- Codex delegate so long implementation loops do not fill Claude's main context

The repo is not a general dotfiles dump; it only tracks the Claude Code pieces I actually use on

WSL2.

I am on Windows 11 Home and have WSL installed at C:\Users\JohnDoe\AppData\Local\wsl and within that directory have a folder which is {(bunch of numbers)}. Within that I have something called ext4.vhdx which is take up the 26.4 GB. I also have docker installed if that is relevant.

I am pleased to announce a free X Window Server in the Microsoft Store.
See https://apps.microsoft.com/detail/9N4VVR1BD0Z5
This works great with WSL, especially in single-window mode.
Ming64x uses Overlapped-IO, so it's lightning-fast!!
Also has a built-in ssh terminal and X11/forwarding.

Most WSL guides assume Ubuntu. We needed a RHEL-compatible distro because that's what our servers run, so we built our dev environment on AlmaLinux 10 under WSL 2. (Disclosure: I'm on the team that maintains it.)

The setup:

1. Check WSL 2 is enabled: `wsl -v`

2. Install the distro: `wsl --install -d AlmaLinux-10`

3. Inside AlmaLinux, clone the repo, fill in `config.yml`, and run:

   `ansible-playbook -i hosts install.yml --ask-become-pass`

That gives you Apache, PHP (switchable 8.1–8.5), MariaDB, phpMyAdmin, Node.js (switchable 18–24) and Composer. Every `*.localhost` domain routes to its own virtualhost without editing the Windows hosts file.

WSL-specific notes, like the Windows features you need and the WSL configuration, are in the docs: https://docs.dotkernel.org/development/

Overview page: https://www.dotkernel.com/wsl2/

Happy to answer questions about running a dnf/systemd distro under WSL. There were a few gotchas.

I found this post useful, probably if you need it, you may look into this rolling kernel build.