Виберіть дистрибутив WSL, який вас не дратуватиме (Ubuntu проти Debian та інші)

На що ви справді погоджуєтеся, коли «вибираєте дистрибутив»

На «чистому металі» вибір дистрибутива може здаватися ідеологічним. У WSL це радше вибір набору налаштувань, під якими вам доведеться жити, поки Windows непомітно тримає кермо.

Ви обираєте:

• Частоту релізів і радіус ураження оновлень. Як часто вам доведеться боротися з хвилями змін у тулчейні проти того, як швидко ви отримуєте виправлення безпеки та нові можливості компіляторів/рантаймів.
• Фрикцію екосистеми пакетів. Чи ваші щоденні інструменти (Python, Node, Go, Rust, OpenJDK, клієнти PostgreSQL, Azure/AWS CLI) — «першого класу», чи постійні винятки.
• Сумісність «працює на моїй машині» в команді. Якщо всі у вашій організації використовують Ubuntu, бути єдиним користувачем Fedora у WSL — означає писати власний графік on-call.
• Початкова безпека. Очікування AppArmor vs SELinux, як налаштований sudo, як обробляються SSH-ключі та як запускаються сервіси.
• Наскільки болісно це відлагоджувати. Кількість відповідей у внутрішніх вікі та в інтернеті має значення. Оригінальність о 2:00 ранку не дає балів.

Цитата про надійність, яку варто закарбувати на дошці спринту

Парафраз ідеї (John Ousterhout): «Складність — корінь більшості програмних проблем.»

WSL вже й так багатошаровий. Ваш вибір дистрибутива має зменшувати складність, а не додавати нову особистісну проблему.

Цікаві факти й історичний контекст (те, що формує сучасні налаштування)

1. WSL 1 (2016) не був віртуальною машиною. Він транслював виклики системи Linux у виклики Windows NT; добре для деяких інструментів, незручно для інших.
2. WSL 2 (2019) перейшов на справжнє ядро Linux у легкій ВМ. Саме тому Docker і реальні можливості ядра стали адекватними.
3. Ubuntu рано став дефолтним варіантом для WSL. Microsoft тісно співпрацювала з Canonical; інерція — потужний інструмент DevOps.
4. Підтримка systemd у WSL з’явилася значно пізніше, ніж бажали користувачі. Роки пролягали в імітації керування сервісами або ручному запуску демонів.
5. Розподіл файлових систем у WSL — фундаментальний. Файли зі сторони Linux (ext4 у ВМ) поводяться інакше, ніж файли Windows під /mnt/c.
6. Гілка stable у Debian прагне передбачуваності замість новизни. Ця ідеологія добре підходить для корпоративної відтворюваності.
7. Fedora часто першою отримує нові Linux-технології. Вона рано отримує нові інструменти — добре для експериментів, гостро для контролю змін.
8. musl libc в Alpine — реальний кордон сумісності. Вона маленька й швидка, але не все в середовищах розробки очікує musl.
9. Kali призначений для робочих процесів тестування безпеки. Використовувати його як щоденну робочу ОС — як принести бензопилу, щоб порізати хліб: можливо, але всім буде некомфортно.

Реалії WSL, що змінюють арифметику вибору

Перш ніж порівнювати Ubuntu і Debian, зрозумійте основні правила. WSL — це не «Linux у Windows» стільки, скільки «Linux поруч із Windows, що має кілька спільних органів». Саме ці спільні органи найчастіше створюють подразники.

Проблема двох файлових систем (і чому вона домінує в продуктивності)

У WSL2 ваша коренева файлову система Linux зберігається на віртуальному диску ext4 (VHDX). Цей шлях швидкий для викликів Linux. Файли Windows, змонтовані під /mnt/c, зручні, але перетин цього кордону коштує вам часу. Дуже багато.

Якщо ви виконуєте багато ввід/вивід (git status у величезних репозиторіях, встановлення node_modules, створення Python virtualenv) на /mnt/c, ви покличете вину на дистрибутив. Неправильний підозрюваний. Вузьке місце — кордон файлової системи.

Мережа — не «просто Linux-мережа»

WSL2 використовує віртуалізований мережевий стек. Зазвичай усе працює. Коли ні — симптоми виглядають як «DNS у Linux не працює» або «мій проксі мене не любить». Виправлення часто включають налаштування на стороні Windows і перезапуск WSL, а не зміну дистрибутива.

Ядро керується Microsoft (переважно)

На відміну від традиційної інсталяції дистрибутива, оновлення ядра пов’язане з WSL і оновленнями Windows, а не пакетами ядра вашого дистрибутива. Це зменшує одну вісь відмінностей, але підвищує значущість сумісності userland і інструментів.

