WSL — Windows Subsystem for Linux 2026: instalacja, dystrybucje, GPU CUDA, Docker, VS Code Remote (kompletny przewodnik)

Co to jest WSL i dla kogo

Windows Subsystem for Linux (WSL) to warstwa kompatybilności Microsoftu pozwalająca uruchamiać natywne dystrybucje Linuksa bezpośrednio w Windows 10 i 11 — bez maszyny wirtualnej w klasycznym rozumieniu, bez dual-boota i bez emulacji. W 2026 roku WSL jest dojrzałym narzędziem deweloperskim, a jego kod źródłowy został otwarty we wrześniu 2025.

WSL to dziś standard dla:

• Programistów webowych — Node.js, Python, Ruby, PHP, Go w natywnym Linuksie z dostępem do Windows IDE
• DevOps i sysadminów — Ansible, Terraform, kubectl, helm bez wychodzenia z Windows
• Data scientistów — pełne wsparcie GPU NVIDIA CUDA dla PyTorch, TensorFlow, Jupyter
• Edukacji — Linux bez ryzyka uszkodzenia głównego systemu
• Security researcherów — Kali Linux, narzędzia pentestingowe natywnie w Windows

W 2026 Microsoft zapowiedział dalsze przyspieszenie operacji plikowych, lepszą wydajność sieciową i ściślejszą integrację z Intune oraz Microsoft Defender for Endpoint. Jądro WSL 2 zostało zaktualizowane do serii Linux 6.18 LTS z obsługą F2FS i ExFAT.

Ten przewodnik przeprowadzi Cię od pierwszej komendy wsl --install przez wybór dystrybucji, konfigurację Ubuntu, integrację z Docker i VS Code, aż po GPU CUDA dla ML — z pułapkami, w które najczęściej wpada się przy pierwszym kontakcie.

WSL 1 vs WSL 2 — architektura i kiedy co wybrać

Microsoft utrzymuje równolegle dwie generacje WSL, ale domyślną i zalecaną w 2026 jest WSL 2.

WSL 1 tłumaczy wywołania systemowe Linuksa na wywołania jądra NT w czasie rzeczywistym — bez prawdziwego jądra Linuksa. Zaletą jest błyskawiczny start i bezpośredni dostęp do plików Windows.

WSL 2 to pełnoprawne jądro Linuksa w lekkiej maszynie wirtualnej Hyper-V (utility VM). Microsoft buduje własne jądro linux-msft-wsl na bazie LTS (6.18). Kompatybilność z natywnym Linuksem jest praktycznie 100% — Docker, eBPF, FUSE, GPU passthrough.

Konwersja między wersjami

wsl -l -v                       # sprawdź obecne
wsl --set-version Ubuntu 2      # konwertuj
wsl --set-default-version 2     # WSL 2 jako domyślne

Konwersja jest jednorazowa, trwa 10-30 min przy dużej dystrybucji. Zrób wsl --export przed.

Wymagania systemowe

• Windows 11 (wszystkie edycje, w tym Home) — pełne wsparcie out of the box
• Windows 10 w wersji 2004 (build 19041) lub nowszej, x64 lub ARM64
• Windows Server 2022 lub nowszy
• Konto z uprawnieniami administratora (jednorazowo do instalacji)
• Procesor x86-64 lub ARM64 ze sprzętowym wsparciem wirtualizacji (Intel VT-x + EPT, AMD-V + RVI)
• Wirtualizacja włączona w BIOS/UEFI — najczęstsza pułapka. Opcja zwykle pod nazwą Intel VT-x, Intel Virtualization Technology, AMD-V, SVM Mode lub Virtualization Extensions
• Minimum 4 GB RAM (zalecane 8-16 GB), 10 GB wolnego dysku

Jak sprawdzić wirtualizację

Get-ComputerInfo -Property "HyperV*"

W Menedżerze zadań: Wydajność → CPU → Wirtualizacja: Włączone. Jeżeli wyłączona, wejdź do BIOS/UEFI (F2/F10/Del podczas startu), znajdź opcję w zakładce CPU, Advanced lub Security.

WSL automatycznie włączy funkcje: Virtual Machine Platform, Windows Subsystem for Linux, Hyper-V Hypervisor (sam komponent jądra). Wymagany restart komputera.

Nested virtualization

