Новая поисковая технология Microsoft Kumo, идущая на смену Live Search, базируется (http://news.cnet.com/8301-13505_3-10235400-16.html) на open source компонентах, созданных в рамках проекта по разработке свободной поисковой системы Apache Lucene (http://lucene.apache.org/). Для хранения и обработки данных в Kumo используется Hadoop (http://hadoop.apache.org/core/) (напоминающая Google BigTable система для организации распределенных вычислений с использованием парадигмы map/reduce) и распределенная файловая система HDFS (Hadoop Distributed Filesystem). Hadoop распространяется под лицензией Apache 2.0, т.е. не обязывает раскрывать изменения кода.URL: http://news.cnet.com/8301-13505_3-10235400-16.html
Новость: http://www.opennet.me/opennews/art.shtml?num=21689
Имеют полное право. Спонсоры как никак.
Эта ... а свои программисты в Microsoft есть?
это можно сказать в адрес любого, кто берет что-то чужое. Вот Ubunta на ядре Linux'а. Значит в Каноникал нет своих программистов?
А это и есть их программисты. Microsoft является платиновым спонсором Apache foundation.
>Имеют полное право. Спонсоры как никак.Угу, конечно.В итоге как всегда выигрывает один микрософт а остальные сосут болт.Замечательно - так держать, даешь проприетарщину назад в массы.
Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии. :)
>Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии.
>:)а какая лицензия у apache 1.3? да и причем тут OpenBSD? она тоже позволяет код закрыть, как и апач.
>Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии.
>:)А что, лицензия OpenBSD обязывает некрофильствовать? oO Ужас какой.
>Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии.
>:)Просто Apache 1.3 для однопроцессорных систем и не поддерживает SMP. В OpenBSD по сути инфраструктура поддержки исполнения на многоядерных процессорах (SMP) не развита, так что Apache 1.3 в самый раз.
Вот, Apache 2.x использует преимущества SMP-архитектуры.
>Просто Apache 1.3 для однопроцессорных систем и не поддерживает SMP. В OpenBSD
>по сути инфраструктура поддержки исполнения на многоядерных процессорах (SMP) не развита,
>так что Apache 1.3 в самый раз.Чего-чего ? Apache 1.3, как и любое приложение параллельно обрабатывающие запросы несколькими процессами, все преимущества SMP задействует.
>Вот, Apache 2.x использует преимущества SMP-архитектуры.
Тем что 5 лет mod_php для мультитредового worker MPM допиливали ? До сих пор в продакшин кроме prefork MPM что-то использовать не рекомендуется, что делает логику работы с процессами Apache2 аналогичной Apache 1.3.
Бред. Apache 2 использует потоки, а Apache 1.3 - нет.
Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc для межпроцессного взаимодействия.
И честного говоря, ещё не известно, что лучше. Зависит от задач.
>Бред. Apache 2 использует потоки, а Apache 1.3 - нет.
>Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc
>для межпроцессного взаимодействия.Ну я это и имел в виду, когда говорил, что Apache 1.3 не поддерживает SMP. Согласитесь, что потоки от процессов отличаются очень даже. Хотя для *nix стоимость создания нового процесса не так велика, как в Windows, например.
>И честного говоря, ещё не известно, что лучше. Зависит от задач.
Потоки используют общее адресное пространство (но разные стеки). Процессы имеют каждый собственное адресное пространство и изолированы друг от друга, используют IPC для обмена данными.
>>Бред. Apache 2 использует потоки, а Apache 1.3 - нет.
>>Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc
>>для межпроцессного взаимодействия.
>
>Ну я это и имел в виду, когда говорил, что Apache 1.3
>не поддерживает SMP. Согласитесь, что потоки от процессов отличаются очень даже.
>Хотя для *nix стоимость создания нового процесса не так велика, как
>в Windows, например.Вы, наверное, не в курсе, что для обработки нового запроса _не_ создается новый процесс, так что стоимость создания нового процесса не играет существенной роли, поскольку создание новых процессов происходит сравнительно нечасто. Так что, хотя и согласимся, что потоки от процессов отличаются, но нисколько не согласимся что апача 1.3 не поддерживает SMP.
>
>>И честного говоря, ещё не известно, что лучше. Зависит от задач.
>
>Потоки используют общее адресное пространство (но разные стеки). Процессы имеют каждый собственное
>адресное пространство и изолированы друг от друга, используют IPC для обмена
>данными.
>Вы, наверное, не в курсе, что для обработки нового запроса _не_ создается
>новый процесс, так что стоимость создания нового процесса не играет существенной
>роли, поскольку создание новых процессов происходит сравнительно нечасто.Всегда думал, что Apache 1.3 на каждый запрос, особенно если это касается mod_php и mod_perl, создаёт новый процесс выполнения или берёт свободный из пула уже запущенных процессов для выполнения запрашиваемой задачи.
>Так что, хотя
>и согласимся, что потоки от процессов отличаются, но нисколько не
>согласимся что апача 1.3 не поддерживает SMP.Ну да, заместо распределения потоков по ядрам, Apache 1.3 тупо исполняет всё в одном процессе/потоке на одном ядре -- об SMP он не в курсах -- заместо него думает шедулер операционной системы, как правильно раскидать его порождённые процессы/потоки по ядрам.
>Всегда думал, что Apache 1.3 на каждый запрос, особенно если это касается
>mod_php и mod_perl, создаёт новый процесс выполнения или берёт свободный из
>пула уже запущенных процессов для выполнения запрашиваемой задачи.Ага. И как раз бОльшая часть попадает во второй случай.
>Ну да, заместо распределения потоков по ядрам, Apache 1.3 тупо исполняет всё
>в одном процессе/потоке на одном ядре -- об SMP он не
>в курсах -- заместо него думает шедулер операционной системы, как правильно
>раскидать его порождённые процессы/потоки по ядрам.Т.е. апач2 сам распределяет потоки по ядрам заменяя собой шедулер ? До чего техника дошла.
>Т.е. апач2 сам распределяет потоки по ядрам заменяя собой шедулер ? До
>чего техника дошла.Нет. Его дело порождать потоки и управлять пулом потоков. А распределением ресурсов, например, под потоки в FreeBSD занимаются библиотека libthr и шедулер ULE3.
>>Т.е. апач2 сам распределяет потоки по ядрам заменяя собой шедулер ? До
>>чего техника дошла.
>
>Нет. Его дело порождать потоки и управлять пулом потоков. А распределением ресурсов,
>например, под потоки в FreeBSD занимаются библиотека libthr и шедулер ULE3.
>Итого и в том и в другом случае ресурсами управляет ядро ОС. Т.е. разница только в некотором снижении нагрузки на систему ценой (теоретического) понижения надёжности из-за использования общей памяти потоками.
А давно ULE3 появился ? В 7-STABLE & 8-CURRENT насколько помню ULE2.
>А давно ULE3 появился ? В 7-STABLE & 8-CURRENT насколько помню ULE2.Оригинальная работа ULE основывается на планировщике O(1) Инго Молнара. Он был экспериментальным и остался в ветке 5.x и до сих пор в 6.x.
ULE3 был разработан Джефом Робертсоном специально для FreeBSD 7.0. Однако в конфигурационном файле ядра получил то же имя -- SCHED_ULE, что и предыдущая версия экспериментального планировщика -- имя осталось, а код полностью переписан.
Предупреждение.
Do NOT use ULE on 6.x. ULE has been revamped heavily on 7.0 and the
version on 6.x is old, and is known to contain some bugs.Use it in 6.x if you dare, just don't complain to us if it breaks your system :-)
i.e. if at any point you start experiencing problems, do not report them
until you have verified that they persist with 4BSD also."И всё равно, кажный раз отряд леммингов пытается воткнуть ULE на 6.x и взлететь :)"
http://www.opennet.me/openforum/vsluhforumID3/40080.html#9
>Ага. И как раз бОльшая часть попадает во второй случай.Ага.Здорово получается когда на такой сервак (вы ведь про префорк?) заходят тулзой типа http_load'а.А 1000 постоянно форкающихся процессов вас не напряжет?Ну или остальные юзеры подождут пока мои 1000 реквестов пул процессов отработает, а я тем временем еще 1000 пришлю.
Впрочем чаще на мало-мальски популярный сервак однажды просто забредает ботнет какого-нить кульхаксора (мало ли там чего, может админ его сдуру забанил, нахамил, или там еще что а у хакеришки карманный ботнетец на пару тыщ машин как раз имелся).И даже при минимальном числе ботов такое легко кладет апача на лопатки.Нет, не выжрав бандвиз.А просто нафоркав процессов(если админ не выставил лимити адекватно возможностям машины).Или (если админ не дятел и выставил лимиты вменяемо) - просто выюзав в хлам пул процессов, так что легитимные юзеры видят только постоянные таймауты не дождавшись пока процесс им внимание вместо ботов уделит.Это ессно про идиотский prefork.Который конечно в теории то масштабируется по многопроцессорным системам, но чтобы он хорошо масштабировался на практике - надо купить под него никак не менее Крэя, вот тогда наверное смасштабируется.
А тот же лайт или нжынкс на аналогичной нагрузке и не бог весть какой машине - вообще не поперхнутся например в случае статики(а апач с префорком и на статику форкается, фигле).В итоге апач с префорком для отдачи статики - просто мечта мазохиста: головняк админу будет обеспечен при минимальной затрате усилий юзеров\хацкеров :)
>Впрочем чаще на мало-мальски популярный сервак однажды просто забредает ботнет какого-нить кульхаксора
>(мало ли там чего, может админ его сдуру забанил, нахамил, или
>там еще что а у хакеришки карманный ботнетец на пару тыщ
>машин как раз имелся).И даже при минимальном числе ботов такое легко
>кладет апача на лопатки.Нет, не выжрав бандвиз.А просто нафоркав процессов(если админ
>не выставил лимити адекватно возможностям машины).Или (если админ не дятел и
>выставил лимиты вменяемо) - просто выюзав в хлам пул процессов, так
>что легитимные юзеры видят только постоянные таймауты не дождавшись пока процесс
>им внимание вместо ботов уделит.Такую ситуацию должен отслеживать нормальный файервол/пакетный фильтр и банить на время "отстоя" адреса, с которых производится DDoS-атака. Не позволять с одного IP-адреса делать реконнекты больше чем с определённой частотой -- святая обязанность файервола.
> Такую ситуацию должен отслеживать нормальный файервол/пакетный фильтрНу, ладно, меня одного с http_load забанить можно(и то, только если я не буду засранцем и не размажу это безобразие через жирный прокси-лист, что при желании сделать не вопрос).А вот что с ботами делать которые ведут себя реалистично, подобно юзерам?Попытка бана приведет к бану и легитимных юзеров если атака мало-мальски грамотная.Собственно несколько тыщ ботов и качать неторопливо файлики пожирнее.Как юзеры.Фигли.При этом каждому боту совсем не обязательно часто делать запросы-ему достаточно меееедленно выкачивать толстый файл полчаса.Заняв на полчаса под бесполезную деятельность целый увесистый процесс.В итоге или апач с префорком убьет все вокруг своими кучами процессов или же если урезать пул процессов до вменяемой величины - легитимные юзеры будут дооооолго ждать своей очереди(пока боты по полчаса медленно качают файл, сделав всего 1 запрос...).В итоге браузер им просто покажет табличку рассказывающую про то что connection timed out или они сами задолбутся ждать.
Это так, по мотивам виденных атак на реальные апачи в их более-менее дефолтном виде, т.е. дурной prefork.В итоге или апач кладет систему (клинч от тысяч процессов такой что по ssh порой не пробиться, ресурсов проца не хватает) или сайт почти перестает обслуживать юзеров хотя ресурсы вроде как есть(просто пул процессов озадачен левизной а юзерам-фига!).
> обязанность файервола.
От именно DDoS, даже весьма легкого, силами школоты - не спасет.Потому как индивидуальные боты в случае заточки атаки против именно апача с его префорком не обязаны часто делать запросы: количеством и медленностью скачки возьмут.И пока все воркеры будут по полчаса отдавать файлики ботам, юзеры, разумеется, подождут.А куда они денутся если всех воркеров на полчаса застолбили боты?А через полчаса можно другой файлик покачать.Еще полчаса.Реальные юзеры могут качать даже чаще.Их - в бан? =)
А уж вполне легитимный NAT какого-нибудь праводера с кучей юзеров за ним при случае накроет только в путь, если они потопают всей кучкой смотреть "а что это там такое?".А прописывать в исключения все NATы и т.п. - заколебешься.
В итоге имхо проще поставить лайт или нжинкс, им на такой тип нагрузки - класть с прибором, расход ресурсов на малоактивные соединения - невелик и уронить становится куда труднее (каналы у серваков обычно толстые и забить их шибко сложнее чем просто поставить апач с префорком в позу).
>>Бред. Apache 2 использует потоки, а Apache 1.3 - нет.
>>Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc
>>для межпроцессного взаимодействия.
>Ну я это и имел в виду, когда говорил, что Apache 1.3 не поддерживает SMP.и в каком именно месте?
1. как бы процессы более подходят для SMP, чем потоки (например, перекидывать потоки с их общим адресным пространством между разными CPU более накладно)
2. IPC - вполне себе оптимизирован для подобных задач. да и пишется он уж точно не прикладными программистами.
к тому же обе эти версии апача всё-равно вынуждены поддерживать ipc.
а чуть меньшее время создания процесса компенсируется созданием пулов процессов, что требует минимального планирования и не более.
сори
s/а чуть меньшее время создания процесса/а чуть меньшее время создания потока/
Адресное пространство самой программы и её копий (сегменты text) в linux и BSD будет общее, да и часть сегментов DATA тоже, если только программа не будет в них производить запись.
Если Майкрософт станет делать свободное и открытое ПО, это будет... неправильно!
>Если Майкрософт станет делать свободное и открытое ПО, это будет... неправильно!ох, и не говорите