WSLg і графічні додатки — окрема вісь

Запуск графічних Linux-додатків (WSLg) працює в різних дистрибутивах, але досвід «з коробки» різниться: пакети, шрифти, GPU-бібліотеки і залежності desktop-класу можуть бути плавнішими в Ubuntu, ніж у мінімалістичних дистрибутивах.

Короткий жарт №1: Вибирати дистрибутив для WSL за естетикою шпалер — сміливо. Це як обирати базу даних через милу емблему.

Швидкі рекомендації (суб’єктивно): що встановити для типових завдань

Якщо хочете найменше драм: Ubuntu LTS

Оберіть Ubuntu LTS, якщо хочете максимум сумісності з підручниками, корпоративними образами, репозиторіями сторонніх постачальників і колегами. Це дефолт не тому, що це модно, а тому що працює.

Вибирайте: Ubuntu 22.04 LTS або Ubuntu 24.04 LTS (залежно від того, що підтримує ваша організація).

Якщо хочете мінімалізм і передбачуваність: Debian stable

Оберіть Debian stable, якщо бажаєте менше «сюрпризів» і вам не потрібні найновіші компілятори за замовчуванням. Він рухається повільніше, що є перевагою, коли потрібно тримати в один лад dev і CI.

Якщо ви живете в контейнерах і потребуєте свіжих інструментів: Fedora (обережно)

Fedora чудова, якщо ви тестуєте сучасні тулчейни, можливості, близькі до ядра, або вам потрібні новіші версії мов. Але оновлення Fedora не соромляться. Якщо ви ненавидите хвилі змін — Fedora вас знайде.

Якщо думаєте, що Alpine буде «маленьким і швидким»: передумайте

Мінімалізм Alpine реальний, але середовища на musl можуть створювати проблеми сумісності в робочих процесах розробки. Alpine блискуче всередині контейнерів. Як основний WSL-дистрибутив це часто податок, на який ви не заклали часу.

Якщо ви займаєтесь навчанням з безпеки: Kali (тільки для цієї мети)

Kali не «кращий Linux» загалом. Це набір інструментів. Використовуйте його як окремий дистрибутив, який ви піднімаєте при потребі, а не як щоденний робочий інструмент.

Ubuntu у WSL: стандарт не дарма

Ubuntu у WSL — це шлях найменшого опору, а в інженерії виробництва це комплімент. Більшість інструкцій від постачальників припускають Ubuntu. Багато внутрішніх ранбуків теж. Якщо вам знадобиться допомога колеги, «я на Ubuntu» знижує когнітивне навантаження.

Що Ubuntu робить правильно у WSL

• Каденс LTS підходить для корпоративного життя. Ви можете залишатися стабільними роками, отримуючи лише оновлення безпеки.
• Доступність тулчейнів. PPA, репозиторії постачальників та пакети зазвичай існують і тестуються.
• Краща ергономіка за замовчуванням. Розумні базові пакети, передбачувана поведінка та багато «цей підручник просто працює».
• Mindshare у WSL. Якщо є специфічний для WSL обхідний шлях, хтось ймовірно написав його для Ubuntu першим.

Що в Ubuntu дратує деяких людей

• Snap. На класичних Linux-машинах Snap — предмет релігійних дискусій. У WSL це більше практичне питання: чи потрібні вам snap-збірки, і чи добре snapd працює під WSL + systemd? Іноді так, іноді це створює фрикції.
• Більше «штух» за замовчуванням. Якщо ви хочете компактне середовище, Ubuntu може здаватися важкою у порівнянні з мінімальною інсталяцією Debian.
• Не-LTS релізи більш мінливі. Якщо ви обираєте не-LTS реліз заради «новіших пакетів», очікуйте частіших оновлень і іноді регресій.

Коли я рекомендую Ubuntu без дискусій

Команди. Спільні dev-середовища. Корпоративні ноутбуки. Паритет CI з Ubuntu-runner’ами. Новачки. Люди, які хочуть працювати, а не курувати середовище.

Debian у WSL: нудний, компактний і зазвичай правильний

Debian stable — це друг, який приходить вчасно, не розповідає про криптовалюти й залишає кухню чистішою, ніж знайшов. Для WSL це сильний аргумент.

Що Debian робить правильно у WSL

• Передбачувані оновлення. Stable — це стабільність. Ви отримуєте виправлення безпеки, але база не змінюється під вами.
• Мінімалізм без дивакуватості. Можна зберегти компактне середовище і залишатися сумісним з більшістю Linux-очікувань.
• Відмінна пакувальна дисципліна. Норми пакування Debian зменшують «таємничу поведінку».

