Comments 174
Интересно, а как там решается вопрос лицензии GNU, которая запрещает линковку с закрытыми продуктами? Microsoft перепишет Linux заново или обходит это как-то по другому?
Схожий вопрос про OSX — APPLE VIOLATING THE GPL WITH BASH ON "OS X"?
Как и в Win там просто исполняемый файл, а не линковка.
Как и в Win там просто исполняемый файл, а не линковка.
Скорее всего откроют прослойку между libc и системными вызовами винды (LXSS)
Но зачем, Карл? В самом ядре английским по байтам написано: 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" — и всё.
Так как у Microsoft'а драйвера есть свои, то им нужно было просто реализовать "kernel services" доступ к которым осуществляется через "normal system calls" — и всё.
Они не линкуют. Они написали транслятор. Запускаться будут уже собранные бинарники из состава Ubuntu (на первых порах).
Да, похоже что настал тот самый момент, встречайте: GNU/Windows.
В GPL есть оговорка, позволяющая программе линковаться с системными библиотеками, даже если они закрыты. Поскольку это теперь часть системы, то нарушения лицензии не происходит.
Круто. А когда это станет доступно?
Вроде как летом со следующим Annual Update для 10. Вроде так услышал на презентации.
А для семерочки будет доступно?
Конечно! Надо только до 10 сначала обновить систему.
Ну я вообще-то вполне серьезно спрашивал) Или там такая сильная завязка на десятку, что оно просто не будет работать под ранними версиями Винды?
Думаю просто не будут тратить ресурсы, на поддержку старой версии. Да и ядро скорее всего менялось в 8, затем в 8.1, затем в 10. А так как там идет трансляция сисколов, то это еще уменьшает шансы.
Я не работаю в Microsoft, но скорее всего дела обстоят так:
Т.е. обновление с 7 до 10 не шутка. Это вполне серьезный ответ. И заметьте, что пока еще это бесплатно. Как будет потом — не известно.
- для того чтобы новые функции появились в ОС, ее надо модифицировать. Т.е. выпустить новую версию ОС.
- для того, чтобы эти же функции появились в старой ОС, надо внести в нее те же модификации. т.е. надо обновить ОС.
Т.е. обновление с 7 до 10 не шутка. Это вполне серьезный ответ. И заметьте, что пока еще это бесплатно. Как будет потом — не известно.
Думаю что всё проще: там нужны разные модификации в ядре, а учитывая политику Microsoft никто их для Windows 7-8 делать не собирается, вот и всё.
К примеру довольно большая часть вещей делается в Linux через фьютексы. В Windows8 они есть, а в Windows7 — их нет. Можно ли эту функцию "вынуть" из Windows8 и перенести в Windows7? Да, разумеется — но кто будет это делать?
К примеру довольно большая часть вещей делается в Linux через фьютексы. В Windows8 они есть, а в Windows7 — их нет. Можно ли эту функцию "вынуть" из Windows8 и перенести в Windows7? Да, разумеется — но кто будет это делать?
Для семерочки будет доступно еще одно обновление с окошком «Get Windows 10».
При установке git под винду bash вроде давным давно ставится
Первое апреля вроде как завтра?
Т.е. это не аналог coLinux и полноценного ядра тут нету? Следовательно, например, примонтировать ext4 не получится?
Да и, к.м.к., будут проблемы с совместимостью, т.к. не будут же они все системные вызовы реализовывать.
Да и, к.м.к., будут проблемы с совместимостью, т.к. не будут же они все системные вызовы реализовывать.
"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.
Тынц
Тынц
А что такого сложного в этих "системных вызовах"? Обычные функции, не?
Сдается мне, написать драйвер ext4 под NT проще, чем драйвер NTFS под Linux.
Интересно, а какие могут быть сценарии использования этого?
Для заточенных под Linux приложений, например git.
TensorFlow/Theano/что там еще используют для машинного обучения.
Для меня это будет мега удобно. Я привык к bash. Но ставить дектопный linux я не хочу. Буду нативно запускать python, docker, вместо костылей типа cygwin
Собирать под виндой расширения Python, требующие всякие libastral-dev без возни с MinGW, например.
Может быть Microsoft чувствует, что теряет разработчиков прикладного софта? Многие переходят на мак или линукс. И таким образом они надеются сделать windows более привлекательным.
А символические ссылки они сделали? без них никакого толку.
Симлинки там и так давно есть
В смысле "сделали"? В ntfs cимлинки сто лет в обед.
Когда я последний раз пользовался cygwin там были текстовые файлы вместо настоящих симлинков. Вот я и спросил все ли хорошо сейчас с этим.
mklink, зачем там cygwin?
Я о том что если там всегда была хорошая совместимая поддержка символических ссылок, зачем тогда разработчикам cygwin пришлось изобретать велосипед и делать свою реализацию?
В NT-based системах — да, прекрасная поддержка. А в Win-9x/Me — только FAT, которая симлинков не имеет. Так что NTFS начала широко распространяться только после 2000 года (да и то сколько лет понадобилось, чтобы сначала 2000, а потом XP вытеснили 98SE) — когда cygwin уже давным-давно существовал. И до сих пор на флешках FAT используется.
Прекрасная поддержка, да? Так сделать можно?
/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$
Это вообще как — создавать линк между несуществующими сущностями?
А вот так: 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 создать можно — но нужно заранее знать: будет эта сущность файлом или подкаталогом!
Вполне себе явное требование, прописанное в стандарте. Но проблема не в этом. Симлинк на "несуществующую сущность" в Windows создать можно — но нужно заранее знать: будет эта сущность файлом или подкаталогом!
Это ограничение скорее всего вытекает из глобальной системы объектов.
Нет, это ограничение проистекает из того, что когда симлинки добавлялись в Windows, то считалось что "мир POSIX" побеждён раз и навсегда и на совместимость с ним "можно забить".
Это слишком частное ограничение для таких глобальных решений.
Дополню — я имею в виду, что symlink в NT — вещь более старая, чем те, о которых мы говорим. И файловый symlink ложится на систему объектов как частный случай (наверно).
Вы не путаете Reparse Pointы (доступные с незапамятных времён) и символьные ссылки (появившиеся в 2006м)?
А можно для чайников, в чем разница?
Отличие в том на каком уровне всё интерпретируется.
Reparse Point — это ошмёток от идеи создания "модульной фаловой системы": теоретически можно заставить обрабатывать каталог в файловой системе как угодно с помощью инсталляции драйвера, практически — есть только один драйвер, установленный по умолчанию, который используется как замена символьным ссылкам. Как несложно догадаться из описания — всё это происходит на уровне NTFS, обрабытывается локально и до уровня CIFS не доходит (то есть если на сервере есть Reparse Pointы, то клиенты про это никак узнать не могут). Однако в силу построения всей конструкции на файлы Reparse Point указывать не могут (драйвер контролирует что "внутри" Reparse Point'а) и на другие машины в сети — тоже (драйвер находится "ниже" уровня CIFS).
Symbolic Links — это специальные объекты файловой системы, никакой магии, просто строчка "сюда не ходи, ходи туда", обрабатываются в ядре — но уже на клиенте и, соответственно, могут быть на оном клиенте увидены, а также могут указывать на другие машины в сети. В связи с такой нелокальностью для их создания нужны специальные права, по умолчанию доступные только админу (что есть IMNSO, бред). Могут также указывать на файлы, не только на каталоги — но "чтоб жизнь мёдом не казалась" это нужно знать в момент создания символической ссылки (что есть IMNSHO ещё больший бред: если вы уже добавляете сущность из POSIX, то зачем ломать всем известную семантику?).
Как-то примерно так.
Reparse Point — это ошмёток от идеи создания "модульной фаловой системы": теоретически можно заставить обрабатывать каталог в файловой системе как угодно с помощью инсталляции драйвера, практически — есть только один драйвер, установленный по умолчанию, который используется как замена символьным ссылкам. Как несложно догадаться из описания — всё это происходит на уровне NTFS, обрабытывается локально и до уровня CIFS не доходит (то есть если на сервере есть Reparse Pointы, то клиенты про это никак узнать не могут). Однако в силу построения всей конструкции на файлы Reparse Point указывать не могут (драйвер контролирует что "внутри" Reparse Point'а) и на другие машины в сети — тоже (драйвер находится "ниже" уровня CIFS).
Symbolic Links — это специальные объекты файловой системы, никакой магии, просто строчка "сюда не ходи, ходи туда", обрабатываются в ядре — но уже на клиенте и, соответственно, могут быть на оном клиенте увидены, а также могут указывать на другие машины в сети. В связи с такой нелокальностью для их создания нужны специальные права, по умолчанию доступные только админу (что есть IMNSO, бред). Могут также указывать на файлы, не только на каталоги — но "чтоб жизнь мёдом не казалась" это нужно знать в момент создания символической ссылки (что есть IMNSHO ещё больший бред: если вы уже добавляете сущность из POSIX, то зачем ломать всем известную семантику?).
Как-то примерно так.
но «чтоб жизнь мёдом не казалась» это нужно знать в момент создания символической ссылки (что есть IMNSHO ещё больший бред: если вы уже добавляете сущность из POSIX, то зачем ломать всем известную семантику?).
Давайте попытаемся объективно прикинуть, почему это так. Для работы с файлами и каталогами будут использоваться разные API, значит для работы с сущностью нам надо знать, что это — директория или файл. Возможно, это связано и с разными методами синхронизации данных (размеры файлов и пр) в условиях сети и возможных отключений.
Это, кстати, по поводу вашей проблемы с пакетным менеджером — вот создали мы симлинк на \abc\def, как ОС должна обрабатывать def — как файл? Или как директорию? А если на том конце def'а нет и мы это проверить не можем?
Симлинки сами по себе не обрабатываются. Никак. Вообще. Это просто строка.
Будет обращение — тогда и разберётесь.
Будет обращение — тогда и разберётесь.
Тяжело, да. Попробую еще раз:
При обращении. Да.
При обращении. Да.
симлинк на \abc\def, как ОС должна обрабатывать def — как файл? Или как директорию? А если на том конце def'а нет и мы это проверить не можем?
Любой симлинк должен иметь возможность указывать в «пустоту» (на удалённый объект) и ОС должна корректно это обрабатывать.
Какую-такую операцию вы пытаетесь осуществить, для которой важно знать — должен быть объект «с того конца» файлом или каталогом, но при этом не важно — существует он или нет?
А если на том конце def'а нет и мы это проверить не можем?Вот с этого, пожалуй, стоит и начать.
Какую-такую операцию вы пытаетесь осуществить, для которой важно знать — должен быть объект «с того конца» файлом или каталогом, но при этом не важно — существует он или нет?
Мне совершенно наплевать на ваши «объектные менеджеры», «синхронизацию данных» и прочее. Симлинк — это просто синоним другого объекта, ни больше, ни меньше. Хотите заводить свои, особенные, структуры данных — заводите. Но зачем ломать известную сементику-то?
P.S. Напомнить за что в своё время Sun засудил Microsoft, нет? Вот и здесь — та же история. Только в это раз она «стреляет» в обратную сторону: пока в Windows не будет, в частности, нормальных симлинков — говорить о какой-либо совместимости с Linux нельзя. И есть у меня подозрением что подобным «гитик» там… есть. Для «вау какая фенечка» на выставке — годится, для работы — нет.
P.S. Напомнить за что в своё время Sun засудил Microsoft, нет? Вот и здесь — та же история. Только в это раз она «стреляет» в обратную сторону: пока в Windows не будет, в частности, нормальных симлинков — говорить о какой-либо совместимости с Linux нельзя. И есть у меня подозрением что подобным «гитик» там… есть. Для «вау какая фенечка» на выставке — годится, для работы — нет.
Мне совершенно наплевать на ваши «объектные менеджеры», «синхронизацию данных» и прочее
А мне — плевать на ваше видение «правильного» симлинка. Это просто предположение о том, почему оно так устроено.
Но зачем ломать известную сементику-то?
С какого-то перепугу вы решили, что все кругом, в том числе не в Linux системах должны реализовывать некоторую сущность 1 в 1 как в Linux.
Нет. Вы говорите о линках (каких бы то ни было) в файловой системе, а я о симлинках Object Manager'а. Ведь по идее файловая система — это объекты в пространстве OM, нет? И симлинки там были (например, DOSовский симлинк 'C:', который указывает на '\Devices\HardDiskVolume0' с очень старых времен. С NT4 как минимум.
Файловая система — это файловая система. Существование Object Manager'а — это деталь реализации которая меня волновать не должна. Также как и запрет на использование всяких букв (ну там ":", "\") в именах файлов. Какой к бесу Object Manager если мы обсуждаем запуск Linux программ???
Впрочем с ограничениями на именование ядро NT вроде всегда сравлялось, это ограничение чисто Win32 API. А вот симлинки… интересно насколько глубоко у них это ограничение сидит…
Впрочем с ограничениями на именование ядро NT вроде всегда сравлялось, это ограничение чисто Win32 API. А вот симлинки… интересно насколько глубоко у них это ограничение сидит…
Какой к бесу Object Manager если мы обсуждаем запуск Linux программ???
Обычный. Это предположение о том, почему есть ограничение. При чем тут Linux программы, если мы обсуждаем поведение симлинка в Windows? Это ограничение — указание типа «на том конце» — оно существует независимо от того, будем мы Linux программы запускать или нет.
это деталь реализации которая меня волновать не должна
Я и не говорю, будто должна. Я говорю, что там тоже есть симлинки, 100 лет как.
Файловая система — это файловая система.
Это замечательное наблюдение. Особенно если вспомнить про proc, например, да? Или про /dev/hd0?
Ах да, «все суть файлы». Ну, тут все суть объекты.
и поддерживает, и создаёт
см. https://cygwin.com/cygwin-ug-net/using-cygwinenv.html
ещё про поддержку символьных ссылок в Cygwin — https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks
З.Ы. следите за обновлениями...
см. https://cygwin.com/cygwin-ug-net/using-cygwinenv.html
/winsymlinks
ещё про поддержку символьных ссылок в Cygwin — https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks
З.Ы. следите за обновлениями...
Вы пробовали пример выше исполнить с этой опцией? Попробуйте — а потом расскажите об ощущениях. Только не забудьте про разницу между winsymlinks:native и winsymlinks:nativestrict — а то полного "экспиенса" не получите...
вчитался в пример
понял о чём Вы
только не понял — а нахуа такое на практике? ))))) или Вы про полное соответствие стандарту?
понял о чём Вы
только не понял — а нахуа такое на практике? ))))) или Вы про полное соответствие стандарту?
Совсем такое — не очень нужно. А вот создавать симлинки "ведущие в никуда" приходится постоянно.
Очень просто: ставите вы два пакета — и в одном из них идут симлинки на файлы из второго. Причём этот пакет с симлинками пресловутый apt-get легко может поставить до второго — тогда симлинки уже будут, а файлов или каталого, на которые они указывают — ещё не будет. Это человек может догадаться что симлинк живущий в /usr/bin, скорее всего, должен указывать на файл, а симлинк в /usr/lib/perl5 — будет указывать на файл, если он оканчивается на .pm и на каталог если расширения нет. А пакетному менеджеру что делать? Весь дизайн переделывать только из-за того, что кто-то когда-то в Microsoft решил что-то там "прооптимизировать"?
P.S. Бонусные очки — за два пакета в каждом из которых есть симлинки на файлы из второго :-)
Очень просто: ставите вы два пакета — и в одном из них идут симлинки на файлы из второго. Причём этот пакет с симлинками пресловутый apt-get легко может поставить до второго — тогда симлинки уже будут, а файлов или каталого, на которые они указывают — ещё не будет. Это человек может догадаться что симлинк живущий в /usr/bin, скорее всего, должен указывать на файл, а симлинк в /usr/lib/perl5 — будет указывать на файл, если он оканчивается на .pm и на каталог если расширения нет. А пакетному менеджеру что делать? Весь дизайн переделывать только из-за того, что кто-то когда-то в Microsoft решил что-то там "прооптимизировать"?
P.S. Бонусные очки — за два пакета в каждом из которых есть симлинки на файлы из второго :-)
А зачем тогда делали систему зависимостей? Если пакет содержит симлинки на файлы другого пакета, то он от него зависит и это обязанность разработчика этого пакета задекларировать эту зависимость. Тогда и гадать не придется. А иначе непонятно, что делать в случае, если тот второй пакет так и не поставиться.
В случае циклических зависимостей разбиваем каждый пакет на 2 — на зависимую часть от другого и на независимую. Сначала ставим независимые части, потом зависимые.
В случае циклических зависимостей разбиваем каждый пакет на 2 — на зависимую часть от другого и на независимую. Сначала ставим независимые части, потом зависимые.
Если пакет содержит симлинки на файлы другого пакета, то он от него зависит
Совершенно необязательно. Зависимость может быть и опциональной. Скажем есть у вас символьная ссылка с libsomething.so на libsomething.so.... Установите пакет — будет вам линковка с разделяемой библиотекой, не установите — не будет.
А иначе непонятно, что делать в случае, если тот второй пакет так и не поставиться.А ничего не делать: в стандарте всё прописано. stat вернёт ENOENT, lstat вернёт информацию про саму ссылку (если мне это для чего-то нужно).
Если же между пакетами циклическая зависимость — ну тогда пакетный менеджер должен разрулить всё и обеспечить транзакционность.
В случае циклических зависимостей разбиваем каждый пакет на 2 — на зависимую часть от другого и на независимую. Сначала ставим независимые части, потом зависимые.Ну то есть как я предполагал: переделать дизайн всей системы. Спасибо, но… спасибо не надо. Мне лень этим заниматься — это у Microsoft'а должна болеть голова о том, как обеспечить поддержку стандарта, а не у меня — о том как поддержать это глючное поделие.
Если Microsoft не решит эту (и кучу других подобных) проблем, то я боюсь разработчики будут относиться к этим багрепортам так же, как относятся к багрепортам с систем со всякими nVidia'вскими драйверами: просить проверить на нормальной системе — а потом уже жаловаться.
Собственно так же, как они сейчас реагируют на жалобы на то, что что-то не работает под CygWin'ом или MinGW.
Мне все же кажется, что стандарт описывает нехитрую ситуация — что делать, если структура попортилась и символьная ссылка стала указывать в никуда. Завязываться на это — не очень хорошая идея, я бы сказал. Даже если она стабильна и десятки лет живет, иначе, как костыль это не воспринимается. Разве в этом стандарте сказано, что можно/нельзя создавать заведомо некорректные ссылки?
Опциональные зависимости, завязанные на таких особенностях, это, конечно, остроумно, но вряд ли мудро. Что ни говори, а зависимость — это зависимость. И управляться она должна пакетным менеджером. Нужна зависимость одной библиотеки от другой библиотеки — ставим пакет, зависящий от обеих библиотек. Это вроде бы и есть Unix-way, разве нет?
Опциональные зависимости, завязанные на таких особенностях, это, конечно, остроумно, но вряд ли мудро. Что ни говори, а зависимость — это зависимость. И управляться она должна пакетным менеджером. Нужна зависимость одной библиотеки от другой библиотеки — ставим пакет, зависящий от обеих библиотек. Это вроде бы и есть Unix-way, разве нет?
Разве в этом стандарте сказано, что можно/нельзя создавать заведомо некорректные ссылки?Именно так и сказано. Английским по байтам: the file named by the path1 argument need not exist when the link is created.
Это вроде бы и есть Unix-way, разве нет?Давайте не рассусоливать про Unix-way, а? Скажу только что пакетные менеджеры — это довольно-таки позднее изобретение в мире Unix и завязываться на их существование — не стоит.
если структура попортилась и символьная ссылка стала указывать в никуда
Не просто попортилась. Скажем, сетевой лаг, отключение.
А что, на линуксовых машинах симлинки на FAT-флешках работают?
Нет. Хотите разрабатывать на флешке — отформатируйте в ext3.
Но так как жалоб на это немного, то следует признать что эра флешек, в общем, прошла: для переноса информации их ещё используют иногда, но программы туда не ставят и разработку не ведут.
Но так как жалоб на это немного, то следует признать что эра флешек, в общем, прошла: для переноса информации их ещё используют иногда, но программы туда не ставят и разработку не ведут.
Вообще, я несколько прозрачно намекал на то, что аргумент "потому что на флешках используется FAT" в том, почему cygwin не использует родные средства винды для символических ссылок, выглядит натянутым. Есть родные средства — используй их по умолчанию, а не пытайся сделать костыльно, но чтобы у всех работало. Путь костыли включают те, кому надо, чтобы и на FAT работало.
Потому что в качестве ФС может быть FAT. Если установить переменную $CYGWIN в winsymlinks:native, то будут создаваться windows-симлинки
К сожалению главная проблема — даже не в FAT'е. На FAT'е хардлинки, к примеру, тоже не работают — и для этого у CygWin'а нет никаких опций. И даже winsymlinks:native не всегда будет создавать нативные симлинки. Я выше говорил почему. Потому что симлинки в Windows ущербные, увы.
Это не ущербность. На POSIX свет клином не сошелся, чтобы несоответствие ему объявлять ущербностью.
В статье про интеграцию подсистемы Linux — это несомненная ущербность. В тех случаях когда POSIX делает одно, а Linux другое — ещё можно о чём-то говорить, если же они «сходятся во мнении», то вопрос исчерпан: либо ты делаешь по стандарту — либо «это глючное поделие мне и даром не нужно».
Пока такое ощущение, что вся это подсистема выглядит как dog and pony show, уж извините.
Пока такое ощущение, что вся это подсистема выглядит как dog and pony show, уж извините.
да, всё хорошо
Так они уже в винде давно есть, MKLINK
Сделали ещё в Vista/2008.
UFO just landed and posted this here
В четвёртой NT были только хардлинки, симлинки появились начиная с Windows 2000 (NTFS 3.0)
В NT4.0 (NTFS4) были реализованы только Hard Links ( «жёсткие» ссылки, как в *nix ).
В 2000-ом (NTFS5) добавили поддержку Junction Points (аналог символических ссылок, но только для папок).
А вот уже в Vista (NTFS5) появились полноценные Symbolic Links.
В 2000-ом (NTFS5) добавили поддержку Junction Points (аналог символических ссылок, но только для папок).
А вот уже в Vista (NTFS5) появились полноценные Symbolic Links.
это фича NTFS ещё с NTFS 3.0 (на каталоги), т.е. с Windows 2000
с 3.1 — на любые объекты, т.е. с XP
с 3.1 — на любые объекты, т.е. с XP
Хм… А у файлов теперь будет executable bit или будет bash.exe? =)
Вы не поверите, но в Windows уже есть executable bit — причём давно. Особенно смешно наблюдать лицо человека пытающегося запустить файл на котором такого бита нет. Копируешь — запускается. Оригинал — ни в какую.
Ссылку на доки можно?
Какие нафиг "ссылки на доки"? Правой кнопкой щёлкните по любому файлу и посмотрите что у вас окошке с правами доступа написано. Или вы про Win 32 API? Тогда — FILE_EXECUTE, 6й бит, описан в WinNT.h ...
Он там давно есть. Смотрите в глубине вкладки безопасности атрибут «траверс папок / выполнение файлов». Если снять галочку, то ни .exe ни .bat файлы запускаться не будут. Файлов без расширений это скорее всего тоже касается. В прочем сомнительно, что NTFS сможет не лагать храня индивидуальные правила безопасности для каждого файла.
С 1 апреля
Недавно была новость про убийство одного из авторов Ubuntu кажется. Нет ли тут связи?
Debian. Нет.
… и не выйграл, а проиграл.
Просто интересно, так как часто вижу. Я без претензий. Вы реально произносите слово как выЙграл?
Вы так говорите, будто произносите выИграл ;)
А как надо?
Ну, везде где я жил, люди как правило таки произносят через «и» краткое, ровно также как и молоко произносят через «а».
Так или иначе — сарказм был на тему того, что вопрос не очень корректный — не все читается как пишется.
Так или иначе — сарказм был на тему того, что вопрос не очень корректный — не все читается как пишется.
Забавно, что все кого я знаю говорят выИграл. Но правильно — выЙграл, хотя первый вариант тоже допустим. Я сам только сейчас об этом узнал ))
http://new.gramota.ru/spravka/buro/search-answer?s=283580
http://new.gramota.ru/spravka/buro/search-answer?s=283580
Ого, даже не подозревал что тут такое обсуждение :) Ну лень было спеллчекер включать, простите. Да, если интересно, «выиграл» произношу как «выйграл».
Пройграл
Кто-нибудь объяснит, с чего тут кипятком писать? Вау, теперь grep на виндовсе можно использовать.
grep, sed и awk + регулярные выражения — реально мощь.
Например можно будет парсить логи и т.д.
Сейчас я на Windows не знаю аналогов для grep, sed и awk.
Например можно будет парсить логи и т.д.
Сейчас я на Windows не знаю аналогов для grep, sed и awk.
PowerShell такое умеет. Синтаксис другой и не всегда компактный, зато со строками можно работать как с объектами:
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
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
Log parser если дело только в логах. На SQL-подобном можно писать запросы.
Лично меня это новость радует, т.к. возможно для большинства моих задач станут не нужны vagrant+vbox, которые я сейчас активно использую. Можно будет обходиться «родными» средствами винды, которые, вероятно, будут работать пошустрее чем vagrant+vbox. А если там еще и docker полноценно будет работать, то вообще красота.
Возврат к практике трёх "Е"?
Про 1 апреля уже было?
UFO just landed and posted this here
И каково теперь будет называть OS GNU/Linux просто линуксом в то время как сам линукс там физически отсутствует. Звучит дико уже в этой статье. Столман, привет.
Скоро на stackoverflow: "Как пропатчить KDE под Win10?"
Сначала сделайте порт KDE в текстовый режим!
Почему упорно называется "Windows subsystem for Linux", если это Linux subsystem for Windows?
lxss.sys — это не LinuX SubSystem ли?
lxss.sys — это не LinuX SubSystem ли?
Наверное по той же логике, почему в директории WOW64 лежат 32-битные файлы.
Ну это-то как раз имеет смысл — system32 зарезервированное имя. А xyz subsystem for Windows, где xyz скажем OS/2 или что-то там еще, использовалось с самого основания системы. Тот же Win32 ss.
Никакого смысла в этом нет. Это полный бред.
Неужели было сложно сделать как в *nix? /usr/lib32 (system32) для 32-битных, /usr/lib64 (system64) для 64.
- Во-первых, доступ к системным директориям должен происходить не по абсолютному пути, а с помощью системного вызова.
- Во-вторых, старые 32-битные приложения которые ничего не знают о 64 битах полезут в system32 и внезапно обнаружат там 64 битные файлы.
- В-третьих, был шанс нормально разграничить старое и новое, когда 64 бита только появились на винде, но они это не сделали. Теперешняя каша никуда уже не денется.
Неужели было сложно сделать как в *nix? /usr/lib32 (system32) для 32-битных, /usr/lib64 (system64) для 64.
Во-вторых, старые 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-битные системы!
Историческое событие — вот так процент Ubuntu на десктопах стал больше чем у Windows! ;)
Сначала над вами смеются, потом добавляют в качестве подсистемы,… Остается только гадать, сколько продержится Windows.
Ну почему именно ubuntu? мне не нужно большинство из десятков тысяч бинарных пакетов в архивах Ubuntu. Будет ли возможность организовать себе archlinux, gentoo, nixos и т.п?
Лучше б организовали windows on windows. Такой чтобы можно было нативно запускать изолированные windows программы.
Лучше б организовали windows on windows. Такой чтобы можно было нативно запускать изолированные windows программы.
По некоторым оценкам 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. Что из этого будет (и будет ли) в десктопной винде из коробки и что можно будет прикрутить ручками (скорее всего с нарушением лицензии), если не будет, пока не ясно.
И, насколько я понимаю, 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. Что из этого будет (и будет ли) в десктопной винде из коробки и что можно будет прикрутить ручками (скорее всего с нарушением лицензии), если не будет, пока не ясно.
UFO just landed and posted this here
никак не пойму почему везде при поиске пишут «Введение в Device Guard», «Обзор Device Guard», но нигде нет как его запустить?
Скинте пример как с его помощью запустить например notepad.exe?
Скинте пример как с его помощью запустить например notepad.exe?
Тут вроде было.
дык это никакая не песочница… это просто система доверенных/недоверенных программ… От мусора внутри программы это не спасёт потому что я будут вынужден для запуска этой программы один фиг сделать её доверенной… херня короче.
От мусора из интернета ничего не спасёт, но DeviceGuard и не предназначен для защиты домашних компьютеров. А про песочницу Lirein немного напутал — в ней живёт LSA и сама проверялка, а не приложения.
Так вроде это Microsoft App-V.
Лично я очень рад. Для меня это весомейшая (и единственная) причина переходить с 7 на 10. Стабильный виндовый GUI + мощная никсовая консоль — о таком можно было только мечтать.
Но вызывают опасения кодировки. Виндовая консоль и в 2016 году продолжает влачить существование с древней досовоской однобайтовой OEM кодировкой. Будет очень грустно если при переходе в bash, там будет выставляться она же (вместо славного UTF-8).
Но вызывают опасения кодировки. Виндовая консоль и в 2016 году продолжает влачить существование с древней досовоской однобайтовой OEM кодировкой. Будет очень грустно если при переходе в bash, там будет выставляться она же (вместо славного UTF-8).
Видимо испугались, что разработчики массово уходят (ушли) на linux. Сейчас по многим вопросам мануалов под винду уже не найти (очень сложно найти). А где разработчики, туда и пользователи подтягиваются. Добровольно или принудительно.
Потому и бьют по одному из главных вопросов: «А как это установить/запустить на винде?»
Потому и бьют по одному из главных вопросов: «А как это установить/запустить на винде?»
Если там в нативном режиме заработает связка Apache и mod_perl — мои аплодисменты!
А то уже надоело искать совместимые версии Apache for Win32/64 + Strawberry Perl + mod_perl.
А то уже надоело искать совместимые версии Apache for Win32/64 + Strawberry Perl + mod_perl.
Была же уже такая шляпа, как Windows Services for UNIX. В чем отличия?
Ситуация заставляет меняться. И зарабатывать не на ОС и базовом ПО, а на сервисах. Акценты развития смещаются, иначе можно потерять весь рынок…
Теперь разработчикам Cygwin будет скучно.
Отлично Майкрософт! Даешь андроид подсистему в Windows Phone?!
Вы почти угадали. То, что они сейчас выкатили — это ошмётки от попытки сделать именно это.
Кто-то в руководстве Microsoft осознал, что таким макаром Windows может последовать по стопам OS/2 и обрезал проект так, чтобы минимизировать потенциальную опасность.
Кто-то в руководстве Microsoft осознал, что таким макаром Windows может последовать по стопам OS/2 и обрезал проект так, чтобы минимизировать потенциальную опасность.
Очень логичный и вписывающийся в общую стратегию (расширение и упрощение средств кроссплатформенной разработки) шаг чтобы удержать адептов Visual Studio от перехода на альтернативные платформы.
Судя по видеотрансляции, они и правда реализовали системные вызовы от юзермода убунты через виндовое ядро. Юзермод убунты предоставлен самим Каноникал, и не переделывался мелкомягкими. Есть пока пробелы, т.к. реализовано далеко не все, по крайней мере пока, но работы ведутся.
Лично тоже хотел бы видеть поддержку EXT-и иже с ним файловых систем на уровне ядра. Пожалуй, пора сдуть пыль с ноута с подпиской на инсайдер превью.
Лично тоже хотел бы видеть поддержку EXT-и иже с ним файловых систем на уровне ядра. Пожалуй, пора сдуть пыль с ноута с подпиской на инсайдер превью.
Пожалуй, пора сдуть пыль с ноута с подпиской на инсайдер превью.
А сейчас еще можно бесплатно получить инсайдер превью или нужно иметь лицензию на винду?
https://insider.windows.com/ — вроде, можно и без оной. Стоит учесть, если захочется отказаться от превью-билдов, возможно, придется реинсталлить ось. Подписался на "галимом" ноуте ещё в прошлый четверг, ждём-с когда прилетит.
ISO-образы с новым релизом доступны
https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewiso?OCID=WIP_r_14_Body_ISOS
Разумеется. подписаться для доступа надо. Но можно тестить на виртуалке итд.
https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewiso?OCID=WIP_r_14_Body_ISOS
Разумеется. подписаться для доступа надо. Но можно тестить на виртуалке итд.
Релиз с bash shell вышел. Первое что заметил не стартуют приложение которые взаимодействуют с сокетом.
Sign up to leave a comment.
Microsoft подтвердила слухи об интеграции подсистемы Linux в Windows 10