Комментарии 81
Попахивает мировым прорывом =) windows-админы будут годами благодарить автора
Не знаю как там насчет «мирового прорыва», вы не представляете насколько я сам себе «благодарен» (а Игорю, Максу и всей команде nginx — за сам nginx под винду).
Не потому что не люблю например тот же IIS или апач, — я даже умею их готовить, а просто разница — все же небо и земля. Ну и потому-что — open source.
Ну а последний фикс позволяет мне делать например ту же балансировку без «всяких» линуксовых (VM) промеж, т.е. прямо в винде.
А вы попробуйте на досуге уговорить например того же корпоративного клиента, поставить где-нибудь линукс, если «у нас везде только виндовс» (причем врет ведь — знаю что врет) и его безопасник кричит «а как я на него антивирус поставлю», «а полиси» и т.д. и т.п.
Не потому что не люблю например тот же IIS или апач, — я даже умею их готовить, а просто разница — все же небо и земля. Ну и потому-что — open source.
Ну а последний фикс позволяет мне делать например ту же балансировку без «всяких» линуксовых (VM) промеж, т.е. прямо в винде.
А вы попробуйте на досуге уговорить например того же корпоративного клиента, поставить где-нибудь линукс, если «у нас везде только виндовс» (причем врет ведь — знаю что врет) и его безопасник кричит «а как я на него антивирус поставлю», «а полиси» и т.д. и т.п.
Никогда не забуду, как в одном образовательном процессе попросили разобраться с некорректной работой nginx под Windows. На виртуалке. На Mac Pro… Автору похвала за проделанную работу.
Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
Только это вина не Windows Vista и последующих версий, а вина архитектуры NGINX. Еще с древних времен писалось, что не стоит работать с абсолютными адресами в разделяемой памяти, только смещения и тут никаких проблем и не было бы даже.
Только это вина не Windows Vista и последующих версий, а вина архитектуры NGINX. Еще с древних времен писалось, что не стоит работать с абсолютными адресами в разделяемой памяти, только смещения и тут никаких проблем и не было бы даже.
Кто-то где-то говорил обратное? Вопрос на самом деле филосовский, и я подозреваю, что оно даже реализуемо «смещениями», но вероятно с небольшой потерей производительности (просто поверьте) и многимя-многимя правлеными строчками кода (такой коммит-убийца, за который вам отдельное спасибо скажут владельцы кастомных сборок и разрабы foreign-модулей)… Как-то так.
Такой коммит-убийца — хороший кандидат на включение в версию 2.0, в которой, наконец-то, можно будет что-нибудь сломать, но сделать всё-таки правильно.
Есть как бы относительная адресация. Да и сравните скорость обращения к памяти и работу сети, тут разница настолько велика, что на потери при работе с памятью можно закрыть глаза.
Да? Четыре 40GBit Ethernet'а дадут вам ~15ГБ/сек, а DDR4 даёт только ~30ГБ/сек. Не такая и большая разница, согласитесь? И 100GBit Ethernet уже на подходе…
Конечно это скорее не для NGINX'а задачки, а для всяких кластерных RPC, но про то, что «сеть — это что-то такое мееедленое-мееедленное» пора забывать. Задержки в сети — да, они чудовищные, тут природу не обманешь, а вот пропускная способность — совсем другое дело, за этим нужно очень и очень следить.
Конечно это скорее не для NGINX'а задачки, а для всяких кластерных RPC, но про то, что «сеть — это что-то такое мееедленое-мееедленное» пора забывать. Задержки в сети — да, они чудовищные, тут природу не обманешь, а вот пропускная способность — совсем другое дело, за этим нужно очень и очень следить.
30ГБ/c это один канал, соответственно для 4х каналов 120. Пока еще порядок разница.
Четыре 40GBit Ethernet'а…
… на винде? :)
Тут даже под linux начнутся муки раскидывания прерываний по ядрам.
На винде — не видел, врать не буду. На Linux — бывает вполне реально в кластерах. Для раздачи статики подобную конфигурацию, понятно, никто использовать не будет.
Очень даже можно, если правильно тюнить систему.
Вот неплохой пример отдачи статики на 80 Гбит/с.
Лично мне кажется, в windows на таком же железе результат будет меньше.
В том числе, из за только одного select в nginx под windows.
Вот неплохой пример отдачи статики на 80 Гбит/с.
Лично мне кажется, в windows на таком же железе результат будет меньше.
В том числе, из за только одного select в nginx под windows.
Гениально сравнили, а вот если загрузить грузовик самыми большими хардами и отправить проехать 5 метров, скорость будет еще выше. Вообще при чём тут скорость работы памяти и скорость работы контроллера памяти и тем более процессора? Относительной адресацией занимается процессор, а никак не память.
На *NIX, где в качестве основного способа порождения дочернего процесса используется fork(), копирующий все адресное пространство — абсолютные адреса в разделяемой памяти являются совершенно нормальным явлением.
Вам не кажется, что обвинять *nix-сервер в том, что его изначально не подготовили для работы под виндой — несколько странно?
Вам не кажется, что обвинять *nix-сервер в том, что его изначально не подготовили для работы под виндой — несколько странно?
На самом деле это не правда, вернее не совсем правда — nginx с незапамятных времен можно было собрать под Windows без этого ограничения — нужно было просто на этапе сборки определить FD_SETSIZE равным нужному вам количеству соединений.То есть с IOCP он работать не умеет, может только косплеить слоупока работая через select?
По моим последним данным (возможно устарело) — It's incomplete and doesn't work.
Если все-таки да, то вероятно это будет следующее за что возьмусь, если (когда) будет много время (улыбаясь сквозь зубы)…
Если все-таки да, то вероятно это будет следующее за что возьмусь, если (когда) будет много время (улыбаясь сквозь зубы)…
Без IOCP это не особо и прорыв на мой вкус. Всё же IOCP это как раз high-performance networking который nginx`у как воздух нужен.
Ну как бы в корпоративном секторе, да под win (ntlm и иже с ним), часто длинный keepalive — поэтому по поводу медленного select я не очень страдаю, главное что хоть все воркеры — наконец воркают…
Про прорыв же — что вы, я без каких либо претензий — фикс он фикс и есть.
Про прорыв же — что вы, я без каких либо претензий — фикс он фикс и есть.
Да я только за вообще. Хоть так.
Под IOCP придётся по другому делать. Он же с пулом потоков работает, значит количество воркеров будет количеством активных потоков в пуле. Всё остальное будет система делать.
Под IOCP придётся по другому делать. Он же с пулом потоков работает, значит количество воркеров будет количеством активных потоков в пуле. Всё остальное будет система делать.
С каких пор IOCP работает с потоками пула? Он «работает» в том потоке, который вызвал GetQueuedCompletionStatus. Возможно, вы путаете поведение IOCP с поведением Overlapped IO без использования IOCP?
Думаю crea7or имел ввиду, что IOCP больше для потоков (threads), чем для процессов (process). Что, не совсем «кошерная» технология для nginx, хотя… будем посмотреть.
И что же мешает применять эту технологию с процессами, а не с потоками? Ну да, будет не один порт создан, а по числу процессов. Ну так ведь и проблема распределения сокетов по процессам уже решена…
На мой взгляд, достаточно сложно ответить на этот вопрос в целом, но подозреваю, что реальный выигрыш на windows будет только действительно на пуле потоков. Ну или комбинировано — N worker process x M worker threads.
Вероятно IocpPoller все-таки реально сварганить с наследованными сокетами, но боюсь overhead на проброс completion события в другой процесс может скушать часть профита. Интересно конечно насколько, вот поэтому и сложно ответить.
Вероятно IocpPoller все-таки реально сварганить с наследованными сокетами, но боюсь overhead на проброс completion события в другой процесс может скушать часть профита. Интересно конечно насколько, вот поэтому и сложно ответить.
Зачем пробрасывать? Можно же в каждом процессе создать свой порт, и связывать «свои» сокеты только с ним.
Проблема будет только с AcceptEx — но соеднинения все-таки устанавливаются не так часто, как через них передаются данные.
Проблема будет только с AcceptEx — но соеднинения все-таки устанавливаются не так часто, как через них передаются данные.
Зачем пробрасывать?Так некто и не хочет…
Просто речь-то про пул потоков vs. пул процессов. Весь выигрыш completion port именно в асинхронном распределении по пулу (потоков).
(Например, один из важнейших управляющих параметров для эффективной работы IOCP — NumberOfConcurrentThreads.)
А то что я имел ввиду — как оно там внутри Windows будет «проброшено» до унаследованного сокета.
В первую очередь преимущество IOCP — в отсутствии необходимости каждый раз сначала формировать FD_SET из 10240 элементов, потом внутри windows его еще и обходить — а после любого принятого байта начинать все заного.
Если сокеты уже распределились по пулу процессов — зачем их потом еще и по пулу потоков раскидывать? Понятно что общий пул потоков даст чуть более равномерную нагрузку на ядра, чем пул процессов с отдельными сокетами (но потребует чуть больше накладных расходов на синхронизацию) — но этот вопрос не имеет никакого отношения к IOCP. Это применимо и для select, и для epoll.
PS а NumberOfConcurrentThreads в nginx, очевидно, будет равен 1
Если сокеты уже распределились по пулу процессов — зачем их потом еще и по пулу потоков раскидывать? Понятно что общий пул потоков даст чуть более равномерную нагрузку на ядра, чем пул процессов с отдельными сокетами (но потребует чуть больше накладных расходов на синхронизацию) — но этот вопрос не имеет никакого отношения к IOCP. Это применимо и для select, и для epoll.
PS а NumberOfConcurrentThreads в nginx, очевидно, будет равен 1
Всё равно переделывать много, так может сразу как надо под платформу соорудить? Работу с диском тоже на IOCP завести и вообще будет зашибись.
Ну да, потоки в пуле будут обрабатывать завершение вв, но они же вместе работают с IOCP.
А как сделана поддержка SO_REUSEPORT?
А у винды такого нету… только REUSEADDR :(
Так через IOCP всё надо делать и не нужны никакие REUSE.
Спасибо, почитал. Но, проблема в том, что IOCP рассчитано только на треды. SO_REUSEPORT позволяет работать в виде нескольких процессов. Я понимаю, что «а нефиг писать однопоточные приложения», но в существующем приложении с однопоточной обработкой прикрутить SO_REUSEPORT и запуск нескольких копий проще, чем переделывать всё приложение на треды.
Переделывать конечно сложнее. Так IOCP не на это рассчитан, а чтобы сразу писали с его поддержкой. Это плохой вариант для портирования, но уж что есть. Опять же быстрее потоками, чем процессами (хоть и не так безопасно в свете текущей моды на процессы). Я сам не замерял, но вот тут с epoll сравнивают — всё же в ядре.
Хотя конкретно с nginx может быстрее особо и не будет (потоки <> процессы). Там если через шаред память перекидывается, то не сильно и медленнее будет одного адресного пространства. Разве что меньше переключений контекста.
А ради интересу, до модификаций 1*5 и после 1*5 отличаются или нет?
Вообще не заметно, т.е. все в рамках погрешности — раз чуть быстрее, раз чуть медленнее.
Иначе, я бы сразу это отключаемо сделал (или в случае 1 worker — по старому, без наследования)
Иначе, я бы сразу это отключаемо сделал (или в случае 1 worker — по старому, без наследования)
Хотя может для совместимости все-таки будет лучше так и сделать (в случае только 1 worker).
А как же сборка от nginx-win.ecsds.eu в которой и Fully ASLR and DEP compliant for shared memory и Select-boost и Multiple workers supported и FD_SETSIZE = 32768 и многое другое…
Вот полный список возможностей этой сборки:
Или несколько человек делают дурную работу делая одно и тоже… или я чего-то недогоняю? Может разработчикам Nginx подсмотреть что и как сделано в этой сборке?
Вот полный список возможностей этой сборки:
- All current nginx features (see with nginx.exe -V) (subject to Windows compatibility)
- Consistent with original nginx code (subject to Windows compatibility)
- FD_SETSIZE = 32768 (modded kernel), allows one worker to handle c250k+ (with optimization registry file)
- Multiple workers supported! use no more than 2 workers for 1 core (cpu)
- SPDY 3.1
- LuaJIT compiled in (lua-nginx-module)
- Naxsi WAF — Web Application Firewall
- Array-var-nginx-module
- HttpSubsModule
- echo-nginx-module
- ngx_http_lower_upper_case
- headers-more-nginx-module
- set-misc-nginx-module
- ngx_http_auth_ldap (experimental)
- Additional custom 503 error handler via 513
- lua-upstream-nginx-module (Manipulate upstream dynamically)
- Select-boost
- Fully ASLR and DEP compliant for shared memory
- encrypted-session-nginx-module
- Nginx-limit-traffic-rate-module
- RDNS (reverse DNS lookup for incoming connection)
- AJP — tomcat backend support
- form-input-nginx-module
- ngxLuaDB, the drizzle and dynamic loaded module solution
- ngx_upstream_jdomain
- cache_purge
- nginx-http-concat
- nginx-module-vts (Virtual host traffic status)
Или несколько человек делают дурную работу делая одно и тоже… или я чего-то недогоняю? Может разработчикам Nginx подсмотреть что и как сделано в этой сборке?
а вы спросите их за исходники…
Хм, исходников действительно нет, просто бесплатная сборка + платная поддержка кому нужно. В любом случае на месте разработчиков я бы связался с командой www.ecsystems.nl и выкупил все их коды и включил в основную ветку. Какой смысл изобретать велосипед и тратить человекоресурсы, если проще заплатить деньги за готовое. В любом случае огромное спасибо вам и за труды и за статью.
А упомянутые вами люди для меня сродни ну например фирмы Apple — я лично просто не собираюсь иметь с ними дела. За nginx не скажу, это повторяю от меня лично.
Еще раз спасибо за такое прекрасное хобби! Наконец-то в оригинальном Nginx за столько лет при полном безразличии разработчиков к Windows платформе можно увидеть реальные перемены в лучшую строну. Причём значительные перемены. Надеюсь ваш пул-реквест насчет воркеров очень скоро станет частью Nginx. Успехов!
Всегда пожалуйста…
А упомянутые вамиредиски люди… По мне как, весь смысл в nginx — только когда он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно), или чтобы что-то где-то подкрутить, или пересобрать с другим модулем или вообще куском «ядра» и т.д. Да много чего можно.
при полном безразличии разработчиков к Windows платформеНу как бы: раз — это совсем не правда, два — а они и необязаны.
А упомянутые вами
Ну как бы: раз — это совсем не правда
Ну тогда я не знаю как по другому объяснить многолетнее отсутствие подвижек в сторону Windows.
два — а они и необязаны.
А кто говорил что обязаны? Я лишь сказал что они безразличны к Windows платформе. Пусть вы и утверждаете обратное (поскольку более тесно с ними общаетесь), но слова это одно, а дело другое. На деле всё это висело мёртвым грузом много лет. Впрочем когда появилась сборка от nginx-win.ecsds.eu жить стало проще, жизнь стала веселей :-)
он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно)
«Тупо глянуть в исходники» не получится, Nginx крайне тяжелый для понимания и редкий программист сможет разобраться в его коде и уж тем более сам что-то дописать. Это уже не раз обсуждалось и об этом все знают. Поэтому меня всегда умиляют ссылки на open source, мол если нужна поддержка Windows — возьмите и допишите.
Лично вам огромное спасибо, это бесспорно, вы это заслужили, а касательно разработчиков Nginx моё мнение никогда не поменяется — им следовало бы больше уделять внимания Windows платформе, точнее хотя бы просто — уделять. И никто не считает их «редисками», они тоже молодцы что создали и поддерживают такой замечательный софт и им тоже за это огромное спасибо, просто я выразил своё личное мнение касательно их отношения к поддержке Windows. Топик ведь о Nginx и Windows, не так ли.
И никто не считает их «редисками»Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»). Ну как бы у меня на этой теме «когнитивный диссонанс» что-ли… и это дело принципа.
А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.
Nginx крайне тяжелый для понимания и редкий программист сможет долететь до середины Днепра ...Неправда ваша, я знаю очень много людей (не из команды nginx) легко могущих прочитать его исходники.
А даже если и не все могут — это ничего не меняет. Сам принцип важен… имхо.
тупо спрятав «исходники»
Не хочу ничего утверждать, но я не уверен что они их прячут. Может с ними никто и никогда не связывался по этому поводу? Или они сами должны на блюде подать? Если даже и прячут, то всё это можно решить путем переговоров по передаче кода, ну или деловых переговоров о продаже если к этому пойдет.
А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.
Простите великодушно, но где вы увидели претензии? Мне процитировать еще раз дословно чтоль свои же слова? Я лишь сказал о том, что на ИХ месте я бы постарался связаться с командой из ecsystems.nl и выкупить или просто получить эти исходники. Вдруг ребята из ecsystems.nl готовы отдать их просто так лишь бы они НЕ легли мёртвым грузом на много лет, а были реально включены в Nginx?
Если уж вы заговорили про команду ecsystems.nl, то хочу вам сказать что в группе рассылки Nginx сидит человек из этой команды и пытается общаться и на английском и на ломаном русском, видимо через Google Translate. Понятия не имею как всё обстоит на самом деле, но вы не предполагали, а может не от хорошей жизни ребята из ecsystems.nl начали сами допиливать Nginx?
Может именно потому что разработчики Nginx никак не развивали свой продукт в этом направлении эти ребята и приложили свои усилия к тому чтобы допилить Nginx до нормального рабочего состояния под Windows.
Ваши обвинения в адрес тех, которые делают профит на базе чего-нибудь из opensource, мне кажутся неуместными. Им наоборот нужно в ноги покланяться, что они допилили Ngixn и более того, всё это распространяется бесплатно, а профит, как вы говорите, они делают на поддержке. Простите, но техподдержкой в нашем мире никто бесплатно заниматься не будет, всем нужно на что-то жить и что-то кушать.
У вас на это своя точка зрения, у меня своя. Думайте как хотите, я вас переубеждать не собираюсь.
А во вторых, я специально не уточнял, на чем они делают профит. Поддержка — это хорошо, и деньги за это брать тоже не грех (хотя я лично занимаюсь этим в куче опенсорсных проектов совершенно бесплатно). Но это дело личное, конечно.
Я про-то, что «зарабатывая деньги» на опенсорсном продукте (не важно как) они его развивали только для себя, ну или для своих клиентов, если хотите. Мне очень не нравится сам этот факт. Я же это делаю для пользы всех, и своей в том числе…
Я вам пример приведу: есть опенсорсная финтифлюшка X (всем миром разрабатывающаяся), фирма F изменив в X чуть-чуть (пару процентов) сделала продукт X2, при этом даже периодически перенимая все изменения и новшества из X (каждый релиз).
Зарабатывая на X2 (а в моей реальности в большей степени на X), они никоим образом не поспособствовали развитию самого X (ну или в несоизмеримо малой степени). Имеют они на то право — возможно. Должен ли я их за это «уважать» — имхо, нет. Ну вот нет и все тут.
Хотя философствовать на эту тему я однозначно не собираюсь. По крайней мере, простите, с вами, и уж точно не в рамках этого поста.
Не хочу ничего утверждать, но я не уверен что они их прячутЗачем тогда нужно предлагать «сборку на заказ» (что они и делают)?
А во вторых, я специально не уточнял, на чем они делают профит. Поддержка — это хорошо, и деньги за это брать тоже не грех (хотя я лично занимаюсь этим в куче опенсорсных проектов совершенно бесплатно). Но это дело личное, конечно.
Я про-то, что «зарабатывая деньги» на опенсорсном продукте (не важно как) они его развивали только для себя, ну или для своих клиентов, если хотите. Мне очень не нравится сам этот факт. Я же это делаю для пользы всех, и своей в том числе…
Я вам пример приведу: есть опенсорсная финтифлюшка X (всем миром разрабатывающаяся), фирма F изменив в X чуть-чуть (пару процентов) сделала продукт X2, при этом даже периодически перенимая все изменения и новшества из X (каждый релиз).
Зарабатывая на X2 (а в моей реальности в большей степени на X), они никоим образом не поспособствовали развитию самого X (ну или в несоизмеримо малой степени). Имеют они на то право — возможно. Должен ли я их за это «уважать» — имхо, нет. Ну вот нет и все тут.
Хотя философствовать на эту тему я однозначно не собираюсь. По крайней мере, простите, с вами, и уж точно не в рамках этого поста.
Да поймите же вы, они ничего не зарабатывают конкретно на opensource, они зарабатывают на поддержке. Не важно какой и не важно чего, просто на поддержке своих клиентов, обработке их тикетов, настройке их серверов и проч. Сделанные ими изменения в коде никакого профита им не приносят и бинарники распространяются бесплатно. С таким успехом можно обвинить любого хостера который использует бесплатный Mysql для своих клиентов (не важно с доработками или без) в зарабатывании денег. Ну бред же.
По факту ECSystems продает услуги по поддержке Windows серверов и сборке Nginx с нужными модулями и часть этих денег жертвует команде, которая и осуществляет доработку Nginx под Windows.
OK не будем спорить :-) Я понял что вы их не уважаете, потому что свой вклад в opensource они пока не внесли.
Но ведь это только пока? По поводу исходников у них в FAQ написано что пока не выкладывают, т.к. проект не готов. Да и какой смысл их прятать, если бинарники и так бесплатные? Т.е. как только будет доделано то что указано в TODO ниже, можно ожидать появления исходников. Будем надеяться…
Todo:
— ldap / ntlm
— allow multiple instances to run on the same machine
— More non-blocking Lua, event based DLL add-on’s like pagespeed, SharePoint, asp/dotnet.
— Full 64 bit builds.
— IO event and thread separation (60% completed).
— Distributed IO and CPU event processing (we have a working proto type).
По факту ECSystems продает услуги по поддержке Windows серверов и сборке Nginx с нужными модулями и часть этих денег жертвует команде, которая и осуществляет доработку Nginx под Windows.
OK не будем спорить :-) Я понял что вы их не уважаете, потому что свой вклад в opensource они пока не внесли.
Но ведь это только пока? По поводу исходников у них в FAQ написано что пока не выкладывают, т.к. проект не готов. Да и какой смысл их прятать, если бинарники и так бесплатные? Т.е. как только будет доделано то что указано в TODO ниже, можно ожидать появления исходников. Будем надеяться…
Todo:
— ldap / ntlm
— allow multiple instances to run on the same machine
— More non-blocking Lua, event based DLL add-on’s like pagespeed, SharePoint, asp/dotnet.
— Full 64 bit builds.
— IO event and thread separation (60% completed).
— Distributed IO and CPU event processing (we have a working proto type).
Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»).
Ну раз уж зашел разговор про конкретные лица.
Насколько мне известно вот тут нелюбимая вами фруктовая компания выкладывает все наработки как «взятые из мира опенсорс», так и открытое ими самими.
И раз уж вы обвиняете — подскажите, пожалуйста, что именно вам известно, какой продукт эта самая фирма «не развивает» или от чего «прячет исходники»?
Очень любопытно. Спасибо.
Можно подискутировать насчет наработок BSD.
До сих пор, если на Mac зайти в консоль, ощущение, что сидишь за FreeBSD — те же команды, вплоть до команды sockstat.
Хотя всегда можно сказать что-то типа «У BSD такая лицензия, когда можно взять и не открывать».
До сих пор, если на Mac зайти в консоль, ощущение, что сидишь за FreeBSD — те же команды, вплоть до команды sockstat.
Хотя всегда можно сказать что-то типа «У BSD такая лицензия, когда можно взять и не открывать».
Вот тут лежит окружение взятое из BSD. Плюс свои драйвера и другие наработки типа вебкита.
Вы не можете скачать?
Я не понимаю в чём претензия.
Вы не можете скачать?
Я не понимаю в чём претензия.
Незачто, потому как я вам ничего не собираюсь доказывать… Кто ищет, тот всегда найдёт.
А что выкладывается — ну так когда от лицензии никуда не деться, приходится. Только это имхо, такая капля в море, при тех то доходах и возможностях.
Это дело почти личное — я же пропагандой ни за ни против не занимаюсь…
Ну вот скажите мне, почему каждая статья, какой бы технической не была, сваливается в глубокий холивар о «птичках»?
А что выкладывается — ну так когда от лицензии никуда не деться, приходится. Только это имхо, такая капля в море, при тех то доходах и возможностях.
Это дело почти личное — я же пропагандой ни за ни против не занимаюсь…
Ну вот скажите мне, почему каждая статья, какой бы технической не была, сваливается в глубокий холивар о «птичках»?
Интересно, а как в cygwin разобрались с ASLR? У них же вызов fork() работает!
Автор, скажите пожалуйста — не появилась ли возможность использовать nginx на Windows в паре с ffmpeg без ручного запуска для перекодирования стримов под Windows в другое качество как это возможно под Linux?
rtmp? Простите, не было нужды под виндой, так что без понятия. Однако не думаю, что оно сильно сложно проверить… например rtmp-модуль вроде под windows собирается. А как там ffmpeg прикручивается, чтобы на лету, я правда не пользовал…
Космические корабли уже много лет бороздят просторы и всё такое, но к сожалению немалая часть человечества продолжает мучаться с виндой и прочим майкрософтовским говнософтом. Когда же уже это закончится наконец?
Я не в том смысле, что автор не молодец. Автор молодец, конечно, но как подумаешь сколько времени и сил можно было бы сэкономить если бы не «в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа».
Я не в том смысле, что автор не молодец. Автор молодец, конечно, но как подумаешь сколько времени и сил можно было бы сэкономить если бы не «в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа».
А у нас кроме проприетарной винды разве нет других систем с той же архитектурой?
C ReactOS мучаться придется еще больше.
Кстати вот не пробовал… а интересно, правда. Время, будь оно неладно.
Если кто вдруг опередит, отпишитесь, плз…
Если кто вдруг опередит, отпишитесь, плз…
Я пытался использовать ReactOS, когда мне приходилось работать с каким-то уродским vpn-клиентом, и я искал способ вынести vpn-клиент на отдельный сетевой хост (доп. условия задачи: клиент работает только под виндой и у меня нет никакого дистрибутива винды, пусть даже с пробным периодом). Так вот, под Hyper-V у ReactOS попросту не нашлось драйверов для сетевой карты. С такими глупыми проблемами ReactOS еще долго не сможет считаться вариантом решения.
С другой стороны, скорость установки ReactOS и загрузки была такова, что я успел проверить обе возможные конфигурации железа и убедиться в несовместимости ReactOS с Hyper-V пока запускалась отладка нашего проекта. Так что какое-то будущее у ReactOS есть, после решения подобных глупых проблем.
С другой стороны, скорость установки ReactOS и загрузки была такова, что я успел проверить обе возможные конфигурации железа и убедиться в несовместимости ReactOS с Hyper-V пока запускалась отладка нашего проекта. Так что какое-то будущее у ReactOS есть, после решения подобных глупых проблем.
Вроде есть, но зачем оно нам? Почему не использовать простой и понятный Unix, который в стопятьсот раз проще и не контролируется одной компанией с весьма сомнительными намерениями. Я понимаю люди делали всякие L4 и Plan9, двигали прогресс, но в случае с Windows, мне кажется что всему прогрессивному человечеству станет гораздо лучше когда мы пройдём этот печальный этап. Я не специалист по архитектуре Windows, и возможно где-то глубоко внутри неё и есть что-то разумное, доброе и вечное, но с точки зрения пользователя, администратора и разработчика я вижу сплошные проблемы и неудобства.
Будет работать в Nano Server?
Замечание:
On many file systems, a short file name contains a tilde (~) character. However, not all file systems follow this convention. Therefore, do not assume that you can skip calling GetLongPathName if the path does not contain a tilde (~) character.
msdn.microsoft.com/en-us/library/windows/desktop/aa364980(v=vs.85).aspx
И если посмотреть ещё раз на исходники:
github.com/sebres/nginx/commit/12fb136744bb4de3ec4568d6a458495cd97f1043#diff-04009b15c59ed35d0ef2738a46174307R746
То текущий вариант будет всегда работать, а новый можно взломать (теоретически).
On many file systems, a short file name contains a tilde (~) character. However, not all file systems follow this convention. Therefore, do not assume that you can skip calling GetLongPathName if the path does not contain a tilde (~) character.
msdn.microsoft.com/en-us/library/windows/desktop/aa364980(v=vs.85).aspx
И если посмотреть ещё раз на исходники:
github.com/sebres/nginx/commit/12fb136744bb4de3ec4568d6a458495cd97f1043#diff-04009b15c59ed35d0ef2738a46174307R746
То текущий вариант будет всегда работать, а новый можно взломать (теоретически).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NGINX — История перерождения под Windows