Хабрахабр

[Перевод] Рассказ о том, как Linux привели в Windows

Всё то время, которое я работаю в Microsoft, я занимаюсь созданием инструментов для Linux-разработчиков. Я приступила к работе в августе 2016 года, после выпуска из Виргинского университета, где изучала информатику и менеджмент. Во время учёбы я программировала, в основном, на C++. Моей основной операционной системой была Linux.

Компания переходила в новое состояние, в котором ей были важны все операционные системы, включая Linux.
Моя работа в Microsoft началась в команде Linux. Может показаться, что мой опыт не вполне соответствует тому, что может понадобиться Microsoft, но в то время компания претерпевала сильнейший сдвиг, как в плане технологий, так и в плане культуры. Мне предложили присоединиться к этой команде, надеясь на то, что я принесу в неё мой опыт в сфере Linux. Я занималась там продуктом SQL Server. Я была под огромным впечатлением от того, что я, хотя только что отучилась, могу представлять ценность для команды из-за моего опыта.

Я присоединилась к команде вскоре после того, как они выпустили первую версию продукта. Несколько лет назад идея о разработке разновидности SQL Server для Linux тянула бы лишь на первоапрельскую шутку, но в 2016 году это было совершенно реально. Этот инструментарий был нацелен на управления Linux-серверами и приложениями. Я занялась улучшением инструментария SQL Server, в частности, предназначенного для администраторов. Использование SQL Server на Linux требовало приведения инструментов командной строки к тому виду, к которому привыкли пользователи Linux.

Я начинала работу с форка Visual Studio Code, который сегодня называется Azure Data Studio. Кроме того, мне выпала возможность спроектировать первую версию графического интерфейса SQL Server для Linux. Это — приложение, основанное на Electron, которое, независимо от операционной системы, может работать с любыми видами SQL Server.

В эти знания я могу включить и освоение подхода к управлению разработкой и сопровождением проектов, основанного на комбинации технологий и бизнес-мышления. Я многое узнала, занимаясь SQL Server для Linux в мой первый год работы в Microsoft.

Команда WSL, Chocolatey и Boxstarter на Microsoft Build 2018

Впервые я услышала о WSL во время анонса на конференции Microsoft Build 2016. В августе 2017 я присоединилась к команде WSL (Windows Subsystem for Linux, подсистема Windows для Linux) в качестве руководителя проекта. Оно явно интересовало аудиторию сильнее, чем многие другие анонсы, сделанные на конференции. Соответствующее видео с Channel 9, «Running Bash on Ubuntu on Windows!», сразу после выпуска стало вирусным. Однако публика от этого прямо-таки сошла с ума, не говоря уже о журналистах. О технологии WSL кратко, буквально в течение пары минут, рассказали в рамках озвучивания основных тезисов конференции. Представитель компании Microsoft, запускающий Bash на Ubuntu, работающей внутри Windows… Это действо мгновенно стало хитом. Был момент, когда команда, занимающаяся поддержкой Channel9, опасалась, что большая заинтересованность пользователей этим видеоклипом объяснялась, на самом деле, DDoS-атакой!

В ходе разработки им снова и снова приходилось слышать о том, что людям хочется чего-то, подобного Bash из Linux. Первой командой, обнаружившей потребность пользователей в WSL, была та, которая работала над Windows Console. В итоге команда пришла к следующей мысли: «Зачем делать что-то, напоминающее Bash, если можно просто сделать так, чтобы оболочка Bash запускалась бы прямо на Windows?».

Создание WSL потребовало комбинации глубокого знания Windows, которым обладала команда разработчиков ядра системы, и технологии, разработанной в Microsoft Research, которая называется пикопроцесс (picoprocess). Нельзя сказать, что сделать это было легко. Интересно то, что пикопроцессы, кроме того, являются той самой технологией, благодаря которой оказывается возможной работа SQL Server на Linux.

Команда, которая занимается ядром Windows, занялась разработкой шимов, предназначенных для соединения системных вызовов Linux с Windows. Пикопроцесс должен был обеспечивать работу немодифицированной реализации Linux в режиме пользователя. При этом не нужно было ни перекомпилировать код, ни пользоваться виртуальными машинами. Другими словами, благодаря WSL стало возможно запускать код, скомпилированный для Linux, на ядре Windows NT.

