Если бы windows был linux org

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

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

Наконец-то у нас появилась возможность запустить свой инструментарий Linux на Windows наравне с виндовыми программами. А это значит, что больше не нужно изучать странный PowerShell или пользоваться архаичной консолью CMD.EXE .

К сожалению, не всё так радужно. 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 должна быть одна общая интегральная подсистема.

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

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

Способ, которым процесс выполняет системные вызовы, и семантика этих системных вызовов специфичны для операционной системы. Например, на старых х86 это выглядит так: открытие файла в системе Win32 — системный вызов 17h , который инициируется через прерывание INT 2EH , а при открытии файла в системе Linux — это системный вызов 5h , который инициируется через прерывание INT 80х .

Но… концептуально открытие файла — это открытие файла, верно? Нам особенно не интересно, что номера системных вызовов или номера прерываний отличаются друг от друга. И в этом заключается ключевой аспект дизайна 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? Здесь две причины:

WSL 1 должен, по сути, реализовать все двоичные интерфейсы приложений (ABI) ядра Linux, как говорится, «бит к биту». Если в интерфейсе есть ошибка, WSL 1 должен её воспроизвести. А если есть функция, которую трудно представить в ядре NT, то она либо не может быть реализована, либо нуждается в дополнительной логике ядра (и поэтому становится медленнее).

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

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

WSL 2 «выбрасывает» всю часть подсистемы Linux и заменяет её полноценной (но очень хорошо скрытой и быстрой) виртуальной машиной. Затем виртуальная машина внутри себя запускает обычное ядро Linux, правильную файловую систему Linux и стандартный сетевой стек Linux. Всё это работает внутри VM.

Это означает, что красота дизайна 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, если бы всё работало так, как задумано:

• Представьте, как здорово набрать ps или top в сеансе WSL и увидеть рядом процессы Linux и Windows, причём любой из них можно убить командой kill ?
• Представьте, как здорово манипулировать службами Windows из сеанса WSL?
• Как здорово использовать ifconfig (аналог ipconfig из Windows, хотя есть ещё ip ) в рамках сеанса WSL для проверки и изменения сетевых интерфейсов компьютера?

По сути, можете представить выполнение абсолютно всех задач системного администрирования в Windows из линуксовой консоли WSL? Это же сказка!

Хотя такого никогда не существовало, такой мир вполне можно себе представить… и это могла обеспечить только архитектура WSL 1. И это вовсе не фантазии, потому что именно такую модель использует macOS (хотя это немного читерство, ведь macOS, по сути, является Unix).

Вот что бесит сильнее всего, пишет Джулио Мерино: «Хотя я могу установить 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, удобная панель управления собственной разработки и посуточная оплата тарифа, который вы можете создать индивидуально под свои задачи.

Источник

Евангелист Open Source Эрик Реймонд: Windows перейдет на ядро Linux в недалеком будущем

Эрик Реймонд — евангелист свободного ПО, сооснователь фонда Open Source Initiative, автор «закона Линуса» и книги «Собор и базар», своеобразной «священной книгой» свободного ПО. По его мнению, в недалеком будущем Windows перейдет на ядро Linux, так что сама Windows станет слоем эмуляции на этом ядре.

Похоже на шутку, но сегодня вроде бы и не 1 апреля. Свое утверждение Реймонд аргументирует активными действиями Windows в сфере открытого ПО. Так, Microsoft активно работает над Windows Subsystem for Linux (WSL) — подсистемой Linux для Windows. Также он не забыл о браузере Edge, который работал сначала на движке EdgeHTML, но полтора года назад его перевели на Chromium.

Плюс ко всему, в прошлом году Microsoft заявила об интеграции в ОС полноценного ядра Linux, что необходимо для работы WSL2 с полной функциональностью. В целом, рациональное зерно в утверждении Реймонда есть, ну а как относиться к этому мнению, личное дело каждого.

У Эрика Реймонда есть и другие аргументы в пользу скорого «переезда» Windows:

