wsl что это такое

Сравнение WSL 1 и WSL 2

Основные различия между подсистемами Windows для Linux WSL 1 и WSL 2 и причины обновления:

WSL 2 использует последнюю и самую новую технологию виртуализации для запуска ядра Linux внутри упрощенной служебной виртуальной машины. Однако WSL 2 не является традиционным функционалом виртуальной машины.

Сравнение возможностей

Как видно из приведенной выше таблицы, архитектура WSL 2 во многом превосходит архитектуру WSL 1, за исключением показателей производительности при работе с несколькими файловыми системами ОС.

Подсистема WSL 2 доступна только в Windows 10 версии 1903, сборки 18362 или выше. Проверьте версию Windows, нажав Windows + R, введите winver, выберите ОК. (Или введите команду ver в командной строке Windows). Может потребоваться выполнить обновление до последней версии Windows. Для сборок ниже 18362 WSL не поддерживается.

Новые возможности в WSL 2

WSL 2 — это основная модернизированная версия базовой архитектуры, которая использует технологию виртуализации и ядро Linux для реализации новых возможностей. Основные приоритеты этого обновления — увеличение производительности файловой системы и добавление полной совместимости системных вызовов.

Архитектура WSL 2

Во время обычной работы виртуальная машина может замедляться при загрузке, изолироваться, потреблять много ресурсов и требовать время для управления. В подсистеме WSL 2 нет таких проблем.

WSL 2 предоставляет преимущества WSL 1, включая простую интеграцию между Windows и Linux, быструю загрузку, незначительное потребление ресурсов и не требует настройки виртуальной машины или управления ею. Хотя WSL 2 использует виртуальную машину, она будет управляемой и будет работать в фоновом режиме, предоставляя тот же пользовательский интерфейс, что и WSL 1.

Полнофункциональное ядро Linux

Ядро Linux в WSL 2 собрано собственными силами корпорации Майкрософт на основе последней стабильной ветви исходного кода, доступного по адресу kernel.org. Этот ядро специально настроено для WSL 2 путем оптимизации размера и производительности, чтобы обеспечить невероятное взаимодействие с Linux в Windows. Ядро будет обслуживаться обновлениями Windows. Это означает, что вы получите новейшие исправления безопасности и улучшения ядра без необходимости заниматься этим самостоятельно.

Ядро Linux WSL 2 — это проект с открытым исходным кодом. Если вы хотите узнать больше, ознакомьтесь с записью блога Реализация ядра Linux в Windows, созданной группой, которая занималась сборкой ядра.

Повышенная производительность операций ввода-вывода файлов

Команды для операций с большими объемами файлов, такие как git clone, npm install, apt update, apt upgrade и другие, с WSL 2 выполняются заметно быстрее.

Фактическое увеличение скорости будет зависеть от того, какое приложение вы используете и как оно взаимодействует с файловой системой. Первоначальные версии WSL 2 запускаются в 20 раз быстрее по сравнению с WSL 1 при распаковке сжатого архива tarball и в 2–5 раз быстрее при использовании команд git clone, npm install и cmake в различных проектах.

Полная совместимость системных вызовов

Двоичные файлы Linux используют системные вызовы для выполнения функций, таких как доступ к файлам, запрос памяти, создание процессов и многое другое. В то время как WSL 1 использует уровень перевода, созданный командой WSL, WSL 2 имеет собственное ядро Linux с полной совместимостью системных вызовов. Доступные преимущества:

целый ряд новых приложений, которые можно запускать внутри WSL, например Docker и другие;

все обновления ядра Linux немедленно готовы к использованию. (Вам не нужно ждать, пока специалисты WSL реализуют обновления и добавят изменения).

Исключения для использования WSL 1 вместо WSL 2

Рекомендуется использовать WSL 2, так как он обеспечивает более высокую производительность и полную совместимость системных вызовов. Однако существует несколько отдельных сценариев, в которых использовать WSL 1 может оказаться более предпочтительным. Рекомендуем использовать WSL 1, если:

Попробуйте использовать удаленное расширение WSL VS Code, чтобы хранить файлы проекта в файловой системе Linux, используя средства командной строки Linux. Также с помощью VS Code в Windows можно создавать, редактировать, отлаживать или запускать проекты в браузере без снижения производительности, связанной с работой в файловых системах Linux и Windows. Подробнее.

Источник

Windows Subsystem for Linux, или как разрабатывать приложения на Windows без боли

Как настроить полноценное окружение разработчика, привыкшего к Linux и Mac OS X.

Традиционно считается, что разработчики (в особенности связанные с бэкенд-разработкой) предпочитают использовать unix-like-системы. Причиной тому было немало. Ситуация начала несколько меняться в 2017 году — именно тогда вышел первый стабильный релиз Windows Subsystem for Linux (также известен под более ранним названием BashOnWindows), который дал разработчикам то, чего они так давно ждали, — полноценный Linux в качестве приложения в Windows!

Но не всё оказалось так просто — лишь к концу 2018 года WSL стало возможно использовать полноценно, при этом способ отнюдь не очевиден. О нём и пойдёт речь.

Для начала пара слов о том, что такое вообще Windows Subsystem for Linux, он же WSL в сокращённом варианте. Это прослойка между ядром Windows и приложениями для Linux, которая позволяет преобразовывать системные вызовы к ядру Linux в вызовы к ядру Windows. Благодаря тому, что виртуализация практически отсутствует, такое решение работает быстрее традиционной виртуализации, где эмулируется целый компьютер, как это происходит в Oracle VirtualBox и VMWare Player.

Кроме того, WSL включает в себя целый ряд утилит для интеграции с Windows — пути в файловой системе автоматически преобразовываются в нужный формат, из-под Linux можно запускать приложения в Windows (но не наоборот!), Linux в WSL имеет доступ ко всем портам и сервисам в Windows.

Для разработчика основное применение WSL сразу же видится в развёртывании среды разработки именно там. Всё же установка многих языков, компиляторов и интерпретаторов, утилит происходит в Linux куда проще — часто одной командой из репозитория. Да и привычная консоль под рукой.

В статье будет рассматриваться именно настройка среды разработки в WSL — для примера возьмём небольшой проект, написанный на Python/Angular/Go (а почему бы и нет?), разрабатываемый в Visual Studio Code. Однако описанные рекомендации в целом подойдут для любого другого редактора или IDE.

Важный момент: WSL официально поддерживается только в Windows 10 x64, начиная с Anniversary Update. Если у вас иная версия — альтернативное решение представлено в следующем разделе.

Инструкция по установке WSL имеется на официальном сайте Microsoft. Если же описать её кратко, то необходимо:

При первом запуске необходимо задать ваши логин и пароль.

Далее уже вам откроется консоль с Ubuntu.

К сожалению, на этих редакциях WSL не поддерживается. Но мы можем без особого труда заменить его Vagrant — мощной утилитой для конфигурирования виртуальных машин. Vagrant работает поверх других сред виртуализации: VirtualBox, VMWare Player или Microsoft Hyper-V. Поэтому стоит понимать, что такой вариант будет по умолчанию медленнее, нежели WSL. А в случае с VirtualBox значительно медленнее из-за файловой системы vboxsf.

Установить Vagrant можно с официального сайта. Также вам потребуется VirtualBox и Git. После этого создайте папку для вашей виртуальной машины, в ней создайте файл Vagrantfile со следующим содержимым:

После чего в том же PowerShell или cmd выполните команду:

После загрузки, настройки и запуска виртуальной машины вы попадёте в консоль Linux. Ура!

Источник

Сравниваем подсистемы WSL 1 и WSL 2. Стоит ли переходить?

В этой заметке в стиле «мысли вслух» автор хотел бы сравнить WSL первой и второй версии, благо опыт общения имеется.

WSL 1 vs WSL 2, что порадовало

1. Использование настоящего ядра линукса

Включение реального ядра Linux повысило IO файловой системы и системные вызовы.
Специально оптимизированное ядро Linux делает WSL 2 вроде как быстрее, чем WSL 1.
В некоторых задачах, по замерам Microsoft, в таких, как распаковка архивов, WSL 2 был в 20 раз быстрее, чем WSL 1, и примерно в 5 раз быстрее при использовании Git clone и npm install.
Потратить своё время на просмотр бенчмарков можете тут и тут.

2. Нативная поддержка докера.

В принципе такая возможность появилась только с WSL 2

На этом радость закончилась.

WSL 1 vs WSL 2, что не порадовало

Начнем с самых новых костылей от Майкрософт и своего рода нововведений, которые лично меня расстроили.
WSL первой версии не использовалось реальное ядро Linux, как и виртуализация. WSL был чем-то наподобие Wine, но не совсем.

Там использовалась какая-то особая прослойка для транслирования вызовов от линуксовых программ в эту оболочку.
Это, ясное дело, замедляло все подряд, но имело и преимущества.

К примеру, все программы, которые работали на WSL 1 были видны в диспетчере задач, этим задачам могли раздаваться приоритеты и задаваться конкретные ядра для исполнения.

Так же все процессы первой версии WSL были видны для антивирусов, им можно было разрешать или запрещать доступ к папкам, как и обычным программам для Windows.

С приходом к WSL 2 конкретные процессы в этой виртуальной машине больше не видны, также, пропала возможность защищать от записи в папки. WSL 2 имеет доступ файловой системе в обход защитника Windows. Какие конкретно уязвимости принесет это в будущем — посмотрим. Но вектором атаки для шифрования всего диска вполне может стать WSL 2.

Работа с сетью тоже немного изменилась в WSL 2. В WSL первой версии был очень странно реализован сетевой стек, он висел на сети, которую использовал сам Windows, более того, прослушиваемые WSL порты можно было проверить в Netstat и закрыть обычным Брандмауэром Windows.

Теперь, в WSL 2 появился отдельный свитч конкретно для WSL, потому что теперь это отдельная виртуальная машина, сплошная скука.

Бенчмарки

WSL дал возможность использовать команды из WSL прямо в Windows. В том числе и в PowerShell.
Используя божественный Powershell, автор произвел замеры своих любимых программ на WSL, которыми сам чаще всего и пользуется.

Во всех бенчмарках использовался Ubuntu 18.04 LTS для WSL1 и WSL2.

Jekyll

Генерация сайта. По одному проходу:

Как видим, WSL2 при построении сайта с помощью Jekyll сильно уступает WSL1. 1,5 секунды против 9,6. Результат в пользу WSL1. Что интересно, WSL1 всегда требовал Sudo для доступа к записи и не хотел выполнять генерацию без прав рута.

Скорость вызова

Тут тестируем скорость вызова оболочки и выполнения одной простейшей команды.

WSl2 грузится чуть медленнее. Это совсем незаметно, так как взят результат выполнения 20 запусков.

Git init и Mkdir

Теперь побенчмаркаем Git init и Mkdir. С помощью Mkdir создаем папку и делаем Git init внутри этой папки с помощью WSL.

WSL vs. другие костыли

Так почему стоит выбрать WSL?

В WSL 2 все так же сохранилась возможность использовать линуксовые команды прямо из винды. Удобно бывает вызвать Bash прямо из строки проводника.

Ну и конечно, WSL использует дефолтное окружение ОС, что вы поставили, вам не придется использовать богомерзкий Vim из Mingw, если вы привыкли работать с человеческими редакторами.

Почему лучше обойти WSL стороной.

Libnotify, в WSL1, как и /proc/sys/fs целиком отсутствуют в WSL1, как было сказано выше, в первой версии не применяется то самое ядро линукса и WSL 2 должен был этот косяк исправить.

В WSL 2 появились все эти библиотеки, теперь все это работает на гипервизоре, но проблем меньше не стало. Автоматическая генерация при создании нового файла и иногда даже при изменении старого так и не работает.

Любители NPM и прочего вот этого вот всего пока что могут обходить WSL стороной, используйте решения, разработанные под Windows.

Крутой лайхак для WSL ( ͡° ͜ʖ ͡°)

Теперь поговорим о единственной причине поставить WSL – Vlmcsd.
Хотите активировать свою лицензионную копию Windows немного другим способом исключительно ради научного эксперимента, но не хотите использовать странные KMS активаторы, скачанные из интернета?
Спасибо Майкрософт, вы можете использовать WSL, вот краткий гайд.