Реальні компроміси Debian

• Старіші версії за замовчуванням. Це може означати старіший Python, Node, GCC/Clang, OpenSSL тощо. Можна використовувати backports або інсталятори мов, але тоді доводиться робити додаткову роботу.
• Деякі скрипти постачальників припускають Ubuntu. Вони можуть перевіряти lsb_release і відмовлятися виконуватись або посилатися на Ubuntu-специфічні пакети.

Коли Debian — найкращий вибір

Коли вам важлива відтворюваність, коли ви підтримуєте довготривалі внутрішні інструменти, коли хочете менше сюрпризів і готові встановлювати новіші рантайми мов явно.

Інші (Fedora, openSUSE, Alpine, Kali): коли вони хороші, а коли — пастка

Fedora: сучасна, швидкорухома, іноді занадто відверта

Fedora чудова, якщо ви хочете актуальні компілятори, новіші рантайми мов і культуру дистрибутива, що швидко впроваджує нові технології. У WSL це може підвищити продуктивність — поки не настане велике оновлення й ваше оточення не почне грати у краш-тесті залежностей.

Fedora у WSL підходить для досвідчених користувачів, які ставляться до своїх dev-середовищ як до стада, а не домашнього улюбленця: експортуйте, знищуйте, імпортуйте й рухайтеся далі.

openSUSE (Leap vs Tumbleweed): недооцінений варіант

openSUSE зазвичай надійна, особливо якщо у вашій організації працює SUSE у продакшені. Leap — стабільна лінія; Tumbleweed — роллінг. У WSL роллінг може бути веселим до того моменту, як це стане вашим завданням.

Alpine: чудова у контейнерах, не завжди — як робоча станція

Musl libc і користувацький простір на основі busybox роблять Alpine відмінним для мінімальних образів контейнерів. Для WSL як загального дистрибутива розробки ви натрапите на крайові випадки: попередньо зібрані бінарні файли, які очікують glibc, скрипти збірки, що розраховують на GNU coreutils, і колеги, які не зможуть відтворити ваше середовище, якщо вони не «п’ють Alpine Kool‑Aid».

Kali: набір спеціалізованих інструментів, а не спосіб життя

Kali чудовий для своєї призначеної задачі. Встановіть його як додатковий дистрибутив WSL для роботи з безпекою. Тримайте щоденну розробку на Ubuntu або Debian.

Короткий жарт №2: Виконувати роллінг-реліз на робочому ноутбуці — захопливо. Як і жонглювати ножами — обидва краще як хобі, ніж як робочі вимоги.

Systemd і сервіси: розділ «чи треба мені це?»

Сучасні дистрибутиви Linux припускають systemd. Багато робочих процесів розробки залежать від сервісів: демона Docker (якщо ви використовуєте Docker-in-WSL), PostgreSQL, Redis, ssh-agent, завдання на кшталт cron. Історично WSL робив це незручно. Нині systemd можна ввімкнути, але рішення має бути свідомим.

Увімкніть systemd, якщо:

• Вам потрібно, щоб сервіси надійно стартували при запуску WSL.
• Ви використовуєте юніти сервісів, таймери або journalctl для налагодження.
• Потрібен паритет із Linux-серверами, де systemd — норма.

Пропустіть systemd, якщо:

• Ваш WSL-дистрибутив головно для CLI-інструментів і збірок.
• Ви запускаєте сервіси в контейнерах (інтеграція Docker Desktop) або на віддалених хостах.
• Хочете мінімальну поверхню для тикетів «чому мій WSL запускається повільно?».

Продуктивність файлової системи: де WSL насправді кусає

Скажу прямо: більшість скарг на «продуктивність дистрибутива WSL» — це помилки у розташуванні сховища.

Золоте правило

Тримайте код, який ви збираєте й тестуєте, всередині файлової системи Linux (де-небудь під домашньою директорією WSL), а не на /mnt/c. Використовуйте монтування Windows для обміну файлами, легкого редагування й зручності, а не для інтенсивних операцій.

Чому це важливо (практично)

• Операції Git торкаються безлічі дрібних файлів. Перетин кордону файлових систем уповільнює це.
• Node/npm/pnpm створюють і сканують величезні дерева директорій.
• Python virtualenv/pip навантажують дрібний ввід/вивід.
• Языкові сервери індексують усе; вони підсилювачі латентності сховища.

Куди що класти