WSL 2 działa wewnątrz innych VM od 2020: VMware Workstation 16+, VirtualBox 6.1+, Hyper-V, Parallels. W chmurze: Azure Dv3/Ev3+ z EnableNestedVirtualization=true, AWS m5.metal/r5.metal, GCP n2-standard z enable-nested-virtualization. W laptopach z Device Guard mogą wystąpić konflikty — konsultacja z IT.

Instalacja WSL krok po kroku

W Windows 11 i nowoczesnym Windows 10 instalacja sprowadza się do jednej komendy.

Metoda 1 (zalecana) — wsl --install

Uruchom PowerShell jako Administrator:

wsl --install

Ta jedna komenda włącza Virtual Machine Platform, włącza WSL, pobiera jądro WSL 2, ustawia WSL 2 jako domyślne, instaluje Ubuntu i prosi o restart. Po restarcie Ubuntu uruchomi się automatycznie i poprosi o nazwę użytkownika UNIX oraz hasło — to konto Linuksa, niezależne od loginu Windows.

Konkretna dystrybucja

wsl --list --online              # pełna lista
wsl --install -d Debian
wsl --install -d kali-linux
wsl --install -d Ubuntu-24.04

Metoda 2 — Microsoft Store

Graficzna instalacja lub brak praw admina: Microsoft Store → wyszukaj „Windows Subsystem for Linux" → Pobierz. Następnie pobierz nazwę dystrybucji (np. „Ubuntu") osobno.

Metoda 3 (legacy) — Windows 10 przed build 19041

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Restart-Computer
# Pobierz wsl_update_x64.msi z aka.ms/wsl2kernel, zainstaluj
wsl --set-default-version 2
# Dystrybucja z Microsoft Store

Jeśli Windows 10 starszy niż 2004 — zaktualizuj go najpierw.

Weryfikacja

wsl --version
wsl -l -v
wsl --status
wsl --update

Po poprawnej instalacji wsl --version zwraca m.in.:

Wersja WSL: 2.5.10.0
Wersja jądra: 6.18.20.1
Wersja WSLg: 1.0.66

Jeśli wsl --update zwraca błąd sieci, sprawdź firewall korporacyjny — wymagany dostęp do *.aka.ms i wslstorebuild.blob.core.windows.net.

Wybór dystrybucji Linuksa

Co wybrać w 2026?

Dla 90% użytkowników: Ubuntu 24.04 LTS. Najwięcej poradników, najszybsze PPA, oficjalne wsparcie Canonical+Microsoft. Działa Docker, CUDA, systemd.

DevOps z ekosystemu Red Hat: AlmaLinux 9 lub Oracle Linux 9 — 100% kompatybilność binarna z RHEL.

Pentester: Kali Linux — wszystkie narzędzia (nmap, metasploit, burp) preinstalowane. Pamiętaj o ograniczeniach raw socket (brak NET_ADMIN w WSL).

Minimalista/embedded: Alpine — 5 MB rootfs, ale musl zamiast glibc bywa problemem przy precompiled binaries.

Niestandardowy rootfs

wsl --import AlmaLinux9 C:\WSL\AlmaLinux9 .\AlmaLinux-9-x86_64-latest.rootfs.tar.gz --version 2
wsl -d AlmaLinux9

Wiele dystrybucji równocześnie

wsl -d Ubuntu-24.04
wsl --set-default Debian
wsl --unregister Kali       # USUWA wszystkie dane bezpowrotnie!

Ostrzeżenie: zawsze wsl --export przed --unregister.

Pierwsza konfiguracja Ubuntu w WSL

Konto użytkownika

Po pierwszym uruchomieniu Ubuntu prosi o nazwę i hasło UNIX. Konto otrzymuje sudo automatycznie. Hasło to klucz do sudo — nie zapomnij go.

Aktualizacja

sudo apt update && sudo apt upgrade -y

systemd

Od 2022 WSL wspiera systemd, w nowych instalacjach jest już domyślnie włączony. Sprawdź: ps -p 1 -o comm= (powinno zwrócić systemd). Jeśli init, dodaj do /etc/wsl.conf:

[boot]
systemd=true

Następnie wsl --shutdown z PowerShell. Dzięki temu działają systemctl, snap, docker bez Docker Desktop, libvirt.

Lokalizacja polska

sudo timedatectl set-timezone Europe/Warsaw
sudo locale-gen pl_PL.UTF-8
sudo update-locale LANG=pl_PL.UTF-8 LC_ALL=pl_PL.UTF-8
exit

Narzędzia deweloperskie

