Пингвин в окне: о потенциале и перспективах WSL2

Автор оригинала: Jack M. Germain
  • Перевод
Привет, Хабр!

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



В мае этого года компания Microsoft объявила, что WSL2, новейшая версия подсистемы Windows на Linux, будет работать на полноценном ядре Linux, собранном в компании.
Таким образом, Microsoft впервые включает в Windows ядро Linux в качестве одного из компонентов. Также Microsoft вводит в Windows командную строку, которая расширит возможности PowerShell и WSL.

Как ядро Linux для WSL2, созданное силами Microsoft, так и новая командная строка Windows интересны, прежде всего, разработчикам.

«Это наиболее сильный ход в партии против AWS,» отмечает Джошуа Швартц, руководитель программ цифровизации в консалтинговой компании A.T. Kearney.

Будущее Microsoft связано не с рынком ПК, хотя, она и в дальнейшем будет прочно удерживать позиции в этом сегменте. Гораздо важнее будет закрепиться на облачном рынке, одной из составляющих которого в будущем смогут стать и настольные ПК.

Что делает WSL2


WSL2 – это новейшая инфраструктура подсистемы Windows для Linux. Она позволяет радикально повысить производительность файловой системы и обеспечивает полную совместимость с системными вызовами.

Один из основных запросов WSL-сообщества был связан с доработкой функционала. На WSL2 работает гораздо больше инструментов под Linux, чем на WSL, в частности, Docker и FUSE.
WSL2 обрабатывает интенсивные файловые операции, в частности, git clone, npm install, apt update и apt upgrade. Фактическое увеличение скорости зависит от конкретного приложения и от того, как оно взаимодействует с файловой системой.

Первые тесты показали, что WSL2 примерно в 20 раз быстрее WSL1 справляется с распаковкой tar из zip. При использовании git clone, npm install и cmake в различных проектах система показывала рост производительности в два-пять раз.

Поможет ли это завоевать доверие разработчиков?


В сущности, Microsoft стремится обрести признание и доверие в сообществе разработчиков, берясь за разработку собственной версии ядра Linux для поддержки процессов WSL2 – считает Коди Суонн, CEO в Gunner Technology.

«Если не считать разработки строго под Windows, создание всех прочих приложений – облачных, мобильных, веб-приложений – на ПК было крайне неудобным, из-за чего разработчику так или иначе приходилось загружать дистрибутив Linux параллельно с ОС Windows. Microsoft это признала и предложила решение,» заключает он.

Маловероятно, что внедрение собственного ядра Linux серьезно скажется на работе с системой с точки зрения обычного пользователя. Однако, в таком случае открываются возможности для более тесного взаимодействия между службами Microsoft и операционной системой Linux.
Такой ход со стороны Microsoft действительно очень грамотный, поскольку помогает глубже проникнуть в сообщество разработчиков, а также активно пользоваться продуктами, которые развивает кто-то еще – то есть, подключиться к опенсорсу – считает Суонн.

Добро пожаловать в Нью-Майкрософт


Тренд в сторону создания и поддержки ядра Linux «специально под Windows» отражает решительную направленность развития в сторону опен-сорса, которую продвигает CEO Сатья Наделла (Satya Nadella). Microsoft уже не тот, что при Гейтсе и Балмере, когда все хранилось за проприетарным частоколом, а об интероперабельности никто и не задумывался.

«Сатья полностью преобразил Microsoft в гораздо более современную платформу, и эта стратегия окупилась сторицей. Привет, капитализация в триллионы долларов», — говорит Швартц.

По мнению Чарльза Кинга, главного аналитика в Pund-IT, два основных достоинства Microsoft связаны с эффективностью и безопасностью.

«Активно используя собственные серьезные наработки – ресурсы и инструменты – компания может гарантировать клиентам, что ядро будет полностью актуальным и оснащенным новейшими патчами и исправлениями, обеспечивающими полную безопасность», — добавляет он.

Разработчики – также в выигрыше


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

Самое сложное – реализовать все системные вызовы. Поскольку в WSL1 это сделано не было, некоторые приложения там работать не могли. В WSL2 появляется множество новых приложений, нормально работающих в данном окружении.

Новая архитектура позволяет Microsoft вносить новейшие оптимизации в ядро Linux гораздо быстрее, чем в случае WSL1. Microsoft может обновлять ядро WSL2, а не реализовывать все ограничения заново.