• Кладіть репозиторії сюди: ~/src всередині WSL.
• Кладіть кеші сюди: стандартні Linux-кеш-директрії підходять; не перенаправляйте їх у Windows.
• Ділися з Windows через: \\wsl$ з Windows Explorer (добре для редагування Windows-інструментами).

Практичні завдання: команди, що відповідають на реальні питання

Ось перевірки, які я справді запускаю, коли хтось каже «WSL повільний» або «цей дистрибутив дивний». Кожне завдання включає: команду, що означає вивід, і яке рішення прийняти.

Завдання 1: Підтвердити версію WSL (1 vs 2) і список дистрибутивів

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-24.04    Running         2
  Debian          Stopped         2

Значення: VERSION 2 означає справжню Linux-VM. VERSION 1 — трансляція викликів syscall (інша продуктивність і сумісність).

Рішення: Якщо у вас WSL1 і ви використовуєте Docker, сучасні файлові системи або очікуєте можливості ядра — мігруйте на WSL2. Якщо ваша головна проблема — продуктивність /mnt/c, WSL2 зазвичай допомагає, але вам усе одно треба правильно розташувати файли.

Завдання 2: Перевірити реліз дистрибутива і вікно підтримки

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04 LTS (Noble Numbat)"
ID=ubuntu

Значення: Ви на конкретному релізі; LTS означає довшу підтримку і менше руйнівних змін.

Рішення: Для корпоративної/командної узгодженості віддавайте перевагу LTS (Ubuntu) або stable (Debian). Якщо ви на релізі, що вийшов з підтримки — плануйте експорт/імпорт при оновленні, а не «просто патчити».

Завдання 3: Перевірити, чи systemd увімкнено (і чи все в порядку)

cr0x@server:~$ ps -p 1 -o comm=
systemd

Значення: PID 1 — systemd. Якщо команда виводить щось інше (або помилку), systemd не є вашим init.

Рішення: Якщо ви спираєтесь на сервіси, увімкніть systemd. Якщо ні — вимкніть його, щоб зменшити кількість рухомих частин, особливо на старих корпоративних збірках, де оновлення WSL запізнюються.

Завдання 4: Перевірити, чи працюєте ви на сховищі, змонтованому з Windows

cr0x@server:~$ pwd
/mnt/c/Users/cr0x/source/big-repo

Значення: Ви в файловій системі Windows.

Рішення: Якщо це репозиторій для збірки/тестування — перемістіть його в ~/src і відкривайте з Windows через \\wsl$. Очікуйте великого приросту продуктивності для нод/пайтон/git-важких робочих процесів.

Завдання 5: Виміряти біль від кордону файлових систем простим тестом створення файлів

cr0x@server:~$ cd ~ && mkdir -p /tmp/io-test && cd /tmp/io-test
cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do echo x > f.$i; done'
real    0m1.8s
user    0m0.5s
sys     0m1.2s

Значення: Це на файловій системі Linux (відносно швидко). Повторіть під /mnt/c і порівняйте.

Рішення: Якщо той самий тест істотно повільніший на /mnt/c, припиніть звинувачувати Ubuntu vs Debian. Виправте розміщення файлів, а потім повертайтеся до питання дистрибутива.

Завдання 6: Перевірити використання диска всередині VHDX світу WSL

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb       100G   41G   55G  43% /

Значення: Ваша Linux-файлова система має вільне місце (або ні).

Рішення: Якщо ви вище ~85% використання, очікуйте дивної поведінки: невдалі інсталяції пакетів, провали збірок, деградацію продуктивності. Очистіть кеші, утилізуйте контейнери або розширте/перемістіть дистрибутив.

Завдання 7: Швидко знайти найбільші споживачі простору

cr0x@server:~$ sudo du -xhd1 /home/cr0x | sort -h
2.1G    /home/cr0x/.cache
6.8G    /home/cr0x/.local
14G     /home/cr0x/src
23G     /home/cr0x

Значення: -x лишається в одній файловій системі; ви бачите реальні витрати місця всередині дистрибутива.

Рішення: Якщо кеші величезні — почистіть їх (pip/npm). Якщо репозиторії великі — розгляньте shallow clone для гігантських vendor-репозиторіїв або sparse checkout.

Завдання 8: Перевірити тиск пам’яті та поведінку swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.1Gi       0.6Gi       0.2Gi       1.0Gi       1.1Gi
Swap:          2.0Gi       1.4Gi       0.6Gi

Значення: У вас відбувається свопінг. Це може зробити «WSL повільний» дуже відчутним.

Рішення: Зменшіть паралельні збірки, збільшіть ліміти пам’яті WSL або перестаньте запускати важкі сервіси локально. Вибір дистрибутива не вирішить нестачі пам’яті.

Завдання 9: Підтвердити поведінку DNS всередині WSL (типовий корпоративний збій)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Значення: DNS-сервери встановлені; якщо вони невірні або відсутні, розв’язання імен буде ненадійним.

Рішення: Якщо DNS вказує на недосяжні сервери або captive VPN-інтерфейс, виправте політику split-tunnel VPN/Windows DNS або обережно перевизначте генерацію resolv.conf у WSL.

Завдання 10: Перевірити проксі-середовище (бо підприємства їх люблять)

cr0x@server:~$ env | grep -i proxy
HTTP_PROXY=http://proxy.corp:8080
HTTPS_PROXY=http://proxy.corp:8080
NO_PROXY=localhost,127.0.0.1,.corp

Значення: У вашому шеллі налаштовані змінні проксі. Інструменти як apt, curl, npm можуть або не можуть їх коректно поважати.

Рішення: Якщо завантаження не вдаються, стандартизуйте конфіг проксі на одному шарі (шелл + apt config + git config) і тримайте NO_PROXY осмисленим для внутрішніх сервісів.

Завдання 11: Перевірити стан менеджера пакетів і блокування

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 1s (135 kB/s)
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Значення: apt працює і репозиторії доступні.

Рішення: Якщо бачите помилки блокування — фоновий apt-процес працює (або завис). Виправте це перед тим, як «діагностувати WSL». Якщо репозиторії заблоковані — у вас проблеми з проксі/DNS/сертифікатами, а не з дистрибутивом.

Завдання 12: Перевірити glibc vs musl (сигнал сумісності Alpine)

cr0x@server:~$ ldd --version
ldd (Ubuntu GLIBC 2.39-0ubuntu8) 2.39
Copyright (C) 2024 Free Software Foundation, Inc.

Значення: Ви на glibc. На Alpine це було б musl, і деякі бінарні файли не працюватимуть.

Рішення: Якщо ваш робочий процес вимагає бінарів постачальника (cloud CLI, пропрієтарні агенти, деякі тулчейни мов), обирайте дистрибутиви на glibc (Ubuntu/Debian/Fedora/openSUSE).

Завдання 13: Підтвердити, де ваш git і чи не зламає вас кінцівка рядка

cr0x@server:~$ git config --global --get core.autocrlf
input

Значення: У вас налаштовано перетворення CRLF при коміті лише вхідних файлів — це безпечна настройка при змішаному використанні Windows і Linux-інструментів.

Рішення: Якщо бачите дивні diff-и або скрипти з помилками /bin/bash^M, виправте autocrlf і застосуйте .gitattributes. Це не вина Ubuntu.

Завдання 14: Перевірити стратегію Docker (інтеграція Desktop vs Docker-in-WSL)

cr0x@server:~$ docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT               ERROR
default             Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux *     Docker Desktop                            unix:///home/cr0x/.docker/desktop/docker.sock

Значення: У вас є контексти; desktop-linux вказує на інтеграцію Docker Desktop.

Рішення: Для більшості розробників інтеграція Docker Desktop зменшує клопоти з демоном. Якщо вам потрібен повний контроль Linux або ви на обмежених машинах — Docker-in-WSL може працювати, але готуйтеся до більшої керованості сервісами.

Завдання 15: Експортуйте дистрибутив перед тим, як «просто оновити»

cr0x@server:~$ wsl.exe --export Ubuntu-24.04 C:\Users\cr0x\backup\ubuntu24.tar
Export in progress, this may take a few minutes.
The operation completed successfully.

Значення: У вас є портований бекап, який можна повторно імпортувати.

Рішення: Завжди експортуйте перед масштабними змінами. Це різниця між «упс» і «відновлення за 5 хвилин».

Швидкий план діагностики (перший/другий/третій)

Коли WSL здається повільним або зламаним, потрібен порядок триажу. Ось той, що швидко знаходить вузьке місце, не перетворюючи ваш ноутбук на наукову виставку.

Перший: ідентифікуйте клас проблеми (I/O, CPU, пам’ять, мережа)

• Підозра на I/O: повільні git-команди, повільні інсталяції, індексація мовних серверів, багато дрібних файлів. Перевірте, чи ви під /mnt/c.
• Підозра на CPU: повільна компіляція при нормальному диску. Перевірте навантаження і ліміти CPU.
• Підозра на пам’ять: усе періодично повільно, шум вентилятора, свопінг. Перевірте free -h.
• Підозра на мережу: apt/npm/curl падає, таймаути DNS, помилки проксі. Перевірте DNS і змінні проксі.