Snap на Ubuntu

sudo apt update
sudo apt install snapd

sudo snap install vlmcsd

С помощью ip addr проверяем ip адрес, на котором висит WSL и используем его в качестве KMS сервера. Вот ссылка на страницу проекта в snapstore.

vlmcsd и Docket на WSL

Тоже самое можно провернуть и через сам Docker, или WSL и Docker. Вот ссылка на проект, лучше него я не объясню.

Со стороны Windows:

Вот как выглядит активация Windows 10 PRO через KMS.

Такой способ установки годится только для шуток, ведь инстанс WSL всегда будет выключен как только вы закроете его окно, как в прочем, пока что, весь WSL годится только для шуток и Git’a.
Автор надеется, вы не сильно заскучали.

Источник

Опыт настройки и использования WSL (подсистемы Linux в Windows 10)

К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.

Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.

Никогда не думал, что однажды вернусь на Windows, но повод попробовать мне дали стечения обстоятельств: жена, далекая от IT, дергала почти каждый раз, когда у нее возникала необходимость воспользоваться компом; проснулась ностальгия по одной игре, но она никак не хотела адекватно работать под wine; а тут еще мне подарили коробочную Windows 10 Pro. WSL я поставил чуть ли не сразу после установки системы, поигрался несколько вечеров, понял, что продукт для моих задач годный, но хочется более привычный терминал и вообще некоторых удобств.

Установка WSL и дистрибутива

Сразу оговорюсь, в интернете можно найти описание установки с помощью выполнения команды lxrun /install в командной строке или консоли PowerShell. Данный способ больше не работает (после выхода WSL в стабильный релиз). Насколько мне известно, сейчас WSL можно установить только из Microsoft Store вместе с предпочитаемым дистрибутивом.

Так же отмечу, что когда установку производил я, на выбор были доступны дистрибутивы OpenSUSE, SUSE Linux Enterprise и Ubuntu 16.04 — последний я и установил. Сейчас также доступны Ubuntu 18.04, Debian 9 и Kali Linux, возможно появятся и другие дистрибутивы. Действия по установке могут отличаться. Так же, часть проблем описанных в статье может быть уже исправлена.

Находим в магазине желаемый дистрибутив и устанавливаем. Установка пройдет быстро, так как скачает только эмулятор ядра Linux и утилиту для запуска подсистемы, которая окажется в системной папке в трех экземплярах: wsl.exe, bash.exe и ubuntu.exe (вместо ubuntu будет имя Вашего дистрибутива). Все они равнозначны и делают одно и то же — запускают собственный эмулятор терминала, в нем linux’овый bash работающий под эмулятором ядра. При первом же запуске нас попросят придумать логин и пароль для пользователя по умолчанию, а после произойдет непосредственно установка дистрибутива. В качестве пользователя по умолчанию указываем root без пароля — это потребуется для дальнейших шагов. Безопасность не пострадает, кроме того при подготовке материалов к статье, в англоязычном туториале, я наткнулся на информацию, что новые версии WSL теперь делают пользователем по умолчанию root без пароля без лишних вопросов.

Дожидаемся установки. Далее первым делом стоит обновить зеркала apt на ближайшие. Для этого понадобится CLI текстовый редактор. В комплекте только vi, я же больше предпочитаю nano, поэтому ставлю его:

sudo вводить не требуется, так как мы уже под root’ом. Отредактируем файл /etc/apt/sources.list:

У меня лучше всего работают зеркала Яндекса, поэтому мой файл выглядит так:

Нажимаем Ctrl+O для сохранения и Ctrl+X для выхода. Теперь можно обновить систему до актуального состояния:

После обновления можно создать нашего основного пользователя. В данной статье я назову его user1, Вы же можете задать привычное имя:

Далее переходим в папку юзера, зайдем под ним, установим пароль и отредактируем файл

Все, подсистема готова к использованию… почти.

Установка X-сервера, Xfce и прочих GUI’шных приложений

Первая же проблема, на которую я натолкнулся — bash-completion в предлагаемом эмуляторе терминала работал, мягко говоря, некорректно. Кроме того, данный эмулятор не умеет вкладки, а каждый его экземпляр запускает все в новом пространстве процессов, с отдельным init’ом (который кстати не заменить). Мне захотелось нормальный эмулятор терминала, некоторых других GUI приложений, а так же панельку, чтоб это все быстро запускать.

