Comments 32
А что, остальных способов было недостаточно? Например .bashrc, cron...?
UFO just landed and posted this here
UFO just landed and posted this here
Идея тут в том, что этот конфиг читает init процесс, который в WSL является pid 1. Systemd у них нет, автозапуска и init системы полноценной тоже. До этого были костыли с bashrc. Теперь будет лучше. И никакой EEE тут не при чем.
В WSL нет
systemd? Серьёзно?
Наверное, мог бы быть, но кто его запустит? bashrc?
Внезапно linux kernel.
А разве это не виртуальная машина с модифицированной Ubuntu или иным дистрибутивом?
Я работал только с WSL1 и активно пользовался его возможностью запускать процессы между подсистемами. Скажем, я могу встроить dcclinux.exe в makefile, стартующий из WSL. И линукс32 трансляторы, стартующие из Windows IDE. Или транслятор в Си, который после того, как в Си перевёл, вызывает собственно транслятор Си и компоновщики, и эти трое исполняются в разных подсистемах. Было неприятно, что надо было с командной строки прописывать поддержку linux32 после каждой перезагрузки. WSL2 не видел, можно ли там так же туда-сюда гулять, не знаю.
Короче. WSL2, как по мне, это в своём роде шаг назад, по сравнению с WSL1 Первая более интегрирована, с остальной системой, чем вторая.
На wsl2 запуск .exe вполне себе работает. И например explorer.exe. откроет текущий каталог в винде, если это /mnt/ — все как обычно откроется а если нет — откроется по «сети» что-то вроде \\wsl$\Ubuntu\home\vikarti
Из windows — можно просто вызвать bash.exe
А то что менее интегированно — ну так это и не скрывают ж. WSL1 такая же подсистема Windows как собственно и Win32 (реально правда многое из win32 — живет в ядре еще с NT4). Из-за этого и совместимость например с файрволлами и проблемы (с тем например что NT Native API все же больше рассчитан на те принципы по которым Win32 работает)
А WSL2 — хитрая виртуалка.
Из windows — можно просто вызвать bash.exe
А то что менее интегированно — ну так это и не скрывают ж. WSL1 такая же подсистема Windows как собственно и Win32 (реально правда многое из win32 — живет в ядре еще с NT4). Из-за этого и совместимость например с файрволлами и проблемы (с тем например что NT Native API все же больше рассчитан на те принципы по которым Win32 работает)
А WSL2 — хитрая виртуалка.
А WSL2 — хитрая виртуалка.
Чем же она хитрее обычных и привычных? Ну да, дистрибутивы там немного обрезанные и стартуют без полноценного systemd/sysvinit. А ещё что?
То как она взаимодействует с виндой. Кстати, обратите внимание, init там есть. Собственно ничего не мешает ему там быть. И почему сейчас там нет systemd вызывает очень большие вопросы. Это из презентации MS, когда вторую WSL ЕМНИП только выкатили… ну или собирались выкатить.
Интеграция.
Нет, можно конечно настроить и динамическую память и файловые шары по сети прокинуть в оба конца и проброс команд реализовать но тут все — работает. И у всех — одинаково. И (насколько я понимаю) для доступа к файлам не используется TCP/IP а 9P используется.
Нет, можно конечно настроить и динамическую память и файловые шары по сети прокинуть в оба конца и проброс команд реализовать но тут все — работает. И у всех — одинаково. И (насколько я понимаю) для доступа к файлам не используется TCP/IP а 9P используется.
WSL2 да, это виртуалка. И почему там нет systemd для меня загадка, великая есть. А вот WSL1, это что-то похожее на вайн или даже точнее на слой совместимости с линукс во FreeBSD.
У меня в башрц запуск докера засунут, из-за чего при запуске у меня просят пароль, т.к. там sudo. Судя по всему, эту штука будет команды от рута запускать. Вот и вполне причина, зачем это делали. WSL2 же не имеет полноценной init системы до сих пор.
UFO just landed and posted this here
Я не знаю, почему они не используют systemd, но подозреваю, что не от вредности и мифических ЕЕЕ. Все таки WSL интегрирован с виндой и мало ли что этот init процесс при запуске делает. Поднимает шары, пайпы какие-нибудь устанавливает с виндой, память шарит, еще чего. То, что требует специфичного для WSL кода.
Может объективно он нужен, а может это просто рудимент и от нехватки времени. WSL1 очевидно мог требовать свой init. WSL2 вполне мог бы и systemd использовать, но чтобы не ломать то, что уже работало, оставили свой init.
Это было бы справедливо, будь это обычная сборка линукса. Здесь же нет «как всегда было». Такой вещи раньше никогда не было банально.
Может объективно он нужен, а может это просто рудимент и от нехватки времени. WSL1 очевидно мог требовать свой init. WSL2 вполне мог бы и systemd использовать, но чтобы не ломать то, что уже работало, оставили свой init.
«все должно быть написано по своему, как всегда было в Microsoft».
Это было бы справедливо, будь это обычная сборка линукса. Здесь же нет «как всегда было». Такой вещи раньше никогда не было банально.
Не знаю на счёт первой версии, но так как WSL 2 — это виртуальная машина, то её запуск может быть из замороженного состояния, никакие запускаторы не сработают.
А что, вашем их WSL уже отменили? Или смузихлёбы из MS про такие «сложности» не в курсе?
PS: Прочитал комменты… Ну это просто «война и немцы»
systemd, например, в этом PS: Прочитал комменты… Ну это просто «война и немцы»
Сам не пробовал, но пишут, что с systemd в WSL2 по-видимому все же есть проблемы:
https://kumekay.com/wsl2-and-systemd/
https://github.com/microsoft/WSL2-Linux-Kernel/issues/44
Наконец станет можно 32разрядные бинарники в binfmt_misc автоматом регистрировать на qemu-user
А последние несколько минут работы после завершения последнего процесса чем занимается? Собирает и отправляет телеметрию?
WSL это конечно хорошо, но когда windows 10 сможет наконец-то запускать APK файлы?
Sign up to leave a comment.
В тестовой сборке Windows 10 появилась возможность автоматически выполнять команды Linux при запуске дистрибутивов в WSL