Дело в том, что существовало множество таких дистрибутивов. Мы не создали тогда лишь собственного дистрибутива Linux. Мы связались со специалистами из Canonical для того чтобы узнать, захочется ли им помочь нам в работе над WSL. Первой разновидностью Linux, доступной в WSL, стала Ubuntu. Это привело к тому, что Ubuntu появилась в Microsoft Store. Они отнеслись к нашей идее с энтузиазмом. Сейчас в Microsoft Store можно насчитать уже 6 дистрибутивов. Кстати, предыдущее предложение, само по себе, звучит достаточно необычно. Интересно, в каких ещё магазинах приложений, имеющихся в неких операционных системах, есть другие операционные системы?

Сейчас в Microsoft Store имеется 6 дистрибутивов Linux, которые можно использовать в WSL

В Linux имеется около 340 системных вызовов. Код, который мы тогда написали, представлял собой Linux-совместимые системные вызовы ядра, служащие интерфейсом между процессами Linux и ядром Windows. Как и в случае с любой операционной системой, в Linux новые системные вызовы добавляются по мере выхода новых версий ОС, но старые вызовы никогда не удаляются, что обеспечивает обратную совместимость. Вопрос был в том, чтобы решить, какие системные вызовы нужно реализовывать первыми. Это позволило команде WSL приступить к анализу того, какие именно системные вызовы нужны пользователям Linux. Сначала была реализована обработка некоего набора системных вызовов, а всё остальное было обёрнуто в события наподобие «ещё не реализовано».

Сообщение об этой технологии на конференции Build было направлено именно на то, чтобы люди начали бы пользоваться WSL и дали бы обратную связь. Ответ на вопрос о том, какие системные вызовы нужно реализовывать в первую очередь, означал необходимость налаживания связи с теми людьми, которые пользовались бы WSL. Подключиться к этой программе может кто угодно. Для того чтобы обзавестись WSL, нужно было быть участником программы предварительной оценки Windows (Windows Insider Program). Их интересовала не только Windows, но и, например, игры, и новые возможности Bluetooth, и WSL. Можно подумать, что участниками программы были только те, кому интересна Windows, но тогда, среди более чем десяти миллионов подписчиков, присутствовали люди с самыми разными интересами.

Весь процесс по сборке их приложений часто представлял собой последовательность Bash-команд. Одной из групп пользователей, заинтересованной в том, чтобы оболочка Bash работала бы на Windows, были веб-разработчики, занимающиеся созданием веб-приложений, запускающихся на Linux-серверах. Это не особенно хорошо для тех, кто, в качестве компьютера для веб-разработки, использует Windows. Кроме того, если кто-то решит обратиться за помощью в сфере разработки веб-приложений, скажем, на Stack Overflow, большинство примеров кода, которые он сможет найти, будет предназначено для запуска на Linux. На macOS подобные примеры кода запускаются без всяких проблем. Часто подобным разработчикам легче всего просто перейти на платформу Mac.

Эта программа выполнялась в оконной системе X11, работающей в WSL. За первые пару недель присутствия WSL в Windows один корпоративный пользователь смог запустить XEyes. Она выводит мультяшные глаза, которые следят за курсором мыши. XEyes — простая программа. Но эта демонстрация взорвала социальные сети.

Программа XEyes работает на Windows через WSL

Традиционным инструментом, применяемым для сбора отзывов, был UserVoice. Мы много обсуждали то, как именно мы хотим собирать отзывы пользователей о WSL. Настоящий вопрос встал перед нами тогда, когда речь зашла о том, использовать ли нам GitHub. У нас был UserVoice-сайт, предназначенный для WSL, на котором набрались сотни идей и тысячи голосований по разным вопросам. Но WSL не была опенсорсным проектом. Так как одной из первых групп пользователей, заинтересованных в WSL, были веб-разработчики, вопрос о GitHub был очень важным. Мы решили пойти разработчикам навстречу и создали на GitHub страницу для сообщений о проблемах, для отзывов и обсуждений. Размещение подобного проекта на GitHub выглядит странно. С тех пор мы получили тысячи сообщений, касающихся множества вопросов, связанных с использованием Linux в Windows.

Каждое подобное сообщение было рассмотрено и обсуждено командой WSL, по каждому из них были даны комментарии. Тысячи людей оставили сообщения об ошибках в GitHub-репозитории WSL. Если для того, чтобы реализовать некую возможность или исправить какую-то ошибку, нужно было написать новый код — этот код создавался и добавлялся в проект WSL, после чего попадал во все сборки Windows, распространяемые по программе Windows Insider. После этого принималось решение о дальнейших действиях. Весь цикл, от получения сообщения об ошибке, до её исправления, занимал не особенно много времени — порядка пары недель.