Когда я гуглил этот вопрос, я наткнулся на множество проблем, вроде необходимости перевода dbus на tcp протокол. На данный момент всех этих проблем нет. В подсистеме нормально работают unix-domain-socket’ы и все спокойно общается через них.

Первым делом нам понадобится X-сервер, притом установленный в основную систему (в Windows). Лично я использую для этих целей VcXsrv — порт X11 на Windows. Официальный сайт указанный в about самой утилиты его сейчас не предоставляет, поэтому гуглим установщик и устанавливаем все по умолчанию.

Пока идет установка возвращаемся в терминал WSL, командой exit выходим обратно в root’а. Первым делом настроим русские локали:

Далее установим некоторые компоненты Xfce. Можно конечно установить его целиком из мета-пакета, но большинство компонентов нам не понадобится, а модульная архитектура Xfce позволяет нам поставить только необходимое:

Запускать каждый раз окружение руками не очень удобно, поэтому я автоматизировал данный процесс. Для этого в основной системе создадим в удобном для нас месте папку, а в ней 3 файла для запуска:

x-run.vbs — WSL всегда запускается со своим эмулятором терминала, если его закрыть — завершатся все его дочерние процессы. Чтоб данное окно не мозолило глаза, неплохо его запускать скрытым. К счастью в Windows встроен интерпретатор VBScript, который позволяет это сделать в одну строчку:

Далее можем запустить наш start.bat и настроить панель Xfce под себя. Замечу, что здесь я наткнулся на еще одну проблему — панель прекрасно отображается поверх всех окон, но вот выделить себе место, как панель на рабочем столе Windows она не может. Если кто знает решение данной проблемы, поделитесь в комментариях.

Ну и под конец данной части, скриншот моего рабочего стола:

Взаимодействие окружения Windows и окружения подсистемы Linux

Из Linux так же можно запускать Windows приложения. Просто запускаем exe-шник и он выполнится в основной системе.

Сетевой стек у подсистемы общий с Windows. Сервер поднятый в Linux будет доступен на localhost в Windows и наоборот. Однако unix-domain-socket для Windows будет просто пустым файлом, работать с этим можно только внутри Linux. Выход во внешнюю сеть у Linux так же есть, в том числе можно слушать порты, если этого не запрещает фаервол.
ifconfig в Linux и ipconfig в Windows выдают одинаковую информацию о сетевых интерфейсах.

Из диспетчера задач Windows можно спокойно прибить процесс внутри подсистемы Linux. Однако Linux увидит только свои процессы.

Особенности, ограничения и подводные камни

Ядро Linux в WSL не настоящее. Это всего лишь прослойка-эмулятор, которая часть Linux-специфичных задач выполняет сама, а часть проксирует напрямую в ядро winNT. Большая часть api в нем реализована, но не все. Свое ядро собрать не получится, как и не получится подключить модули ядра (.ko, Kernel Object).

Init процесс у WSL тоже свой и заменить его, например, на system.d не выйдет. У меня давно есть желание написать менеджер демонов на go, который бы работал с файлами юнитов system.d и предоставлял бы схожий интерфейс, да все руки не доходят.

Нет поддержки openFUSE, соответственно примонтировать виртуальную или удаленную файловую систему не получится. Так же нельзя сделать mount из файла, mount вообще ничего кроме bind здесь, похоже, не умеет.

Так же нет никакой возможности разбить файловую систему Linux на несколько разделов/дисков.

Прямой доступ к железу практически отсутствует. Все таки мы находимся в песочнице Windows, а не в полноценном Linux. /dev и /sys заметно пустуют, в них лишь проц да виртуальные устройства. Доступ к GPU — только через X-сервер, напрямую — никак, так что нейросети обучать придется в Windows.

В JS разработке столкнулся с тем, что electron.js отказался запускаться в WSL, пришлось дублировать окружение node.js в Windows.

Итоги