sudo apt install -y build-essential git curl wget unzip htop jq vim \
  net-tools iputils-ping dnsutils ca-certificates gnupg lsb-release software-properties-common

Git

git config --global user.name "Jan Kowalski"
git config --global user.email "jan@example.com"
git config --global init.defaultBranch main

ssh-keygen -t ed25519 -C "jan@example.com"
cat ~/.ssh/id_ed25519.pub   # wklej w github.com → Settings → SSH keys

Node.js / Python

Node przez nvm:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts && nvm use --lts

Python:

sudo apt install -y python3-pip python3-venv
python3 -m venv ~/venv && source ~/venv/bin/activate

System gotowy — czas otworzyć w VS Code (sekcja dalej).

Współdzielenie plików Windows ↔ Linux

Z Linuksa do Windows

Wszystkie dyski Windows są zamontowane pod /mnt/:

ls /mnt/c/Users/jan/Documents/
explorer.exe .           # otwórz Eksplorator w bieżącym katalogu
code .                   # otwórz VS Code
notepad.exe plik.txt

Pułapka wydajnościowa: I/O na /mnt/c/ w WSL 2 jest przez Plan 9 over Hyper-V Socket — wolniejsze niż natywny ext4. Klonowanie repo z 5000 plików na /mnt/c/ zajmie 2-5 min, w ~/projekty/ — 10-20 sek.

Z Windows do Linuksa

\\wsl$\Ubuntu\home\jan\projekty\
\\wsl.localhost\Ubuntu\home\jan\projekty\   (nowsza składnia, Win 11)

Wpisz w Eksploratorze. Windows 11 ma też w lewym panelu sekcję Linux.

Reguła kciuka

/etc/wsl.conf — opcje montowania

[automount]
enabled = true
options = "metadata,umask=22,fmask=11"

[interop]
enabled = true
appendWindowsPath = true

metadata włącza chmod/chown na NTFS. appendWindowsPath dodaje PATH Windows do basha — możesz wywołać notepad.exe, code, git.exe. Jeśli powoduje konflikty (Python na Win i Lin), ustaw false.

Clipboard i interop

cat plik.txt | clip.exe                       # do schowka Windows
powershell.exe Get-Clipboard                  # ze schowka Windows
powershell.exe -c "Start-Process https://kluczesoft.pl"
powershell.exe Get-Process | head -20         # procesy Windows do head Linux

Ta interoperacyjność jest core'em WSL 2.

GPU acceleration — NVIDIA CUDA dla ML i AI

WSL 2 obsługuje GPU passthrough — karta NVIDIA (a od 2023 też AMD i Intel) jest widoczna w Linuksie z pełnym CUDA, cuDNN i sterownikami. Otwiera to drogę do trenowania modeli ML, inferencji LLM (Ollama, llama.cpp), renderingu Blender Cycles, kodowania NVENC.

Wymagania

• NVIDIA GPU Maxwell (2014) lub nowsza — praktycznie każda GTX 900 / RTX
• Windows 11 lub Windows 10 21H2+
• Sterownik NVIDIA Game Ready / Studio dla Windows 470.76+ (zalecane: najnowszy)
• WSL 2 z Ubuntu 22.04/24.04

Krok 1 — sterownik NVIDIA NA WINDOWS (nie w Linuksie!)

NIGDY nie instaluj sterownika NVIDIA Linux wewnątrz WSL 2. Sterownik Windows jest automatycznie stub-owany do WSL jako /usr/lib/wsl/lib/libcuda.so.1. Instalacja sterownika Linux nadpisze stub i CUDA przestanie działać.

Pobierz Game Ready Driver z nvidia.com i zainstaluj w Windows.

Krok 2 — weryfikacja

nvidia-smi

Output (RTX 4070):

NVIDIA-SMI 565.77.01    Driver Version: 566.36   CUDA Version: 12.7
NVIDIA GeForce RTX 4070

Driver Version = sterownik Windows, CUDA Version = maksymalna wspierana wersja CUDA Toolkit.

Krok 3 — CUDA Toolkit (TYLKO toolkit, nigdy cuda ani cuda-drivers)

wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

sudo apt install -y cuda-toolkit-12-6   # NIE `cuda`!

echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

nvcc --version

Krok 4 — test PyTorch i Ollama

pip install torch torchvision --index-url https://download.pytorch.org/whl/cu126
python3 -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"
# True / NVIDIA GeForce RTX 4070

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b   # automatycznie na GPU

