Browse linux from windows

What is the Windows Subsystem for Linux?

The Windows Subsystem for Linux lets developers run a GNU/Linux environment — including most command-line tools, utilities, and applications — directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup.

• Choose your favorite GNU/Linux distributions from the Microsoft Store.
• Run common command-line tools such as grep , sed , awk , or other ELF-64 binaries.
• Run Bash shell scripts and GNU/Linux command-line applications including:
  • Tools: vim, emacs, tmux
  • Languages: NodeJS, Javascript, Python, Ruby, C/C++, C# & F#, Rust, Go, etc.
  • Services: SSHD, MySQL, Apache, lighttpd, MongoDB, PostgreSQL.
• Install additional software using your own GNU/Linux distribution package manager.
• Invoke Windows applications using a Unix-like command-line shell.
• Invoke GNU/Linux applications on Windows.

What is WSL 2?

WSL 2 is a new version of the Windows Subsystem for Linux architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. Its primary goals are to increase file system performance, as well as adding full system call compatibility.

This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version).

Individual Linux distributions can be run with either the WSL 1 or WSL 2 architecture. Each distribution can be upgraded or downgraded at any time and you can run WSL 1 and WSL 2 distributions side by side. WSL 2 uses an entirely new architecture that benefits from running a real Linux kernel.

Источник

Крутые лайфхаки для работы с WSL (Подсистема Windows для Linux )

Я глубоко погружен в WSL (Windows Subsystem для Linux), и теперь, когда WSL2 доступен в Windows Insiders, это отличное время, чтобы по-настоящему изучить доступные опции. Очень интересная фича, которую я нашел в WSL, — возможность «чисто» перемещать данные между мирами. Это не тот опыт, который вы легко можете получить с полноценными виртуальными машинами, и он говорит о тесной интеграции Linux и Windows.

Под катом подробнее о некоторых интересных вещах, которые вы можете делать, смешивая арахисовое масло и шоколад!

Запустите Windows Explorer из Linux и получите доступ к файлам вашего дистрибутива

Когда вы находитесь в командной строке WSL / bash и хотите получить визуальный доступ к своим файлам, вы можете запустить «explorer.exe .», где находится текущий каталог, и вы получите окно проводника Windows, в котором ваши файлы Linux будут доставлены вам через сервер локальной сети plan9.

Используйте настоящие команды Linux (не CGYWIN) из Windows

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

Вы можете вызвать любую команду Linux напрямую из DOS/Windows/чего угодно, просто поместив ее после WSL.exe, вот так.

Исполняемые файлы Windows можно вызывать/запускать из WSL/Linux, поскольку путь к Windows находится в $PATH до Windows. Все, что вам нужно сделать, это явно вызвать его с .exe в конце. Вот как работает «Explorer.exe.». Вы также можете сделать notepad.exe или любой другой файл.

Запустите Visual Studio Code и получите доступ к вашим приложениям Linux нативно на Windows

Вы можете запустить «code.», находясь в папке в WSL, и вам будет предложено установить расширения VS Remote.. Это эффективно разделяет Visual Studio Code пополам и запускает «headless» VS Code Server в Linux с клиентом VS Code в мире Windows.

Вам также необходимо установить Visual Studio Code и расширение Remote — WSL. При желании, установите бета-версию Windows Terminal для лучшего опыта работы с терминалом в Windows.

Вот отличная подборка статей из блога Windows Command Line.

• Виртуальные машины являются ресурсоемкими и создают очень независимый опыт.
• Исходный WSL был очень «подключенным», но имел довольно низкую производительность по сравнению с VM.
• WSL 2 предлагает гибридный подход с облегченными VM, полностью подключенным интерфейсом и высокой производительностью.

Запуск нескольких Linux в считанные секунды

Здесь я использую «wsl —list —all», и в моей системе уже есть три Linux.

Я могу легко запустить их, а также назначить профили, чтобы они появлялись в моем Windows Terminal.

Запустите X Windows Server под Windows с Pengwin

Pengwin — это специальный Linux-дистрибутив WSL, который очень крут. Вы можете получить его в Windows Store. Объедините Pengwin с X Server, например X410, и вы получите очень классную интегрированную систему.

Простое перемещение дистрибутивов WSL между системами Windows.

Ana Betts отмечает эту замечательную технику, с помощью которой вы можете легко перенести свой идеальный дистрибутив WSL2 с одной машины на n машин.

Вот и все. Получите идеальную настройку Linux, синхронизированную на всех ваших системах.

Используйте провайдер учетных данных Windows Git внутри WSL

Все перечисленные фичи переткают в кульминацию в этом крутом посте от Ana Betts, где она интегрирует Windows Git Credential Provider в WSL, превращая /usr/bin/git-credential-manager в сценарий оболочки, который вызывает диспетчер git creds Windows. Гениально. Это было бы возможно только при условии чистой и тесной интеграции.

Источник

Что такое подсистема Windows для Linux

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

Можно сделать следующее.

• Выберите предпочтительные дистрибутивы GNU/Linux из Microsoft Store.
• Запускайте средства командной строки, например grep , sed , awk , или другие двоичные файлы ELF-64.
• Запускайте сценарии Bash Shell и приложения командной строки GNU/Linux, включая:
  • инструменты: vim, emacs, tmux;
  • языки: NodeJS, Javascript, Python, Ruby, C/C++, C# и F#, Rust, Go и пр.
  • Службы. SSHD, MySQL, Apache, lighttpd, MongoDB, PostgreSQL.
• Установите дополнительное программное обеспечение с помощью своего собственного диспетчера пакетов дистрибутивов GNU/Linux.
• Вызывайте приложения Windows с помощью оболочки командной строки, похожей на UNIX.
• Вызывайте приложения GNU/Linux в Windows.

Что такое WSL 2?

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

Эта новая архитектура изменяет способ взаимодействия этих двоичных файлов Linux с Windows и с оборудованием компьютера, но по-прежнему предоставляет то же взаимодействие с пользователем, что и WSL 1 (текущая общедоступная версия).

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

Источник

Утраченный потенциал подсистемы 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, удобная панель управления собственной разработки и посуточная оплата тарифа, который вы можете создать индивидуально под свои задачи.

Источник