У компании уже имелся подобный опыт. Оригинальная концепция Windows NT (на которой основана Windows 10) подразумевала присутствие там трех подсистем: родной MS Win32, UNIX POSIX, а также IBM OS/2. Обе последние подсистемы отвалились где-то по дороге, которая вела к превращению Windows 2000 в Windows XP, а сама POSIX перекочевала в отдельный инструмент без возможности присутствия в дистрибутиве Windows по умолчанию. То же касается микропроцессорной архитектуры Alpha, от поддержки которой Microsoft также отказалась с выходом Windows 2000. Остается только гадать, сколько продержится в Windows подсистема Linux.
Стоит отметить, что во-первых, архитектура ядра Windows 10, как и прочих версий Windows NT, подразумевает под собой интеграцию других ОС, хотя бы на уровне поддержки запуска там приложений с возможностью реализации соответствующих системных вызовов с правильной семантикой. Для этого был введен вспомогательный уровень подсистем, который в случае с Win32 называется NT layer (ntdll). Прочие библиотеки подсистем также имели доступ к ядру и могли воспроизводить то поведение системных вызовов, которое было нужно конкретной подсистеме (например, fork в POSIX, которая выполняла ветвление процессов).
Во-вторых, концепции Windows NT и Linux во многом похожи: обе основаны на монолитном ядре, разбитом на подсистемы, обе используют схожие механизмы реализации объектов ядра и межпроцессного взаимодействия, а также обе берут свои истоки у концепции ядра оригинальной UNIX.
Нам сложно сказать, что именно подвигло Microsoft на интеграцию в Windows 10 второй подсистемы, однако, как и в прочих случаях компания подошла к этому весьма основательно, не опираясь на какие-либо подходы псевдо-эмуляции или виртуальных машин. Все вышеперечисленные подсистемы разрабатывались исключительно как native и имели схожие с Win32 полномочия в реализации функций собственных подсистем.
И так, по сути. Анонс новой подсистемы состоялся на известной конференции Microsoft под названием Build 2016, на которой анонсируются программные новинки компании. Было заявлено, что в будущей версии Windows 10 пользователи смогут пользоваться услугами командного интерпретатора Linux, известного как bash, что в свою очередь сразу указывает на присутствие в Windows загрузчика исполняемых ELF-файлов, а также среды (подсистемы) для их исполнения и стандартных инструментов типа ssh, grep, sed, и awk. В качестве эталона была выбрана Ubuntu Linux.
Рис. Слайд презентации «Linux on Windows». На слайде указано, что речь идет именно о полноценной подсистеме Linux, а не о псевдо-эмуляции или виртуальных машинах. Да, Linux становится частью Windows 10 и так же как POSIX и OS/2 будет работать в пользовательском режиме с реализацией семантики системных вызовов на уровне ядра.
Рис. Собственно архитектура или все то, что мы говорили выше, плюс специальная поддержка семантики системных вызовов Linux на уровне ядра, за что и отвечают два драйвера, указанных в самом начале.
Рис. Так как Linux становится полноценной подсистемой и частью Windows, ее командный интерпретатор можно вызвать через оболочку Windows Shell или же командный интерпретатор, как и показано на слайде.
Рис. 3. Демонстрация работы известной UNIX-команды ls для вывода списка содержимого директории.
Рис. 4. Утилита readelf для анализа заголовка ELF-файла в действии.
Рис. 5. Компилятор исполняемых файлов gcc.
Рис. Есть над чем поработать. :)
Полное видео демонстрации работы подсистемы Linux на Windows можно посмотреть здесь.
Комментарии (173)
mkpankov
31.03.2016 12:18+2Круто. А когда это станет доступно?
Razaz
31.03.2016 12:19+1Вроде как летом со следующим Annual Update для 10. Вроде так услышал на презентации.
NeoCode
31.03.2016 13:42-15А для семерочки будет доступно?
leschenko
31.03.2016 18:11+31Конечно! Надо только до 10 сначала обновить систему.
NeoCode
01.04.2016 15:18Ну я вообще-то вполне серьезно спрашивал) Или там такая сильная завязка на десятку, что оно просто не будет работать под ранними версиями Винды?
Razaz
01.04.2016 15:21Думаю просто не будут тратить ресурсы, на поддержку старой версии. Да и ядро скорее всего менялось в 8, затем в 8.1, затем в 10. А так как там идет трансляция сисколов, то это еще уменьшает шансы.
leschenko
01.04.2016 15:27Я не работаю в Microsoft, но скорее всего дела обстоят так:
- для того чтобы новые функции появились в ОС, ее надо модифицировать. Т.е. выпустить новую версию ОС.
- для того, чтобы эти же функции появились в старой ОС, надо внести в нее те же модификации. т.е. надо обновить ОС.
Т.е. обновление с 7 до 10 не шутка. Это вполне серьезный ответ. И заметьте, что пока еще это бесплатно. Как будет потом — не известно.leschenko
01.04.2016 15:30Т.е. 7 + все новые фичи это и есть 10.
Если вам нравится 7, но вы хотите получить новые фичи -> обновляйтесь до 10.
khim
01.04.2016 15:39+2Думаю что всё проще: там нужны разные модификации в ядре, а учитывая политику Microsoft никто их для Windows 7-8 делать не собирается, вот и всё.
К примеру довольно большая часть вещей делается в Linux через фьютексы. В Windows8 они есть, а в Windows7 — их нет. Можно ли эту функцию "вынуть" из Windows8 и перенести в Windows7? Да, разумеется — но кто будет это делать?
Lsh
31.03.2016 12:56+2Т.е. это не аналог coLinux и полноценного ядра тут нету? Следовательно, например, примонтировать ext4 не получится?
Да и, к.м.к., будут проблемы с совместимостью, т.к. не будут же они все системные вызовы реализовывать.Razaz
31.03.2016 13:07+5"So maybe something like a Linux emulator?" Now you're getting warmer! A team of sharp developers at Microsoft has been hard at work adapting some Microsoft research technology to basically perform real time translation of Linux syscalls into Windows OS syscalls.
Тынц
tkf
31.03.2016 14:37+4line? line is not emulator :D
Ничто не ново под луной в общем.
Gorthauer87
31.03.2016 14:39+1Ну ради вайна в ядро не тащили сисколы, только китайцы как-то выпендривались.
avor_il
31.03.2016 13:00+1Интересно, а какие могут быть сценарии использования этого?
BlackRaven86
31.03.2016 19:39Для заточенных под Linux приложений, например git.
pvasili
02.04.2016 22:39git и так давно в win прекрасно поживает :)
Найти что-то очень заточенное — реально сложно. Скорее всего будет удобно использовать разработчикам, которым нужно 2 среды.
ExileeD
03.04.2016 17:40Для меня это будет мега удобно. Я привык к bash. Но ставить дектопный linux я не хочу. Буду нативно запускать python, docker, вместо костылей типа cygwin
JTG
03.04.2016 17:42Собирать под виндой расширения Python, требующие всякие libastral-dev без возни с MinGW, например.
vovka667
03.04.2016 17:42Может быть Microsoft чувствует, что теряет разработчиков прикладного софта? Многие переходят на мак или линукс. И таким образом они надеются сделать windows более привлекательным.
pftbest
31.03.2016 13:01-9А символические ссылки они сделали? без них никакого толку.
intnzy
31.03.2016 13:23+8В смысле "сделали"? В ntfs cимлинки сто лет в обед.
pftbest
31.03.2016 13:25-9Когда я последний раз пользовался cygwin там были текстовые файлы вместо настоящих симлинков. Вот я и спросил все ли хорошо сейчас с этим.
mukizu
31.03.2016 13:44+9mklink, зачем там cygwin?
pftbest
31.03.2016 15:15+1Я о том что если там всегда была хорошая совместимая поддержка символических ссылок, зачем тогда разработчикам cygwin пришлось изобретать велосипед и делать свою реализацию?
eandr_67
31.03.2016 15:47В NT-based системах — да, прекрасная поддержка. А в Win-9x/Me — только FAT, которая симлинков не имеет. Так что NTFS начала широко распространяться только после 2000 года (да и то сколько лет понадобилось, чтобы сначала 2000, а потом XP вытеснили 98SE) — когда cygwin уже давным-давно существовал. И до сих пор на флешках FAT используется.
khim
01.04.2016 00:00+2Прекрасная поддержка, да? Так сделать можно?
/tmp$ ls -al src
Как будет можно — заходите. CygWin поддерживает виндовые симлинки — но не создаёт. Вот именно поэтому: их нормально создать под Windows нельзя, собственно. А FAT на флешках — это фигня, это не самое страшное…
ls: cannot access src: No such file or directory
/tmp$ ls -al target
ls: cannot access target: No such file or directory
/tmp$ ln -s target src
/tmp$ echo test > target
/tmp$ cat src
test
/tmp$ rm target
/tmp$ mkdir target
/tmp$ cd src
/tmp/src$
MacIn
01.04.2016 01:05-2Это вообще как — создавать линк между несуществующими сущностями?
khim
01.04.2016 11:46А вот так: A symbolic link provides no such assurance; in fact, the file named by the path1 argument need not exist when the link is created. A symbolic link can cross file system boundaries.
Вполне себе явное требование, прописанное в стандарте. Но проблема не в этом. Симлинк на "несуществующую сущность" в Windows создать можно — но нужно заранее знать: будет эта сущность файлом или подкаталогом!MacIn
01.04.2016 16:13-1Это ограничение скорее всего вытекает из глобальной системы объектов.
khim
01.04.2016 16:41+1Нет, это ограничение проистекает из того, что когда симлинки добавлялись в Windows, то считалось что "мир POSIX" побеждён раз и навсегда и на совместимость с ним "можно забить".
MacIn
01.04.2016 17:22-1Это слишком частное ограничение для таких глобальных решений.
MacIn
01.04.2016 17:47-1Дополню — я имею в виду, что symlink в NT — вещь более старая, чем те, о которых мы говорим. И файловый symlink ложится на систему объектов как частный случай (наверно).
khim
01.04.2016 18:56Вы не путаете Reparse Pointы (доступные с незапамятных времён) и символьные ссылки (появившиеся в 2006м)?
Lsh
04.04.2016 00:36А можно для чайников, в чем разница?
khim
04.04.2016 13:55+1Отличие в том на каком уровне всё интерпретируется.
Reparse Point — это ошмёток от идеи создания "модульной фаловой системы": теоретически можно заставить обрабатывать каталог в файловой системе как угодно с помощью инсталляции драйвера, практически — есть только один драйвер, установленный по умолчанию, который используется как замена символьным ссылкам. Как несложно догадаться из описания — всё это происходит на уровне NTFS, обрабытывается локально и до уровня CIFS не доходит (то есть если на сервере есть Reparse Pointы, то клиенты про это никак узнать не могут). Однако в силу построения всей конструкции на файлы Reparse Point указывать не могут (драйвер контролирует что "внутри" Reparse Point'а) и на другие машины в сети — тоже (драйвер находится "ниже" уровня CIFS).
Symbolic Links — это специальные объекты файловой системы, никакой магии, просто строчка "сюда не ходи, ходи туда", обрабатываются в ядре — но уже на клиенте и, соответственно, могут быть на оном клиенте увидены, а также могут указывать на другие машины в сети. В связи с такой нелокальностью для их создания нужны специальные права, по умолчанию доступные только админу (что есть IMNSO, бред). Могут также указывать на файлы, не только на каталоги — но "чтоб жизнь мёдом не казалась" это нужно знать в момент создания символической ссылки (что есть IMNSHO ещё больший бред: если вы уже добавляете сущность из POSIX, то зачем ломать всем известную семантику?).
Как-то примерно так.MacIn
05.04.2016 22:09-1но «чтоб жизнь мёдом не казалась» это нужно знать в момент создания символической ссылки (что есть IMNSHO ещё больший бред: если вы уже добавляете сущность из POSIX, то зачем ломать всем известную семантику?).
Давайте попытаемся объективно прикинуть, почему это так. Для работы с файлами и каталогами будут использоваться разные API, значит для работы с сущностью нам надо знать, что это — директория или файл. Возможно, это связано и с разными методами синхронизации данных (размеры файлов и пр) в условиях сети и возможных отключений.MacIn
05.04.2016 22:14-1Это, кстати, по поводу вашей проблемы с пакетным менеджером — вот создали мы симлинк на \abc\def, как ОС должна обрабатывать def — как файл? Или как директорию? А если на том конце def'а нет и мы это проверить не можем?
khim
05.04.2016 22:24Симлинки сами по себе не обрабатываются. Никак. Вообще. Это просто строка.
Будет обращение — тогда и разберётесь.MacIn
05.04.2016 23:50Тяжело, да. Попробую еще раз:
При обращении. Да.
симлинк на \abc\def, как ОС должна обрабатывать def — как файл? Или как директорию? А если на том конце def'а нет и мы это проверить не можем?
khim
06.04.2016 01:13Любой симлинк должен иметь возможность указывать в «пустоту» (на удалённый объект) и ОС должна корректно это обрабатывать.
А если на том конце def'а нет и мы это проверить не можем?
Вот с этого, пожалуй, стоит и начать.
Какую-такую операцию вы пытаетесь осуществить, для которой важно знать — должен быть объект «с того конца» файлом или каталогом, но при этом не важно — существует он или нет?
khim
05.04.2016 22:23-1Мне совершенно наплевать на ваши «объектные менеджеры», «синхронизацию данных» и прочее. Симлинк — это просто синоним другого объекта, ни больше, ни меньше. Хотите заводить свои, особенные, структуры данных — заводите. Но зачем ломать известную сементику-то?
P.S. Напомнить за что в своё время Sun засудил Microsoft, нет? Вот и здесь — та же история. Только в это раз она «стреляет» в обратную сторону: пока в Windows не будет, в частности, нормальных симлинков — говорить о какой-либо совместимости с Linux нельзя. И есть у меня подозрением что подобным «гитик» там… есть. Для «вау какая фенечка» на выставке — годится, для работы — нет.MacIn
05.04.2016 23:52Мне совершенно наплевать на ваши «объектные менеджеры», «синхронизацию данных» и прочее
А мне — плевать на ваше видение «правильного» симлинка. Это просто предположение о том, почему оно так устроено.
Но зачем ломать известную сементику-то?
С какого-то перепугу вы решили, что все кругом, в том числе не в Linux системах должны реализовывать некоторую сущность 1 в 1 как в Linux.
MacIn
05.04.2016 22:05-2Нет. Вы говорите о линках (каких бы то ни было) в файловой системе, а я о симлинках Object Manager'а. Ведь по идее файловая система — это объекты в пространстве OM, нет? И симлинки там были (например, DOSовский симлинк 'C:', который указывает на '\Devices\HardDiskVolume0' с очень старых времен. С NT4 как минимум.
khim
05.04.2016 22:39-1Файловая система — это файловая система. Существование Object Manager'а — это деталь реализации которая меня волновать не должна. Также как и запрет на использование всяких букв (ну там ":", "\") в именах файлов. Какой к бесу Object Manager если мы обсуждаем запуск Linux программ???
Впрочем с ограничениями на именование ядро NT вроде всегда сравлялось, это ограничение чисто Win32 API. А вот симлинки… интересно насколько глубоко у них это ограничение сидит…MacIn
05.04.2016 23:59Какой к бесу Object Manager если мы обсуждаем запуск Linux программ???
Обычный. Это предположение о том, почему есть ограничение. При чем тут Linux программы, если мы обсуждаем поведение симлинка в Windows? Это ограничение — указание типа «на том конце» — оно существует независимо от того, будем мы Linux программы запускать или нет.
это деталь реализации которая меня волновать не должна
Я и не говорю, будто должна. Я говорю, что там тоже есть симлинки, 100 лет как.
Файловая система — это файловая система.
Это замечательное наблюдение. Особенно если вспомнить про proc, например, да? Или про /dev/hd0?
Ах да, «все суть файлы». Ну, тут все суть объекты.
Zapped
01.04.2016 16:35+1и поддерживает, и создаёт
см. https://cygwin.com/cygwin-ug-net/using-cygwinenv.html/winsymlinks
ещё про поддержку символьных ссылок в Cygwin — https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks
З.Ы. следите за обновлениями...khim
01.04.2016 16:45Вы пробовали пример выше исполнить с этой опцией? Попробуйте — а потом расскажите об ощущениях. Только не забудьте про разницу между winsymlinks:native и winsymlinks:nativestrict — а то полного "экспиенса" не получите...
Zapped
01.04.2016 16:51+1вчитался в пример
понял о чём Вы
только не понял — а нахуа такое на практике? ))))) или Вы про полное соответствие стандарту?khim
01.04.2016 17:12+2Совсем такое — не очень нужно. А вот создавать симлинки "ведущие в никуда" приходится постоянно.
Очень просто: ставите вы два пакета — и в одном из них идут симлинки на файлы из второго. Причём этот пакет с симлинками пресловутый apt-get легко может поставить до второго — тогда симлинки уже будут, а файлов или каталого, на которые они указывают — ещё не будет. Это человек может догадаться что симлинк живущий в /usr/bin, скорее всего, должен указывать на файл, а симлинк в /usr/lib/perl5 — будет указывать на файл, если он оканчивается на .pm и на каталог если расширения нет. А пакетному менеджеру что делать? Весь дизайн переделывать только из-за того, что кто-то когда-то в Microsoft решил что-то там "прооптимизировать"?
P.S. Бонусные очки — за два пакета в каждом из которых есть симлинки на файлы из второго :-)
Mingun
03.04.2016 19:18А зачем тогда делали систему зависимостей? Если пакет содержит симлинки на файлы другого пакета, то он от него зависит и это обязанность разработчика этого пакета задекларировать эту зависимость. Тогда и гадать не придется. А иначе непонятно, что делать в случае, если тот второй пакет так и не поставиться.
В случае циклических зависимостей разбиваем каждый пакет на 2 — на зависимую часть от другого и на независимую. Сначала ставим независимые части, потом зависимые.khim
03.04.2016 21:53Если пакет содержит симлинки на файлы другого пакета, то он от него зависит
Совершенно необязательно. Зависимость может быть и опциональной. Скажем есть у вас символьная ссылка с libsomething.so на libsomething.so.... Установите пакет — будет вам линковка с разделяемой библиотекой, не установите — не будет.
А иначе непонятно, что делать в случае, если тот второй пакет так и не поставиться.
А ничего не делать: в стандарте всё прописано. stat вернёт ENOENT, lstat вернёт информацию про саму ссылку (если мне это для чего-то нужно).
Если же между пакетами циклическая зависимость — ну тогда пакетный менеджер должен разрулить всё и обеспечить транзакционность.
В случае циклических зависимостей разбиваем каждый пакет на 2 — на зависимую часть от другого и на независимую. Сначала ставим независимые части, потом зависимые.
Ну то есть как я предполагал: переделать дизайн всей системы. Спасибо, но… спасибо не надо. Мне лень этим заниматься — это у Microsoft'а должна болеть голова о том, как обеспечить поддержку стандарта, а не у меня — о том как поддержать это глючное поделие.
Если Microsoft не решит эту (и кучу других подобных) проблем, то я боюсь разработчики будут относиться к этим багрепортам так же, как относятся к багрепортам с систем со всякими nVidia'вскими драйверами: просить проверить на нормальной системе — а потом уже жаловаться.
Собственно так же, как они сейчас реагируют на жалобы на то, что что-то не работает под CygWin'ом или MinGW.Mingun
03.04.2016 23:10Мне все же кажется, что стандарт описывает нехитрую ситуация — что делать, если структура попортилась и символьная ссылка стала указывать в никуда. Завязываться на это — не очень хорошая идея, я бы сказал. Даже если она стабильна и десятки лет живет, иначе, как костыль это не воспринимается. Разве в этом стандарте сказано, что можно/нельзя создавать заведомо некорректные ссылки?
Опциональные зависимости, завязанные на таких особенностях, это, конечно, остроумно, но вряд ли мудро. Что ни говори, а зависимость — это зависимость. И управляться она должна пакетным менеджером. Нужна зависимость одной библиотеки от другой библиотеки — ставим пакет, зависящий от обеих библиотек. Это вроде бы и есть Unix-way, разве нет?khim
04.04.2016 14:01Разве в этом стандарте сказано, что можно/нельзя создавать заведомо некорректные ссылки?
Именно так и сказано. Английским по байтам: the file named by the path1 argument need not exist when the link is created.
Это вроде бы и есть Unix-way, разве нет?
Давайте не рассусоливать про Unix-way, а? Скажу только что пакетные менеджеры — это довольно-таки позднее изобретение в мире Unix и завязываться на их существование — не стоит.
MacIn
05.04.2016 22:10если структура попортилась и символьная ссылка стала указывать в никуда
Не просто попортилась. Скажем, сетевой лаг, отключение.
Mingun
03.04.2016 19:19А что, на линуксовых машинах симлинки на FAT-флешках работают?
khim
03.04.2016 21:54Нет. Хотите разрабатывать на флешке — отформатируйте в ext3.
Но так как жалоб на это немного, то следует признать что эра флешек, в общем, прошла: для переноса информации их ещё используют иногда, но программы туда не ставят и разработку не ведут.Mingun
03.04.2016 23:12Вообще, я несколько прозрачно намекал на то, что аргумент "потому что на флешках используется FAT" в том, почему cygwin не использует родные средства винды для символических ссылок, выглядит натянутым. Есть родные средства — используй их по умолчанию, а не пытайся сделать костыльно, но чтобы у всех работало. Путь костыли включают те, кому надо, чтобы и на FAT работало.
khim
04.04.2016 14:03С этим я согласен. Если бы родные средства были — вопросов бы не было. Но их нет. Вернее они есть — но не такие, какие нужны.
Stamerlan
03.04.2016 17:41Потому что в качестве ФС может быть FAT. Если установить переменную $CYGWIN в winsymlinks:native, то будут создаваться windows-симлинки
khim
03.04.2016 21:57К сожалению главная проблема — даже не в FAT'е. На FAT'е хардлинки, к примеру, тоже не работают — и для этого у CygWin'а нет никаких опций. И даже winsymlinks:native не всегда будет создавать нативные симлинки. Я выше говорил почему. Потому что симлинки в Windows ущербные, увы.
MacIn
05.04.2016 22:16Это не ущербность. На POSIX свет клином не сошелся, чтобы несоответствие ему объявлять ущербностью.
khim
05.04.2016 22:36В статье про интеграцию подсистемы Linux — это несомненная ущербность. В тех случаях когда POSIX делает одно, а Linux другое — ещё можно о чём-то говорить, если же они «сходятся во мнении», то вопрос исчерпан: либо ты делаешь по стандарту — либо «это глючное поделие мне и даром не нужно».
Пока такое ощущение, что вся это подсистема выглядит как dog and pony show, уж извините.MacIn
06.04.2016 00:07А вы знаете, как оно будет работать в POSIX под Windows в рамках данного проекта? Я-то думал, мы существующее положение дел в NT/Win32 обсуждаем. Может, добавят какой костыль, может снимут это ограничение — чего шкуру неубитого медведя-то делить?
chupasaurus
31.03.2016 13:27Сделали ещё в Vista/2008.
Lirein
31.03.2016 14:50+4Я их ещё с четвёртой NT помню.
vladon
31.03.2016 22:28+3В четвёртой NT были только хардлинки, симлинки появились начиная с Windows 2000 (NTFS 3.0)
MeG
03.04.2016 17:41В NT4.0 (NTFS4) были реализованы только Hard Links ( «жёсткие» ссылки, как в *nix ).
В 2000-ом (NTFS5) добавили поддержку Junction Points (аналог символических ссылок, но только для папок).
А вот уже в Vista (NTFS5) появились полноценные Symbolic Links.
vladon
31.03.2016 22:27это фича NTFS ещё с NTFS 3.0 (на каталоги), т.е. с Windows 2000
с 3.1 — на любые объекты, т.е. с XP
Lsh
31.03.2016 13:02+9Хм… А у файлов теперь будет executable bit или будет bash.exe? =)
khim
01.04.2016 00:03+3Вы не поверите, но в Windows уже есть executable bit — причём давно. Особенно смешно наблюдать лицо человека пытающегося запустить файл на котором такого бита нет. Копируешь — запускается. Оригинал — ни в какую.
Athari
02.04.2016 01:44+1Ссылку на доки можно?
khim
02.04.2016 04:43Какие нафиг "ссылки на доки"? Правой кнопкой щёлкните по любому файлу и посмотрите что у вас окошке с правами доступа написано. Или вы про Win 32 API? Тогда — FILE_EXECUTE, 6й бит, описан в WinNT.h ...
none7
03.04.2016 17:40Он там давно есть. Смотрите в глубине вкладки безопасности атрибут «траверс папок / выполнение файлов». Если снять галочку, то ни .exe ни .bat файлы запускаться не будут. Файлов без расширений это скорее всего тоже касается. В прочем сомнительно, что NTFS сможет не лагать храня индивидуальные правила безопасности для каждого файла.
tumikosha
31.03.2016 13:13-17Недавно была новость про убийство одного из авторов Ubuntu кажется. Нет ли тут связи?
SamDark
31.03.2016 13:36+2Debian. Нет.
Ununtrium
31.03.2016 14:37+3… и не выйграл, а проиграл.
Meklon
31.03.2016 18:58+8Просто интересно, так как часто вижу. Я без претензий. Вы реально произносите слово как выЙграл?
mukizu
31.03.2016 22:35+1Вы так говорите, будто произносите выИграл ;)
MacIn
31.03.2016 22:42+6А как надо?
mukizu
31.03.2016 22:49+1Ну, везде где я жил, люди как правило таки произносят через «и» краткое, ровно также как и молоко произносят через «а».
Так или иначе — сарказм был на тему того, что вопрос не очень корректный — не все читается как пишется.
maxshopen
01.04.2016 02:49Забавно, что все кого я знаю говорят выИграл. Но правильно — выЙграл, хотя первый вариант тоже допустим. Я сам только сейчас об этом узнал ))
http://new.gramota.ru/spravka/buro/search-answer?s=283580MacIn
01.04.2016 03:33Но правильно — выЙграл,
Такого по ссылке не указано. Сказано, что это произношение — предпочтительное.maxshopen
01.04.2016 04:41Ну я лично исхожу что предпочтительно — это более правильно. А так то да, можно и в[ы]грать
toxicdream
01.04.2016 08:23+1Не путайте написание и произношение.
Пишем "выиграл", читаем (предпочтительное произношение) "выйграл".maxshopen
01.04.2016 21:18Я говорил исключительно только про произношение, поэтому даже теоретически не мог ничего попутать
rprokop
01.04.2016 15:11+1И с ударением на "й"?..
43 года живу на свете, вживую ни разу не слышал "выйграл", только в комментариях читаю.
Ununtrium
07.04.2016 15:47+1Ого, даже не подозревал что тут такое обсуждение :) Ну лень было спеллчекер включать, простите. Да, если интересно, «выиграл» произношу как «выйграл».
Ununtrium
31.03.2016 14:43-10Кто-нибудь объяснит, с чего тут кипятком писать? Вау, теперь grep на виндовсе можно использовать.
petro25
31.03.2016 20:34grep, sed и awk + регулярные выражения — реально мощь.
Например можно будет парсить логи и т.д.
Сейчас я на Windows не знаю аналогов для grep, sed и awk.
navion
31.03.2016 22:08+1PowerShell такое умеет. Синтаксис другой и не всегда компактный, зато со строками можно работать как с объектами:
https://blogs.msdn.microsoft.com/zainnab/2007/07/08/grep-and-sed-with-powershell/
http://windows-powershell-scripts.blogspot.com/2009/06/awk-equivalent-in-windows-powershell.html
fornit1917
03.04.2016 17:41Лично меня это новость радует, т.к. возможно для большинства моих задач станут не нужны vagrant+vbox, которые я сейчас активно использую. Можно будет обходиться «родными» средствами винды, которые, вероятно, будут работать пошустрее чем vagrant+vbox. А если там еще и docker полноценно будет работать, то вообще красота.
dvserg
31.03.2016 16:32Про 1 апреля уже было?
cold147
31.03.2016 18:33+1Не былоТолько от вас
Krey
31.03.2016 19:06+1И каково теперь будет называть OS GNU/Linux просто линуксом в то время как сам линукс там физически отсутствует. Звучит дико уже в этой статье. Столман, привет.
MacIn
31.03.2016 20:49+6Почему упорно называется "Windows subsystem for Linux", если это Linux subsystem for Windows?
lxss.sys — это не LinuX SubSystem ли?
Halt
04.04.2016 14:13+1Наверное по той же логике, почему в директории WOW64 лежат 32-битные файлы.
MacIn
05.04.2016 22:18Ну это-то как раз имеет смысл — system32 зарезервированное имя. А xyz subsystem for Windows, где xyz скажем OS/2 или что-то там еще, использовалось с самого основания системы. Тот же Win32 ss.
Halt
06.04.2016 07:20Никакого смысла в этом нет. Это полный бред.
- Во-первых, доступ к системным директориям должен происходить не по абсолютному пути, а с помощью системного вызова.
- Во-вторых, старые 32-битные приложения которые ничего не знают о 64 битах полезут в system32 и внезапно обнаружат там 64 битные файлы.
- В-третьих, был шанс нормально разграничить старое и новое, когда 64 бита только появились на винде, но они это не сделали. Теперешняя каша никуда уже не денется.
Неужели было сложно сделать как в *nix? /usr/lib32 (system32) для 32-битных, /usr/lib64 (system64) для 64.khim
06.04.2016 14:15Во-вторых, старые 32-битные приложения которые ничего не знают о 64 битах полезут в system32 и внезапно обнаружат там 64 битные файлы.
Не обнаружат.
Во-первых, доступ к системным директориям должен происходить не по абсолютному пути, а с помощью системного вызова.
В идеальном мире — да. Но Windows живёт не в идеальном мире, а в реальном, с реальными программами. Отсюда и все эти редиректоры и LLP64 режим (aka IL32P64 — когда даже long'и в 64 битном режиме 32 битные) и прочее.
Неужели было сложно сделать как в *nix? /usr/lib32 (system32) для 32-битных, /usr/lib64 (system64) для 64.
А как потом заставить пользователей это покупать? Если у них программы не работают и/или падают после перекомпиляции? В мире *nix у людей не было выбора: на серверах им нужно было как-то работать с системами >4GiB, так что пришлось «жрать кактус», а Windows только-только перебралась на 64 бита! Чуть не половина пользователей до сих пор используют 32-битные системы!
Sergey6661313
01.04.2016 08:38Ну почему именно ubuntu? мне не нужно большинство из десятков тысяч бинарных пакетов в архивах Ubuntu. Будет ли возможность организовать себе archlinux, gentoo, nixos и т.п?
Лучше б организовали windows on windows. Такой чтобы можно было нативно запускать изолированные windows программы.VolCh
01.04.2016 09:15+3По некоторым оценкам Ubuntu самый популярный дистрибутив в мире и по подавляющем большинству входит в тройку лидеров (все "родственники" — Debian, Ubuntu, Mint), так что выбор разумный.
И, насколько я понимаю, Ubuntu в Windows является лишь предустановленным юзерспейсом из Ubuntu над подсистемой LinuxOnWindows, совместимой по API с Linux kernel API и работающей поверх ядра Windows NT (так же как поверх него работает подсистема WinAPI и работали (?) подсистемы Posix и OS/2 ). И теоретически никто не мешает вам поставить свой юзерспейс из любого другого дистрибутива, только патчи ядра не сможете применять из него, довольствуясь примененными из Ubuntu. Ну и, возможно, реакции MS на баги LoW под другими юзерспейсами не будет вообще и уж точно приоритет будет меньше.
Windows Server 2016 будет поддерживать три вида контейнеров: Windows Server Containers (шаринг ядра для WinAPI контейнеров), Hyper-V Containers (каждый со своим ядром) и Docker (тут, судя по всему, шаринг ядра для WinAPI и Linux kernel API контейнеров) — подробнее https://msdn.microsoft.com/en-us/virtualization/windowscontainers/containers_welcome. Что из этого будет (и будет ли) в десктопной винде из коробки и что можно будет прикрутить ручками (скорее всего с нарушением лицензии), если не будет, пока не ясно.Lirein
01.04.2016 12:31В Windows 10, так то Device Guard есть, но требует поддержку SLAT и VT-d от оборудования. Позволяет запускать отдельные приложения в песочнице.
Sergey6661313
02.04.2016 14:22никак не пойму почему везде при поиске пишут «Введение в Device Guard», «Обзор Device Guard», но нигде нет как его запустить?
Скинте пример как с его помощью запустить например notepad.exe?navion
02.04.2016 15:19Тут вроде было.
Sergey6661313
02.04.2016 18:32дык это никакая не песочница… это просто система доверенных/недоверенных программ… От мусора внутри программы это не спасёт потому что я будут вынужден для запуска этой программы один фиг сделать её доверенной… херня короче.
lightman
02.04.2016 08:16Лично я очень рад. Для меня это весомейшая (и единственная) причина переходить с 7 на 10. Стабильный виндовый GUI + мощная никсовая консоль — о таком можно было только мечтать.
Но вызывают опасения кодировки. Виндовая консоль и в 2016 году продолжает влачить существование с древней досовоской однобайтовой OEM кодировкой. Будет очень грустно если при переходе в bash, там будет выставляться она же (вместо славного UTF-8).
Aeliot
03.04.2016 17:40-4Видимо испугались, что разработчики массово уходят (ушли) на linux. Сейчас по многим вопросам мануалов под винду уже не найти (очень сложно найти). А где разработчики, туда и пользователи подтягиваются. Добровольно или принудительно.
Потому и бьют по одному из главных вопросов: «А как это установить/запустить на винде?»
gaidukav
03.04.2016 17:40+1Если там в нативном режиме заработает связка Apache и mod_perl — мои аплодисменты!
А то уже надоело искать совместимые версии Apache for Win32/64 + Strawberry Perl + mod_perl.
x_sourer
03.04.2016 17:41Ситуация заставляет меняться. И зарабатывать не на ОС и базовом ПО, а на сервисах. Акценты развития смещаются, иначе можно потерять весь рынок…
Manulable
03.04.2016 17:41Отлично Майкрософт! Даешь андроид подсистему в Windows Phone?!
khim
03.04.2016 22:14Вы почти угадали. То, что они сейчас выкатили — это ошмётки от попытки сделать именно это.
Кто-то в руководстве Microsoft осознал, что таким макаром Windows может последовать по стопам OS/2 и обрезал проект так, чтобы минимизировать потенциальную опасность.
VerdOrr
03.04.2016 17:42Очень логичный и вписывающийся в общую стратегию (расширение и упрощение средств кроссплатформенной разработки) шаг чтобы удержать адептов Visual Studio от перехода на альтернативные платформы.
FlarGargoyl
03.04.2016 17:42Судя по видеотрансляции, они и правда реализовали системные вызовы от юзермода убунты через виндовое ядро. Юзермод убунты предоставлен самим Каноникал, и не переделывался мелкомягкими. Есть пока пробелы, т.к. реализовано далеко не все, по крайней мере пока, но работы ведутся.
Лично тоже хотел бы видеть поддержку EXT-и иже с ним файловых систем на уровне ядра. Пожалуй, пора сдуть пыль с ноута с подпиской на инсайдер превью.Lsh
04.04.2016 00:33Пожалуй, пора сдуть пыль с ноута с подпиской на инсайдер превью.
А сейчас еще можно бесплатно получить инсайдер превью или нужно иметь лицензию на винду?FlarGargoyl
04.04.2016 08:57https://insider.windows.com/ — вроде, можно и без оной. Стоит учесть, если захочется отказаться от превью-билдов, возможно, придется реинсталлить ось. Подписался на "галимом" ноуте ещё в прошлый четверг, ждём-с когда прилетит.
FlarGargoyl
05.04.2016 13:28ISO-образы с новым релизом доступны
https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewiso?OCID=WIP_r_14_Body_ISOS
Разумеется. подписаться для доступа надо. Но можно тестить на виртуалке итд.ExileeD
05.04.2016 14:34Этот релиз не включается в себя bash shell
FlarGargoyl
05.04.2016 14:37да, я «промахнулся» кнопкой «ответить» — хотел воткнуть в предыдущую цепочку. Можно не свою ось обновлять или лепить отдельную, а сразу «воткнуть» нужный превью билд. Это я хотел сказать :)
ExileeD
07.04.2016 18:33Релиз с bash shell вышел. Первое что заметил не стартуют приложение которые взаимодействуют с сокетом.
terryP
Интересно, а как там решается вопрос лицензии GNU, которая запрещает линковку с закрытыми продуктами? Microsoft перепишет Linux заново или обходит это как-то по другому?
Razaz
Схожий вопрос про OSX — APPLE VIOLATING THE GPL WITH BASH ON "OS X"?
Как и в Win там просто исполняемый файл, а не линковка.
hardex
Скорее всего откроют прослойку между libc и системными вызовами винды (LXSS)
khim
Но зачем, Карл? В самом ядре английским по байтам написано: This copyright does not cover user programs that use kernel services by normal system calls — this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".
Так как у Microsoft'а драйвера есть свои, то им нужно было просто реализовать "kernel services" доступ к которым осуществляется через "normal system calls" — и всё.
dartraiden
Они не линкуют. Они написали транслятор. Запускаться будут уже собранные бинарники из состава Ubuntu (на первых порах).
MamOn
Да, похоже что настал тот самый момент, встречайте: GNU/Windows.
pda0
В GPL есть оговорка, позволяющая программе линковаться с системными библиотеками, даже если они закрыты. Поскольку это теперь часть системы, то нарушения лицензии не происходит.