Другий: підтвердіть, що підкладка WSL здорова

• Переконайтеся, що це WSL2, а не WSL1.
• Перевірте використання диска (df -h) і найбільших споживачів (du).
• Якщо щось «мерехтить», перезапустіть WSL із Windows: wsl.exe --shutdown і відкрийте заново.

Третій: лише потім дискутуйте про вибір дистрибутива

Якщо біль продуктивності спричинений кордоном файлової системи, тиском пам’яті або політикою Windows VPN/проксі, перемикання з Ubuntu на Debian вас не врятує. Воно лише змінить форму того самого вогню.

Міняйте дистрибутив, коли:

• Потрібні старіші/більш стабільні пакети (Debian stable) для відповідності продакшену.
• Потрібна краща підтримка постачальників і відповідність підручникам (Ubuntu LTS).
• Потрібен найсвіжіший userland (Fedora/openSUSE Tumbleweed) і ви приймаєте хвилі змін.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Git жахливо повільний у WSL»

Симптоми: git status триває секунди; npm install займає вічність; CPU здебільшого простий.

Корінь: Репозиторій на /mnt/c (монтування файлової системи Windows).

Виправлення: Перемістіть репо в ~/src всередині WSL. Доступайтеся до нього з Windows через \\wsl$. Повторно перевірте.

2) «apt update випадково падає на роботі»

Симптоми: Таймаути, TLS-помилки, «Temporary failure resolving», тільки в VPN або тільки поза VPN.

Корінь: Поведінка корпоративного проксі/DNS; автоматична генерація DNS у WSL конфліктує з VPN-адаптерами.

Виправлення: Стандартизувати змінні проксі; перевірити DNS всередині WSL; якщо потрібно — відключити автоматичне генерування resolv.conf і керувати ним свідомо (за внутрішнім ранбуком, а не на основі інтуїції).

3) «Сервіс не запускається / systemctl не працює»

Симптоми: помилки systemctl, демони вмирають після закриття терміналу.

Корінь: systemd не увімкнено або ви очікуєте фонові сервіси без init-системи.

Виправлення: Увімкніть systemd, якщо це необхідно; інакше запускайте сервіси через Docker Desktop або явні скрипти.

4) «Docker builds повільні й дивні»

Симптоми: Збірки займають години; виявлення змін у файлах ненадійне; томи поводяться дивно.

Корінь: Змішування файлової системи Windows, файлової системи WSL і Docker-контекстів; бінд-монтування через кордон повільне.

Виправлення: Тримайте build context всередині файлової системи WSL; оберіть одну стратегію Docker і дотримуйтеся її (інтеграція Desktop зазвичай найпростіша).

5) «Після оновлення Python/Node зламалися»

Симптоми: Невідповідність тулчейну, відсутні бібліотеки, помилки pip wheels, drama з node-gyp.

Корінь: Оновлення не-LTS дистрибутива або змішування системних пакетів з менеджерами версій мов неправильно.

Виправлення: Фіксуйте версії і використовуйте менеджер версій (pyenv/nvm/asdf) послідовно, або залишайтеся на Ubuntu LTS/Debian stable і оновлюйте цілеспрямовано з бекапом експорту.

6) «WSL пожирає мій диск»

Симптоми: Диск Windows заповнюється; WSL показує помірне використання; дані не сходяться.

Корінь: VHDX росте і не завжди стискається автоматично; накопичуються кеші й шари контейнерів.

Виправлення: Очищайте кеші й контейнери; експортуйте/імпортуйте для компактності при потребі; уникайте збереження гігантських артефактів у WSL, якщо політика зберігання на стороні Windows жорстка.

Контрольні списки / покроковий план

Контрольний список A: Оберіть дистрибутив за 10 хвилин

1. Приєднуєтеся до існуючої команди? Використайте те, що використовують вони, якщо немає вагомої причини інакше. Зазвичай Ubuntu LTS.
2. Потрібна максимальна сумісність з підручниками/постачальниками? Ubuntu LTS.
3. Потрібна «не змінюйте мою базу» стабільність? Debian stable.
4. Потрібен найновіший userland і ви приймаєте хвилі змін? Fedora або openSUSE Tumbleweed.
5. Потрібен набір інструментів для тестування безпеки? Kali як додатковий дистрибутив, не як основний.
6. Думаєте взяти Alpine? Кладіть Alpine у контейнер. Використовуйте Ubuntu/Debian як хост-дистрибутив, якщо вам не подобається дебаг libc-проблем.

Контрольний список B: Налаштуйте WSL так, щоб він залишався швидким

1. Встановіть WSL2 і перевірте за допомогою wsl.exe -l -v.
2. Створіть ~/src і клонуйте репозиторії туди.
3. Доступайтеся до файлів з Windows через \\wsl$ замість роботи під /mnt/c.
4. Вирішіть питання systemd: вмикайте тільки якщо потрібні сервіси.
5. Виберіть одну підхід до Docker і стандартизуйте його (зазвичай інтеграція Docker Desktop).
6. Експортуйте дистрибутив перед масштабними оновленнями.

Контрольний список C: Оновлюйте без драм

1. Експорт: wsl.exe --export <Distro> C:\path\backup.tar.
2. Документуйте необхідні пакети: компілятори, рантайми мов, ключові CLI.
3. Якщо середовище крихке, розгляньте відновлення з нуля і відновлення лише dotfiles та SSH-ключів.
4. Імпортуйте під новою назвою, якщо хочете чистий шлях відкату.

Три корпоративні міні-історії з практики

Міні-історія №1: Інцидент через хибне припущення (редакція про кордон файлової системи)

Одна продуктова команда мала WSL-базоване dev-середовище і великий монорепозиторій. Новим розробникам неформально казали «просто клонувати репо у ваш домашній каталог Windows і використовувати WSL для збірок». Звучало логічно: інструменти Windows бачать файли, Linux-інструменти можуть їх збирати. Здавалося, що зручність виграє, правда?

За місяць команда почала бачити періодичні провали тестів і «випадкові» таймаути. CI був у порядку. Тільки ноутбуки плавилися. Головний симптом — повільне сканування файлів: збірка і мовні сервери повільно обходили директорії, розробники вбивали процеси, інкрементальні збірки починали плутатися, що змінилося.

Хтось нарешті профілював це по-непоказному: виміряли час створення файлів і git status у двох місцях. Файлова система Linux: достатньо швидко. /mnt/c: болісно повільно і нестабільно. «Випадкові» таймаути не були випадковими. Це була збірка, що чекала на файлові операції, які перетинали кордон Windows/Linux тисячі разів на хвилину.

Виправлення було нудне, але миттєве: перемістити репо в ~/src всередині WSL, документувати «не збирати на /mnt/c» і навчити користувачів Windows відкривати репо через \\wsl$. Інцидент закінчився не патчем у збірці, а виправленим припущенням про те, де фізично знаходяться файли.

Міні-історія №2: Оптимізація, що дала відбій (самовпевненість роллінг-релізу)

Підгрупа інфраструктури захотіла «новіше все» на машинах розробників, щоб зменшити тертя з сучасними тулчейнами. Вони стандартизувалися на швидкорухомому дистрибутиві для WSL, бо він давав нові компілятори та бібліотеки без додаткових репозиторіїв. Певний час все було чудово: швидші збірки, менше ручних інсталяцій, щасливі інженери.

Потім почалась хвиля оновлень. Кілька ключових пакетів змінили поведінку — нічого катастрофічного, але достатньо, щоб зламати пару внутрішніх скриптів, що припускали старі налаштування. Одночасно один CLI від постачальника, що використовувався половиною компанії, випустив бінарник, який не любив нову версію однієї бібліотеки. Режим фейлу був потворний: «працює на моїй машині» перетворився у «працювало вчора».

Навантаження на підтримку зросло. Не тому, що дистрибутив «поганий», а тому, що організація не мала дисципліни для частих оновлень. Люди фіксували пакети як попало. Хтось перестав оновлювати зовсім. Флот набув трьох станів: оновлений, частково оновлений і скам’янілий.

Відновлення полягало в розділенні на два рівні: стабільний дефолт (Ubuntu LTS) і «просунутий/експериментальний» варіант (роллінг). Також додали політику: великі оновлення відбуваються свідомо, з попереднім експортом. Урок не в тому, щоб ніколи не використовувати сучасні дистрибутиви, а в тому, що «сучасність за замовчуванням» — це операційне зобов’язання, а не настрій.

Міні-історія №3: Нудна, але правильна практика, що врятувала день (дисципліна експорт/імпорт)

Одна команда, близька до фінансів, накопичила за роки WSL-дистрибутив з купою тулів: Python-енви, локальні бази даних для інтеграційних тестів, кастомні бінарі — усе, що завгодно. Ноут одного інженера почав дивно поводитись після оновлення Windows: WSL запускалося, а потім зависало. Перезавантаження не допомогло. Миттєвий страх — втрата даних і багатоденний ребілд.

Але команда мала непоказну звичку: перед великими змінами вони експортували WSL-дистрибутиви в стандартне місце. Не щодня, не ідеально, але досить регулярно, щоб це мало значення. Інженер мав експорт з попереднього тижня.

План відновлення був простий: wsl.exe --shutdown, видалити проблемну реєстрацію дистрибутива і імпортувати з tarball під новою назвою. Вони швидко повернулись у робочий стан і змогли спокійно діффити старе й нове середовища.

Ця «нудна практика» не лише зекономила час; вона зберегла якість прийняття рішень. Без неї люди роблять відчайдушні зміни і створюють ще більший хаос. З відомим шляхом відкату команда може спокійно шукати корінь проблеми.

Питання та відповіді

1) Чи обирати Ubuntu чи Debian для WSL, якщо я новачок у Linux?

Ubuntu LTS. Ви отримаєте більше «працює просто», більше підручників, що відповідають вашій системі, і менше сюрпризів з пакетами.

2) Чи Debian «більш стабільний», ніж Ubuntu LTS?

За швидкістю змін базових пакетів Debian stable зазвичай більш консервативний. Ubuntu LTS теж стабільний, але з іншими дефолтами і іноді новішими стеком через backports/HWE. Для більшості користувачів WSL обидва підходять; обирайте за сумісністю екосистеми.

3) Чи вибір дистрибутива усуне повільність на WSL?

Іноді, але рідко. Найбільший важіль — розміщення робочого навантаження у файловій системі Linux, а не на /mnt/c. Далі — тиск пам’яті, ліміти CPU і стратегія Docker.

4) Чи слід увімкнути systemd у WSL?

Увімкніть його, якщо вам потрібна поведінка сервісів як на серверах Linux: systemctl, таймери, journald-логи. Якщо потрібні тільки шелли і компілятори — пропустіть і тримайте середовище простішим.

5) Чи можна запускати Docker у WSL без Docker Desktop?

Так, але ви будете керувати демоном і його сховищем, а також життєвим циклом сервісів. Більшість розробників повинні використовувати інтеграцію Docker Desktop, якщо політика не забороняє.

6) А openSUSE або Fedora, якщо у мене в продакшені вони?

Це виправдана причина узгодження з продакшеном. Просто будьте чесні щодо частоти оновлень: Fedora рухається швидше; openSUSE має і стабільні, і роллінг-опції.

7) Чи Alpine підходить як WSL-дистрибутив для розробки?

Alpine чудовий для контейнерів. Для загальної розробки у WSL проблеми сумісності musl і відмінності userland можуть коштувати часу. Використовуйте його, коли вам потрібна саме сумісність з Alpine.

8) Як тримати кілька WSL-дистрибутивів без хаосу?

Називайте їх за призначенням (наприклад, Ubuntu-Work, Debian-CI-Parity, Kali-Lab). Тримайте свій «дефолт» нудним. Експортуйте перед оновленнями. Не діліться тими самими репозиторіями між дистрибутивами через /mnt/c, якщо важлива продуктивність.

9) Чи можна безпечно отримати доступ до файлів WSL з Windows?

Так — використовуйте \\wsl$ з Windows. Уникайте прямого доступу до підкладкових VHDX або файлової системи дистрибутива з Windows шляхів, не призначених для цього.

10) Якщо я вже помилився з вибором, наскільки болісно перемкнутися?

Не так болісно, якщо ви ставитесь до дистрибутива як до замінного. Експортуйте за потреби, перевстановіть інший дистрибутив і відновіть через скрипти. Біль приходить від снігових середовищ; виправте це один раз — і майбутній ви перестане посилати вам сердиті листи.

Висновок: практичні наступні кроки

Якщо ви хочете WSL-дистрибутив, який не дратуватиме, оптимізуйте під передбачуваність і спільну реальність, а не під особистий смак.

1. Вибір за замовчуванням: встановіть Ubuntu LTS, якщо немає конкретної причини не робити цього.
2. Пріоритет стабільності: використовуйте Debian stable, коли хочете мінімум хвиль змін і чисті дефолти.
3. Підвищення продуктивності: тримайте репозиторії у файловій системі Linux; припиніть збирати на /mnt/c.
4. Операційна гігієна: експортуйте дистрибутив перед оновленнями і тримайте скрипт відновлення для базових тулів.
5. Тріаж як у SRE: перевіряйте місце розташування файлів, тиск пам’яті і мережу/проксі перед тим, як звинувачувати дистрибутив.

Оберіть нудний варіант, налаштуйте його правильно і витрачайте час на доставку фіч, а не на вивчення нових і захопливих способів, якими менеджер пакетів може вас підвести.