Windows Subsystem for Linux (WSL) продовжує набирати обертів. Настільний додаток GitHub Copilot отримав експериментальну підтримку WSL, і поки це впроваджується, Google тихо підтвердила, що працює над WSL для Antigravity — своєї агентської платформи розробки, а також над кращою нативною підтримкою Windows, що є рідкістю для компанії з невиразною історією підтримки Windows.
WSL дозволяє запускати дистрибутив Linux безпосередньо у Windows, без необхідності подвійного завантаження або повноцінної віртуальної машини. Значна частина сучасного програмного забезпечення, такого як конвеєри збирання, хмарна інфраструктура та фреймворки ШІ, як-от PyTorch і llama.cpp, спочатку пишеться та тестується на Linux.
Якщо ви ще не усвідомили, Antigravity та GitHub Copilot належать до однієї категорії інструментів розробки на базі ШІ. І хоча GitHub Copilot тепер експериментально підтримує WSL, Google працює над WSL для Antigravity.
WSL2 запускає ядро Linux у легкій керованій Microsoft віртуальній машині, завдяки чому такі інструменти, як Docker, bash та нативні менеджери пакунків Linux, працюють так, як очікують розробники, залишаючись у середовищі Windows. Microsoft невпинно працює над покращенням WSL як серйозної платформи, і новини від Google цього тижня є найчіткішим свідченням того, що ця ставка виправдалася.
Google нарешті підтримує WSL та нативну Windows, і це рідкість
Ні для кого не секрет, що Google рідко виявляла щедрість щодо Windows. Більшість її інструментів розробки або розглядають Windows як другорядний варіант, або постачаються у вигляді ресурсномістких браузерних додатків замість нативних. Але, схоже, ситуація змінюється, принаймні для Antigravity.
Роді Девіс, старший інженер із розгортання розробки у відділі Antigravity та DeepMind компанії Google, написав у X:
«Ми працюємо над підтримкою WSL та кращою нативною підтримкою Windows. Це вимагає часу, щоб дійсно зробити це правильно і щоб воно працювало так, як ми хочемо. Щодо інших функцій, я передам це команді!»
Windows Latest помітив це, переглядаючи гілку обговорення, яку Девіс розпочав, перераховуючи нещодавні оновлення Antigravity, такі як кастомні субагенти, дистанційне керування, розширення IDE та підтримка корпоративних API-ключів, а потім запитуючи користувачів, які прогалини залишаються в їхніх робочих процесах.
Один із користувачів попросив можливість змінити середовище агента на WSL у додатку Antigravity 2.0. Девіс підтвердив, що робота над підтримкою WSL та нативної Windows триває.
Частину WSL легко уявити. Агенти Antigravity могли б виконувати файлові операції, команди оболонки та збірки в середовищі Linux, замість того, щоб перекладати все через Windows.
Частина про «нативну підтримку Windows» є несподіваною, оскільки Девіс не уточнив, що це означає. Він не згадав WinUI, але це єдиний кандидат, який підходить. Microsoft на конференції Build 2026 підтвердила, що WinUI є постійним фреймворком для нативних додатків Windows, відкинувши «3» від WinUI 3, щоб показати відсутність майбутніх фреймворків. Microsoft також почала відкривати вихідний код WinUI на GitHub, з уже доступними зовнішніми внесками та відстеженням загальнодоступних проблем.
Іронічно, що більшість кросплатформних інструментів розробки на базі ШІ за замовчуванням використовують Electron, оскільки це дозволяє швидше випускати продукти скрізь. Однак, усі ми знаємо, як вони поглинають оперативну пам’ять, ніби вона дешева. Нативний додаток WinUI від Google став би одним із небагатьох продуктів Google на Windows, що не працює на Chromium. Хоча, я не повірю в цей оптимізм, поки продукт не вийде, але відповідь Девіса, схоже, не є чимось, що Google говорить легковажно, хоча він і згадує, що це займе набагато більше часу.
Додаток GitHub Copilot тепер запускає сесії агентів у WSL
Але для розробників ця друга частина історії, ймовірно, буде найцікавішою. Пірс Боґґан, керівник відділу PM у GitHub Copilot і раніше в Xamarin, повідомив, що «Windows Subsystem for Linux (WSL) тепер експериментально підтримується в додатку GitHub Copilot!», супроводжуючи це відеодемонстрацією.
Налаштування знаходиться в розділі Settings, Experimental, де новий перемикач «WSL hosts (Preview)» дозволяє додатку «підключатися до WSL та створювати сесії всередині нього». Після активації окрема сторінка Environments відображає кожен встановлений дистрибутив WSL 2 через wsl.exe, у цьому випадку — дистрибутив Ubuntu, позначений як типовий і запущений. Підключення до нього показує активну адресу WebSocket, а звідти ви реєструєте проєкт, вказавши його абсолютний шлях у Linux, наприклад /home/pboggan/coloring-book, який додаток перевіряє перед додаванням.
Запуск нової сесії для цього проєкту показує позначку «WSL: Ubuntu» угорі, підтверджуючи, що сесія виконується в межах дистрибутива Linux. У демонстрації Боґґан ввів запит, попросивши агента додати нижній колонтитул із текстом «Made in Park City, UT». Агент завантажив навичку дизайну інтерфейсу, знайшов файли page.tsx, layout.tsx та globals.css проєкту Next.js, виконав команди git status –short && git branch безпосередньо в WSL, щоб перевірити поточний стан, знайшов наявний стилізований нижній колонтитул і змінив його одним рядком.
Потім він повторно перевірив файл, щоб підтвердити правильність нового тексту, і виконав команду git diff –check для перевірки змін, перш ніж відобразити кнопку «Create PR». Весь цикл з обґрунтуванням, редагуванням файлів та перевіркою Git виконувався всередині WSL, працюючи на моделі під назвою GPT-5.6 Sol.
Внутрішній потік зворотного зв’язку GitHub для додатку Copilot відзначав «Обмежену підтримку Windows + WSL» як відому скаргу. У відповідях підтверджується, що незабаром буде більше функцій. Очікується підтримка віддаленого SSH вже наступного тижня, оскільки основа для WSL також слугує базовою архітектурою для підключення до будь-якого загального віддаленого хоста.
Інший користувач попросив додати або клонувати проєкт безпосередньо з головного меню, замість того, щоб заглиблюватися в налаштування, що, як підтвердив Боґґан, є наступним кроком. Інженер Microsoft Майкл Тірні зазначив, що підтримка WSL не змінює спосіб генерації коду Copilot, а лише те, де відбуваються файлова система та виконання команд оболонки агента.
WSL зараз є однією з найактивніших частин Windows. Останній стабільний збірок, версія 2.7.3, додав монтування VirtioFS на рівні каталогу, IPv6 для мережевих з’єднань virtio та DNS-тунелювання для режиму VirtioProxy, на додаток до оновлення ядра до 6.18. Ми вже розглядали ширший план Microsoft на 2026 рік щодо оновлення WSL з прискореним доступом до файлів, покращеним мережевим підключенням і простішим налаштуванням. Окремо Microsoft випустила WSL Containers, що дозволяє створювати та запускати контейнери Linux безпосередньо з Windows без Docker Desktop. Ми також протестували WSL Containers, щоб побачити, як він працює на практиці.
Windows знову стає серйозною платформою для розробників
Незважаючи на майже постійну негативну пресу, яку отримує Windows 11 через рекламу, помилки та нав’язливі функції ШІ, сторона ОС для розробників переживає сильний період. На конференції Build 2026 Microsoft представила Coreutils для Windows, надавши понад 75 знайомих утиліт командного рядка Linux, як-от ls, grep і mv, нативно для Windows без необхідності WSL, побудованих на основі проєкту uutils з відкритим вихідним кодом на Rust. Зобов’язання WinUI як постійного фреймворку для нативних додатків, а також його перехід до повністю відкритого вихідного коду, свідчать про те, що Microsoft знову робить розробку нативної Windows пріоритетом.
Нещодавно ми писали про те, що Ubuntu зростає у Windows 11 швидше, ніж на нативних ПК з Linux, згідно з даними Canonical, що багато говорить про те, де розробники обирають запускати робочі навантаження Linux.
Windows 11 все ще має багато відповідей. Але WSL Containers, що замінюють Docker Desktop, Copilot, що запускає агентів у дистрибутивах Linux, WinUI з відкритим вихідним кодом, а тепер і Google, що розробляє для WSL та Windows, — усе це свідчить про те, що Microsoft робить усе можливе, щоб повернутися до своїх витоків.