Хабрахабр

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

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

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

image

Источник MSDN

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 были видны в диспетчере задач, этим задачам могли раздаваться приоритеты и задаваться конкретные ядра для исполнения.

image

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

image

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

image

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

image

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

image

Бенчмарки

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

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

Jekyll

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

WSL1

image

WSL2

image

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

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

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

Measure-Command { [int]$i do { $i++ wsl.exe -e 'uname' } until ($i -eq 20)}

WSL1

image

WSL2

image

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

Git init и Mkdir

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

Код:

Measure-Command { [int]$i do { Set-Location "C:\Users\user\Desktop\TestFolder" $i++ $Foldername = Get-Random wsl.exe ''mkdir $Foldername'' Set-Location $Foldername wsl.exe ''git init'' } until ($i -eq 20)}

WSL1

image

WSL2

image

Результаты идентичные.

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

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

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

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

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

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

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

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

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

image

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

Ссылка на Github проекта, ссылка на релизы.

Snap на Ubuntu

Устанавливаем Snap:

sudo apt update
sudo apt install snapd

Устанавливаем vlmcsd:

sudo snap install vlmcsd

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

vlmcsd и Docket на WSL

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

Со стороны Windows:

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

slmgr.vbs -ipk W269N-WFGWX-YVC9B-4J6C9-T83GX
slmgr.vbs -skms 192.168.88.166
slmgr.vbs -ato

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть