Кодек для сжатия без потерь LZHAM обеспечивает коэффициенты архивации на уровне LZMA, но зато демонстрирует в 1,5-8 раз более высокую скорость декомпрессии. Написан на C/С++.
Первая версия официально работает под Linux x86/x64, Windows x86/x64, OS X и iOS. Скоро обещают поддержку Android. Программный код вчера опубликован на Github.
Кодек LZHAM специально оптимизирован для максимально высокой скорости декомпрессии на высоких уровнях сжатия. При этом он снабжён программными интерфейсами, совместимыми с zlib. Его разработка велась около трёх лет усилиями, преимущественно, Рича Гельдрейха (Rich Geldreich), бывшего программиста Valve, который занимался в этой фирме проектами, связанными с Linux и OpenGL. Как выяснилось теперь, свободное от работы время он уделял проекту LZHAM.
На современном оборудовании Intel кодек LZHAM показывает скорость декомпрессии гораздо выше, чем LZMA. При этом степень сжатия практически не отличается, LZHAM уступает совсем немного.
LZHAM может быть особенно полезен при использовании на встроенных системах, на игровых платформах и в других приложениях, где скорость декомпрессии является критически важным фактором. В принципе, это любые приложения, где архивация осуществляется в офлайне, а затем архив распространяется для большого количества пользователей.
Автор кодека говорит, что наибольший выигрыш от использования LZHAM по сравнению с LZMA достигается при декомпрессии данных объёмом между 1000 и 13000 байт.
Результаты независимого сравнения производительности кодеков см. здесь и здесь (там представлена альфа-версия LZHAM). Более свежие бенчмарки опубликованы в блоге Гельдрейха.
Координируя работу соседних хотспотов и грамотно распределяя между ними частоты и количество радиоканалов для связи, можно значительно повысить общую пропускную способность сети.
Проблема в том, что сейчас соседские WiFi-хотспоты работают в «эгоистичном» режиме, не согласовывая друг с другом частоты и часто захватывая одинаковые диапазоны, из-за чего возникает интерференция, а скорость доступа снижается у всех клиентов.
Докторант Жульен Герцен (Julien Herzen) из Федеральной политехнической школы Лозанны с коллегами в 2013 году предложил децентрализованный алгоритм SAW: Spectrum Assignment for WLANs, способный решить эту проблему. Если такой алгоритм внедрят все производители домашних маршрутизаторов, то выгода будет существенной.
Алгоритм пытается решить проблему оптимизации, учитывая интерференцию каналов (I) и пропускную способность сети (b).
За прошедшие полтора года проведено несколько симуляций и экспериментов в реальных условиях, которые доказывают эффективность SAW. Например, такой опыт был проведён в здании Федеральной политехнической школы Лозанны в кластере из 21 беспроводной точки доступа (все работали на стандартном коммерческом оборудовании с прошивкой OpenWrt и драйвером ath9k).
На диаграмме легко заметить, насколько повышается суммарная скорость после активации SAW в районе 600-й секунды эксперимента.
Герцен с коллегами подали заявку на патент и надеются продать лицензии производителям WiFi-маршрутизаторов.
Пятый международный форум по практической безопасности Positive Hack Days состоится 26 и 27 мая 2015 года в московском Центре международной торговли. На конференции, организованной компанией Positive Technologies, соберутся ведущие специалисты по киберзащите и элита хакерского мира, представители государственных структур и руководители крупного бизнеса, молодые учёные и журналисты.
В начале декабря стартовал приём заявок от желающих выступить на PHDays V, и сейчас анонсирована первая группа участников, попавших в основную техническую программу форума.
Создатель Shodan в Москве
Одним из ключевых событий PHDays станет выступление Джона Мэтерли (John Matherley), создателя «самого страшного поисковика».
Как раскрыть ботнет
Владельцы ботнетов стремятся затруднить обнаружение управляющих серверов, которые контролируют заражённые компьютеры. Для этого они применяют различные способы маскировки, среди которых и специальные алгоритмы создания доменных имен (domain generation algorithms, DGA). С их помощью возможна регистрация доменов, сформированных по псевдослучайному принципу, например в зависимости от текущей даты: постоянно меняющийся адрес управляющего сервера затрудняет обнаружение.
Главный кибердетектив компании Bambenek Consulting Джон Бамбенек (John Bambenek) расскажет о том, как осуществлять обратную разработку алгоритмов DGA для обнаружения ботнетов и получения информации об их конфигурации практически в режиме реального времени.
Соревнования мастеров социнженерии
Крис Хаднаги (Chris Hadnagy), основатель компании Social-Engineer и администратор сайта social-engineer.org, поделится своим опытом подготовки соревнований для «социальных инженеров» DEFCON SECTF. Цель таких соревнований — познакомить ИБ-специалистов с проблемами социальной инженерии и показать широкой аудитории, насколько опасно мошенничество с использованием психологических методов.
Мастер-класс по RFID: от низких к высоким частотам
Основное внимание в ходе мастер-класса по RFID ведущий уделит высокочастотной идентификации, но будут рассмотрены и низкие радиочастоты, поскольку они нередко используются при организации контроля доступа в помещения (подъезды домов, офисы, гаражи, отели). Кроме того, будут затронуты темы безопасности мобильных платежных сервисов, а также технологий Paypass, Paywave и NFC USIM.
Занятие проведёт Науэль Грисолия (Nahuel Grisolía) — аргентинский ИБ-эксперт и предприниматель, который специализируется на безопасности веб-приложений и взломе аппаратного обеспечения. Он обнаружил уязвимости в McAfee Ironmail, VMware и Manage Engine Service Desk Plus, а также в ряде проектов, посвященных разработке свободного ПО: Achievo, Cacti, OSSIM, Dolibarr и osTicket. Проводил мастер-классы на международных конференциях, в числе которых и Positive Hack Days III (слайды выступления).
Как попасть на PHDays
Первый этап Call for Papers продлится до 30 января. Специалисты по информационной безопасности могут представить свои исследования, чтобы выступить 26 и 27 мая на форуме. Полный список докладов будет опубликован в апреле на официальном сайте мероприятия (все лучшее с прошлого года см. на Хабрахабре).
Информацию о других способах попасть в число участников ты найдёшь на официальном сайте PHDays. Приобрести билеты можно на странице «Принять участие». До 30 января действует скидка: билет на два дня форума стоит 7337 руб. Скоро стоимость участия возрастет сначала до 9600 руб., затем до 14 400 руб.
Компания «Графитек», эксклюзивный дистрибьютор бренда ASTRO Gaming в России, завезла в страну второе поколение гарнитур ASTRO. Гаджеты оптимизированы для работы с игровой приставкой Xbox One. Серия гарнитур представлена тремя моделями: A50, A40 и А30.
Поддержкой Xbox One дело не ограничивается. Линейка гарнитур ASTRO Generation 2 также совместима с ПК или Mac (если у них есть оптический выход), подключается к PlayStation 3, PlayStation 4 — все необходимое есть в комплекте. Для подключения к Xbox 360 нужно докупить кабель Xbox Live Chat Cable (2.5mm – 2.5mm), чтобы подключить гарнитуру прямо к контроллеру Xbox 360.
Обновленная серия гарнитур относится ко второму поколению игровых гарнитур ASTRO — Generation 2, отличительными чертами которого являются:
Высокое качество звука
Более удобная и более долговечная конструкция
Улучшенная эргономика (по сравнению с Gen1)
Специальный адаптер для подключения гарнитуры к контроллеру Xbox One (в старых версиях ASTRO A50 такого переходника нет)
Гарнитуры нового поколения с поддержкой Xbox One также отличаются от своих предшественниц новым цветовым исполнением.
ASTRO A50 Gen2
ASTRO A40 Gen2
Официальные трейлеры нового поколения гарнитур ASTRO A50 доступны по ссылкам:
Интересно, что игровой портал IGN.com охарактеризовал второе поколение ASTRO Gaming весьма нескромными словами: «Гарнитуры ASTRO A50 выполнили невыполнимое — улучшили совершенство».
ASTRO Gaming — известный бренд среди поклонников видеоигр и киберспортсменов в США и Европе, главной миссией которого является выпуск аудиосистем, наушников и гарнитур, способных удовлетворить требованиям самых заядлых геймеров.
Гарнитуры серии ASTRO A50 второго поколения получили несколько наград от крупнейших игровых ресурсов, максимальную оценку им выставили такие сайты, как Kotaku, PC Magazine и Game Informer. Вот ещё парочка нескромных цитат из этих статей:
OpenStack — очень модное слово в современном айтишном медиапространстве. Слышал о нем практически каждый, но в деле видели не очень многие. А попробовать его всерьез отважились вообще единицы. Мы у себя рискнули-таки, и сегодня я расскажу, чем это для нас обернулось и почему мода зачастую бежит впереди рассудительности и стабильности.
Мы уже как-то писали краткий обзор «карманной облачной инфраструктуры» в одном из предыдущих номеров, но было это давно и неправда (подумать только, уже почти три года прошло!). Так что на всякий случай вот краткая выжимка: OpenStack — это открытая (Apache License 2.0) платформа, позволяющая малыми силами организовать на любом количестве железных серверов облачную инфраструктуру а-ля Amazon Web Services. Тут вам и масштабирование виртуалок, и живые миграции, и балансировка нагрузки по нодам, и устойчивость к выходу из строя некоторого процента узлов. В числе основных разработчиков — небезызвестная NASA и Rackspace, Red Hat, Canonical, IBM, AT&T и некоторые другие конторы. В целом затея благая и очень дельная — такой инструмент, в теории, был бы полезен при разработке различных новых систем и сервисов, позволяя на ходу жонглировать инфраструктурой, экспериментировать с архитектурой. Но это все в теории и официальном описании. А что в жизни?
История первая
В жизни все сильно сложнее. OpenStack — это как беременность в шестнадцать. Завести его себе обычно оказывается сильно проще, чем потом с ним адекватно сосуществовать. Через день, неделю, если повезет, то через месяц придет Осознание. К примеру, в один не очень прекрасный момент по какой-то причине виртуалки просто перестанут создаваться. Все хорошо, все есть — и место на дисках, и свободные вычислительные мощности, и IP-адреса в сети. Но нет. Висит себе в состоянии Creating Instance, и все. Полчаса, час, два, пять. Ничего не происходит. В логах тишина. Еще несколько часов, проведенных в гугле, наудачу перезагружаем «кролика», и оп — все внезапно заработало. Виртуалки создаются, поднимаются, все снова хорошо. Вопрос «И что это было?» повисает в воздухе.
История вторая
Еще через месяц, к примеру, Hetzner, в котором стоят серверы с твоим OpenStack’ом, вдруг решает провести техработы по части электропитания. И оказывается, что Compute-нода как раз под эти техработы попадает. Ты заблаговременно останавливаешь на ней все сервисы, сам руками выключаешь сервер. Ждешь положенные пару часов, нода после технических работ поднимается. Вот только ничего не работает. Ни одна виртуалка не доступна. Заходишь в панель — на первый взгляд, все выглядит прилично и как должно. Опять непонятно. Идешь руками на сервер по SSH, virsh list. Виртуалки на месте, поднялись, virsh -c qemu+ssh://username@host/system — оп! No route to host. Как так? ifconfig && iptables-save, сетевых интерфейсов нет. Логи, гугл, логи, гугл, логи, логи, гугл. С мертвой точки дело не сдвигается. По старой виндузявой привычке наудачу решаешь перезагрузить сервер еще раз. Так, на всякий случай. Сервер выходит из ребута, все поднимается и работает. Стараясь не делать резких движений, выходишь из панели стака и с сервера и решаешь по возможности больше никогда к нему не подходить.
Злоключение
Как уже успели на себе прочувствовать те немногие, кто решился использовать OpenStack в относительном продакшене, он еще «не готов для десктопа». Пока, к сожалению, он не дает удовольствия ограничить общение с собой исключительно нажиманием кнопочек в веб-интерфейсе для создания новых виртуалок и распределением доступов к ним. Шаг вправо, шаг влево — и можно наткнуться на что-то такое, про что еще даже в гугле не написали. И на отладку может уйти не только не один день, но даже не одна неделя. Ребята в одной из самых известных компаний — поставщиков готовых решений на базе OpenStack сравнивают этот процесс с постройкой дома:
«При упоминании OpenStack хороша аналогия с домом. OpenStack опирается на множество сложных открытых проектов, слепленных друг с другом через различные API, которые зачастую ставят в тупик даже самых прожженных инженеров. С точки зрения бизнеса попытка самостоятельно во всем этом разобраться может пагубно сказаться на сроках сдачи проекта и достижении поставленных целей. Подход „сделай сам“ пока еще очень популярен в среде OpenStack-новичков и часто не приводит их к сколько-нибудь удовлетворительному результату, отчего мнение о всей системе остается не очень лестное.
Главной целью поставщика готовых решений в данном случае является помощь в проектировании и развертывании надежной площадки для проектов клиента. И ключевой момент в данном вопросе — правильный выбор опытного поставщика, который сможет собрать все необходимые части системы, корректно их связать и в дальнейшем поддерживать то, что получилось. Пожалуйста, доверьте поддержку OpenStack проверенному поставщику».
В чем-то с ними даже можно согласиться. Далеко не каждый может позволить себе тратить такое количество админо-часов на даже банальное поддержание текущей работоспособности системы, не говоря уже о каком-то дальнейшем развитии.
О новинках
Но если капризы работоспособности OpenStack’а — это уже в некоторой степени стабильный вопрос, немало обшученный, то новинкам проекта, думаю, стоит уделить внимание.
Heat
Heat — это основной инструмент оркестровки, используемый в мире OpenStack. Он позволяет запускать готовые облачные архитектуры из темплейтов, описанных текстом, своего рода подобием программного кода. Формат темплейтов у Heat свой собственный, но помимо него поддерживается совместимость с форматом AWS CloudFormation. Таким образом, многие уже готовые темплейты CloudFormation вполне можно будет запускать и под OpenStack’ом. У Heat есть возможность общаться с внешним миром как через родной ReST API OpenStack’а, так и через совместимый API запросов CloudFormation’а.
Архитектура Heat
Как это вообще работает?
Темплейты облачной инфраструктуры — это обычные умеренно человеко-понятные plain-text документы, их можно хранить в системах контроля версий, удобно сравнивать, делать патчи и прочее.
Список элементов инфраструктуры, доступных для описания в темплейтах: серверы, IP-адреса, тома, группы безопасности, пользователи, ключи и так далее.
Heat предоставляет возможность организации автоматического масштабирования под нагрузкой при интеграции с Ceilometer (о нем чуть дальше).
Естественно, в темплейтах также описываются не только отдельные ресурсы, но и их взаимоотношения — привязка томов и адресов к конкретным серверам, определение конкретных серверов в конкретные группы безопасности, распределение доступов к серверам между пользователями и многое другое. Это позволяет максимально полно автоматизировать разворачивание необходимой инфраструктуры через API OpenStack’а, избегая дополнительного ручного вмешательства.
Heat контролирует и изменения в инфраструктуре. Когда тебе надо что-то поменять, просто вносишь нужные правки в соответствующий темплейт и обновляешь конфигурацию Heat, и он уже там сам разбирается и приводит все к эталону.
Кусок примерного темплейта для Heat
Ничего знакомого в этом всем не заметил? Правильно, схожие идеи мы уже видели в таких проектах, как Chef и Puppet. Использовать или нет — это уже на твой вкус. Говорят, у Heat’а даже есть какое-то подобие интеграции с ними, но мы пока не пробовали, так что детальнее рассказать, к сожалению, не смогу.
Ceilometer
Ceilometer — это инструмент для сбора различных статистических данных в облаке OpenStack. Основной целью проекта является мониторинг нагрузки и измерения потребления ресурсов клиентами, но возможности фреймворка могут быть расширены и для других нужд. Доступ к метрикам можно получать через отдельно реализованный REST API.
Архитектура Ceilometer
Центральный агент (Central Agent) опрашивает данные по утилизации ресурсов, которые не связаны с виртуальными машинами или вычислительными узлами (Compute Nodes). В каждой системе Ceilometer может быть запущен только один центральный агент.
Вычислительный агент (Compute Agent) собирает данные измерений и статистику с вычислительных узлов (в основном гипервизора). Вычислительный агент должен быть запущен на каждом вычислительном узле, состояние которого необходимо отслеживать.
Коллектор (Collector) отслеживает очереди сообщений (на предмет уведомлений, которые присылает инфраструктура, и на предмет результатов измерений от агентов). Уведомления обрабатываются, преобразовываются в измерительные данные, затем подписываются и возвращаются на шину передачи сообщений в соответствующую тему. Коллектор может работать на одном или нескольких серверах управления.
Хранилище данных (Data Store) — это база данных, которая может обрабатывать одновременные запись (с одного или нескольких коллекторов) и чтение данных (с API-сервера). Коллектор, центральный агент и API могут работать на любом узле.
Эти службы сообщаются с помощью стандартной шины передачи сообщений OpenStack. Только коллектор и API-сервер имеют доступ к хранилищу данных. Поддерживаются SQL базы данных, совместимые с SQLAlchemy, а также MongoDB и HBase. Однако разработчики Ceilometer рекомендуют именно MongoDB, в связи с более эффективной обработкой одновременных операций чтения/записи данных. Кроме того, только конфигурация Ceilometer с MongoDB прошла тщательное тестирование и развертывание в коммерческих средах. Для базы данных Ceilometer рекомендуется использовать выделенный узел, так как инфраструктура может создавать изрядную нагрузку на БД. Согласно оценкам разработчиков, измерение инфраструктуры на коммерческом уровне предполагает до 386 записей в секунду и 33 360 480 событий в день, что потребует до 239 Гб для хранения статистики за месяц.
Архитектура Ceilometer
В проекте Ceilometer реализованы три типа измерений:
Cumulative (кумулятивные): их еще можно назвать инкрементальными — значения, которые все время растут (к примеру, аптайм виртуальной машины);
Gauge (индикатор): отдельные события и значения (например, IP-адреса, привязанные к тому или иному серверу, или данные по вводу-выводу дисковой подсистемы);
Delta (дельта): изменение со временем (например, пропускная способность сети).
Каждый измеритель собирает данные с одного или нескольких образцов (собираемых из очереди сообщений или агентами), которые представлены счетчиками. Каждый счетчик имеет следующие поля:
counter_name. Строка названия счетчика. По общепринятому соглашению точка используется как разделитель при переходе от наименее конкретного слова к наиболее конкретному (например, disk.ephemeral.size);
counter_type. Тип счетчика (кумулятивный, индикатор, дельта, см. выше);
counter_volume. Объем измеряемых данных (такты ЦП, число байтов, переданных по сети, время развертывания виртуальной машины и так далее). Это поле несущественно для счетчиков типа индикатор; в этом случае ему должно быть присвоено значение по умолчанию (обычно 1);
counter_unit. Описание единицы измерения счетчика. Для обозначения используются единицы измерения системы СИ и их утвержденные сокращения. Количество информации должно выражаться в битах (б) или байтах (Б). Когда измерение представляет собой не количество данных, описание всегда должно содержать точную информацию, что измеряется (виртуальные машины, дисковые тома, IP-адреса и так далее);
project_id. Идентификатор проекта, которому принадлежит ресурс;
user_id. Идентификатор пользователя, которому принадлежит ресурс;
resource_metadata. Некоторые дополнительные метаданные для информационного наполнения сообщения об измерении.
Полный список доступных на данный момент измерений можно найти в документации Ceilometer (https://wiki.openstack.org/wiki/Ceilometer).
Ceilometer — это довольно перспективный проект, ставящий своей целью унификацию возможностей по сбору информации обо всех аспектах жизни облачной инфраструктуры. Использование Ceilometer позволяет поставить «карманное облако» на достаточно крепкие коммерческие рельсы.
Зе енд
Как видно, не все так просто в Датском королевстве. Есть там место и бедам и приключениям. OpenStack развивается очень активно, но все еще не готов к быстрому и простому использованию в производстве, как некоторые продукты коммерческой виртуализации прошлого поколения.
Если виртуализация — это одно из основных направлений твоей деятельности, то, без сомнения, уже пора начинать в нем разбираться. Если нет, но все равно интересно, то, пожалуйста, пробуй, но в производство без крайней нужды пускать не советую. На данный момент лучше будет пользоваться классическими системами виртуализации всем, у кого нет особых против того противопоказаний. Сбережете много нервов и денег. Мы же у себя подумываем в некотором не очень отдаленном будущем тоже открывать направление поддержки OpenStack-решений. Кажется, это будет довольно интересно :).
В любой момент времени десятки миллионов человек используют BitTorrent для обмена «пиратским» контентом: кинофильмами и телесериалами. Новый сайт Pirate Cinema выводит самые популярные видеотрансляции на общий экран.
Pirate Cinema — концептуальный проект на стыке цифрового искусства и современных технологий. Генерация контента осуществляется автоматически на одном сервере по простому алгоритму. Он отслеживает статистику по трекерам, скачивает 100 самых популярных торрентов и ретранслирует их через веб-сайт.
Проект реализовал художник Николя Мегрэ (Nicolas Maigret). В течение двух лет он демонстрировал свою работу на разных фестивалях цифрового искусства, а на прошлой неделе впервые запустил его в онлайне.
На экране Pirate Cinema отображается не только видеопоток, но также IP-адреса и страны источника раздачи и получателя (IP-адреса частично скрыты в целях безопасности). Это сделано для большей реалистичности эксперимента и чтобы показать, насколько легко получить такую информацию.
Николя Мегрэ говорит, что демонстрация IP-адресов символизирует вездесущую слежку, которая осуществляется за пользователями в интернете. В то же время, демонстрация передачи файлов из страны в страну показывает, как современные технологии файлообмена способствуют культурному обмену в глобальном мире. Зачастую P2P является единственным способом получить доступ к контенту. Таким образом, трудно переоценить важность этой технологии для культурного развития человеческой цивилизации.
Кто сказал, что радиолюбители лишены чувства прекрасного? Автор художественного проекта The Clock наглядно опровергает это утверждение. Он потратил три года, чтобы вручную спаять великолепную трёхмерную структуру. На изготовление ушёл 1161 диод, 340 транзисторов, 340 резисторов, 60 светодиодов, 6 магнитных переключателей и 3 сдвоенных цифровых дисплея. Общее количество деталей — 1916 штук, плюс 3-миллиметровое стекло сверху и блок питания, спрятанный позади корпуса.
The Clock — это не просто часы, а настоящий символ богу времени, если бы такой существовал. Электрическая цепь демонстрирует в увеличенном масштабе примерно то, что мы бы увидели под микроскопом, если бы рассмотрели микросхему, установленную в обычных электронных часах.
Хотя велик соблазн повторить подвиг и изготовить копию The Clock, но сделать это непросто. Дело в том, что электрическая цепь из этого проекта синхронизирует счётчик секунд по импульсам от источника переменного тока с частотой 60 Гц, какие используются в энергосетях Северной Америки. Если запустить его в нашей сети с частотой 50 Гц, то часы будут неправильно показывать время. Поэтому перед началом работы придётся внести изменения в оригинальную электросхему.
В часах отсутствуют кнопки, для коррекции времени используются специальные магниты. Шесть магнитных переключателей установлены в разных фрагментах цепи.
2. Front-end Job Interview Questions: подходящие вопросы для кандидатов на должность frontend-разработчика. Список очень большой, так что можно выбрать несколько наиболее понравившихся вариантов — и использовать их на интервью. С другой стороны, кандидаты тоже могут готовиться по этому списку.
3. What happens when…: ещё одна попытка ответа на вечный вопрос: что происходит, когда ты набираешь google.com в адресной строке браузера и нажимаешь кнопку Enter. Для понимания последующих событий требуется фундаментальное образование в области информатики, архитектуры компьютерных систем и программирования.
9. Paperwork: сервис для заметок и хранения документов, свободная альтернатива Evernote, Microsoft OneNote и Google Keep.
10. TIL (Today I Learned): репозиторий небольших документов, где программисты делятся друг с другом маленькими приёмами и трюками (несколько предложений + пример кода).