Люди сообщали о проблемах или о своих пожеланиях через UserVoice или GitHub, команда всё это рассматривала и вносила в проект изменения, которые затем появлялись в сборках проекта Windows Insider. В итоге, благодаря оперативной реакции команды WSL на обращения пользователей, можно было говорить о том, что сообщество принимает участие в процессе создания WSL.

Жалобы пользователей, в основном, касались совместимости и производительности. Когда я вошла в команду WSL в роли руководителя проекта, я сосредоточила свои усилия на том, чтобы вывести WSL из состояния бета-версии. О производительности заботятся лишь те, кто решает с помощью некоей программной системы какие-то большие задачи. Но, по-моему, если пользователи беспокоятся о таких вещах, это значит, что они используют нашу разработку всерьёз. В результате, хотя нам многое ещё нужно было сделать, делали мы это не просто так, а ради того, чтобы люди получили бы возможность решать больше задач с помощью WSL, и ради того, чтобы они смогли бы решать свои задачи быстрее.

Очень интересно было посещать мероприятия наподобие PyCon и OSCON. По мере того, как возможности WSL начали расширяться, мы приложили усилия к тому, чтобы приблизить WSL к разработчикам, а не только к тем пользователям, которые традиционно работают, применяя экосистему Microsoft. Разработчики с недоверием относились к идее запуска Linux в среде Windows. Разработчики, которые там присутствовали, были удивлены тому, что участие в этих мероприятиях принимают и представители Microsoft. На этих мероприятиях я показывала SQL Server, WSL и Visual Studio Code.

Демонстрация WSL на различных мероприятиях

Когда сомневающиеся начинали выполнять собственные команды, небольшие скрипты и сниппеты, я всегда встречалась с бурной реакцией на происходящее: «Постойте, а это и правда Linux. Я отвечала на их скептические замечания предложением попробовать то, что я им демонстрировала. Почему я об этом не знал?». Как вы это сделали? Часто они приходили к выводу о том, что мы создали нечто, соответствующее их потребностям, нечто такое, что выглядит весьма интересно.

Она обеспечивает полную совместимость благодаря включению в Windows ядра Linux и даёт 20-кратный прирост скорости. Мы учли жалобы пользователей, касающиеся совместимости и производительности WSL, и выпустили новую архитектуру системы — WSL 2. Сегодня проект WSL уже перерос бета-версию и добрался до версии 2. Я получила интереснейшие впечатления, создавая основу WSL 2 и наблюдая за анонсом этой технологии на конференции Build, которая прошла в мае 2019 года.

Одним из значительных примеров подобного использования WSL можно назвать Visual Studio Code. Кроме того, я работала в Microsoft с другими командами, стремясь к тому, чтобы WSL можно было бы использовать и с их продуктами. Я заинтересовалась Visual Studio Code тогда, когда я поняла, что разработчики, использующие этот редактор, могут получить значительные преимущества от WSL. Это — самая популярная среда для работы с кодом, используемая при разработке JavaScript и Node.js-проектов. Основной задачей было упрощение отладки Node.js-программ, выполняемых в среде WSL. Поначалу речь не шла о необходимости писать огромные объёмы кода. Отладка таких программ выглядела бы точно так же, как их отладка в Linux. Это дало бы разработчикам возможность разрабатывать программы, рассчитанные на Linux-версию Node.js, на Windows-компьютере с использованием WSL.

Первая попытка интеграции Visual Studio Code с WSL и Node.js

Меня восхитил этот пример интеграции WSL и VS Code, я обнаружила, что мне всё это чрезвычайно интересно. После того, как подобное оказалось возможным для JavaScript и Node.js, к нам стало поступать множество запросов на то, чтобы нечто похожее было бы сделано и для других языков, скажем, для C++ и Python. Сейчас я уделяю основное внимание инструментам для C++-разработчиков в VS Code. Это привело меня к моей новой роли в сфере создания инструментов для Linux-разработчиков. Приятно было видеть демонстрацию системы Visual Studio Code Remote Development на мероприятии PyCon в этом году, когда было выпущено соответствующее расширение WSL. В этой работе я, конечно, ориентируюсь на Linux. Тогда же было представлено и расширение для C++, разработкой которого занималась моя команда.

Это и базы данных, и поддержка Linux в Windows, и средства для написания и отладки кода. Несмотря на то, что я провела в Microsoft не так уж и много времени, меня радует то, что мне удалось поучаствовать в создании множества инструментов для Linux-разработчиков. Я планирую и дальше заниматься Linux и создавать инструменты, которыми с удовольствием будут пользоваться разработчики во всём мире.

Уважаемые читатели! Пользуетесь ли вы WSL?

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

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

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

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

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