Facebook Hacker Cup 2011 проходит в 4 раунда — квалификационный, два онлайн раунда и финальный, в главном офисе.

Квалификационный раунд, анонсированный официально Хабром завершился успешно.
Результаты раунда говорят о 5846 игроках, прошедших в первый онлайн тур.
Участникам квалификационного раунда предлагалось 3 задачи, для прохождения достаточно было правильного решения любой из них.

А вот первый онлайн раунд, прервав ближе к завершению, перенесли из-за технических проблем минимум на неделю:
We've decided to push back the remaining subrounds of round 1 until we are sure that they can run smoothly. Updates will follow here, but you can safely assume that the subrounds will not occur at least until next weekend.

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

Бывают ситуации, когда читерство в сетевых играх переходит границу стандартной защиты и становится на первый взгляд непреодолимой проблемой.
Но даже в таких ситуациях можно найти выход.
В этой статье пойдет речь о не очень популярной игре ARMA 2 и не совсем обычных методах борьбы с читерами.
Тематика (игровое администрирование) довольно необычная для хабра, но она также имеет отношение к IT, и я считаю, вполне заслуживает внимания.

Многие из вас знакомы с Оверсаном по статьям в нашем блоге на Хабре, где мы много рассказывали об архитектуре систем ДЦ Оверсан-Меркурий. Об архитектуре облака Скалакси мы тоже рассказывали, но в основном на профильных конференциях, многие наши доклады и презентации уже устарели и стали неактуальны.

Мы думаем, что многие из подсистем и архитектурных решений в Скалакси будут вам интересны и решили о них рассказать. Начать именно с темы распределения ресурсов CPU решили потому, что вопрос о гарантированном объеме вычислительных ресурсов всегда на слуху: мы регулярно слышим его от клиентов, просто интересующихся, критиков и блоггеров.

Чтобы разобраться с распределением ресурсов, придется рассмотреть архитектуру нашей системы виртуализации хотя бы в общих чертах и детально изучить частности. В этой статье я постараюсь объяснить, как работает распределение вычислительной мощности CPU между виртуальными машинами клиентов: сколько времени CPU достается каждой VM и за счет чего это достигается.

Журнал Forbes опубликовал интервью с 35-летним американским программистом Яном Панасюком (Yan Panasjuk), который купил во вселенной Entropia Universe большую часть космического курорта Neverdie, включая семь биозданий, стадион, ночной клуб и торговый центр. Эта покупка признана самой крупной сделкой с виртуальной недвижимостью в истории компьютерных игр.



Зачем советский эмигрант из Бостона вложил такие большие деньги в столь эфемерную вещь как виртуальная недвижимость? Вот что Ян ответил в онлайновом интервью Forbes.

Перед тем, как перейти собственно к возможностям Stackless и Concurrence, рассмотрим самый простой способ написать сетевое приложение, обрабатывающее несколько одновременных соединений:

socket()
bind()
listen()
accept()
fork() ->
    read()
    write()
    ...
    close()

Под каждое новое входящее соединение процесс создаёт свою копию через fork(). Это чрезвычайно накладный способ, у которого, к тому же, есть сложности с синхронизацией между процессами. В простом случае они решаются через создание каналов (pipes) между родительским и дочерним процессами и сериализацию данных. В более сложных потребуются примитивы межпроцессной синхронизации. Вспомним ещё про затраты на создание, разрушение и переключение процессов. Это очень ресурсоёмкие операции — как по памяти, так и по вычислительной мощности. Поэтому обработать много одновременных соединений будет весьма сложно.