Большое количество уязвимостей в ядре самой Windows. Так, в последнем апдейте для Windows 10 содержится около полусотни исправлений.
Необходимость вкладывать крупные средства в развитие проприетарного ядра Windows. Чтобы оптимизировать затраты, корпорация Microsoft может перейти на бесплатное Linux-ядро.
Снижение прибыли от продаж Windows. Сейчас большая часть прибыли корпорации Microsoft поступает от облачного сервиса Azure, а не от продажи ПО, как раньше.

Правда, продажа программного обеспечения до сих пор приносит неплохие деньги, но здесь суммы в несколько раз меньше, чем у облачного подразделения. Так, рост оборота подразделения More Personal Computing, которое занимается, в том числе, продажей лицензий Windows, составляет около 7% в 2020 году. А вот с Microsoft Inteligent Cloud дело другое — прирост выручки составляет 17% по сравнению с прошлым годом.

Абсолютные показатели тоже разные. Если в первом случае рост оборот около $2,5 млрд, то во втором — $13,4 млрд.

Замедляет рост выручки «софтверного» подразделения Microsoft, в первую очередь, снижение объемов продаж ПК и ноутбуков. Это хорошо заметный тренд последних несколько лет. Если экономические проблемы не исчезнут, а это вряд ли, то к 2021 году рынок ПК и ноутбуков испытает не одно потрясение. А это означает, что у Microsoft тоже возникнут проблемы.

Во что превратится Windows?

Как и говорилось выше, Реймонд утверждает, что Windows станет слоем эмулятора на ядре Linux. Интерфейс же ОС от Microsoft станет просто графической средой для Linux, где можно будет запускать приложения под Windows через эмулятор.

Пример такого эмулятора уже существует — это Proton, который дает возможность запускать Windows-игры на ПК под управлением Linux. Proton разработан компанией Valve, и если к этому продукту приложить дополнительные усилия, он может стать почти идеальным. Но ничего не мешает разработать что-то похожее самой Microsoft, не одалживая чужие платформы.

В итоге компания сэкономит кучу денег, а финансовый вопрос почти всегда важнее для компаний, чем идеология. В результате Linux победит на десктопах, став одной из основных ОС для персональных компьютеров. По мнению евангелиста свободного ПО, разработчики постепенно перейдут на двоичные файлы ELF с API Linux, отказавшись от двоичных файлов ОС Windows.

Microsoft давно дружит c Linux

Впервые о тесной дружбе Microsoft с разработчиками Linux стало известно 4 года назад. Тогда компания вместе с Canonical заявила об интеграции ОС Ubuntu в Windows. Получилось нечто вроде эмулятора, но вполне работоспособного.

Все логические диски, вроде C:, монтировались для чтения и записи в директории /mnt, то есть /mnt/c, /mnt/d и т.д. И наоборот, файловая система Ubuntu появилась в «Проводнике» в C:\Users\Kirkland\AppData\Local\Lxss\rootfs\.

Но это были лишь первые эксперименты, которые постепенно продолжались, пока не переросли в нечто большее.

В апреле прошлого года корпорация Microsoft впервые представила Windows Subsystem for Linux. Затем было разработано уже второе поколение этой системы, которая позволяет запускать под Windows любые приложения под Linux, включая не только консольные, но и графические. Сейчас в WSL добавлена поддержка компьютерных вычислений на GPU. Разработчики могут полноценно использовать свои аппаратные ресурсы, например, для машинного обучения, используя NVIDIA CUDA и DirectML. В Linux-окружении можно запустить TensorFlow и PyTorch.

Осенью этого года Microsoft выпустила экспериментальную сборку ОС Windows 10, которая отличается от других тем, что содержит ряд инструментов для работы с Linux. Например, файловый менеджер Windows научился работать с файловыми системами для Linux, включая ext4.

Плюс ко всему, Microsoft является одним из крупнейших партнеров Linux Foundation. Угадайте, кому принадлежит самой большой раздел на GitHub, посвященный открытому ПО? Правильно, Microsoft. Компания выпускает все больше продуктов с открытым исходным кодом и сотрудничает с крупнейшими представителями сферы Open Source.

Источник