Статья получилась довольно длинной, надеюсь, что она окажется еще и полезной.
WSL для меня лично оказался инструментом вполне юзабельным, решающим мои задачи fullstack backend разработчика. Виртуалка с Linux за полгода так и не понадобилась. По общим ощущениям Windows+WSL намного функциональнее, чем Linux+Wine.

Пока писал статью, обнаружил, что в Microsoft Store появилась сборка WSL с Debian 9.3, данный дистрибутив мне более симпатичен, чем Ubuntu, поэтому буду пробовать ставить.

Источник

Утраченный потенциал подсистемы Windows для Linux (WSL)

Если вы несколько лет вообще не следили за Windows 10 и не знаете, что происходит, то пропустили одну вещь — очень горячей темой для разработчиков стала подсистема Windows для Linux, она же WSL. Среди программистов очень часто её обсуждают. Действительно, потрясающе интересная штука.

К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с «родными» инструментами Windows.

А ведь изначально всё задумывалось совсем иначе, пишет Джулио Мерино (Julio Merino), автор блога для разработчиков jmmv.dev. Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле.

Чтобы понять причины этого провала, нужно сначала понять различия между WSL 1 и WSL 2 и как переход на WSL 2 закрыл некоторые интересные перспективы.

Обзор архитектуры WSL 1

Давайте сначала взглянем на WSL 1, и первым делом — на её странное название. Почему эта функция называется подсистемой Windows… для Linux? Разве не наоборот? Это же не подсистема в Linux, которая делает что-то связанное с Windows, а именно наоборот! То есть грамотно она должна называться «Подсистема с функциональностью Linux для Windows» или «Подсистема Linux для Windows» или LSW. Откуда путаница?

Есть мнение, что Microsoft была вынуждена выбрать название «наоборот», чтобы избежать упоминания чужих торговых марок. Вот слова Рича Тёрнера (Rich Turner), проект-менеджера WSL:

Что ж… с другой стороны, такое странное название технически можно считать корректным, если внимательно изучить архитектуру ядра Windows NT. На странице «Архитектура Windows NT» в Википедии мы находим следующее:

«Пользовательский режим Windows NT состоит из подсистем, передающих запросы ввода-вывода соответствующему драйверу режима ядра посредством менеджера ввода-вывода. Есть две подсистемы на уровне пользователя: подсистемы окружения (запускают приложения, написанные для разных операционных систем) и интегрированные или внутренние подсистемы (управляет особыми системными функциями от имени подсистемы окружения). Режим ядра имеет полный доступ к аппаратной части и системным ресурсам компьютера».

Windows NT разработана с нуля для поддержки процессов, запущенных из множества операционных систем, а Win32 был «просто» одной из этих подсистем окружения. На такой платформе WSL 1 предоставляет новую подсистему окружения, подсистему Linux, для запуска бинарников Linux поверх ядра Windows NT. У подсистем окружения Win32 и Linux должна быть одна общая интегральная подсистема.

Что всё это на самом деле значит?

Разные системы называют «фронтендами» — вот что это значит. Процесс пользовательского пространства — это набор двоичных команд, которые процессор выполняет непрерывно (оставим в стороне прерывания). Ядро операционной системы не знает о том, что делает процесс, пока процесс не выдаст системный вызов: в этот момент ядро восстанавливает контроль для выполнения операции от имени пользователя, которая может быть чем-то вроде чтения файла или паузы на несколько секунд.

Но… концептуально открытие файла — это открытие файла, верно? Нам особенно не интересно, что номера системных вызовов или номера прерываний отличаются друг от друга. И в этом заключается ключевой аспект дизайна WSL 1: подсистема Linux в ядре NT — это, проще говоря, реализация уровня системных вызовов Linux перед ядром NT. Эти системные вызовы позже делегируются примитивам NT, а не вызовам Win32. Самое главное: нет никакого перевода с системных вызовов Linux на системные вызовы Win32.

В каком-то смысле это подвиг архитектурной мысли и реальной программной разработки, учитывая в целом хорошую поддержку Linux-приложений под WSL 1 и помня о множестве реальных внутренних отличий NT от Unix, когда Windows вообще нативно не воспринимает стандартную юниксовую логику fork–exec.