Полностью опенсорсный инструмент


Разработка собственного ядра Linux компанией Microsoft стала кульминацией многолетней работы, проделанной Linux Systems Group, а также многих других команд, действующих во всей корпорации Microsoft – свидетельствует Джек Хэммонс (Jack Hammons), менеджер программ в Linux Systems Group, Microsoft.

Ядро, предоставляемое для WSL2, будет полностью опенсорсным, и Microsoft выложит на GitHub инструкции о том, как собрать такое ядро. Компания будет взаимодействовать с разработчиками, желающими помочь проекту, и стимулировать восходящие изменения.

Разработчики Microsoft создавали WSL2 при помощи систем непрерывной интеграции и непрерывной доставки, действующих в компании. Этот софт будет обслуживаться через систему обновлений Windows и будет полностью прозрачен для пользователя. Ядро будет оставаться актуальным и включать все возможности новейшей стабильной ветки Linux.

Чтобы обеспечить доступность исходников, компания зеркалит репозитории локально, а также постоянно мониторит содержимое почтовой рассылки Linux по проблемам безопасности, а также сотрудничает с несколькими компаниями, поддерживающими работу с базами данных в корпоративной виртуальной среде (CVE). Таким образом гарантируется, что в ядре Linux от Microsoft будут учитываться новейшие обновления и устраняться все возникающие угрозы.

Восходящие изменения становятся обязательными


Microsoft гарантирует, что все изменения ядра будут распространяться в восходящем направлении – это важный аспект философии Linux. Поддержка нисходящих патчей сопряжена с дополнительной сложностью; кроме того, такая практика не является общепринятой в сообществе свободной разработки.

Цель Microsoft, активно использующей Linux –стать дисциплинированным членом этого сообщества и поставлять вносимые изменения в распоряжение сообщества. Чтобы добиться стабильности веток, связанных с долгосрочной поддержкой, некоторые патчи – например, содержащие новые возможности – могут включаться лишь в новые версии ядра, а не портироваться в текущую версию LTS в режиме обратной совместимости.

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

Более приятное оформление окон


Microsoft также анонсировала выход готовящейся «зимней» версии Windows Terminal – это новое приложение для пользователей, работающих с инструментами командной строки и оболочками, в частности, Command Prompt, PowerShell и WSL.



Терминал Windows

Windows Terminal 1.0 предлагает множество настроек и конфигурационных возможностей, дающих более полный контроль над оформлением окна терминала, а также над оболочками/профилями, которые должны открываться как новые вкладки.

Настройки будут сохраняться в структурированном текстовом файле, благодаря чему их станет легко конфигурировать и оформлять окно терминала на свой вкус.

Microsoft прекращает доработку имеющейся консоли Windows, а создает новую с нуля, решив применить при этом свежий подход. Windows Terminal устанавливается и и работает параллельно с имеющимся приложением Windows Console, поставляемым «из коробки».

Как это работает


Когда пользователь Windows 10 напрямую запускает Cmd/PowerShell/т.д, срабатывает процесс, прикрепленный к обычному экземпляру Console. Механизм конфигурации нового терминала позволяет пользователям Windows создавать множество профилей для всех желаемых оболочек/приложений/инструментов, будь то в PowerShell, командной строке, Ubuntu, или даже при SSH-соединениях с Azure или устройствами Интернета Вещей.

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

Основные достоинства нового командного интерфейса Windows – множество вкладок и красивый текст. Поддержка множества вкладок считалась самым востребованным запросом по поводу разработки терминала. Красивый текст получается благодаря движку рендеринга на основе DirectWrite/DirectX, оснащенного GPU-ускорением.

Движок отображает текстовые значки, глифы и специальные символы, имеющиеся в шрифтах, в том числе, китайские, японские и корейские идеограмы (CJK), эмодзи, символы powerline, иконки и программерские лигатуры. Кроме того, этот движок отображает текст гораздо быстрее, чем GDI, ранее использовавшийся в консоли.

Обратная совместимость остается в полном порядке, хотя, при желании можно попробовать и Windows Terminal.

Хронология: как это будет


Microsoft будет предоставлять Windows Terminal через Microsoft Store в Windows 10 и регулярно его обновлять. Таким образом, пользователи всегда будут работать с новейшими версиями и самыми последними доработками – практически без лишних усилий.

Microsoft планирует запустить новый терминал ближайшей зимой. После того как Microsoft выкатит Windows Terminal 1.0, разработчики продолжат заниматься множеством возможностей, уже отложенных в бэклог.

Исходный код Windows Terminal и Windows Console уже выложен на GitHub.

Что нас может ждать в дальнейшем?


Возможность того, что Microsoft станет использовать собственное ядро Linux и для других целей, например, для разработки своего дистрибутива Linux, сегодня кажется несколько гипотетической.

Вероятно, исход зависит от того, удастся ли Microsoft обнаружить заметный спрос на такой продукт, и какие коммерческие возможности потенциально могут открыть такие разработки – считает Чарльз Кинг.

Он думает, что в обозримом будущем компания сосредоточит основную работу на обеспечении все более тесной совместимости Windows и Linux и их взаимном дополнении.

Джошуа Швартц полагает, что в данном случае потребуется взвесить, каковы будут вложения в эту работу, и какова – отдача от нее. Если бы сегодня Microsoft была совсем молодой компанией, то, вероятно, все делала бы на основе Linux. Однако, портирование всех наработок, уже имеющихся у Microsoft, на нативную архитектуру Linux, сегодня представляется дорогостоящим и сложным проектом, который едва ли хорошо окупится. Любители Linux получат себе Linux, а основная архитектура останется нетронутой.

Когда Apple в 2000 году заново изобрела Mac OS, эта операционная система строилась на основе BSD Unix, которая более схожа с Linux, чем с DOS. Сегодня же новая версия Microsoft Windows создается именно на базе Linux.

Возможно, перед нами отворяется новая дверь?


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

Гораздо разумнее использовать гетерогенные технологии и системы, наиболее полно отвечающие бизнес-требованиям и конкретным практическим ситуациям.

Более важный стратегический вопрос заключается в том, какие новые стратегические возможности открывает такой ход для самой платформы Microsoft?

Azure – облачная экосистема от Microsoft – уже предоставляет колоссальную поддержку Linux. Ранее Windows хорошо поддерживала Linux при помощи виртуальных машин.

Принципиальные изменения, происходящие сегодня, связаны с тем, что теперь процессы Linux будут нативно выполняться на ядре Windows, а значит – работа с Linux из Windows пойдет гораздо быстрее, чем на виртуальных машинах. Вполне вероятно, что в результате Azure обогатится целой прослойкой инженеров, использующих Linux в промышленных масштабах.
Издательский дом «Питер»
260,99
Компания
Поделиться публикацией

Комментарии 66

    +6
    Виртуалка не нужна. У WSL1 еще был шанс.

    О, да в этой «отличной» статье даже не сказано, что WSL2 это HyperV и конфликтует с остальными средствами виртуализации…
      0
      В дополнение скажу, что насколько я знаю, там используется какая то тонкая, «особая» виртуализация (не контейнер, но и не полноценная VM)
        0

        Явно заявлено "подмножество Hyper-V" — https://devblogs.microsoft.com/commandline/wsl-2-post-build-faq/ "Does WSL 2 use Hyper-V? — The newest version of WSL uses Hyper-V architecture to enable its virtualization. This architecture will be available in an optional component that is a subset of the Hyper-V feature."
        И там же про конфликты — некоторые сторонние виртуализаторы уже обновили: "Some 3rd party applications cannot work when Hyper-V is in use, which means they will not be able to run when WSL 2 is enabled. Unfortunately, this does include VMware, and versions of Virtual Box before Virtual Box 6"

          +1
          Насколько я понял, там используется специально собранное ядро Linux, с целью максимально быстрой загрузки. Также там используется динамическая память, т.е. она жрёт столько оперативной памяти, сколько жрёт Linux, а не фиксированно 4 гигабайта, например. Хотя по-моему ничего не мешает все эти фичи интегрировать в какой-нибудь VirtualBox-образ, если так уж надо (у меня CentOS в VirtualBox загружается за считанные секунды, лично мне это совсем не критично, когда активно пользовался — просто поставил headless запуск в автозапуск и через Putty заходил в любое время).
          0
          Это не виртуалка, это скорее User-mode Linux или даже coLinux майкрософтовского разлива.
            +2
            WSL2 как раз таки виртуалка
            +3
            Вы так говорите, будто в мире linux ничто и никогда не конфликтовало…
            ЗЫ и название статьи «о потенциале и перспективах WSL2», а не «о проблемах и сложностях WSL»
              0
              конфликтует с остальными средствами виртуализации…

              В VirtualBox уже реализовали поддержку Hypervisor Platform. Пока ещё не очень быстро, но ситуация улучшается.
              –2
              Однажды винда перешла на ядро OS/2. Грядёт переход на ядро Linux?
                0

                Я тоже так думаю. А WINE вместе с родными MS-овскими DLL-ками обеспечит обратную совместимость.

                  +3
                  Не было такого. Было ядро которое IBM и MS разрабатывали совместно. Потом на базе этих наработок IBM сделала полуось, а ms windows NT
                    0

                    Если быть точным: IBM и MS совместно выпускали полуось. Потом было принято решение сделать новое ядро, этим занялись MS. В какой-то момент совместный проект закончился, и было принято решение выпустить версию Windows на основе этого ядра.

                      +3
                      >> Потом на базе этих наработок IBM сделала полуось, а ms windows NT

                      Ну разве что если «базой наработок» считать наработанный опыт сотрудников.
                      Ядро NT — совсем другое.
                    –4

                    Какой же это линукс если не можешь сам ядро собрать?
                    Возникает и обратный вопрос — зачем нужен wsl, если есть полноценный линукс и вайн?

                      +5
                      Затем, что есть много виндовой работы, которая на линуксах такая же боль, как линуксовая работа на винде. Сам долгое время просидел в WSL/Ubuntu терминале с ансиблом и прочей линуксовой радостью (только вот линуксового докера очень там не хватает), попутно оставаясь в актуальном рабочем окружении (Visual Studio / .NET framework, MS SQL), пока не открыл для себя VSC Remote.
                        –3
                        Раз вам приходится прыгать между окружениями, то скорее всего у вас процесс разработки построен плохо. Нет плана, четкого разделения работы между платформами с описанием взаимодействия, нет тестов и отдельной дев среды. Завтра вам придется работать с отличным от убунта\центос дистрибутива, будете просить мелкософт добавить их поддержку?
                        Виртуалка с ssh решает ту же задачу не хуже, но позволяет не думать, что что-то в WSL может не работать и какие подводные камни всплывут при выводе в прод.
                        Если уж все равно извращаетесь, то Visual Studio, .net и MSSQL работают в линухе под вайном, а что-то уже и нативно, но бонусом вся прелесть линуксовой автоматизации, нормальный гит и секьюрность из коробки.
                        Ансибл это кроссплатформенная радость.
                          0
                          Ну до такого уровня извращений как запуск студии под вайном я надеюсь никогда не доживу. На счёт чёткого деления на среды — не знаю как в кровавом энтерпрайзе, а в студиях попроще приходится заниматься всем чем. Я больше в роли девопс/SRE, где приходится собирать всё подряд на всём подряд, при этом время от времени влезая в код. А виртуалка — штука на практике не особо удобная, переключения контекста бесят.
                            0
                            А что именно неудобно в виртуалке? Скажем в каком-нибудь headless mode, например.
                              +1
                              Ну вот по факту к тому и пришёл, что от линуксов всё что мне нужно — это некий headless, а будет это виртуалка, отдельный комп или WSL — без разницы, лишь бы работало. А WSL работает без проблем для моих целей, вот только докеров там не хватает.
                      +1

                      А есть где-нибудь почитать, что с WSL1 не так? Я натыкался на комментарии о том, что он слишком медленный, но что помешало майкрософту его ускорить?

                        0

                        Многие утилиты тупо не работали или вели себя странно. Например, nmap

                          +3

                          Ну неработающие утилиты это понятно, ведь там, ЕМНИП, не все системные вызовы до конца были доделаны. Но опять же остаётся любопытно, что помешало их доделать

                            +1
                            Так они и доделали — через втаскивание линухового ядра. Надо полагать, это оказалось тупо менее затратно и более эффективно, чем бесконечно пилить слой эмуляции системных вызовов.
                              +1
                              Менее затратно — понятно (программисты не бесплатные), но почему более эффективно — совершенно непонятно
                                0

                                По сообщению MS в WSL1 тормозили файловые операции — https://devblogs.microsoft.com/commandline/announcing-wsl-2/ "Initial tests that we’ve run have WSL 2 running up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone"
                                Вероятно замедлялось из-за того, что слою трансляции системных вызовов приходилось эмулировать свойства и метаданные posix fs поверх ntfs, а затем вызывать ntfs подсистемы, предполагали также проблемы с кэшированием.


                                В WSL2 файловые операции быстрее для linux root fs, т.е. образа фс, с которым реализация файловых систем ядра линукс работает напрямую: https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/ "Make sure to put the files that you will be accessing frequently with Linux applications inside of your Linux root file system to enjoy the file performance benefits.
                                … To enjoy the faster file system access in WSL 2 these files must be inside of the Linux root file system."
                                А трансляцию доступа к файлам в linux root fs в wsl2 теперь производят для виндовых приложений.

                                  0
                                  Для программиста это выглядит как бред необразованного юзера.

                                  Прямой вызов, пусть даже неэффективной функции, против слоя виртуализации…

                                  Скорее политические мотивы.
                                    +2

                                    С точки зрения файлового ввода-вывода:
                                    Новая система WSL2 — это виртуальная машина в удобной обертке. Внутри виртуальной машины работает ядро Linux со своим родным кэшем, VFS, ФС (ext4). Слой виртуализации замедлит лишь доступ к блочному устройству в котором лежит ext4. (Доступ к ФС между ОС — по 9p протоколу через сеть.) Тесты ФС показывают для WSL2 незначительное замедление по сравнению с нативным линуксом: https://www.phoronix.com/scan.php?page=article&item=windows-10-wsl2&num=2 например, тест на создание файлов https://openbenchmarking.org/embed.php?i=1906141-HV-WSL2MICRO62&sha=6af9cf2&p=2 (виртуализация wsl2 добавила 5 мкс к 11 мкс нативного линукса; в wsl1 было в 60 раз медленнее); git быстрее https://openbenchmarking.org/embed.php?i=1906141-HV-WSL2MICRO62&sha=2c29823&p=2


                                    ФС в старом WSL1 — это огромный слой эмуляции "lxcore VFS" — см https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/ — при этом там есть два разных драйвера VolFs ("/", "/home", эмулятор posix флагов через NTFS Extended Attributes) и DrvFs (для /mnt/c, медленнее т.к. отключает часть кэшей фс); которые затем обращались к NT ядру для исполнения реальных запросов в NTFS. (вызов цепочки функций, увеличение числа запросов — для каждого linux stat надо прочитать несколько ntfs ea)

                        0
                        Сегодня же новая версия Microsoft Windows создается именно на базе Linux.

                        В смысле?
                          +2
                          Принципиальные изменения, происходящие сегодня, связаны с тем, что теперь процессы Linux будут нативно выполняться на ядре Windows, а значит – работа с Linux из Windows пойдет гораздо быстрее, чем на виртуальных машинах. Вполне вероятно, что в результате Azure обогатится целой прослойкой инженеров, использующих Linux в промышленных масштабах.

                          Если я правильно понял и WSL2 это виртуалка, то этот абзац бессмысленнен.
                          Непонятно при чем тут ажур. Те, кто хотели держать линукс на ажуре — давно его там держат. Какая прослойка инженеров должна появиться? Что за marketing bullshit.
                            +4
                            Сегодня же новая версия Microsoft Windows создается именно на базе Linux.
                            Как же автора занесло.
                              +1
                              Это переводчика занесло. В оригинале говорится о том, что Windows основана на DOS, и гораздо дальше от Linux чем MacOS (которая основана на BSD). Тоже сомнительно — непонятно зачем приплетать DOS, но не совсем бред.

                              When Apple reinvented the Mac OS in 2000, it was built atop the BSD Unix OS — which is more like Linux than DOS, which is what Microsoft Windows is built atop, Swartz pointed out.

                              +4
                              У меня к WSL две основные претензии:

                              • Невозможность производить операции с файлами в WSL файловой системе средствами Windows программ.
                              • Каждый WSL терминал имеет свой собственный init процесс, из-за чего приходится городить огороды, чтобы получить постоянно работающий SSHD. Гораздо разумнее было бы пускать WSL-init фоном, как виндовый сервис.

                              Использовать WSL для разработки под Linux неудобно, проще работать в Linux.
                              Использовать WSL для разработки под Windows (линуксовые утилиты + кросскомпиляция) так же неудобно, уж лучше MSYS2/MinGW. Отсюда вопрос — зачем оно? Чтобы без PuTTY иметь возможность подключаться к Linux машинам, сидя в Windows окружении?
                                +5
                                Использовать WSL для разработки под Windows (линуксовые утилиты + кросскомпиляция) так же неудобно, уж лучше MSYS2/MinGW


                                MinGW невероятно, запредельно тормозной.

                                А вот разработка под микроконтроллеры, например, где кросс-компиляция будет по-любому, под WSL прекрасна — с одной стороны виндовый софт, с другой git/make/gcc в родном для них окружении.
                                  0
                                  А как обстоят дела с cygwin? Что в нём не работает?
                                    +1
                                    Не знаю как сейчас, но когда я 6 лет назад пробовал собрать кросс под нужный мне ARM, тормозило просто ужасно. Так что я думаю все тормоза MinGW применимы и к GCC в cygwin. Опять же, в качестве приоритета в cygwin — портируемость, а не производительность.
                                    Из того что не работает — пробовал завести distcc под cygwin, он тупо крашился) спрашивал в одном из своем посте в комментах — кто-то вообще заводил distcc+cygwin, мне не ответили.
                                      +3
                                      Очень медленный. Работа с ФС — это просто боль, с WSL не то что на тестовых, а на практических задачах компиляции исходников или клонирования гита разница в 2-3 раза легко.
                                        +1

                                        Я бы сказал не 2-3, а до 10 раз на мелких файловых операциях.


                                        Плюс невменяемая стоимость exec и отсутствие fork/clone, из-за чего неприемлемо тормозит весь не-виндовый софт.

                                          0
                                          К сожалению, неправда. Тормозной цыгвин работает быстрее с фс чем WSL, я уже писал:
                                          , распаковка архива tar.gz с 2.5 ГБ исходных текстов занимает 2 минуты 50 сек. Даже тормозной cygwin шелл выигрывает — 2 минуты 17 секунд.


                                          В остальном, WSL это плюс.
                                            +1
                                            К сожалению или к счастью, распаковывать 2,5-ГБ архивы мне приходится не то что не каждый день, но и не каждый месяц.

                                            На реальной задаче компиляции проекта MinGW проигрывает WSL в 2-3 раза.
                                        0
                                        Если нужен билд сервер, то может… надо поднять этот билд-сервер(в т.ч. в виртуалке)?
                                        Да не, бред какой-то, надо WSL использовать, скучно ведь.
                                          +1
                                          А зачем конкретно мне нужны пляски с виртуалкой, в которой надо что-то поднимать, которая жрёт кучу памяти, которая не может прозрачно работать с файловой системой и вообще ресурсами хоста, если я могу тыцнуть одну кнопку и получить всё нужное в WSL?
                                            0
                                            Вы тыркнете в Windows Store по Ubuntu 18.04 и бац, открылась терминалка и хрен до неё докопаешься так просто, что это не полноценный линукс. Просто работает. Ну и к чему вся эта возня с тормознутыми виртуалками если можно без них?
                                              +1
                                              Если действительно разработка под линукс, а не пару вспомогательных программ запустить, то там и внутренности ковырять приходится. И модули может потребоваться поставить и файловую систему позаковыристей и пораспределенней настроить и чуется мне все равно виртуалку придется ставить.
                                              Ну и к чему тогда эта возня с WSL?

                                              Я бы предпочел один раз настроить виртуалку, чем каждый раз сталкиваясь с необяснимым проверять а не в WSL ли это дело? А могу я использовать этот софт для дебагга в нем? Запустится ли он вообще?
                                              К тому же виртуалки уже давно не тормознутые. Консольный вариант так и вовсе неотличим по задержкам.
                                                0
                                                За всё время существования WSL ни я, ни кто-либо из коллег не сталкивались с необъяснимым в WSL на примере данной конкретной задачи.

                                                Зачем конкретно нам надо настраивать виртуалку и каждый день плясать вокруг неё и её ограничений?
                                                0
                                                Вы тыркнете в Windows Store по Ubuntu 18.04 и бац, открылась терминалка и хрен до неё докопаешься так просто, что это не полноценный линукс. Просто работает. Ну и к чему вся эта возня с тормознутыми виртуалками если можно без них?


                                                От используемого linux-софт же зависит.
                                                К примеру, попробуйте кучу основанного на Docker софта запустить в WSL 1.
                                                Для чего? Чтобы получить наиболее приближенную к production среду на этапе разработки.
                                                  0
                                                  ставите докер в WSL, в настройках expose daemon on… и
                                                  declare -x DOCKER_HOST=«tcp://127.0.0.1:2375»

                                                  К примеру, попробуйте кучу основанного на Docker софта запустить

                                                  Докер докеру рознь. «Софт основанный на докере» работает по разном на разных машинах. Например, на официальном докере для виндовс (виртуальная hyper-v машина) libgit не работает корректно с оверлеями, пока не пропатчишь, а на линукс машинах — без проблем.

                                                  -  if (git_repository_open_ext(&repository_, path_.c_str(), 0, NULL) != 0)
                                                  +  if (git_repository_open_ext(&repository_, path_.c_str(), GIT_REPOSITORY_OPEN_CROSS_FS, NULL) != 0)
                                                  
                                                    +1
                                                    ставите докер в WSL, в настройках expose daemon on… и
                                                    declare -x DOCKER_HOST=«tcp://127.0.0.1:2375»


                                                    Вы предлагаете некий способ решения проблемы.

                                                    А MS продает сервис, удобство, комфорт. Она за вас решает проблему в WSL 2 (и, автоматически, ряд других проблем). Тем самым увеличивая количество лояльных к Windows пользователей.

                                                    При выборе Ubuntu vs Arch большинство предпочитает Ubuntu. Люди в большинстве своем предпочитают «готовенькое», а не то, где нужно потратить дополнительные усилия для решения проблемы.

                                                    MS делает так, чтобы большинство предпочитало Windows.
                                                    Тут их позиция в корне не изменилась никак со времён предустановки Windows на 80% компьютеров мира.

                                                    «Сделаем пользователю удобнее, дадим ему сервис — и он выберет нас»

                                                    P.S.:
                                                    Согласен, что изначальное решение в виде легковесной оболочки было вполне изящно. Хотелось бы чтобы и такой вариант оставили, буде WSL 1 более производительным на ряде задач, чем WSL 2.
                                            0
                                            Так пробовали?

                                            c:\users\%username%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\ LocalState\rootfs

                                            на Хабре переносы сломались поставил пробел
                                              +1
                                              Вы меня неправильно поняли. Нет никакой проблемы найти расположение файлов WSL. Проблема в том, что при их модификации/копировании с помощью Windows программ, портятся их метаданные. Т.е. файлы как бы есть, но трогать их можно только из WSL. Поэтому тот же CLion, при использовании WSL тулчейна, работает через SSH подключение.
                                            0

                                            Поскольку в абзаце про CVE речь идёт о безопасности, CVE database companies — это, видимо, "компании, поддерживающие базы данных распространённых уязвимостей".

                                              +4
                                              > решительную направленность развития в сторону опен-сорса, которую продвигает CEO Сатья Наделла

                                              Смешно слышать о направленности в сторону опен-сорса компании, которая вымогает деньги с производителей Android-устройств, угрожая возможными исками по поводу нарушения ядром Linux каких-то их патентов.

                                              Они вынужденно делают свои продукты более совместимыми с open-source решениями, чтобы не терять долю рынка. И делают это весьма неплохо, молодцы. Но ни о каком дружелюбии речи тут не идёт.
                                              0
                                              Разве подобное включение не нарушает GPL? Даже если ядро запущено в виртуальной машине, достаточно тесная интеграция одного с другим все равно может рассматриваться как динамическая линковка
                                                0
                                                GPL не запрещает использовать в коммерческих продуктах.
                                                  0

                                                  Речь об открытости исходного кода, а не о том, коммерческий ли продукт

                                                    0
                                                    Речь об открытости исходного кода, а не о том, коммерческий ли продукт


                                                    Там общая память по вашей ссылке как критерий идет, да.

                                                    Из чего вы делаете далеко идущие выводы, так как:

                                                    Значит, и все ОС должны быть открыты, так как у них есть прикладное API и общая память (через которые и идет вирусное заражение лицензией, достаточно интегрировать в систему хоть одну единицу открытого ПО, а это широко используется, даже и с коммерческими ОС).

                                                    После чего — заражаются лицензией заодно и абсолютно все прикладные программы, так как они через API и общую память взаимодействуют с ОС, открытыми на предыдущем шаге?

                                                      +1
                                                      Для прикладных API в Linux отдельно прописано
                                                      исключение из GPL
                                                        0
                                                        Для прикладных API в Linux отдельно прописано


                                                        И?
                                                        Почему виртуальная машина под это условие-исключение не попадает? Там тоже API docs.microsoft.com/en-us/virtualization/api

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

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

                                                        GPL не требует публикации. GPL требует возможности получения исходного кода желающим. Да хоть по отдельному запросу в MS электро-почтой вам лично.

                                                          +1
                                                          Исключение заключается в том, что приложения не заражаются лицензией ядра при использовании системных вызовов. Без такого явного указания это было бы недопустимо. Однако, оно не затрагивает, например, модули ядра, которые обязательно должны быть GPL-совместимыми. Я не понимаю причем тут API Windows Hypervisor Platform.

                                                          Я полагал что WSL2 будет поставляться как компонент системы и тесно с ней интегрироваться, что нарушало бы GPL.

                                                          Вопрос был не в возможности получения исходного кода модифицированного ядра, он и так доступен. Вопрос в том, в праве ли Microsoft включать в состав дистрибуции проприетарной Windows ядро Linux, распространяющееся под GPL.
                                                            +1
                                                            Я полагал что WSL2 будет поставляться как компонент системы и тесно с ней интегрироваться, что нарушало бы GPL.

                                                            А как вы думаете, почему для WSL 1 выбран столь неудобный способ:

                                                            1) Часть функционала активируется простой галочкой
                                                            2) А часть — требует обязательно явной установки пользователем из MS Store

                                                            Такой же практики придерживается и Ubuntu при установке несовместимых с ее лицензией компонент.
                                                +1
                                                берясь за разработку собственной версии ядра Linux

                                                EEE во все поля.
                                                Embrace уже давно почти завершен. Под Linux сидят только те, кому Windows-only средства не нужны. Компиляция идет через mingw, тестирование через виртуалки. Большинство сидит на виндах.
                                                Extend уже идет полным ходом. Достаточно почитать сообщения выше, чтобы понять, что такая «разработка под linux» требует огромное количество костылей, какие-то патчи и хаки для docker. Потом microsoft введет пару «улучшений» в ядро и всё, то, что запускается на WSL не будет работать в Linux. Это УЖЕ есть, почитайте выше про docker и про то, что два терминала не могут с друг другом связаться.
                                                  0

                                                  Писать "новая Windows делается на основе linux" то ли чересчур оптимистично, то ли это попытка ввести в заблуждение. Просто новые инструменты, действительно, пишутся в первую очередь под linux, и windows версия часто плохо поддерживается. Например, докер под windows работает через виртуальную машину вместо нативной версии. А туториалы начинаются с "установите ubuntu...". Желания и сил вносить патчи в тысячи проектов у МС нет, потому они решили добавить слой совместимости для нативного запуска линуксовых компиляторов, докеров, менеджеров пакетов, ноды и т.д. чтобы разработчики оставались на Windows, а не убегали на linux.


                                                  Следующим шагом, я думаю, МС постарается сделать, чтобы работа с WSL была комфортнее, чем на настоящем линуксе — сделают какой-нибудь графический менеджер пакетов, чтобы начинающие любители яваскрипта могли поставить ноду без консольных команд или какой-нибудь удобный конфигуратор докера. При этом завяжут его на Windows API и магазин приложений Windows, чтобы на линуксе его запустить было нельзя. Не уверен, правда, что у них это получится.


                                                  При этом скорее всего WSL будет оптимизироваться исключительно под запуск докера, нгинкса, ноды, стандартного набора веб-разработчика, а например поддерживать Гном или KDE никто не будет — зачем вам Гном, если у вас уже есть десктопное окружение?


                                                  Windows не будет разрабатываться поверх линукса хотя бы из-за лицензии. Кому нужна винда, которую можно взять бесплатно и удалить из нее всю телеметрию?

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое