Всем привет. Одним игровым проектом на физике box2d стало больше, закончили онлайн-файтинг на физике ragdoll. Хотелось бы сделать некоторые выводы и рассказать об основных технических проблемах, с которыми пришлось столкнуться, и о методах их решения. Статья заинтересует начинающих разработчиков [флеш-]игр с использованием физических движков. Фокус делается на сетевом слое для движка физики.
koriza @koriza
Пользователь
Учёт ресурсов в облаках
7 мин
Слова «облако», «облачные вычисления», «облачный» используются для чего попало. Новое модное слово, buzzword. Мы видим «облачные антивирусы», «облачные блейд-сервера». Даже именитые вендоры сетевого оборудования, не стесняются выставлять коммутаторы с ярлыком «for cloud computing». Это вызывает инстинктивную неприязнь, примерно, как «органические» продукты питания.
Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку. Он будет прав. Облака, в том виде, как их делают сейчас — обычные виртуальные машины.
Однако, облака, это не только маркетинг и переименованные VDS. У слова «облако» (или, точнее у фразы «облачные вычисления») есть есть своя техническая правда. Она не такая патетичная и восхитительно-инновационная, как рассказывают маркетологи, но она всё-таки есть. Придумана она была много десятилетий назад, но только сейчас инфраструктура (в первую очередь, Интернет и технологии виртуализации x86) доросла до уровня, который позволяет реализовать её в массовом порядке.
Итак, сначала о причине, которая вообще породила потребность в облаках:
Вот как выглядит предоставляемая услуга для обычного VDS (на месте этого графика может быть любой ресурс: процессор, память, диск):
Обратите внимание: это недельный график. Существующие технологии временного увеличения лимита потребления ресурса (burst, grace period) не способны решить эту проблему на таких длинных интервалах. Т.е. машина недополучает ресурсы тогда, когда они ей больше всего нужны.
Вторая проблема — посмотрите на огромные интервалы (голубой цвет), когда ресурсы, фактически, пришлось оплатить, но использовать не удалось. Виртуальной машине ночью просто не нужно столько ресурсов. Она простаивает. И не смотря на это — владелец платит по полной.
Возникает проблема: человек вынужден заказывать ресурсов больше, чем нужно в среднем, для того, чтобы переживать без проблем пики. В остальное время ресурсы простаивают. Провайдер видит, что сервер не нагружен, начинает продавать ресурсов больше, чем есть (это называют «оверселл»). В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства. Он обещал 70 человекам по 1Ггц — но у него есть только 40 (2.5*16 ядер). Нехорошо.
Продавать полосу честно (без оверселла) невыгодно (и цены нерыночные получаются). Оверселлить — снижать качество сервиса, нарушать условия договора.
Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продавать простаивающие ресурсы?
Именно ответом на эту проблему и стала идея «облачных вычислений». Слова хоть и модные, но своей основой уходящие во времена больших мейнфреймов, когда продавалось машинное время.
Облачные вычисления делают то же самое — вместо лимитов и квот, которые оплачиваются вне зависимости от реального потрбления, пользователям предоставляется возможность использовать ресурсы без ограничения, с оплатой реального потребления (и только того, что было реально использовано). Это и есть суть «облака».
Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку. Он будет прав. Облака, в том виде, как их делают сейчас — обычные виртуальные машины.
Однако, облака, это не только маркетинг и переименованные VDS. У слова «облако» (или, точнее у фразы «облачные вычисления») есть есть своя техническая правда. Она не такая патетичная и восхитительно-инновационная, как рассказывают маркетологи, но она всё-таки есть. Придумана она была много десятилетий назад, но только сейчас инфраструктура (в первую очередь, Интернет и технологии виртуализации x86) доросла до уровня, который позволяет реализовать её в массовом порядке.
Итак, сначала о причине, которая вообще породила потребность в облаках:
Вот как выглядит предоставляемая услуга для обычного VDS (на месте этого графика может быть любой ресурс: процессор, память, диск):
Обратите внимание: это недельный график. Существующие технологии временного увеличения лимита потребления ресурса (burst, grace period) не способны решить эту проблему на таких длинных интервалах. Т.е. машина недополучает ресурсы тогда, когда они ей больше всего нужны.
Вторая проблема — посмотрите на огромные интервалы (голубой цвет), когда ресурсы, фактически, пришлось оплатить, но использовать не удалось. Виртуальной машине ночью просто не нужно столько ресурсов. Она простаивает. И не смотря на это — владелец платит по полной.
Возникает проблема: человек вынужден заказывать ресурсов больше, чем нужно в среднем, для того, чтобы переживать без проблем пики. В остальное время ресурсы простаивают. Провайдер видит, что сервер не нагружен, начинает продавать ресурсов больше, чем есть (это называют «оверселл»). В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства. Он обещал 70 человекам по 1Ггц — но у него есть только 40 (2.5*16 ядер). Нехорошо.
Продавать полосу честно (без оверселла) невыгодно (и цены нерыночные получаются). Оверселлить — снижать качество сервиса, нарушать условия договора.
Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продавать простаивающие ресурсы?
Именно ответом на эту проблему и стала идея «облачных вычислений». Слова хоть и модные, но своей основой уходящие во времена больших мейнфреймов, когда продавалось машинное время.
Облачные вычисления делают то же самое — вместо лимитов и квот, которые оплачиваются вне зависимости от реального потрбления, пользователям предоставляется возможность использовать ресурсы без ограничения, с оплатой реального потребления (и только того, что было реально использовано). Это и есть суть «облака».
XSS-червь: кто меньше?
2 мин
Наткнулся на днях на новость о конкурсе, в котором предлагают создать минимальный JavaScript-код, который будет сам себя копировать дальше. Автор конкурса — Robert Hansen aka RSnake, достаточно крупный специалист по информационной безопасности.
По условиям конкурса от кода требовалось следующее:
Условия
По условиям конкурса от кода требовалось следующее:
Compiz Fusion — Не только красиво, но и удобно!
4 мин
В наши времена, когда найти человека способного удивиться графическим 3д-ефектам операционной системы становиться всё сложнее, а сами эффекты становятся все ярче и тяжеловеснее, большинство пользователей воспринимают их как ненужное украшательство и бесполезную трату ресурсов системы. Потому и просто напросто отключают, даже не заглянув в суть.
А ведь может быть не только красиво, а ещё и удобно!
Поэтому я хочу рассказать о Compiz Fusion (бывшем Beryl) — композитном оконном менеджере, который занимаеться визуальными эффектами в Linux. Только рассказать не со стороны wow-эфекта и 3д-рюшечек, а о том, как при грамотной настройке с его помощью можно добавить максимум удобства и юзабилити к своей любимой системе.
А ведь может быть не только красиво, а ещё и удобно!
Поэтому я хочу рассказать о Compiz Fusion (бывшем Beryl) — композитном оконном менеджере, который занимаеться визуальными эффектами в Linux. Только рассказать не со стороны wow-эфекта и 3д-рюшечек, а о том, как при грамотной настройке с его помощью можно добавить максимум удобства и юзабилити к своей любимой системе.