Мой рабочий ноутбук выдала компания: Windows, корпоративный агент безопасности, который я не могу выключить, VPN-клиент и полтора десятка политик поверх. Продакшен, куда я выкатываю код, — машины с Ubuntu. Между этими двумя фактами годами была пропасть, и каждый закрывал её как умел: второй ноутбук, вторая система на диске, ругань с админами. Сейчас пропасть закрывает подсистема Linux внутри Windows — и, судя по данным Canonical, так живёт уже очень много людей.
Почему это стало массовым
Ноутбук выбирает работодатель, сервер — архитектура
Разработчик редко решает, на чём он работает: ноутбук приезжает из корпоративного парка с доменом, шифрованием диска и заявкой в поддержку на любое отклонение. А продакшен всё равно Linux — контейнеры, systemd, чувствительные к регистру пути, права на файлы, cron. За зазор между этими реальностями платишь каждый день: скрипт деплоя не идёт локально, тесты падают на путях, чужой файл с переводами строк CRLF ломает bash.
Подсистема снимает противоречие в лоб. Ноутбук остаётся корпоративной Windows-машиной со всеми политиками — админам не о чем спорить. А рядом, в той же системе, живёт настоящая Ubuntu, где терминал ведёт себя так же, как на боевом сервере.
Что именно сказал Canonical
Повод для разговора дал не маркетинг Microsoft, а Canonical — компания, которая делает Ubuntu. Её вице-президент по инженерии Джон Сигер весной 2026 года сказал в интервью изданию The Pragmatic Engineer: за год рост числа установок Ubuntu внутри подсистемы Windows заметно выше, чем рост числа пользователей настольной версии, и он ждёт, что «оконных» станет больше «настольных» уже в ближайшие месяцы. В августе новость пересказал 3DNews, следом её растащили западные издания.
Оговорку в пересказах теряют: абсолютных чисел Canonical не публиковала. Речь про темпы роста по своей телеметрии, а «обгонит» — прогноз одного человека, пусть и хорошо информированного. Но направление я вижу и без цифр: в двух последних командах из десятка бэкендеров на настоящем Linux сидели двое, остальные — из подсистемы.
Как это устроено внутри
Не эмуляция, а настоящее ядро
От устройства зависит всё остальное. Первая версия подсистемы была слоем перевода: программа делала системный вызов Linux, а прослойка переводила его в вызов ядра Windows. Работало неплохо — ровно до момента, когда программе требовалось что-то по-настоящему ядерное, как контейнерам. Вторая версия устроена иначе: внутри запускается настоящее ядро Linux, собранное Microsoft из стабильной ветки исходников с kernel.org, и живёт оно в лёгкой служебной виртуальной машине на Hyper-V.
Отсюда две вещи. Совместимость по системным вызовам полная: ядро то же, что на сервере, и обновляется вместе с Windows. И «виртуальная машина» здесь не то, что вы видели в VirtualBox: её не надо настраивать, ей не надо заранее выделять память, она стартует примерно за секунду.
Что из этого следует по скорости
Всё, что упирается в процессор и в собственный диск подсистемы, идёт практически с родной скоростью: ядро то же, ext4 лежит на виртуальном диске без прослоек. Microsoft приводила замеры перехода со старой версии на новую: распаковка архива ускорилась примерно в двадцать раз, git clone, npm install и сборка через cmake — в два-пять раз.
Но у виртуализации есть цена, и она сосредоточена ровно в одном месте — на границе между файловыми системами Linux и Windows. Об это спотыкаются все, поэтому дальше отдельный раздел.
Где подсистема реально выручает
Окружение перестаёт отличаться от продакшена
Главная ценность не в удобстве, а в совпадении. Я ставлю тот же дистрибутив, что крутится на сервере, те же пакеты тем же apt, получаю ту же версию glibc и те же пути. Права настоящие, chmod +x означает то, что означает, регистр в именах имеет значение. Systemd включается парой строк в конфиге, так что сервис поднимается ровно так же, как на боевой машине. Багов, которые видны только на сервере, стало в разы меньше.
Docker перестаёт быть отдельной проблемой
Контейнерам нужны конкретные механизмы ядра: пространства имён, контрольные группы, слоёная файловая система. На старой версии подсистемы их не было, и Docker на Windows жил в отдельной виртуалке со своими правилами. Сейчас он использует подсистему как основу: контейнеры идут на том же ядре, а собранный локально образ ведёт себя на сервере одинаково. Для бэкендера это главный практический аргумент.
Инструменты, которых под Windows просто нет
Половина моей отладки — strace на зависшем процессе, tcpdump на непонятном трафике, ss на занятых портах, perf на подозрительной нагрузке. Аналогов под Windows либо нет, либо они другие, а переучиваться ради ноутбука бессмысленно. Плюс мелочь, из которой состоит день: конвейеры из grep, awk, sed и jq, make с настоящим шеллом, ansible, kubectl, скрипты коллег, написанные в расчёте на bash.
Связь между мирами двусторонняя: из Linux-терминала открывается проводник Windows, из Windows видны файлы дистрибутива по сетевому пути. Редактор ставится на сторону Windows, а его серверная часть, языковой сервер и сборка работают внутри Linux — вы правите код в привычном окне, а компилируется он там же, где потом побежит.
Где подсистема тормозит
Граница файловых систем — главное разочарование
Соблазн выглядит так: проект уже лежит на диске C, в подсистеме он виден как /mnt/c, значит можно ничего не переносить. Нельзя. Диск Windows подключён к Linux по сетевому протоколу: файловый сервер работает на стороне Windows, Linux ходит к нему через служебный канал. Каждое открытие файла, запрос атрибутов, обход каталога — отдельный запрос с ограниченным размером сообщения. Один большой файл вы скопируете и не заметите, а git status в большом репозитории и сборка с десятками тысяч мелких файлов складываются из этих запросов в минуты.
Насколько плохо — зависит от задачи: в сообществе гуляют замеры с десятикратным отставанием от родной файловой системы, в синтетике разрыв бывает и больше. Показательнее другое. Microsoft в своей документации честно держит «производительность через границу файловых систем» единственной графой, где старая версия выигрывает у новой, и советует хранить файлы там, чьими инструментами вы работаете. В обратную сторону правило то же: индексатор редактора или антивирус Windows упрётся в ту же границу.
Вывод у меня один и без исключений: проект живёт в домашней папке Linux, а не на диске C. Перенос обычно решает проблему целиком, тюнить дальше нечего. Границу постепенно чинят — старый протокол вытесняет более быстрый транспорт через общую память, — но правило от этого не отменяется, просто наказание мягче.
Графика и железо
Графические приложения работают: подсистема показывает окна Linux-программ прямо в Windows и умеет ускорять их видеокартой. Клиент к базе или браузер для автотестов — нормальный сценарий. Но это не рабочий стол Linux: масштабирование, буфер обмена и звук иногда ведут себя странно.
С железом сложнее. USB-устройства напрямую не видны — их пробрасывают отдельной утилитой поверх протокола USB/IP, и, пока устройство отдано в Linux, из Windows оно пропадает. Последовательные порты не поддерживаются: документация отправляет на старую версию. Вычисления на видеокарте работают, а всё, что требует своих модулей ядра или прямого доступа к устройству, отпадает.
Память и сеть
Две мелочи, которые злят на второй месяц. Память подсистема отдаёт обратно, но кеш файловых страниц держит до полной остановки: после суток работы с большими репозиториями машина занимает несколько гигабайт «просто так» — лечится ограничениями в конфиге. И сеть: по умолчанию подсистема сидит за трансляцией адресов, её адрес меняется после перезапуска. Localhost работает прозрачно, но корпоративный VPN или хитрый DNS превращают это в отдельную настройку.
Подсистема, виртуалка или вторая система
Все три варианта «дают Linux», поэтому их постоянно путают. Разница не в удобстве, а в том, где проходит граница с железом.
Когда хватает подсистемы
Если работа заканчивается терминалом, контейнером и портом на localhost — берите подсистему и не думайте. Она стартует за секунду, не требует выделять ресурсы заранее, файлы видны из обеих систем, а Windows остаётся под рукой для почты и созвонов. Это девяносто процентов бэкенда, скриптов и веб-разработки.
Когда нужна полноценная виртуалка
Виртуалка даёт то, чего у подсистемы нет: своё ядро под вашим контролем, произвольный дистрибутив, снимки состояния, настоящую изоляцию. Собираете модуль ядра, проверяете обновление системы, поднимаете стенд из трёх машин с нормальной сетью, сознательно ломаете систему и откатываетесь на снимок — это виртуалка. Платите загрузкой как у обычного ПК, заранее выделенными памятью и диском, общими папками вместо сквозного доступа к файлам.
Когда всё-таки вторая система
Вторая система на диск — единственный вариант, где Linux получает железо целиком: драйверы, видеокарту, звук, всё время работы от батареи. Смысл есть, если Linux для вас не инструмент, а рабочее место. Цена — перезагрузка ради одного корпоративного приложения, а на служебном ноутбуке ещё и разговор с безопасностью. К этому приходят не от нехватки скорости, а от желания жить в Linux постоянно.
Есть и четвёртый вариант, о котором забывают: удалённая машина. Ноутбук становится терминалом, код собирается и запускается на выделенном сервере по SSH или в контейнере разработки. В строгих корпоративных контурах это часто самый честный ответ.
С чего начать
Три решения до первой команды
Первое: какой дистрибутив. Тот же, что на сервере, и той же ветки. Если продакшен на Debian, не ставьте Ubuntu только потому, что она популярнее. Второе: где лежат файлы — папка в домашнем каталоге Linux, и с первого дня только там. Третье: как подключается редактор — окно в Windows, сборка внутри Linux; и в популярных редакторах, и в средах JetBrains это штатный режим, а не хак.
Первый вечер
Дальше всё скучно и быстро: одна команда установки, выбор дистрибутива, создание пользователя. Сразу после этого я включаю systemd, если стек требует, и прописываю ограничения по памяти и ядрам, чтобы машина не съела ноутбук. Потом клонирую рабочий репозиторий в домашнюю папку Linux и запускаю проект теми же командами, что на сервере. Поднялось — вы получили то, за чем пришли, за один вечер.
Чего не делать
Не оставляйте репозиторий на диске C «пока так». Не смешивайте инструменты двух систем: программы Windows видны в путях Linux, и однажды ваш node окажется node.exe, а ошибка будет выглядеть сюрреалистично. Не считайте виртуальный диск надёжным хранилищем — команда удаления дистрибутива сносит всё без вопросов. И не пытайтесь сделать из подсистемы замену рабочему столу Linux.
Мой итог: подсистема — не «Linux для бедных», а способ убрать несовпадение между ноутбуком, который выдал работодатель, и сервером, который выбрала архитектура. Полного Linux она не даёт и не пытается: железо, десктоп и всё, что ниже ядра, остаются за её пределами. Зато она закрывает то, чем бэкендер занят целыми днями, и делает это за вечер вместо недели согласований.
Пока нет комментариев