Вы, как человек 8 лет занимающийся сетевой безопасностью, должны понимать, что во-первых, самым слабым звеном является пользователь, а во-вторых всё упирается, скажем, в зоны ответственности или зоны безопасности.
Основная доля машин в кластере ботнета, приходится на машины самых обычных пользователей, сидящих у себя по-домам в куче различных подсетей, включая виртуальные. То есть нельзя выделить какую-то конкретную зону для фильтрации. На машине пользователя может быть в общем случае установлено всё что угодно, открывающее какие угодно порты и передающее какой угодно трафик. Фильтровать этот трафик не то что нельзя, просто невозможно. Более того, интернет в дальнейшем, из сервероориентированного (такого, где подключения можно было бы разрешать только к серверам и запрещать пользователям открывать порты у себя) будет всё сильнее скатываться в сторону распределённой системы частных серверов. (Opera Unite, DropBox — это первые ласточки).
Что касается корпоративных пользователей — торренты я бы закрывал на рабочем месте ибо нефиг, со скайпом — да, дела обстоят хуже, но он прекрасно работает и через NAT без возможности коннекта к нему из-вне (хотя и торрент-клиенты тоже могут, кстати).
Почему вы боитесь именно ботнета, на основе скайпа или торрентов? Потому-что они уже похожи на ботнеты?
Понятное дело, что в сервероориентированном интернете гораздо проще было бы обеспечить безопасность, закрыв на оборудовании всех провайдеров все порты кроме определённых и/или жёстко фильтруя трафик.
А как вам вариант заражения какого-нибудь флеш приложения в фейсбуке или вконтакте, или того-же квипа? Точно так же можно будет организовать DDOS, при этом совершенно обычными, честными HTTP запросами.
———
Мне пришла в голову мысль, что защитные системы должны работать по принципу DNS — то есть заранее определяется, какие виды трафика могут посылаться на конкретный сервер, и что самое главное в каких объёмах. Эта информация расползается по оборудованию провайдеров и в случае нарушений в определённой подсети начинает всё это шейперить, вплоть до блокировки. Причём, кстати на базе DNS такую систему можно развернуть уже сейчас, возможно написанием не сложных конфигов для шейперов.
1. Как-то в общих положениях много лишнего.
2. «Требования к программному обеспечению сайта», забыли аппаратные требования, да и вообще раздел странный
3. Структура сайта и навигация — рядом бы.
А вообще мне не очень нравится, как-то размазанно.
На мой взгляд, дизайн следует разделять на оформление и логику, и описывать отдельно.
Всю программную часть описывать тоже в отдельном разделе.
Ещё не следует забывать, что веб-сайты можно разделить (грубо) на:
— презентационные
— информативные
— корпоративные (+ полноценные веб-приложения)
Каждый из типов требует немного разных подходов при написании ТЗ, соответственно шаблонов нужно несколько.
А дайте линк, интересно где это всё можно закупить :)
Далеко — по причине не совершенства именно механизмов, а не алгоритмов. Хотя нужно отметить, что насекомые, сопоставимых размеров, тоже не так быстро могут передвигаться, в сравнении с их крошечными собратьями.
Ещё, по поводу актуальности — инверсная кинематика, конечно не таблица умножения, но ничего нереального в ней нет. Я совершенно уверен, что в физическом симуляторе можно добиться уже сейчас довольно правильного управления балансом и скоростью даже у двуногой модели. Кстати импользовать для обратной связи видеокамеру — это по меньшей мере странно — акселерометр куда более удобен.
Берём айпод, подключаемся по вай-фаю к основному устройству и управляем им)
Да не в алгоритмах даже дело. Я когда вот такое вижу не могу избавиться от мысли, что на самом деле, за последние лет 20 мало что изменилось.
Да, появились хорошие блоки управления — тут вообще полноценный комп, считай. Все радуются что робот сам учится ходить. Это замечательно, но ведь эти же эксперименты прекрасно могут проводиться и при отсутствии физической реализации, физический движок сделать или взять готовый — не такая большая проблема.
В общем с «мозгами» роботов дела идут не быстро, но в верном направлении. Основная же проблема, например у нас, в России — где достать качественные «мышцы» (электроприводы, соленоиды) — ну вот правда, во сколько обошлись бы мне вот такие детали, как в этой шестиножке? Из чего и как сделаны лапки? Вот этой информации не хватает.
Вторая проблема вытекает из первой — автономность роботов сейчас упирается в мощность элементов питания — самое лучшее соотношение по дальности и мощности у летающих роботов с ДВС, а шагающие, увы, пока ещё далеко не ушагают, может быть уплывут :)
Мне, как правило, быстрее и проще добавить 10 репозиториев из консоли, чем колупаться с каждым репозиторием на битбакете + я люблю чтобы каждая ветка лежала в своём.
В общем то, про что я пишу применимо скорее, когда есть 30 репозиториев и их нужно как-то хитро рассортировать и раздать. $50/month за такое платить не очень сильно хочется — за почти эти же деньги не то, что VPS можно и дедик взять.
А я всё думаю, когда же кто-нибудь скажет про bitbucket.org :) — безусловно отличный сервис, 1 приватный репозиторий бесплатно, но вот за остальное придётся платить.
А у нас перевезённый около 14 дней назад сервер уже 11 часов не работает.
Звонил им в 11 вечера, сказали мол «вот была у нас проблема в датацентре, починили, сервера поднимутся в течение часа». При этом на фоне беготня, крики, голос у говорящего жутко смущённый и не уверенный.
Не знаю как они так должны подниматься по часу, они тоже видимо не знают. Атас полный.
Ну а что следующим шагом от apple должен быть выпуск раза в iMad, раза в 4 больше iPad и снимающегося с классической iMac ножки.
Кстати… жаль, что iPad не крепится на холодильник, как магнит. А если серьёзно, мне кажется будут появляться настенные тачскрины скоро и много, через них будет делаться всё и их можно будет снимать, и все они будут с wifi/n в одной домашней мегасети и… ох хватит пожалуй.
Вот вы говорите, «Спорт-спорт»… Вот стабильную систему собрать, с максимальной производительностью, за минимальные деньги — это спорт. А вот то, что тут описано — это такой же спорт, как если обколоться анаболиками, пробежать 100-метровку за 6 секунд и помереть на финише, испарившись.
Хотя зрелищно и круто — это факт. Это всё — хороший «PR», но никак не спорт.
дело вкуса наверное, ну и то, что pyhton гораздо лучше для написания именно приложений, которые живут между запросами. Да и расширения писать под него проще.
Не буду спорить, конечно я всей ситуации не знаю, просто меня смутили факты:
— до этого это было ActiveX, значит работало как веб приложение, значит был смысл в веб-приложении, иначе бы сразу писали на «голом» C.
— рассматривался вариант с PHP
— Python + расширения на C или C++ для узких мест + javascript — получаем хорошее, расширяемое веб-приложение.
Но если более 2-х месяцев обсуждали, значит были веские причины отказываться от изначальной схемы.
Основная доля машин в кластере ботнета, приходится на машины самых обычных пользователей, сидящих у себя по-домам в куче различных подсетей, включая виртуальные. То есть нельзя выделить какую-то конкретную зону для фильтрации. На машине пользователя может быть в общем случае установлено всё что угодно, открывающее какие угодно порты и передающее какой угодно трафик. Фильтровать этот трафик не то что нельзя, просто невозможно. Более того, интернет в дальнейшем, из сервероориентированного (такого, где подключения можно было бы разрешать только к серверам и запрещать пользователям открывать порты у себя) будет всё сильнее скатываться в сторону распределённой системы частных серверов. (Opera Unite, DropBox — это первые ласточки).
Что касается корпоративных пользователей — торренты я бы закрывал на рабочем месте ибо нефиг, со скайпом — да, дела обстоят хуже, но он прекрасно работает и через NAT без возможности коннекта к нему из-вне (хотя и торрент-клиенты тоже могут, кстати).
Почему вы боитесь именно ботнета, на основе скайпа или торрентов? Потому-что они уже похожи на ботнеты?
Понятное дело, что в сервероориентированном интернете гораздо проще было бы обеспечить безопасность, закрыв на оборудовании всех провайдеров все порты кроме определённых и/или жёстко фильтруя трафик.
А как вам вариант заражения какого-нибудь флеш приложения в фейсбуке или вконтакте, или того-же квипа? Точно так же можно будет организовать DDOS, при этом совершенно обычными, честными HTTP запросами.
———
Мне пришла в голову мысль, что защитные системы должны работать по принципу DNS — то есть заранее определяется, какие виды трафика могут посылаться на конкретный сервер, и что самое главное в каких объёмах. Эта информация расползается по оборудованию провайдеров и в случае нарушений в определённой подсети начинает всё это шейперить, вплоть до блокировки. Причём, кстати на базе DNS такую систему можно развернуть уже сейчас, возможно написанием не сложных конфигов для шейперов.
Мне дизайн очень нравится. Но мне очень не нравится графика в трансляциях, отвратительные шрифты, да и сама логика этих интерфейсов — ужас.
2. «Требования к программному обеспечению сайта», забыли аппаратные требования, да и вообще раздел странный
3. Структура сайта и навигация — рядом бы.
А вообще мне не очень нравится, как-то размазанно.
На мой взгляд, дизайн следует разделять на оформление и логику, и описывать отдельно.
Всю программную часть описывать тоже в отдельном разделе.
Ещё не следует забывать, что веб-сайты можно разделить (грубо) на:
— презентационные
— информативные
— корпоративные (+ полноценные веб-приложения)
Каждый из типов требует немного разных подходов при написании ТЗ, соответственно шаблонов нужно несколько.
Далеко — по причине не совершенства именно механизмов, а не алгоритмов. Хотя нужно отметить, что насекомые, сопоставимых размеров, тоже не так быстро могут передвигаться, в сравнении с их крошечными собратьями.
Ещё, по поводу актуальности — инверсная кинематика, конечно не таблица умножения, но ничего нереального в ней нет. Я совершенно уверен, что в физическом симуляторе можно добиться уже сейчас довольно правильного управления балансом и скоростью даже у двуногой модели. Кстати импользовать для обратной связи видеокамеру — это по меньшей мере странно — акселерометр куда более удобен.
Берём айпод, подключаемся по вай-фаю к основному устройству и управляем им)
Да, появились хорошие блоки управления — тут вообще полноценный комп, считай. Все радуются что робот сам учится ходить. Это замечательно, но ведь эти же эксперименты прекрасно могут проводиться и при отсутствии физической реализации, физический движок сделать или взять готовый — не такая большая проблема.
В общем с «мозгами» роботов дела идут не быстро, но в верном направлении. Основная же проблема, например у нас, в России — где достать качественные «мышцы» (электроприводы, соленоиды) — ну вот правда, во сколько обошлись бы мне вот такие детали, как в этой шестиножке? Из чего и как сделаны лапки? Вот этой информации не хватает.
Вторая проблема вытекает из первой — автономность роботов сейчас упирается в мощность элементов питания — самое лучшее соотношение по дальности и мощности у летающих роботов с ДВС, а шагающие, увы, пока ещё далеко не ушагают, может быть уплывут :)
В общем то, про что я пишу применимо скорее, когда есть 30 репозиториев и их нужно как-то хитро рассортировать и раздать. $50/month за такое платить не очень сильно хочется — за почти эти же деньги не то, что VPS можно и дедик взять.
Звонил им в 11 вечера, сказали мол «вот была у нас проблема в датацентре, починили, сервера поднимутся в течение часа». При этом на фоне беготня, крики, голос у говорящего жутко смущённый и не уверенный.
Не знаю как они так должны подниматься по часу, они тоже видимо не знают. Атас полный.
Есть у кого подобные проблемы сейчас?
Кстати… жаль, что iPad не крепится на холодильник, как магнит. А если серьёзно, мне кажется будут появляться настенные тачскрины скоро и много, через них будет делаться всё и их можно будет снимать, и все они будут с wifi/n в одной домашней мегасети и… ох хватит пожалуй.
Если улучшить алгоритмы распознавания образов (или прикрутить уже довольно хорошие) то много чего можно сделать.
А если прикрутить искусственный интеллект…
Хотя зрелищно и круто — это факт. Это всё — хороший «PR», но никак не спорт.
— до этого это было ActiveX, значит работало как веб приложение, значит был смысл в веб-приложении, иначе бы сразу писали на «голом» C.
— рассматривался вариант с PHP
— Python + расширения на C или C++ для узких мест + javascript — получаем хорошее, расширяемое веб-приложение.
Но если более 2-х месяцев обсуждали, значит были веские причины отказываться от изначальной схемы.