AMD i Intel

• AMD ROCm od 2024 (Radeon RX 7000+, Ubuntu 22.04): rocm-hip-sdk z repo AMD
• Intel Arc / Iris Xe: intel-opencl-icd + oneAPI Base Toolkit, PyTorch z intel_extension_for_pytorch

Typowe problemy

• nvidia-smi: command not found → zainstalowałeś sterownik Linux. sudo apt purge nvidia-*
• CUDA driver version is insufficient → zaktualizuj sterownik Windows
• Failed to initialize NVML → wsl --shutdown i restart

WSLg — aplikacje graficzne Linuksa w Windows

WSLg (dodany 2021) pozwala uruchamiać graficzne aplikacje Linuksa bezpośrednio w Windows — bez X-Servera, VcXsrv, tuneli SSH X11. Działa od pierwszej instalacji WSL 2 na Windows 11 (i Win 10 21H2+).

Pod maską WSLg uruchamia mini-dystrybucję CBL-Mariner z Wayland compositor (Weston) i PulseAudio. Obraz jest streamowany przez MSRDC jako pojedyncze okna RDP — z akceleracją GPU i integracją z paskiem zadań Windows.

Test w 30 sekund

sudo apt install -y gedit
gedit &

Okno edytora otwiera się jak natywna aplikacja Windows.

Popularne aplikacje

Audio i GPU

PulseAudio działa automatycznie — głośniki i mikrofon Windows. Z włączonym CUDA passthrough aplikacje 3D używają GPU:

sudo apt install -y mesa-utils
glxinfo | grep "OpenGL renderer"
# OpenGL renderer string: D3D12 (NVIDIA GeForce RTX 4070)

Blender Cycles na GPU, FreeCAD z OpenGL, gry przez Steam Proton (różne rezultaty).

Ograniczenia

• Brak pełnego fullscreen (działa jako okno RDP)
• Akceleracja 3D ma 5-15% narzut vs natywny Linux
• Drag&drop plików między Windows a WSLg działa ograniczenie
• Wielomonitorowość bywa kapryśna

Wyłączenie

# /etc/wsl.conf
[wsl2]
guiApplications = false

Po wsl --shutdown WSLg jest wyłączone — przydatne na serwerach lub w politykach zabraniających RDP loopback.

Docker Desktop + WSL 2 — integracja kontenerów

Docker Desktop dla Windows używa WSL 2 jako backendu od 2020 — obecnie domyślna i jedyna zalecana konfiguracja (Hyper-V backend wycofany). Docker działa z natywną wydajnością Linuksa, a kontenery są dostępne i z Windows, i z każdej dystrybucji WSL.

Instalacja

1. Pobierz z docker.com/products/docker-desktop
2. Zaznacz Use WSL 2 instead of Hyper-V
3. Docker Desktop wystartuje i wykryje dystrybucje WSL

Integracja z dystrybucjami

Settings → Resources → WSL Integration:

• ✅ Enable integration with my default WSL distro
• ✅ Zaznacz konkretne dystrybucje (Ubuntu, Debian)

Weryfikacja

docker version
docker run hello-world
docker compose version

Dlaczego tak szybko?

Docker Desktop tworzy ukrytą dystrybucję docker-desktop (oraz docker-desktop-data na cache). W niej działa daemon. Twoja Ubuntu używa go przez /var/run/docker.sock montowany przez WSL Interop. Kontenery startują w <1 sek (vs 5-10 sek na Hyper-V).

Docker bez Docker Desktop (alternatywa pro)

Docker Desktop jest płatny w firmach >250 pracowników lub >10M USD przychodu. Alternatywy:

# Natywny Docker w WSL Ubuntu
sudo apt install -y docker.io docker-compose-v2
sudo usermod -aG docker $USER
sudo systemctl enable --now docker     # wymaga systemd
docker run hello-world

• Podman — bezdaemonowy, kompatybilny z Docker CLI, świetny dla CI
• Rancher Desktop — darmowy, containerd lub dockerd, integracja K8s

Pułapki

• Image storage rośnie szybko — %LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx do dziesiątek GB. wsl --shutdown + Optimize-VHD
• Port forwarding — przed Win 11 22H2 porty kontenerów nie były dostępne z LAN. Włącz networkingMode=mirrored
• Volume performance — wolumeny z /mnt/c/ są wolne. Używaj ~/docker-volumes/ lub named volumes

VS Code Remote WSL — flagship developer experience