Истинная красота этой конструкции заключается в том, что на машине работает одно ядро, и это ядро имеет целостное представление обо всех процессах под ним. Ядро знает всё о процессах Win32 и Linux. И все эти процессы взаимодействуют с общими ресурсами, такими как единый сетевой стек, единый менеджер памяти и единый планировщик процессов.

Причины для создания WSL 2

Если WSL 1 так крут, то зачем нужен WSL 2? Здесь две причины:

Уровни и интерфейсы между ними: API и ABI. Высокоуровневое сравнение

Это означает, что красота дизайна WSL 1 исчезла: ядро Windows NT больше не видит ничего в мире Linux. Просто большой чёрный ящик, который делает что-то неизвестное внутри себя. Ядро Windows NT видит только точки подключения VMENTER и VMEXIT для виртуальной машины и запросы чтения/записи на уровне блоков на виртуальном диске. Это самое ядро NT теперь ничего не знает о процессах Linux и доступе к файлам. Точно так же работающее ядро Linux ничего не знает об NT.

О некоторых других различиях можно прочитать в официальной документации.

Потерянный потенциал

С точки зрения пользователя, подсистема WSL 2 выглядит лучше: действительно, приложения Linux теперь работают намного быстрее, потому что не проходят через неудобную «эмуляцию» системных вызовов Linux в ядре NT. Если NTFS трудно использовать с семантикой Linux, то теперь такой проблемы нет, потому что теперь окружение Linux использует ext4 на своём виртуальном диске. И поддержка приложений Linux может быть гораздо более полной, потому что… ну, потому что WSL 2 — это и есть полноценный Linux.

Но подумайте, за счёт чего достигнуто это удобство? Чего мы лишились?

Какой должна была стать WSL, если бы всё работало так, как задумано:

Вот что бесит сильнее всего, пишет Джулио Мерино: «Хотя я могу установить WSL на свою машину разработки для Azure, но никак не могу его использовать вообще ни для чего. По-прежнему приходится работать в CMD.EXE, поскольку здесь происходит взаимодействие с нативными процессами и ресурсами Windows, а инструменты, с которыми я имею дело, предназначены только для Windows».

На странице вопросов и ответов написано, что WSL 1 не будет заброшен, то есть можно запускать дистрибутивы WSL 1 и WSL 2 вместе, проапгрейдить любой дистрибутив на WSL 2 в любое время или вернуться на WSL 1. И если посмотреть на строгую приверженность к обратной совместимости Microsoft, из-за которой мы до сих пор вынуждены пользоваться архаичными инструментами и протоколами, это может быть правдой. Но поддержка WSL 1 — колоссальное усилие, потому что придётся отслеживать и соответствовать всем изменениям Linux. Как бы то ни было, будем надеяться, что WSL 1 продолжит своё существование. И кто знает, вдруг когда-нибудь всё-таки воплотится в жизнь тот волшебный мир, который мы представляем?

Уровень совместимости в BSD

Интересно, что семейство операционных систем BSD ( FreeBSD, OpenBSD, NetBSD, MidnightBSD, GhostBSD, Darwin, DragonFly BSD) всегда отставали от Linux и других коммерческих операционных систем. Но у них очень давно была реализована эта совместимость на бинарном уровне, о которой мы говорим. Джулио Мерино говорит, что совместимость с Linux в ядре NetBSD была реализована ещё в 1995 году, то есть четверть века назад и за 21 год до рождения WSL 1.

И самое замечательное, эта совместимость не ограничивается только Linux. На протяжении многих лет NetBSD поддерживала эмуляцию различных операционных систем. Поддержка SVR4 появилась в 1994 году, и в течение короткого периода времени NetBSD даже поддерживала… бинарные файлы PE/COFF — да, правильно, это бинарные файлы Win32! Таким образом, в некотором смысле NetBSD реализовала модель WSL 1 наоборот: она позволяла запускать бинарные файлы Win32 поверх ядра NetBSD ещё в 2002 году. Вот так вот.

На правах рекламы

VDSina предлагает VDS в аренду под любые задачи, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO, удобная панель управления собственной разработки и посуточная оплата тарифа, который вы можете создать индивидуально под свои задачи.

Источник