VS Code Remote WSL sprawia, że edytor działa „dwustronnie": UI jako natywna aplikacja Windows, ale VS Code Server instaluje się w WSL i tam działa cała logika — IntelliSense, debugger, terminal, rozszerzenia, formatery. Pliki edytowane w natywnym ext4, Git lokalnie w Linuksie, Windows obsługuje tylko renderowanie. To rekomendowany przez Microsoft setup dla każdego dewelopera używającego Windows.

Instalacja

1. VS Code dla Windows z code.visualstudio.com
2. Rozszerzenie WSL (ms-vscode-remote.remote-wsl)
3. Restart VS Code

Otwarcie projektu

cd ~/projekty/moja-aplikacja
code .

Lub Ctrl+Shift+P → WSL: Connect to WSL in New Window. W lewym dolnym rogu — zielony znacznik WSL: Ubuntu.

Pod maską

Przy pierwszym uruchomieniu VS Code instaluje VS Code Server w ~/.vscode-server/ (~150 MB Node.js + binarki). Server komunikuje się z UI przez WebSocket.

Rozszerzenia mają flagę:

• Językowe (Python, Go, Rust, ESLint) → w WSL Server
• UI-only (motywy, ikony) → w Windows
• Niektóre (GitLens, Docker) → w obu

Korzyści

• IntelliSense na liniach Linuksa — pyright, tsc, gopls w WSL widzi prawdziwe pakiety
• Debugger Linux z Windows IDE jakby lokalny
• Terminal natywnie w WSL (Ctrl+`)
• Brak narzutu I/O /mnt/c/
• Git natywny w WSL, brak konfliktów line endings

Konfiguracja stacków

Python: sudo apt install python3-venv python3-pip, rozszerzenie Python (Microsoft), Python: Create Environment.

Node.js: po nvm install --lts → rozszerzenia ESLint + Prettier.

Go: sudo snap install go --classic, rozszerzenie Go (Google) — auto-instalacja gopls, dlv, gofumpt.

Rust: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh, rozszerzenie rust-analyzer.

JetBrains a WSL

JetBrains (IntelliJ, PyCharm, GoLand, WebStorm) wspiera WSL przez WSL toolchain od 2023: Settings → Build → Toolchain → Add → WSL.

Jeśli używasz WSL, VS Code Remote WSL nie jest opcją — jest standardem.

Tipy, skróty i backup

Najprzydatniejsze komendy wsl.exe

wsl                       # uruchom domyślną
wsl -d Ubuntu             # konkretną
wsl --shutdown            # zatrzymaj WSZYSTKIE (twardy reset)
wsl --terminate Ubuntu    # zatrzymaj jedną
wsl -l -v                 # lista + stan
wsl --status              # stan systemu
wsl --update              # aktualizacja jądra
wsl --set-default Debian  # zmień domyślną
wsl --unregister Kali     # USUŃ (bezpowrotnie!)
wsl --user root           # wejdź jako root
wsl -e <komenda>          # wykonaj bez interaktywnej sesji

Backup — wsl --export

wsl --shutdown
wsl --export Ubuntu D:\Backups\Ubuntu-2026-05-31.tar

# Przywrócenie pod inną nazwą
wsl --import Ubuntu-restored D:\WSL\Ubuntu-restored D:\Backups\Ubuntu-2026-05-31.tar --version 2

# Wszystkie naraz
foreach ($d in (wsl -l -q)) {
  wsl --export $d "D:\Backups\$d-$(Get-Date -Format yyyy-MM-dd).tar"
}

Backup raz w tygodniu (Zadanie Harmonogramu) + przed dużymi aktualizacjami. Tar Ubuntu z 5 GB pakietów = ~2 GB skompresowany.

Migracja na inny dysk

wsl --shutdown
wsl --export Ubuntu D:\temp\ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu D:\WSL\Ubuntu D:\temp\ubuntu.tar --version 2
ubuntu config --default-user jan   # domyślny user

.wslconfig (globalna, %USERPROFILE%\.wslconfig)

[wsl2]
memory=12GB
processors=8
swap=4GB
localhostForwarding=true
nestedVirtualization=true
networkingMode=mirrored
firewall=true

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

Po edycji: wsl --shutdown i restart.

Mirror Networking (Win 11 22H2+)

networkingMode=mirrored rozwiązuje 90% problemów sieciowych: WSL widzi te same interfejsy co Windows, aplikacje WSL nasłuchują na portach widocznych z LAN, VPN korporacyjny (Cisco AnyConnect, GlobalProtect) działa bez konfiguracji, IPv6 działa.

Kompresja VHDX

wsl --shutdown
$path = (Get-ChildItem "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu*\LocalState\ext4.vhdx").FullName
Optimize-VHD -Path $path -Mode Full   # wymaga Hyper-V tools

Aliasy w .bashrc

alias open='explorer.exe'
alias edit='code'
alias clip='clip.exe'
alias paste='powershell.exe Get-Clipboard'
alias ll='ls -lah'
alias dc='docker compose'

Najczęstsze problemy i rozwiązania

1. „Virtualization is not enabled"

BIOS/UEFI (F2/F10/Del podczas startu) → Intel VT-x / AMD-V / SVM Mode / Virtualization → Enabled. W laptopach firmowych może być zablokowane przez BitLocker / Device Guard — wymagana zgoda IT.

2. WSL zżera całą pamięć

Proces vmmem rośnie do 10+ GB i nie zwalnia (Linux cache'uje filesystem). Doraźnie: wsl --shutdown. Trwale w %USERPROFILE%\.wslconfig:

[wsl2]
memory=8GB
[experimental]
autoMemoryReclaim=gradual

W Linuksie: sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'.

3. Wolne operacje na plikach

npm install w /mnt/c/projekt/ trwa 10 min, w ~/projekt/ — 30 sek. Trzymaj projekty w natywnym ext4 (~/projekty/), edytuj przez VS Code Remote.

4. Problemy z DNS w sieciach korporacyjnych

# .wslconfig
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

Lub ręczny DNS:

# /etc/wsl.conf
[network]
generateResolvConf = false

# /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1

5. „localhost" nie działa Windows ↔ WSL

localhostForwarding=true (domyślnie) lub networkingMode=mirrored. Alternatywa: bind aplikacji na 0.0.0.0 zamiast 127.0.0.1 (HOST=0.0.0.0 npm start).

6. Windows Defender spowalnia WSL

Wyjątki (Privacy → Windows Security → Exclusions): foldery \\wsl$\ i %LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu*, procesy vmmem.exe, wsl.exe.

7. WSL nie startuje po aktualizacji Windows

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all
wsl --update --web-download
Restart-Computer

8. „Cannot connect to the Docker daemon"

Sprawdź czy Docker Desktop działa. Settings → Resources → WSL Integration — włącz dla dystrybucji. Restart: wsl --shutdown.

9. USB niedostępne (Arduino, czytnik kart, klucz U2F)

Zainstaluj usbipd-win w Windows (github.com/dorssel/usbipd-win):

usbipd list
usbipd bind --busid 4-2
usbipd attach --wsl --busid 4-2

W WSL: lsusb — urządzenie widoczne.

WSL vs dual-boot vs VirtualBox vs natywny Linux

Kiedy WSL 2

• Programowanie, DevOps, data science — równolegle z Office, Adobe, Teams, grami Windows
• Nauka Linuksa bez ryzyka uszkodzenia głównego systemu
• Praca w firmie wymuszającej Windows (Intune, BitLocker, Defender)
• GPU CUDA dla ML bez drugiego komputera
• Lokalny Docker / Kubernetes

Kiedy dual-boot

• Gaming Linux (Steam Proton, natywne tytuły)
• Kernel development, modyfikacja sterowników
• 100% wydajności dla HPC / renderingu
• Specjalistyczny sprzęt (RAW capture, urządzenia laboratoryjne)

Kiedy VirtualBox / VMware

• Test wielu dystrybucji równolegle w sandboxach
• Lab security/pentestingowy z mostami sieciowymi
• Snapshoty maszyn wirtualnych (rollback)
• Stare wersje OS (Windows XP, CentOS 6) niewspierane w WSL

Kiedy natywny Linux

• Linux jako podstawowy system na co dzień
• Bez Office, Photoshopa, gier Windows
• Sprzęt zaprojektowany pod Linuxa (System76, Framework, Tuxedo)

Hybrydowe podejście

W praktyce większość profesjonalistów łączy: Windows + WSL 2 jako codzienne środowisko (95% pracy) + opcjonalnie dual-boot lub dedykowany Linux dla zadań specjalnych. W 2026 WSL 2 zaspokaja 90-95% potrzeb deweloperów — to długofalowa strategia Microsoftu. Dla większości czytelników WSL 2 będzie najlepszym wyborem.