[Из песочницы] Готовим многопоточность с core.async

Всё больше набирает популярность паттерн использования каналов при создании
многопоточных приложений. Идея не нова, ее дизайн заложен ещё в далёком 1978 году
в виде CSP.Наиболее известная реализация сейчас повсеместно используется в Golang.

Мы же в статье рассмотрим реализацию CSP в core.async для Clojure, если интересно, добро пожаловать под кат.

В статье будут рассмотрены простые и базовые практики для работы с core.async, описанного в статье будет достаточно для хорошего старта в многопоточное программирование.

В отличии от Golang где парадигма работы с потоками через каналы встроена в сам язык, core.async является просто библиотекой для Clojure, если вам импонирует другая парадигма, то выбор есть: pulsar, promesa, manifold

При этом core.async и promesa можно также использовать на стороне браузера в ClojureScript, естественно в этом случае ни о какой многопоточности говорить не приходится, так как все это добро компилируется в ES5 и исполняется в браузере, но знакомый интерфейс и удобная работа с асинхронностью может хорошо послужить.

Так что же нам дает core.async? Если объяснять на пальцах то core.async нам предоставляет диспетчеризацию через go-блоки в свой фиксированный Thread Pool состоящий из 8 тредов (размер Thread Pool можно менять через специальную опцию). При поступлении сообщения в канал, core.async сам найдет свободный поток, и передаст ему задачу, либо поставит сообщение в очередь. Кто впервые слышит про Thread Pool можно почитать хорошую заметку по паттерну Worker Thread

---

Пример № 1

(defonce log-chan (chan))

(defn loop-worker [msg]
  (println msg))

(go-loop []
  (let [msg (<! log-chan)]
    (loop-worker msg)
    (recur)))

В примере выше, мы создали канал log-chan, и определили функцию loop-worker которая будет обрабатывать сообщения из канала.Затем создали go-block с бесконечным циклом, поместив туда наш loop-worker.Теперь мы можем отправить данные в канал: (>!! log-chan "привет")

Функция loop-worker была вынесена отдельно за go-block умышленно, ради удобной ее отладки через REPL.

Само тело go-loop так как это макрос запекается где то внутри core.async, и перекомпиляция его на лету в REPL носит странный характер, поэтому обработчик проще вынести отдельно и жить спокойно.

Тут стоит заметить что никакого бесконечного цикла в привычном его понимании go-loop не делает.
После получения сообщения, происходит разовое выполнения функции обработчика, а затем go-block паркуется функцией <! которая будет ждать нового сообщения. Таким образом можно создавать сколько угодно много каналов и обработчиков к ним.

В пределах go-блока функция чтения из канала <! осуществляет парковку потока.
За пределами go блока есть возможность использовать для чтения из канала функцию <!! которая блокирует основной поток до получения сообщения. Поведение <!! можно сравнить с функцией await в ES7.

Parking go блока, это термин core.async означающий, что поток освобожден, и доступен для других задач. Также существует термин blocking, который означает что поток будет непосредственно заблокирован и недоступен для новых задач до его освобождения.

В примере №1 есть изъян, если в loop-worker будет вызван Exception, то произойдет прерывание выполнения формы, и (recur) никогда не будет вызван, следовательно ожидание данных из канала log-chan прекратится, исправим это в примере № 2.

Пример № 2

(defonce log-chan (chan))

(defn loop-worker [msg]
  (throw (Exception. "my exception message")))

(go-loop []
  (let [msg (<! log-chan)
        res (try
              (loop-worker msg)
              :ok
              (catch Exception e
                (println (.getMessage e))
                :error))]
    (recur)))

В этом примере мы обернули весь вызов loop-worker в форму try, а переменная res, будет содержать флаг, сообщающий об успешном выполнении формы или же об ошибке. Этот флаг может пригодится, например, если мы захотим закрыть канал в случае ошибки. Рабочий пример этого подхода можно посмотреть тут

Пример № 3

  (let [c1 (go (<! (timeout (rand-int 1000))) 5)
        c2 (go (<! (timeout (rand-int 1000))) 7)]
    (go (let [v1 (<! c1)
              v2 (<! c2)]
          (println {:v1 v1
                    :v2 v2
                    :summ (+ v1 v2)}))))

Данный пример будет ждать результата от всех асинхронных операций перечисленных в блоке let. Эта практика очень удобна для решения проблемы callback hall в JavaScript, и очередной повод порадоваться что это можно использовать на стороне браузера в лице ClojureScript.

Пример № 4

(defn upload 
 "upload emulator"
  [headshot c time]
  (go (Thread/sleep time)
      (>! c headshot)))

  (let [c1 (chan) c2 (chan)]
    (upload "pic1.jpg" c1 30)
    (upload "pic2.jpg" c2 40)
    (let [[headshot channel] (alts!! [c1 c2 (timeout 20)])]
      (if headshot
        (println "Sending headshot notification for" headshot)
        (println "Timed out!"))))

В этом примере мы создали функцию upload эмулирующую асинхронную операцию, в данном случае загрузку файла. Последним аргументом upload, принимает время задержки в миллисекундах. С помощью функции alts!!! мы можем получить первый же результат, который нам вернет один из перечисленных в векторе каналов. В нашем векторе, последним каналом идет (timeout 20), этот канал нам вернет результат через 20 миллисекунд, и это будет первым значением которое будет записано в переменную headshot и будет продолжено выполнение формы. Таким образом данный пример эмулирует установку времени на timeout, в течении которого мы будем ждать выполнения набора асинхронных операций.

Пример № 5

(def ping (chan))
(def pong (chan))

(go-loop []
  (let [msg (<! ping)]
    (when (= msg :ping)
      (println msg)
      (>! pong :pong)
      (Thread/sleep 1000))
    (recur)))

(go-loop []
  (let [msg (<! pong)]
    (when (= msg :pong)
      (println msg)
      (>! ping :ping)
      (Thread/sleep 1000))
    (recur)))

(>!! ping :ping)

Пример общения двух каналов, классический Ping-Pong.

Это был последний пример который я хотел показать. Отдельно так же стоит выделить наличие в clojure типов данных, созданных специально для записи туда информации в несколько потоков, это atom и agent а также общую иммутабельность остальных типов, всё это очень облегчает жизнь разработчика при разработке многопоточного приложения.

---

Полезные ссылки:

» http://ift.tt/14B62aL
» http://ift.tt/187ujp5
» http://ift.tt/2e3yKys
» http://ift.tt/14CqVJ2
» http://ift.tt/1te0rXX

Let's block ads! (Why?)

[Перевод] Scrum от военного летчика: Искусство делать вдвое больше дел в два раза быстрее

Логика сознания. Часть 8. Пространственные карты коры мозга

[recovery mode] Как я стала дизайнером за шесть месяцев

Сколько места в куче занимают 100 миллионов строк в Java?

[Перевод] Воровство контента в китайском геймдеве

Ядро Linux, спрятанное внутри Windows 10

Разработка Vivaldi: работа над ошибками

Всем привет!

Разработка программного обеспечения — это сегодня само по себе дело сложное в связи с обилием всевозможных языков программирования, операционных систем, платформ, устройств и прочих факторов. Но, пожалуй, создание браузера — это одна из наиболее трудных задач, требующих особого внимания: всё-таки, браузер — это на сегодняшний день главное приложение, с которым работает ежедневно каждый пользователь Интернета. А учитывая, что контент сегодня представлен в столь сложном динамическом виде, что и не снился разработчикам первых браузеров, при этом принципы работы с этим контентом переросли из «посмотреть — почитать» в полноценную работу с приложениями, задача оказывается совсем не тривиальной. В общем, вывод напрашивается один: браузеры сегодня становятся всё сложнее и, как следствие, в процессе разработки в код проникает всё больше ошибок. Как с этим можно бороться? Как с этим боремся мы в Vivaldi? Вот об этом вкратце и поговорим.

Итак, начну с главного. Из чего состоит процесс разработки? Он состоит из нескольких важных этапов, включающих собственно написание кода, тестирование и выпуск публичной версии. Так это работает, например, если вы пишете программу уровня «Hello, world!». Впрочем, на самом деле при разработке браузера это работает точно так же, просто на чуть более сложном уровне, включающем несколько релизов разной степени готовности и несколько «фильтров» отлова ошибок. в нашей компании процесс выглядит следующим образом.

Первый этап

На первом этапе происходит добавление разработчиками своего кода в браузер, при этом на серверах компании ежедневно идёт процесс компиляции исходников браузера в бинарные пакеты, по несколько версий в день. Это — внутренние сборки, в которых разработчики имеют возможность проверить свои свежие правки, как говорится, в деле — на живом браузере.

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

Отдельные «счастливчики» могли понять это, обнаружив после обновления зелёную иконку браузера (см. слева) — именно она используется для внутренних тестовых сборок. Впрочем, зелёная иконка имеется и у сборки следующего этапа.

Второй этап

На этом этапе выпускается сборка для Sopranos — наших добровольных тестеров со всего мира (включая Россию), которые оказывают нам неоценимую и уникальную помощь в создании браузера. Их сборка, выпускаемая ежедневно, также имеет зелёную иконку и все экспериментальные функции, но самые явные ошибки в свежем коде разработчиков там уже отловлены. На этом этапе тестеры (а все они — отличные спецы в программировании и отладке) проверяют, как вновь добавленный код повлиял на уже существующие функции. Это очень важный этап, позволяющий выявить основную массу действительно критичных недочётов. Также можно добавить, что именно Sopranos в первую очередь проверяют и все сообщения об ошибках, ежедневно поступающие в нашу BTS от пользователей, и это уже

Третий этап

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

Еженедельные сборки для нас имеют не менее важное значение, чем и внутренние: именно здесь происходит отлов основной массы ошибок и недочётов благодаря тому, что у пользователей данных версий исключительно широкий разброс как по «железу», так и по личным привычкам в работе с браузером. Происходит полноценный тест-драйв браузера в реальных боевых условиях. Пользователи находят такие недочёты, которые оказались скрытыми от глаз как самих разработчиков, так и официальных тестеров Sopranos.

Главная же цель выпуска подобных тестовых публичных сборок — шлифовка и полировка кода браузера для подготовки уже стабильной версии браузера, которая выходит примерно раз в 6 недель и знаменует собой

Четвёртый этап

Итак — финальная версия. Привычная красная иконка и сравнительно стабильный, отлаженный код. Почему — «сравнительно»? Потому, что идеал недостижим и полностью избавиться от всех ошибок в коде сегодня практически нереально — слишком сложными стали сегодня программные продукты. Это как с самолётами. Мало кто знает, что абсолютно в каждом самолёте, перевозящем в данную минуту пассажиров из одной географической точки в другую, имеется журнал известных на данный момент неполадок — список недочётов, с которыми самолёт допускается к работе. Другими словами, абсолютно исправными самолёты не бывают никогда в принципе.

И с браузером — аналогичная история. Он всегда содержит некоторое количество недочётов, не влияющих критически на работу приложения и позволяющих полноценно использовать эту версию в повседневной работе. Часть из них известна разработчикам, часть — нет. И вот именно эту часть находят со временем пользователи уже стабильной версии — о чём нас и уведомляют посредством отправки сообщений об ошибках через соответствующую онлайновую форму. Эти сообщения попадают под контроль Sopranos, проверяются, группируются и докладываются разработчикам с предложением исправить вот прямо сейчас или чуть попозже — в зависимости от критичности ошибки или недочёта.

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

В качестве итога

Конечно, весь процесс описан довольно схематично и не включает множества мелких, но важных деталей, но в общем и целом показывает, как всё работает. Что же даёт такой многоуровневый подход? Он даёт равномерность процесса разработки и отладки браузера. Все ошибки фильтруются на каждом этапе в зависимости от критичности, при этом делается это постепенно, с привычной периодичностью. Таким образом разработчики имеют примерно постоянный объём ошибок в процессе исправления и в процессе ожидания очереди, тестеры (как официальные, так и неофициальные — еженедельных сборок) распределяют между собой «обязанности» по отлову ошибок в зависимости от своей квалификации, а конечные пользователи браузера получают достаточно стабильную версию, которая будет надёжно работать в ежедневном режиме. Вот, вкратце, и всё. Если у вас есть вопросы — задавайте их в комментариях, я постараюсь ответить.

Также не забывайте заглядывать на наш официальный веб-сайт vivaldi.com — там в последнее время происходят интересные изменения и появляется полезная информация, включая приглашение на работу.

P.S. Да, если вдруг вы забыли, откуда можно загрузить браузер Vivaldi — добро пожаловать!

Let's block ads! (Why?)

Как влияют тренды кибербезопасности на рынок хищений денежных средств

За 2015-2016 финансовый год в России хакеры украли более 5,5 миллиарда рублей. Это на 44% больше, чем в прошлом году. Наибольшую долю в общей сумме ущерба обеспечил взлом российских банков. Так, они потеряли 2,5 миллиарда рублей, что в четыре раза превышает аналогичный показатель за прошлый год.

Общий объем хищений, которые удалось предотвратить, составил пять миллиардов рублей, сообщил в четверг заместитель начальника главного управления безопасности и защиты информации ЦБ Артем Сычев. Сюда входят физические, юридические лиц и банки как таковые.

На 83% снизилось количество кибератак на компьютеры физических лиц. За 2015-2016 финансовый год они потеряли 6,4 миллиона. Вдвое уменьшилось число атак на системы интернет-банкинга юридических лиц: у них хакеры за год украли 956 миллионов рублей.
Существенно пострадали пользователи мобильных устройств на базе Android. С помощью специальных троянов киберпреступники за год смогли украсть с их счетов в российских банках 348,6 миллиона рублей.

Эксперты зафиксировали в этой сфере самый большой прирост преступлений — 471 процент. А число пользователей Android-устройств, зараженных вирусами, выросло до 350 новых человек в день.

В мае Reuters сообщал, что российские хакеры похитили данные 272 миллионов пользователей.

Эксперт по компьютерной безопасности Алекс Холден, который в свое время первым обнаружил атаки на компанию Adobe и банк JPMorgan, заявил, что хакеры провели крупнейшую кибератаку, в результате которой злоумышленники из «российского преступного мира» получили пароли и логины от 272 миллионов учетных записей.

По оценке Холдена, более других от атаки пострадал почтовый сервис Mail.ru. Также жертвами хакеров стали службы электронной почты американских компаний Google, Yahoo и Microsoft.

В четверг, 13 октября, в Москве прошла крупнейшая в Восточной Европе конференция по кибербезопасности CyberCrimeCon. Представители Интерпола и Европола, а также ведущих европейских компаний и банков рассказали о главных хакерских угрозах для бизнеса и простых пользователей сети.

Возглавляющий отдел спецопераций в Европейском центре по борьбе с киберпреступностью Фернандо Руиз косвенно намекнул на необходимость более тесного сотрудничества России и Запада.

Представитель Интерпола Нур Ажар Аиоб отметил, что вполне реальная угроза масштабных сетевых войн должна подтолкнуть ведущие мировые державы к подписанию пактов о запрете на использование кибервооружений.

Представителя Интерпола поддержал гендиректор Group-IB Илья Сачков, назвавший международное сотрудничество ключевым условием успеха борьбы с хакерами: «Если мы завтра проснемся, и все государства объединятся, обменяются своими большими данными и имеющейся у спецслужб информацией, то проблема вполне может решиться сама собой».

Пока же борцы с киберугрозами призвали журналистов поменьше писать о сетевых преступниках: это только привлекает к ним внимание и придает популярность. «Сегодня быть хакером — это гламурно. Если человек кого-то взломал, то все сразу восхищаются. А ведь он нарушил закон, — подчеркнул Сачков.

Он также отметил, что 99% компьютерных преступлений связаны с попыткой заработать денег. Тем не менее, целью оставшихся 1% компьютерных преступлений является шпионаж и кибертерроризм.

В ноябре 2015 года компания Zerodium, занимающаяся поиском и устранением уязвимостей, опубликовала цены на взлом ряда продуктов IT-компаний. За взлом Safari и Internet Explorer специалисты готовы заплатить хакерам 50 тысяч долларов, за Google Chrome — 80 тысяч долларов, а за неавторизованный доступ к системам на Android и Windows Phone — 100 тысяч долларов. Дороже всего оценивается брешь в защите iOS — за нее хакер получит 500 тысяч долларов.

Тем временем в Китае используют более хитрую схему.

Китайская компания ShenZhen Computer Users Association (SZCUA) намерена приобрести у российских инженеров по информационной безопасности уязвимости на iPhone, Android-смартфонах и компьютерных браузерах.

Как рассказали изданию «Коммерсант» представители нескольких российских компаний, к ним обратился представитель SZCUA по имени Роберт Невский. По его словам, SZCUA хочет купить эксплойты (инструменты для проведения атак на вычислительные системы), использующие так называемые «уязвимости нулевого дня» (ошибки ПО, о которых не знает его производитель). За подобные программы для мобильных платформ iOS и Android, а также ряда веб-приложений и браузеров китайцы готовы заплатить от 100 тысяч долларов.

При этом эксперты отмечают, что китайская компания скорее всего занимается скупкой уязвимостей для правительственных хакерских группировок, которые затем используют их для создания кибероружия.

И в заключение приведем факты и прогнозы, озвученные на конференции по информационной безопасности:

Ежедневно хакеры успешно атакуют 8 российских компаний, каждая из которых теряет в среднем 480 000 рублей.

Русскоязычные вирусописатели больше ориентируются на зарубежные рынки: к 16 из 19 троянов для ПК, наиболее активно использующихся для хищений по всему миру, связаны с русскоязычными преступниками.

Набирающая популярность индустрия «интернета вещей» (internet of things, IoT) привлекает и хакеров: IoT-устройства, не защищенные антивирусами, стали главным драйвером роста бот-сетей для DDoS-атак.

Расширяется спектр угроз для брендов. Доверие к брендам позволяет успешно атаковать не только физических, но и юридических лиц.

Успешные целевые атаки на банки продолжатся, средний размер ущерба одной успешной атаки увеличится.

Инцидентов с программами-шифровальщиками, в том числе с шифрованием мобильных устройств станет больше.

Количество атак на промышленные объекты будет расти, высока вероятность атаки на объект критической инфраструктуры со значительным ущербом.

Let's block ads! (Why?)

Почему я больше не нажимаю кнопку «Add contact» в Telegram

Поиск Яндекса с инженерной точки зрения. Лекция в Яндексе

Сегодня мы публикуем ещё один из докладов, прозвучавших на летней встрече об устройстве поиска Яндекса. Выступление руководителя отдела ранжирования Петра Попова получилось в тот день самым доступным для широкой аудитории: минимум формул, максимум общих понятий о поиске. Но интересно было всем, потому что Пётр несколько раз переходил к деталям и в итоге рассказал много такого, о чём Яндекс никогда раньше публично не заявлял.

Кстати, одновременно с публикацией этой расшифровки начинается вторая встреча из серии, посвящённой технологиям Яндекса. Сегодняшнее мероприятие — уже не про поиск, а про инфраструктуру. Вот ссылка на трансляцию.

Ну а под катом — лекция Петра Попова и часть слайдов.

---

Меня зовут Пётр Попов, я работаю в Яндексе. Здесь я уже примерно семь лет. До этого программировал компьютерные игры, занимался 3D-графикой, знал про видеокарточки, писал на SSE-ассемблере, в общем, такими вещами занимался.

Надо сказать, что, устраиваясь на работу в Яндекс, я достаточно мало знал о предметной области — о том, что здесь люди делают. Знал только, что здесь работают хорошие люди. Поэтому испытывал некоторые сомнения.

Сейчас я расскажу достаточно полно, но не очень глубоко о том, как выглядит наш поиск. Что такое Яндекс? Это поисковик. Мы должны получить запрос пользователя и сформировать десятку результатов. Почему именно десятку? Пользователи чрезвычайно редко переходят на более далёкие страницы. Можно считать, что десять документов — это всё, что мы показываем.

Не знаю, есть ли в зале люди, которые занимаются рекламой Яндекса, потому что они считают, что основной продукт Яндекса — это совсем другое. Как обычно, здесь две точки зрения и обе правильные.

Мы считаем, что основное — это счастье пользователя. И, как ни удивительно, от состава десятки и того, как десятка отранжирована, это счастье зависит. Если мы ухудшаем выдачу, пользователи пользуются Яндексом меньше, уходят в другие поисковики, плохо себя чувствуют.

Какую конструкцию мы соорудили ради решения этой простой задачи — показать десять документов? Конструкция достаточно мощная, снизу, видимо, разработчики на неё взирают.

Наша модель работы. Нам нужно сделать всего несколько вещей. Нам нужно обойти интернет, проиндексировать получившиеся документы. Документом мы называем скачанную веб-страницу. Проиндексировать, сложить в поисковый индекс, запустить над этим индексом поисковую программу, ну и ответить пользователю. В общем-то, всё, профит.

Пройдемся по шагам этого конвейера. Что такое интернет и какого он объема? Интернет, считай, бесконечный. Возьмем любой сайт, который продает что-нибудь, какой-нибудь интернет-магазин, сменим там параметры сортировки — появится другая страничка. То есть можно задавать СGI-параметры страницы, и содержание будет совсем другое.

Сколько мы знаем принципиально значащих страниц с точностью до отбрасывания незначащих CGI-параметров? Сейчас — порядка нескольких триллионов. Скачиваем мы странички со скоростью порядка нескольких миллиардов страничек в день. И казалось бы, что нашу работу мы могли бы выполнить за конечное время, там, за два года.

Как мы вообще находим новые странички в интернете? Мы обошли какую-то страничку, вытянули оттуда ссылки. Они — наши потенциальные жертвы для скачивания. Возможно, за два года мы обойдем эти триллионы URL, но появятся новые, и в процессе парсинга документов появятся ссылки на новые странички. Уже тут видно, что наша основная задача — бороться с бесконечностью интернета, имея на руках конечные инженерные ресурсы в виде дата-центров.

Мы скачали все безумные триллионы документов, проиндексировали. Дальше нужно положить их в поисковый индекс. В индекс мы кладем не всё, а только лучшее из того, что скачали.

Есть товарищ Ашманов, широко известный в узких кругах специалист по поисковым системам в интернете. Он строит разные графики качества поисковых систем. Это график полноты поисковой базы. Как он строится? Задается запрос из редкого слова, смотрится, какие документы есть во всех поисковиках, это 100%. Каждый поисковик знает про какую-то долю. Сверху красным цветом мы, снизу черным цветом — наш основной конкурент.

Тут можно задаться вопросом: как мы такого достигли? Возможны несколько вариантов ответа. Вариант первый: мы пропарсили страничку с этими тестами, выдрали оттуда все URL, все запросы, которые задает товарищ Ашманов и проиндексировали странички. Нет, мы так не делали. Второй вариант: для нас Россия является основным рынком, а для конкурентов она — что-то маргинальное, где-то на периферии зрения. Этот ответ имеет право на жизнь, но он мне тоже не нравится.

Ответ, который мне нравится, заключается в том, что мы проделали большую инженерную работу, сделали проект, который называется «большая база», под это закупили много железа и сейчас наблюдаем этот результат. Конкурента тоже можно бить, он не железный.

Документы мы скачали. Как мы строим поисковую базу? Вот схема нашей контент-системы. Есть интернет, облачко документов. Есть машины, которые его обходят — спайдеры, пауки. Документ мы скачали. Для начала — положили его в сохраненную копию. Это, фактически, отдельная междатацентровая хеш-таблица, куда можно читать и писать на случай, если мы потом захотим этот документ проиндексировать или показать пользователю как сохраненную копию на выдаче.

Дальше мы документ проиндексировали, определили язык и вытащили оттуда слова, приведенные согласно морфологии языка к основным формам. Ещё мы вытащили оттуда ссылки, ведущие на другие страницы.

Есть еще один источник данных, который мы широко используем при построении индекса и вообще в ранжировании — логи Яндекса. Задал пользователь запрос, получил десятку результатов и как-то там себя ведёт. Ему показались документы, он кликает или не кликает.

Разумно предположить, что если документ показался в выдаче, или, тем более, если пользователь по нему кликнул, провел какое-то взаимодействие, то такой документ нужно оставить в поисковой базе. Кроме того, логично предположить, что ссылки с такого хорошего документа ведут на документы, которые тоже хороши и которые неплохо бы приоритетно скачать. Здесь изображено планирование обхода. Стрелочка от планирования обхода должна вести в обход.

Дальше есть стадия построения поискового индекса. Эти округлые прямоугольнички лежат в MapReduce, нашей собственной реализации MapReduce, которая называется YT, Yandex Table. Тут я немножко лакирую — на самом деле построение базы и шардирование оперируют с индексами как с файлами. Мы это немножко зафиксим. Эти округлые прямоугольнички будут лежать в MapReduce. Суммарный объем данных здесь — порядка 50 ПБ. Тут они превращаются в поисковые индексы, в файлики.

В этой схеме есть проблемы. Основная связана с тем, что MapReduce — сугубо батчевая операция. Чтобы определить приоритетные документы для обхода, например, мы берем весь линковый граф, мёржим его со всем пользовательским поведением и формируем очередь для скачки. Это процесс достаточно латентный, занимающий какое-то время. Ровно так же с построением индекса. Там есть стадии обработки — они батчевые для всей базы. И выкладка так же устроена, мы или дельту выкладываем, или всё.

Важная задача при этих объемах — ускорить процедуру доставки индекса. Надо сказать, что эта задача для нас сложная. Речь идёт о борьбе с батчевым характером построения базы. У нас есть специальный быстрый контур, который качает всякие новости в real time, доносит до пользователя. Это наше направление работы, то, чем мы занимаемся.

А вот вторая сторона медали. Первая — контент-система, вторая — поиск. Можно понять, почему я рисовал пирамидку — потому что поиск Яндекса действительно похож на пирамиду, такую иерархическую структуру. Сверху стоят балансеры, фронты, которые генерируют выдачу. Чуть пониже — агрегирующие метапоиски, которые агрегируют выдачу с разных вертикалей. Надо сказать, что на выдаче вы наверняка видели веб-документы, видео и картинки. У нас три разных индекса, они опрашиваются независимо.

Каждый ваш поисковый запрос уходит по этой иерархии вниз и спускается до каждого кусочка поисковой базы. Мы весь индекс, который построили, разбили на тысячи кусков. Условно, — на две-три-пять тысяч. Над каждым куском подняли поиск, и этот запрос всюду спустился.

Тут же видно, что поиск Яндекса — большая штука. Почему она большая? Потому что мы в своей памяти храним, как вы видели на предыдущих слайдах, достаточно репрезентативный и мощный кусок интернета. Храним не один раз: в каждом дата-центре от двух до четырёх копий индекса. Запрос наш спускается до каждого поиска, фактически проходится по каждому индексу. Сейчас используемые структуры данных — такие, что мы вынуждены всё это хранить напрямую в оперативке.

Что нужно делать? Вместо дорогой оперативки использовать дешевый SSD, ускорить поиск, допустим, в два раза, и получить профит — десятки или сотни миллионов долларов капитальных расходов. Но тут не нужно говорить: кризис, Яндекс экономит и всё такое. На самом деле всё, что мы сэкономим, мы пустим в полезное дело. Мы увеличим индекс в два раза. Мы будем по нему качественнее искать. И это то, ради чего осуществляется такого рода сложная инженерка. Это реальный проект, правда, достаточно тяжелый и вялотекущий, но мы действительно так делаем, хотим поиск наш улучшить.

Поисковый кластер не только достаточно большой — он ещё и очень сложный. Там реально крутятся миллионы инстансов разных программ. Я вначале написал — сотни тысяч, но товарищи из эксплуатации меня поправили — таки миллионы. На каждой машинке в очень многих экземплярах 10-20 штук точно крутится.

У нас тысячи разных типов сервисов размазаны по кластеру. Надо пояснить: кластер — это такие машинки, хосты, на них запущены программы, все они общаются по TCP/IP. Программы имеют разное потребление CPU, памяти, жесткого диска, сети — короче, всех этих ресурсов. Программы живут на хостах в общежитии. Точнее, если будем сажать одну программу на хост, то утилизация кластера будет никакой. Поэтому мы вынуждены селить программы друг с другом.

Дальше слайд про то, что с этим делать. А здесь — небольшое замечание, что все данные программы, все релизы мы катаем с помощью торрентов, и число раздач на нашем торрент-трекере превышает оное число на Pirate Bay. Мы реально большие.

Что нужно делать со всей этой кластерной конструкцией? Нужно улучшать механизмы виртуализации. Мы реально вкладываемся в разработку ядра Linux, у нас есть собственная система управления контейнерами а-ля Docker, про неё Олег подробнее расскажет.

Нам нужно заранее планировать, на каких хостах какие программы друг с другом селить, это тоже сложная задача. У нас постоянно что-то на кластер едет. Сейчас там наверняка десять релизов катятся.

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

Что мы с этого получаем? Пользу в десятки миллионов долларов экономии капитальных расходов. Вы уже знаете, как мы эти деньги потратим — мы потратим их на улучшение нашего поиска.

Здесь я рассказал о конструкции в целом. Какие-то отдельные строительные блоки. Эти блоки люди долбили стамеской, и у них что-то получилось.

Ранжирующая функция Матрикснет. Достаточно простая функция. Можете почитать — там лежат в векторе бинарные признаки документа, а в этом цикле происходит вычисление релевантности. Я уверен, что среди вас есть специалисты, которые умеют на SSE программировать, и они бы живо это ускорили в десять раз. Так оно в какой-то момент и случилось. Тысяча строчек кода нам спасли 10-15% общего потребления CPU на нашем кластере, что опять же составляет десятки миллионов долларов капитальных расходов, которые мы знаем, как потратить. Это тысяча строчек кода, которая стоят очень дорого.

Мы более-менее вычистили из репозитория, соптимизировали, но там ещё есть что поделать.

Имеется у нас платформа для машинного обучения. Индексы с предыдущего слайда нужно подбирать жадным образом, перебирая все возможности. На CPU это делать долго. На GPU — быстро, зато пулы для обучения не лезут в память. Что нужно делать? Или покупать кастомные решения, куда этих железок много-много втыкается, или связывать машинки быстрым, использовать интерконнект какой-то, infiniband, учиться с этим жить. Оно типично глючит, не работает. Это очень забавный инженерный вызов, с которым мы тоже встречаемся. Он, казалось бы, совсем не связа с нашей основной деятельностью, но тем не менее.

Во что мы ещё инвестируем, так это в алгоритмы сжатия данных. Основная задача сжатия выглядит примерно следующим образом: есть последовательность целых чисел, нужно её как-то компрессировать, но не просто компрессировать — нужно ещё иметь случайный доступ к i-тому элементу. Типичный алгоритм — маленькими блоками сжать это, иметь разметку для общего потока данных. Такая задача — совсем другая, нежели контекстное сжатие типа zip или LZ-family. Там совсем другие алгоритмы. Можно сжать Хаффманом, Varlnt, блоками типа PFORX. У нас есть собственный патентованный алгоритм, мы его улучшаем, и это опять же 10-15% экономии оперативной памяти на простенький алгоритм.

У нас есть всякие забавные мелочи, например доработки в CPU, планировщики Linux. Там какая проблема с гипертредными камнями от Intel? То, что на физическом ядре есть два потока. Когда там два треда занимают два потока, то они работают медленно, латенция увеличивается. Нужно правильно раскидывать задачки по физическим процессорам.

Если раскидывать правильно, а не так, как делает стоковый планировщик, можно получить 10-15% латентности нашего запроса, условно. Это то, что видят пользователи. Сэкономленные миллисекунды умножайте на число поисков — вот и сэкономленное время для пользователей.

У нас есть какие-то совсем странные вещи типа собственной реализации malloc, который на самом деле не работает. Он работает в аренах, и каждая локация просто сдвигает указатель внутри этой арены. Ну и rev counter арены поднимает на единичку. Арена жива, пока жива последняя локация. Для всякой смешанной нагрузки, когда у нас есть короткоживущая и долгоживущая локация, это не работает, это выглядит как утечка памяти. Но наши серверные программы устроены не так. Приходит запрос, мы там аллоцируем внутренние структуры, как-то работаем, потом отдаем ответ пользователю, всё сносится. Этот аллокатор идеально работает для наших серверных программ, которые без состояния. За счет того, что все локации локальны, последовательны в арене, оно работает очень быстро. Там нет никаких page fold, cache miss и т. п. Очень быстро — это от 5% до 25% скорости работы наших типичных серверных программ.

Это инженерка, что ещё можно делать? Можно заниматься машинным обучением. Про это вам с любовью расскажет Саша Сафронов.

А сейчас вопросы и ответы.

Я возьму очень понравившийся мне вопрос, который пришел на рассылку и который следовало бы включить в мою презентацию. Товарищ Анатолий Драпков спрашивает: есть знаменитый слайд про то, как быстро росла формула до внедрения Матрикснета. На самом деле и до, и после. Есть ли сейчас проблемы роста?

Проблемы роста у нас стоят в полный рост. Очередной порядок увеличения числа итераций в формуле ранжирования. Сейчас мы там порядка 200 тысяч итераций делаем в функции Матрикснет, чтобы ответить пользователю. Был получен следующим инженерным шагом. Раньше мы ранжировали на базовых. Это значит, что каждый базовый запускает у себя Матрикснет и выдает сто результатов. Мы сказали: давайте мы лучшие сто результатов объединим на среднем и отранжируем ещё раз совсем тяжелой формулой. Да, мы это сделали, на среднем можно вычислять в нескольких потоках функцию Матрикснет, потому что ресурсов нужно в тысячу раз меньше. Это проект, который нам позволил достичь очередного порядка увеличения объемов ранжирующей функции. Что будет ещё — не знаю.

Андрей Стыскин, руководитель управления поисковых продуктов Яндекса:
— Сколько занимала байт первая формула ранжирования Яндекса?

Пётр:
— Десяток, наверное.

Андрей:
— Ну, да, наверное, где-то символов сто. А сколько сейчас занимает формула ранжирования Яндекса?

Пётр:
— Где-то 100 МБ.

Андрей:
— Формула релевантности. Это для наших смотрителей с трансляций, специалистов по SEO. Попробуйте зареверсинженирить наши 100 МБ ранжирования.

Алеся Болгова, Intel:
— По последнему слайду про malloc не могли бы пояснить, как вы выделяете память? Очень интересно.

Пётр:
— Берется обычная страничка, 4 КБ, в начале у нее rev counter, и дальше мы каждую аллокацию… если маленькие аллокации меньше страницы, мы просто двигаемся в этой страничке. В каждом треде, естественно, эта страничка своя. Когда страничку закрыли — всё, про неё забыли. Единственное, у неё rev counter в начале.

Алеся:
— То есть вы страницу выделяете?

Пётр:
— Внутри страницы аллокациями вот так растем. Единственное, страничка живет, пока в ней последняя аллокация живет. Для обычного workload это выглядит как утечка, для нашего — как нормальная работа.

— Как вы определяете качество страницы, стоит её класть в индекс или нет? Тоже машинное обучение?

Пётр:
— Да, конечно. У странички есть множество факторов, от её размера до показов на поиске, до…

Андрей:
— До robot rank. Она находится на каком-то хосте, в какой-то поддиректории хоста, на неё сколько-то входящих ссылок. Те, кто на неё ссылаются, обладают каким-то качеством. Все это берем и пытаемся предсказать, с какой вероятностью, если данную страничку скачать, на ней будет информация, которая попадет по какому-то запросу в выдачу. Это предсказывается, отбирается топ с учетом размера документов — потому что в зависимости от размера документа вероятность, что она хоть по какому-то запросу попадет, повышается. Задача об оптимальном наполнении рюкзака. Отбирается с учетом размера документа и кладется топовая в индекс.

— …

Андрей:
— Давай мы тебя представим сначала.

— Может, не стоит?

Андрей:
— Владимир Гулин, начальник ранжирования поисковика Mail.Ru.

Владимир:
— Первый мой вопрос — про количество поисков вообще. Вы говорили, что вы там драматически увеличили размер базы. Хочется вообще понимать, с какого объема вы стартовали, каков был объем русского индекса, иностранного индекса, сколько документов приходилось на каждый шард, ну и после увеличения…

Пётр:
— Это такие цифры, слишком технические. Может, в кулуарах я бы сказал. Я могу сказать, во сколько раз мы примерно увеличились — на полтора порядка где-то. В 30 раз, условно. За последние три года.

Владимир:
— Я тогда абсолютные цифры в кулуарах уточню.

Пётр:
— Да, за отдельную плату, что называется.

Владимир:
— Ладно. Что касается свежести — какой приблизительно сейчас в Яндексе объем быстрого индекса? И вообще с какой скоростью вы это всё обновляете, смешиваете?

Пётр:
— Индекс реально реалтаймовый, там порядка двух минут латенции на то, чтобы добавить документ в индекс. От момента, как мы его проиндексировали, и дискавери тоже — скачка быстрая.

Владимир:
— Но именно найти документ. Сначала надо узнать, что документ существует.

Пётр:
— Я понимаю, что вопрос такой — непонятно, когда в интернете появилась первая ссылка на данный документ. Когда мы узнали первую ссылку, то дальше это вопрос минут в быстром слое.

Андрей:
— Речь идет о миллионах документов, которые ежедневно находятся в этом быстром индексе. Про них обычно очень много внешней информации: упоминание в Твиттере, сайтмэпы, упоминание новости на сайте Lenta.ru. И так как мы перекачиваем чуть ли не каждую секунду морду Lenta.ru, мы очень быстро обнаруживаем эти документы и в течение единиц минут в худшем случае доставляем их до поиска. Они могут искаться. По сравнению с большим индексом речь идет про драматически маленькое число документов, это миллионы.

Пётр:
— Да, на 3-4 порядка меньше.

Андрей:
— Да, это миллионы документов, которые умеют обновляться real time.

Владимир:
— Миллионы документов в сутки?

Пётр:
— Побольше чуть-чуть, но примерно так, да.

Владимир:
— Теперь вопрос про смешивание свежих результатов и результатов основного поиска.

Пётр:
— У нас два способа смешивания. Один — документ той же формулой ранжируется, что и батчевый обычный документ. А второй — специальное новостное подмешивание, когда мы определяем интент запроса, понимаем, что он реально свежий и что нужно что-то такое показать. Два способа.

Владимир:
— Как вы боретесь с ситуацией, когда у вас по популярным запросам, где дофига кликов, появляются свежие результаты? Как вы определяете, что свежий результат надо показывать выше того результата, который уже накликан? Спросили у вас: «Google». Вы вроде знаете, какие результаты по такому запросу хорошие. Но тем не менее, в новостях ещё что-то, какие-то статьи…

Пётр:
— Это всякие запросные факторы, всякие тренды и всё такое.

Андрей:
— Для всех поясню, в чем сложность задачи и в чем вопрос. Про документ, который долго существует в интернете, мы много чего знаем. Мы много знаем входящих на него ссылок, знаем, сколько на нем люди проводили времени, а про свежие документы этого всего не знаем. Поэтому сложность задачи ранжирования свежих документов и новостей — угадывать, будут ли люди это читать, уметь предсказывать количество ссылок, которые он наберет за какое-то время, чтобы его показывать нормально. И для подмешивания документов по запросу «Google», когда Google что-то хорошее сделал, там существует некая оптимизационная метрика, которая у нас называется профицит. Мы её умеем оптимизировать.

Пётр:
— Мы знаем поток запросов, содержание свежескачанных страниц. Эти две вещи мы можем анализировать и понимать, что реально свежий запрос требует подмешивания.

Андрей:
— А потом, на основе ручной оценки и пользовательского поведения именно в эту секунду в этот день, мы понимаем, что именно сегодня эта новость по запросу важна и у неё есть такие факторы: документ только появился, на него столько-то ретвитов. И поэтому следующую новость, которая будет с таким же распределением признаков, тоже нужно показывать, когда она наберет соответствующие значения.

Пётр:
—А факторы там могут быть такими: число найденного в обычном слое против числа найденного по этому запросу в свежем. Такие, самые наивные, хотя мы его выпиливаем тщательно.

Андрей:
— Для тех, кого пугает слово «факторы», специально будет третий доклад, где мы расскажем базовые принципы — как вообще устроено машинное обучение, ранжирование, что такое факторы, как с помощью этого сделать поисковик, который выдает нормальные хорошие результаты.

Владимир:
— Спасибо, остальное спрошу потом.

Никита Пустовойтов:
— Получается, у вас существует большое количество урлов, про которые вы в принципе знаете, а качать вы можете на несколько порядков меньше. Поскольку за время скачивания будут появляться новые, больше вы никогда не посетите. Для выбора применяется машинное обучение, какие-то эвристики?

Пётр:
—Только машинное обучение. Идея там простая: мы имеем сигнал на какой-то документ, любой, число показов, и его распространяем по ссылочному графу. Всё это агрегируем на странице «цель ссылки», дальше машинным обучением так же обучаем шанс показаться, исходя из этих данных.

Никита:
— Второй вопрос — инженерный. Вы говорили, что у вас много CPU-затратных задач. Рассматривали ли вы вариант использования процессора Xeon Phi от Intel? Он вроде гораздо быстрее работает с оперативной памятью, чем GPU.

Пётр:
— Мы его рассматривали для задач обучения именно нашего Матрикснета, нашей формулы, и там он феерично плохо себя показал. А так вообще у нас профиль очень плоский, у нас топовая функция где-то 1,5%. Мы всё, что можно, руками соптимизировали, а так у нас портянки С++-кода, который туда не ложится.

— Насколько я знаю, Яндекс был первым поисковиком, который начал работать с русской морфологией. Скажите, на данный момент это всё ещё является каким-либо преимуществом или все поисковики одинаково хорошо работают с русской морфологией?

Пётр:
— Сейчас в области морфологии наука не стоит на месте. Саша Сафронов расскажет о том, чего мы сейчас достигаем, там реально есть новые подходы и новые способы решения проблем. Например, определение запросов, похожих на этот, по пользовательскому поведению. Не расширение отдельных слов, а расширение запросов запросами.

Андрей:
— То есть это не совсем морфология. Морфологию действительно, наверное, все поисковики более-менее освоили, но это базовая вещь. А вот лингвистика, нахождение, чем и какие слова запроса можно расширить, какие ещё вещи стоит поискать в документе, чтобы найти кандидатов, которые будут более релевантные — про это будет третий доклад. Там наше ноу-хау, мы расскажем.

Пётр:
— По крайней мере, намекнем.

Андрей (зритель):
— Спасибо за краткий экскурс в столь сложную технологию, как поиск Яндекса. Использует ли Яндекс deep learning и алгоритмы обучения с подкреплением в построении быстрого индекса или кеша? Вообще если используете где-то, то как?

Пётр:
— Deep learning используем для того, чтобы факторы ранжирования обучать. Безотносительно к быстрому или медленному индексу. Он используется для картинок, веба и всего такого.

Андрей Стыскин:
— Летом запустили версию ранжирования, которая дала 0,5% прироста качества, где мы правильно сварили deep learning на словах. Приезжали наши бывшие коллеги из-за границы и рассказывали, что там такое не работает, а мы научились.

Пётр:
— А может, это потому, что мы для топ-100 документов это делаем. Речь идёт об очень затратной задаче. Наш способ построения пайплайна поиска позволяет для сотни документов это делать.

Андрей Стыскин:
— Невозможно посчитать deep learning для всех кандидатов, которых сотни миллионов на запросы, но для топа документов можно провернуть, и у нас эта схема поиска ровно так работает — позволяет такие очень сложные наукоемкие алгоритмы внедрять.

Игорь:
— Про будущее поисковика в целом. Интернет сейчас растет очень быстро, объем, наверное, растет экспоненциально. Уверены ли вы, что через 10 лет вы будете успевать за ростом интернета, и уверены ли, что будете охватывать его в таком же объеме? Повторите ещё раз, в каком объеме сейчас интернет охвачен по вашей оценке, и что будет через 10 лет?

Пётр:
— К сожалению, можно только процентно по отношению с кем-то степень охвата определять. Потому что он реально бесконечный.

Андрей:
— Это красивый философский вопрос. Пока мы в нашем коллективе за законом Мура успеваем, каждый год кратно увеличиваем наш размер базы. Но это правда сложно, правда интересно, и, конечно же, нам даже не хватает рук, чтобы это делать, но мы хотим и знаем, как это увеличивать в ближайшие несколько лет некоторыми сериями улучшений.

Пётр:
— 10 лет — слишком далеко, но ближайшие годы да, осилим.

Андрей (зритель):
— Сколько весит реплика интернета, как она разносится между ДЦ, и как осуществляется синхронизация реплик?

Пётр:
— Полный объем роботных данных — порядка 50 ПБ, реплика меньше, индекс меньше. Можете умножить на коэффициент, который вам кажется разумным. Вы же инженер, прикиньте.

Андрей:
— А как разносится?

Пётр:
— Разносится банально — через torrent, torrent share. Потом качаем этот файлик.

Андрей:
— То есть в какой-то момент времени они не консистентны?

Пётр:
— Нет, там потом консистентные переключения. Бывает, что переключаем по ДЦ, когда ночью оно вдруг не консистентно.

Андрей:
— То есть можно через F5 — если нажимаем, один документ имеем…

Пётр:
— Мы боремся с этой проблемой, знаем о ней, ее решение стоит в наших планах.

Иван:
— Как вы боретесь с различными бот-системами и за что можно отправиться в бан?

Пётр:
— У нас есть специальные люди, которые знают ответ на этот вопрос, но они не скажут.

Андрей Стыскин:
— На сегодняшнем мероприятии мы хотели поговорить про технические детали.

Пётр:
— Про роботоловилку мы можем ответить. Нас действительно регулярно ддосят, поэтому у нас прямо на балансере, на первом слое, когда запрос попадает, есть детекция, что запрос из какой-то сети пришел негодной. Это быстро обновляется, мы быстро реджектим, оно не валит наш кластер.

Андрей:
— И это тоже устроено методом машинного обучения. Показывается капча, и в зависимости от того, как ты её разгадываешь, мы получаем положительные и отрицательные примеры. На каких-то факторах — типа айпишника подсетки, какого-то поведения, времени между действиями — обучаем и баним или не баним такие запросы. DDoS не пройдет.

Андрей Аксёнов, Sphinx Search:
— У меня технические вопросы. Проходной вопрос — почему память? Неужели даже децл подисковать на SSD не получается, чтобы индекс чуть-чуть не влезал, изредка упирался в SSD?

Пётр
— Там получается так, что футпринт одного запроса порядка 50-100 МБ, он прямо жесткий. С такой скоростью ты не сможешь сервить тысячу запросов в секунду, как мы хотим. Мы работаем над тем, чтобы этот футпринт уменьшить. Проблема, что данные про документ рассыпаны по всему диску. Мы хотим их собрать в одно место, и тогда наша общая мечта осуществится.

Андрей Аксёнов:
— Упирается в bandwidth или latency?

Пётр:
— В оба. Мы и последовательно пейджфолдимся, и объемы большие.

Андрей Аксёнов:
— То есть невероятно, но факт: даже если чуть-чуть…

Пётр:
— Да, даже если чуть-чуть отожрешь — всё.

Андрей Аксёнов:
— Экспоненциальное падение во много раз?

Пётр:
— Да-да.

Андрей Аксёнов:
— Теперь важнейший вопрос для промышленного хозяйства: сколько классов строка и классов векторов в базе?

Пётр:
— А вот всё меньше и меньше.

Андрей Аксёнов:
— Ну конкретнее.

Пётр:
— У нас пришли правильные люди, они насаждают правильные порядки. Сейчас это число уменьшается.

Андрей Аксёнов:
— Векторов-то сколько и строк?

Пётр:
— Сейчас векторов, наверное, даже один-два максимум.

Андрей Аксёнов:
— Один не бывает, два хоть…

Пётр:
— Ну вот видишь.

Андрей Аксёнов:
— А строк?

Пётр:
— Ну должен же быть корпоративный какой-то дух Яндекса.

Андрей Аксёнов:
— Скажи, не томи, ну.

Пётр:
— Строк две минимум. Ну три, может.

Андрей Аксёнов:
— Не пять?

Пётр:
— Не пять.

Андрей Аксёнов:
— Налицо прогресс, спасибо.

Фёдор:
— Про вашу схему с метапоисками. У вас очень высокий каскад. Какие тайминги на каждом уровне, можете озвучить?

Пётр Попов:
— Прямо сейчас вставляем ещё один слой, не хватает. Времена ответов… Средний метапоиск делает три раунда хождений туда-сюда, у него порядка 250 мс, 95-я квантиль. Дальше построение выдачи не очень быстрое, но вся конструкция где-то за 700 мс отрабатывает.

Андрей Стыскин:
— Да, там выше JavaScript, так что это 250 мс, а там 700.

Пётр:
— То, что снизу, оно делает кучу раундов. У нас тоже специалисты заняты прямо сейчас решением этой проблемы.

Фёдор:
— У вас нарисовано три группы вертикалей. Но у вас есть ещё Афиша, Новости и так далее. Где вы их замешиваете в итоге?

Пётр:
— В построении выдачи у нас есть такой блендер, который объединяет все эти вертикали, по пользовательскому поведению решает, кого показать. Это как раз построение выдачи.

Андрей:
— Вертикалей порядка сотни, это слой, который называется верхним метапоиском. В нём сливаются результаты средних метапоисков из вертикали веба, Картинок, Видео и ряда других, а также из маленьких базовых источников типа Афиши, Расписаний, ТВ и Электричек.

Пётр:
— Это к вопросу о том, почему у нас тысячи разных типов программ. Там очень много всяких источников, оно набегает.

Фёдор:
— Раз у вас так много вертикалей, есть ли среди них сторонние, которые не вы считаете?

Пётр:
— Особо нет. Реклама наша тоже вертикальная, отдельно от поиска, но стороннего особо нет.

Артём:
— У вашего основного конкурента выдача всегда была real time, он дельта-индексами докидывал. А у Яндекс был up выдачи. Складывалось впечатление, что темной ночью раз в семь дней человек нажимает рычаг и раскатывает индексы.

Пётр:
— К сожалению, так и происходит.

Артём:
— Правильно понимаю, что быстрый индекс был сделан для того, чтобы актуализировать выдачу real time?

Пётр:
— Да, но решение общее. Многие так реально делают, в том числе и наш основной конкурент.

Артём:
— Стремитесь ли вы к тому, чтобы тоже дельта-индексами подкидывать, просто отказаться от быстрого индекса?

Пётр:
— Естественно, стремимся. Ещё бы знать, как.

Артём:
— Когда это можно ожидать?

Пётр:
— Хороший вопрос. На тех же графиках Ашманова видно, как мы обновляем индекс. Сейчас это видно меньше, и мы делаем так, чтобы это проходило совсем быстро и незаметно. Такова одна из наших задач.

Артём:
— Вы каждый раз обрабатываете запрос пользователя? Приходит запрос, вы отсылаете его на бэкенд, рассчитывается формула и результат?

Пётр:
— Есть кеши, но они работают в 50% случаев. 40-50% запросов пользователей — уникальные и никогда больше не будут заданы. Очень много по-настоящему уникальных запросов пользователей вообще за всю жизнь Яндекса. Кешируем 50-60%. Для кеширования тоже своя система.

Let's block ads! (Why?)

Security Week 41: неделя патчей, 12-летняя уязвимость в sshd возвращается, StrongPity APT

На прошлой неделе в Денвере прошла 26-я по счету конференция VB, организованная авторитетнейшим порталом-долгожителем Virus Bulletin. Конференция по тематике схожа с BlackHat, но в ней куда меньше шоу и куда больше технических деталей. Эксперты «Лаборатории» выступали на конференции с двумя докладами. С одним, про ложные доказательства принадлежности вредоносного кода и таргетированных атак, предлагаю ознакомиться самостоятельно, а про другой расскажу подробнее.

Атака StrongPity (новость, исследование) интересна не столько своими возможностями по краже данных (тут вообще трудно чем-либо удивить), сколько правильным таргетированием жертв. Организаторы атаки создали несколько веб-страниц, мимикрирующих под официальные сайты популярного софта, конкретно WinRAR и TrueCrypt. Ссылки на эти веб-сайты также удалось протащить на пару софтовых агрегаторов.

На поддельных сайтах распространялись подготовленные дистрибутивы вышеуказанного софта: они работали, но имели дополнительную функциональность, направленную на сбор и кражу данных. Кроме того, вредоносные компоненты позволяли более детально профилировать жертв. Был предусмотрен поиск специализированного админского софта, ПО для шифрования или для удаленного доступа: putty, winscp, пара клиентов Remote Desktop и так далее. Трактовать такое поведение можно по-разному. Во-первых, очевидно, велись прицельные попытки атаковать системных администраторов, априори имеющих расширенные права в сети жертвы. Во-вторых, таргетирование жертв, использующих софт для шифрования данных позволяет предположить прицельный поиск тех, кому есть что скрывать.

Сетевые устройства подвержены уязвимости в SSHD 12-летней давности
Новость. Исследование Akamai.

Мощная DDoS-атака на сайт эксперта-безопасника Брайана Кребса в сентябре (новость) привлекла повышенное внимание к сетевым автономным устройствам, которые также можно отнести и к «интернету вещей». Благодаря выложенному в сеть исходному коду софта для автоматизированного и взлома уязвимых устройств, было окончательно подтверждено, что для атаки был использован, пусть и не впервые, зато с максимальным масштабом, именно IoT-ботнет. Проблема была отслежена (новость) до конкретного OEM-производителя устройств — цифровых видеорекордеров, систем видеонаблюдения и IP-камер. Увы, говорить о «взломе» устройств этого вендора не приходится: зашитый пароль суперпользователя скорее можно трактовать как полное отсутствие защиты у девайсов, постоянно включенных в сеть.

Но есть и чуть менее тривиальные варианты. Исследователи компании Akamai на этой неделе опубликовали работу, в которой проанализировали уязвимость сетевого видеорекордера. Исследование началось с жалобы клиента на вредоносную активность, ассоциированную с подобным устройством. Анализ безопасности рекордера показал следующее: веб-интерфейс рекордера закрыт дефолтным паролем (admin:admin). Веб-интерфейс, впрочем, не обязательно доступен при подключении из-за пределов локальной сети, зато возможно подключение по ssh. Зайти с дефолтным паролем по ssh, впрочем, тоже не получится — такая опция заблокирована в настройках.

К сожалению, по умолчанию возможно подключение по ssh в режиме прокси (включена опция AllowTcpForwarding), что позволяет обойти ограничение. В результате рекордер (не исключено, что и другие устройства тоже) можно как минимум использовать для перевалки вредоносного трафика. Как максимум — использовать устройство для взлома локальной сети, в которой оно установлено. Примечательно, что данная уязвимость (скорее неправильная конфигурация) была описана (CVE-2004-1653) 12 лет назад применительно к OpenSSH, но встречается до сих пор.

Кажется пришла пора объявить месяц борьбы с дефолтными паролями.

Неделя патчей: Microsoft, Adobe, Cisco, Chrome
Эта неделя также отметилась большим количеством заплаток к популярному или стратегически важному софту. Microsoft (новость) закрыл 10 уязвимостей, из которых пять были квалифицированы как zero-day — уже были зафиксированы случаи атак с их использованием на момент выпуска патча. Уязвимости, способные привести к удаленному выполнению кода, закрыты в Microsoft Edge, MS Office (обработка документов RTF) и компоненте Microsoft Internet Messaging API (может быть эксплуатирована через MS Outlook).

Adobe квартальным патчем закрыла более 80 дыр в своих продуктах (новость), большинство в Acrobat и Reader, плюс немного уязвимостей в Adobe Flash. Cisco, которой недавно пришлось быстро латать уязвимости, раскрытые в утечке ShadowBrokers, закрыла еще несколько критичных дыр в NX-OS, используемой в роутерах Nexus. Наконец, Google закрыла 21 уязвимость в браузере Chrome, обнаруженных в рамках работы с независимыми исследователями по программе Bug Bounty. Среди них — две серьезные уязвимости во встроенном просмотрщике PDF.

Что еще произошло:
На этой неделе Reuters процитировал генерального директора МАГАТЭ Юкия Амано, который публично подтвердил факт успешной кибератаки на атомную электростанцию. Подробностей нет, известно лишь, что атака вызвала «сбои в работе». Предположительно атака произошла 2 или 3 года назад.

Интересное исследование про кейлоггер, который крадет данные кредиток на стороне веб-сервера. Очевидно повышение «эффективности» атаки при таком сценарии.

Древности

Семейство «Little»

Нерезидентные очень опасные вирусы. Длина — всего 45 или 46 байт. Крайне примитивны. Записывают себя в начало всех .COM-файлов текущего каталога, не сохраняя старого содержимого этих файлов. Пораженные файлы, естественно, не восстанавливаются.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 37.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Let's block ads! (Why?)

Проблемы безопасности IoT: исследователь обнаружил серьезные уязвимости в MatrixSSL

SSL — основной инструмент обеспечения безопасности в интернете, позволяющий организовывать защищенный обмен данными даже в недоверенной сети. Однако реализация устойчивого SSL — не такая уж и легкая задача, ошибки в решении которой могут приводить к масштабным проблемам, таким, как уязвимость Heartbleed.

В сфере интернета вещей существует собственная реализация SSL — MatrixSSL, и как показывает практика, с уровнем ее защищенности не все хорошо.

В чем проблема

Подобные масштабные уязвимости поднимают вопросы реализации подходов безопасной разработки и недостатков процессов проектирования, применявшихся создателями многих реализаций SSL. В разгар скандала с Heartbleed даже звучали призывы отказаться от использования OpenSSL в пользу NSS, GnuTLS и Polar SSL. Что касается устройств так называемого интернета вещей (Internet of Things, IoT), то в этом случае многие эксперты по безопасности рекомендовали использовать MatrixSSL — компактный SSL/TLS стек, разработанный специально для применения в сфере IoT.

Однако в 2015 году было опубликовано исследование SEC Consult, авторы которого сумели обнаружить более 80000 подключенных к сети устройств, которые использовали одни и те же ключи шифрования, опубликованные в домашнем репозитории MatrixSSL. Еще десятки тысяч устройств на базе MatrixSSL можно найти с помощью поисковика Shodan.

Такие устройства часто — это сетевое оборудования вроде WiMAX-шлюзов или кабельных модемов интернет-провайдеров. Это значит, что наличие критических уязвимостей в софте, использующимся этими устройствами, может приводить к масштабным инцидентам информационной безопасности.

И подобные уязвимости были обнаружены исследователями — в 2016 году Флориан Ваймер (Florian Weimer) и Ханно Бёк (Hanno Böck) раскрыли информацию о криптографических проблемах MatrixSSL — помимо прочего была обнаружена возможность похищения частных ключей шифрования. После общения с Бёком, ИБ-исследователь компании Tripwire Крейг Янг (Craig Young) решил внимательнее изучить уровень защищенности сертификата X.509 MatrixSSL.

С помощью инструмента American Fuzzy Lop (AFL) ему удалось обнаружить сразу несколько серьезных уязвимостей. Среди найденных проблем, переполнение буфера, приводящее к выполнению кода (CVE-2016-6890), уязвимость buffer over-read (CVE-2016-6891) и некорректная работа механизма освобождения памяти в модуле x509FreeExtensions() (CVE-2016-6892).

Данные ошибки могут приводить к серьезным проблемам. К примеру, в том случае, если система на базе MatrixSSL используется для обработки недоверенных сертификатов X.509 — частая ситуация при аутентификации клиентского приложения, то атакующий может получить возможность осуществления удаленного выполнения кода. Для роутер или IoT-устройств это означает практически гарантированный полный доступ с привилегиями root-пользователя.

Как защититься

По словам Янга, производители, использующие в своих продуктах MatrixSSL, были уведомлены об обнаруженных уязвимостях в сентябре, и уже работают над патчами. Вендоры и частные пользователи MatrixSSL могут скачать обновленную прошивку из официального GitHub-репозитория Matrix SSL. Исправления найденных ошибок включены в коммит b8dcfd875923da5a65ecfdbbe790ed63b1d33de3 для релиза 3.8.6.

К сожалению, многие устройства на базе MatrixSSL, использующиеся в корпоративных сетях, никогда не будут обновлены — не все IoT-производители в итоге выпустят патчи, а в случае отсутствия автоматического обновления сами пользователи вряд ли будут этим заниматься.

Все это поднимает важный вопрос — вместо обсуждения более надежных инструментов обеспечения защиты в интернете и необходимости поиска их замены, гораздо перспективнее думать о реализации более продвинутых механизмов распространения обновлений и внедрения подходов безопасной разработки софта.

Let's block ads! (Why?)

[Из песочницы] Как мы придумали и сделали свою первую игру на Android. Часть 1: Механика игры

Всем привет! Мы два новоиспеченных разработчика мобильных игр, бывшие одноклассники, выпускники Казанского федерального университета, Айдар и Эд.

Айдар: «История нашей игры началась с того, что мне приснился странный сон. Он представлял собой компьютерную игру, где на квадратном поле синхронно передвигались четыре белых шарика. Когда первый из них вырвался за пределы игрового поля, я проснулся. Наутро я позвонил Эду, а уже в обед мы встретились во дворе университета, где я работал».

Эд: «Какой программист не мечтал сделать свою игру? Летом 2014-го у меня было много свободного времени, и я с радостью ухватился за эту идею. Тогда мы и представить себе не могли, с какими трудностями мы столкнемся».

Впрочем, на первом этапе мы были полны энтузиазма, все было легко и интересно. Именно о нем мы и расскажем в первой части статьи.

Итак, на входе у нас была одна простая идея — игрок одним движением управляет четырьмя героями.

Вначале нужно было разобраться с жанром игры. Аркады мы отклонили довольно быстро: управлять таким количеством одновременно движущихся элементов — задача не из легких. Нам обоим нравятся размеренные интеллектуальные игры, поэтому мы сошлись на том, что это будет пошаговая головоломка. Правда, пользователям от этого легче не стало — игра получилась хардкорной. Также мы решили исключить случайные и непредсказуемые элементы, чтобы процесс игры полностью зависел от действий игрока.

Эд: «Недолго думая, в качестве языка программирования я выбрал Processing, так как на нем легко создавать прототипы без предварительных настроек. Кроме того, синтаксис Java позволил нам без труда перенести логику игры на Android при помощи таких комбинаций, как Ctrl+C и Ctrl+V, но об этом позднее. Мы создали четырех героев в виде белых кругов и меняли их координаты с помощью стрелок на клавиатуре».

Айдар: «Начальное положение героев мы установили в равноудаленных местах уровня, так как это выглядело симметрично и “почему бы и нет?”. Впоследствии, мы решили, что будет прикольно, если каждый уровень будет начинаться так же».

Немного поэкспериментировав с управлением, мы поняли, что героям нужна цель, некий выход с уровня. Поначалу мы рассматривали идею вывести героев за пределы игрового поля (именно так было во сне Айдара). Но единственный выход показался нам интереснее и драматичнее — он накладывал больше ограничений (из которых, как известно, и рождается творчество). Так у нас появилось единственное условие победы: все герои должны выйти живыми. Табличку «выход» обычно подсвечивают зеленым цветом. Мы поступили так же.

«На второй день Они создали стену. Да будет стена посреди уровня, и да отделит она героев от выхода».

Объект стена — это естественное препятствие и основной инструмент для построения сценария прохождения. Интуитивно мы решили, что герой остается на месте, если на пути его следования стоит стена. Так как стены обычно строят из камня, то мы изобразили их как серый квадрат.

Игровое поле мы составили в виде шахматной доски размерностью 11 на 11. Таким образом проще хранить и перемещать объекты. Например, если герой находится в левом нижнем углу, то его координаты — [0][0]. Чтобы подвинуть героя на одну клетку вверх, достаточно прибавить единицу к значению строки: [0+1][0]=>[1][0]. Каждую клетку может занимать только один объект, из чего вытекает естественный вопрос: «Что произойдет, если два объекта окажутся на одной клетке?» Впервые мы над этим задумались, только когда один герой уперся в стену, а второй на него наехал. Так появилось одно из условий проигрыша: два героя на одной клетке взаимно уничтожаются.

Еще одно условие проигрыша появилось, когда мы создали элемент ловушка — клетка, при попадании на которую герой умирает. Ловушку нужно было изобразить как что-то опасное и запретное, поэтому, придерживаясь минималистичного стиля, мы выбрали красный квадрат.

Эд:«Мне очень нравится настольная игра «Роборалли», и в особенности система конвейеров, которая вносит элемент неожиданности, если неверно рассчитать свои действия. Конвейеры срабатывают в отдельной фазе хода (после передвижения героев) и смещают объекты по направлению стрелки. В нашу игру мы привнесли нечто подобное, назвав это потоками».

Потоки имеют две основные функции:

1) Система ниппель. Она пропускает в одну сторону, но не пропускает обратно.

2) Поточная линия. С помощью нее герои, враги и ящики (о них чуть позже) могут кататься по предустановленным маршрутам.

Айдар: «Продолжая поиск изощренных способов убить героев, мы решили развить идею ловушек и сделать их подвижными. Сначала у нас была мысль ввести в игру ловушку-маятник, которая с определенной частотой перемещалась бы между двумя клетками. Но ловушка, которая может путешествовать по всему игровому полю — это намного круче. Такие элементы получаются “живыми”, и мы сразу же назвали их врагами».

Однако беспорядочное перемещение элементов вносит в игру непредсказуемость и неконтролируемость, которые идут вразрез с законами придуманного нами мира. Поэтому мы приняли решение, что враги должны управляться самим игроком и, будучи антагонистами героев, двигаться наперекор командам, то есть в обратную сторону. Например, если герой идет направо, то враг — налево.

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

Эд: «На одном из тестовых уровней враги так раздражали, что мне все время хотелось им отомстить. Нужен был инструмент, а точнее оружие против них, которым могли бы воспользоваться герои. Перебрав несколько вариантов, мы решили давить врагов тяжелыми предметами».

Мы вспомнили игру «Сокобан» и создали модифицированный вид ящиков (новое — это хорошо забытое старое). По сути, ящики — это стены, которые можно толкать, поэтому мы изобразили их как уменьшенные серые квадраты с перекрестием. Они гармонично вписались в правила нашей игры: если толкнуть ящик на клетку с героем или врагом, то персонажи умирают, так как по закону два объекта не могут находиться в одной клетке. Кроме того, ящики могут ездить в потоках, а при попадании в ловушку или выход они разрушаются. Как и в игре «Сокобан», нельзя толкать больше одного ящика в ряд, поэтому возможны ситуации, когда герой оказывается взаперти.

Айдар: «При создании уровня предугадать все возможные решения практически невозможно, и уже в самом начале мы с Эдом заметили, что проходим уровни по-разному. Это неудивительно, ведь с каждым новым ходом число состояний растет экспоненциально».

Вариативность прохождения — это особенность игры, которой мы искренне гордимся. Конечно, большинство уровней возможно пройти не задумываясь, но тогда вместо двадцати ходов вам может понадобиться сорок или шестьдесят. Так в игре появился стимул к повторному прохождению — поиск кратчайшего решения.

Эд: «Лично для меня поиск оптимального прохождения — это любимая часть в игре. В самом начале разработки мы завели таблицу, где наши друзья, самые первые пользователи, делились своими рекордами: за сколько ходов был пройден уровень. Бить рекорды и попадать в этой список мотивировало нас играть дальше».

Перед релизом игры нам понадобилось собрать кратчайшие прохождения всех уровней, чтобы выдавать их в виде платных подсказок. Для этого мы запрограммировали алгоритм перебора с ограничениями, но он работал чересчур долго на уровнях с большим количеством объектов. Когда время расчетов превысило несколько суток, мы решили воспользоваться краудсорсингом (англ. crowdsourcing, crowd — «толпа» и sourcing — «использование ресурсов»). Если игрок улучшал рекорд на одном из уровней, то с помощью Google Analytics мы получали его решение в виде последовательности ходов. Опытные игроки обычно ищут оптимальное прохождение эвристически, применяя свои наработанные шаблоны и избегая избыточных ходов. Таким образом, мы быстро пополнили базу прохождений, но, к нашему удивлению, некоторые игроки до сих пор продолжают бить рекорды. Их мы аккуратно записываем и обновляем в последующих версиях приложения.

Продолжение следует…

В следующей части мы расскажем о том, как разрабатывали загадки и технику прохождения уровней.

Let's block ads! (Why?)

[Перевод] Советы и рекомендации по работе с Unity3D

[Перевод] Великая война хакеров 1990 года (Great Hacker War)

Под «Великой войной хакеров» подразумевается конфликт 1990-1991 гг. между Masters of Deception (MOD) и группой, отколовшейся от группировки Legion of Doom (LOD), от старой гвардии хакеров, а также другими менее известными хакерами. Якобы обе главные группы предпринимали попытки взлома ресурсов друг друга через интернет, Х.25 и телефонные сети.

На дебатах в рамках конференции «The Next HOPE» в 2010 г. Phiber Optik не раз повторил, что «война группировок в киберпространстве» между LOD и MOD — всего лишь сплетни, что она выдумана прокуратурой США и падкими на сенсации СМИ. Более того, двое из высокопоставленных членов LOD подтвердили, что «Великой война хакеров» не было, а если что и было, то не более чем соревнование, желание показать свое превосходство.

Однако, все же был конфликт между «новым» LOD, возглавляемым Erik Bloodaxe, и MOD. Даже если и была «война», все это совсем не так, как принято считать.

Про двух лидеров уже писали на Хабре:
Erik Bloodaxe (Крис Гогганс)
Phiber Optik (Марк Абен)

Что было на самом деле

Ирония в том, что никто из членов LOD никогда не пытался перехватить управление различными АТС у MOD, не забивал их чаты надписями вроде «phiber sux» и т.д. Об этом сказал Netw1z в радиопередаче «HOPE talk». И, несмотря на это, Гогганс (Erik Bloodaxe) провозгласил победу в «войне», чистую победу MOD на всех фронтах, даже начал раздавать футболки на конференции «HoHoCon» с надписью «Великая хакерская война» и «LOD: 1 MOD: 0». Другие участники LOD, которые не участвовали в этом, например Marauder и другие, считают это просто пропагандой Гогганса нового LOD.

Примечательно, что единственный кто получил доступ на территорию телекоммуникационных компаний и X.25 PSN, признанной за MOD, сделал это из желания показать, что он достоит уровня участников MOD, и никогда не упоминал о своей причастности к какой-либо войне. Джон Ли и Аллен Вилсон заявили, что The Phrezh Prince of Bellcore относится к недосягаемой элите, и это мнение разделяют многие знающие его хакеры. Да, иногда он может потролить в IRC, но по навыкам во многих сферах он не имеет себе равных.

Опоздавший в MOD и LOD

Phrezh Prince of Bellcore (aка sw1tchg0d) было 16, когда он, как утверждают, контролировал RBOCs Qwest, Bell Atlantic и ILEC GTE (последние две потом превратились в Verizon) и, по свидетельствам его сторонников, все северо-американские телефонные компании ’99-‘01. Еще спустя долгое время после того, как закончилась «война» между sw1tchg0d и Erik Bloodaxe, который оставил о себе впечатление у MOD и sw1tchg0d как о доносчике. Члены группы sw1tchg0d — H4G1S — и предполагаемые друзья группы MOD заявили, что sw1tchg0d был лучшим по взлому внутренних систем и сетей Bell, к тому же в столь молодом возрасте, да и еще в ту пору, когда было задействовано больше механизмов по обеспечению безопасности (идентификация SecurID, среди прочих). Никнейм sw1tchg0d (в жизни — Джонатан) раньше использовал его наставник — основатель H4G1S Shokwave Rider (sw_r), еще один взломщик телефонных сетей. Джонатан присвоил этот никнейм через некоторое время, чтобы выразить уважение Мохаммеду (sw_r).

После прочтения книги о MOD sw1tchg0d стал с почтением к ним относиться. И поэтому он якобы завладел доступом Phiber Optik к манхэттенской АТС, вытащив данные qcm, qinfo и qdn, просто в качестве сувенира на память, а не с целью продемонстрировать пренебрежение. Phiber Optik сообщили о том, что тот, кто это сделал, хорошо знает свое дело.

Мишенью для шуток sw1tchg0d был также Erik Bloodaxe, о котором он распространил в хакерской среде выдержки из судебного дела, где идет речь о его стрельбе из дробовика в свою жену.

Знания

В группе Masters of Deception было трое членов с особенной специализацией. По общей договоренности Phiber Optik обладал огромным багажом информации о телекоммуникациях. W1ng обычно считался спецом по UNIX, еще до того как стали известны большинство трюков, и Джон Ли (Corrupt) был отменным взломщиком систем и отлично разбирался в VMS.

Phiber Optik знал о многих внутренних АТС, о не задокументированных особенностях гарнитур, о системах SCCS, о возможности пройти аутентификацию, о получении привилегированных прав и о многом другом, что не стоит здесь публиковать, чтобы не вызвать на себя критику. Это были мощные штуки, он делился ими только с несколькими людьми, в MOD.

В LOD мало интересовалась телекоммуникациями или X.25, испытывали трудности в проникновении и удержании контроля над подобными системами. Не было у них понимания Datakit, заметим, необходимого для ведения «войны» в телекоммуникационных сетях. Более того, есть архивы BBS ряда хакеров, где Erik Bloodaxe задает нелепые вопросы о телекоммуникационных системах. Говорят так: «Erikb мог бы получить доступ к телекоммуникационным системам, только если бы он наткнулся на все еще залогиненный терминал COSMOS».

Согласно Phiber Optik и C0rrupt, так называемая «война» началась из-за того, что Erik Bloodaxe вымаливал у Phiber Optik доступ к Nynex Packet Switched Network (npsn — доступный в то время через Nynex Datakit, которого у Bloodaxe не было). Баланс мастерства был настолько больше смещен в сторону Masters of Deception, что это почти никогда и нигде не подвергалось сомнению, кроме Erik Bloodaxe и его друзьями.

Развитие событий

«Великая война хакеров» длилась всего несколько дней, в течение которых можно выделить 4 основных события.

Событие один
Все началось с закрытия электронной доски объявлений (с доступом по инвайтам) «Fifth Amendment» («Пятая Поправка»), участники которой были известными хакерами. Она управлялась членами недавно реформированного LOD под руководством Криса Гогганса (Erik Bloodaxe) and Ллойда Бланкешипа (The Mentor).

В закрытии обвинили Джона Ли (Corrupt) из MOD. Крис Гогганс объявил, что Ли распространяет информацию, которая обсуждается в чате. В MOD же обнаружили, что Крис Гогганс и его друзья решили использовать информацию с «Fifth Amendment», чтобы организовать компанию в области информационной безопасности и слили информацию другим организациям, деятельность которых обсуждалась на этой доске объявлений.

Событие два
Несколько розыгрышей по домашнему телефону расстроили Гогганса и он призвал всех раздобыть персональную информацию членов MOD на организованной между членами LOD телефонной конференции.

Члены MOD подключились к ней и подслушали, как их поливают грязью, издеваются над их расовой принадлежностью. Кончилось все тем, что члены MOD «оборвали провода» звонками на личные номера участников конференции с шутками и угрозами.

Событие три
Состоялся разговор между Крисом Гогганом и Марком Абеном. Джон Ли скрытно для первого тоже был на линию. Гогганс разозлился, что Абен отказался выполнять его многочисленные требования предоставить личную информацию об участниках MOD, хакерскую информацию якобы принадлежащую LOD и пр., и сказал следующее: «MOD — всего лишь нигеры, латиносы и белая шваль».

Событие четыре
Члены MOD стали прослушивать телефонные разговоры Криса Гогганса, чтобы понять его мотивацию, используя удаленную гарнитуру через ближайшую к Гоггансу АТС (DMS-100). И услышали подтверждение ранней версии: Гогганс, Скот Часин (Doc Holiday) и Джейк Кенион Шульман (Malefactor) решили основать компанию в области информационной безопасности под названием ComSec.

Эпилог
В 1991 г. Phiber Optik на первой CFP конференции в Сан-Франциско вместе с Крейгом Нейдорфом был приглашен принять участие в телефонной конференции, организованной хакерами-друзьями, на которой раскаивающийся Шульман выразил сожаление о том, что ситуация вышла за рамки, о том, что Гогганс перешел черту, передав информацию о других хакерах властям для поднятия престижа компании ComSec.

Далее начали подозревать Гоггенса в сдаче информации федеральным властям об австралийской хакерской группировке The Realm. Другие члены LOD связывались с Абеном, желая узнать, не вовлек ли Гогганс и его информаторы их в текущее судебное дело Абена, и уверяли его в непричастности к подобному непристойному поведению.

В 1993 г. на третей CFP конференции, тоже в Сан-Франциско, Phiber/Абен встретил первый раз в живую нескольких своих старых друзей из LOD (за исключением Гогганса), хотя к этому моменту они дружили уже более 10 лет. Немного повспоминали прошлое.

Спустя несколько лет Гогганс публично заявил, что он сожалеет о том, что втянул Абена в свои показания правоохранительным органам.

В общем, наверняка во всем этом Phiber и Lex Luthor сходятся в одной вещи — не было на самом деле никакой «Великой хакерской войны», и что все эти спекуляции на тему «воюющих хакерских банд» лишь результат рьяного отношения властей и безответственности СМИ.

Читать еще

Gang War in Cyberspace | WIRED
История компьютерного андеграунда: Legion of Doom vs Masters of Deception

Перевод: Сергей Даньшин

Let's block ads! (Why?)

[Из песочницы] Python-шпаргалка. Часть 1 — Язык и Типы объектов

Данная статья представляет собой очень краткую, но емкую выжимку всего, что должен знать начинающий разработчик или QA-инженер о языке Python. Надеюсь, что усердие, приложенное при написании данной статьи, поможет многим подготовиться к собеседованиям на соответствующие вакансии и расширить свой IT-кругозор.

Статью стоит воспринимать не как учебник, а как удобную шпаргалку или «опорный сигнал» (так моя учительница истории называла подобное «творчество» в школе). Здесь не будет подробных определений, объяснений в целую главу, а лишь четкие термины, списки, краткие выжимки кода. Статья основана на замечательной книге Марка Лутца «Изучаем Python (5-е издание)», так что за её корректность и достоверность можете не переживать. Итак, начнем.

Вкратце о Python

Python — высокоуровневый язык программирования общего назначения (часто называется языком сценариев), ориентированный на повышение производительности разработчика и читаемости кода.
Преимущества Python:

• Качество ПО
• Высокая скорость разработки
• Переносимость программ
• Библиотеки поддержки
• Интеграция компонентов (можно вызывать функции из библиотек C/C++)

Основные возможности Python:

• Динамическая типизация (при этом она строгая)
• Автоматическое управление памятью
• Модульное программирование
• Встроенные типы объектов
• Библиотеки утилит

Процесс запуска программ:

• Сценарий компилируется (перевод программы) в байт-код (платформонезависимое представление исходного текста программы, .pyc файл)
• Байт-код передается виртуальной машине PVM.

Сравнение с C/C++:

• Отсутствует этап сборки
• Байт код не является двоичным машинным кодом (не может выполняться так же быстро)

Альтернативные реализации Python:

• CPython (реализация на ANSI C)
• Jython (реализация на Java классах)
• IronPython (реализация для использования с .Net)

Типы объектов в Python

Данные в Python представляется в форме объектов — либо встроенных, либо создаваемых с помощью конструкций языка Python или других (например С).

Программы <= Модули <= Инструкции <=Выражения

Формы отображения объектов:

• repr (в виде программного кода, например 6.28300000000004)
• str (более читаемый, например 6.283)

Строка — неизменяемая последовательность (упорядоченная коллекция) других объектов (односимвольных строк) в языке Python.
Некоторые операции над последовательностями:

• len(s) — длина
• s[0] — обращение к элементу
• s[-1] — обращение к элементу с конца последовательности
• s[1:3] — срез начиная со смещения 1 и до 2 (не 3)
• s[:] — скопировать все содержимое (не путать с a=s)
• s*8 — повторение
• s+’xyz’ — конкатенация

Особые символы табуляции:

• \n — конец строки
• \t — табуляция
• ord(‘\n’) — байт с числовым значением
• ‘A\0B\0C’ — \0 двоичный ноль

[Hint] Чтобы вывести все доступные методы у переменной: dir(s)
Списки (lists) – это упорядоченные по местоположению коллекции объектов произвольных типов, размер которых не ограничен.
Списки являются последовательностями => поддерживают все операции над последовательностями. Единственное отличие состоит в том, что результатом таких операций являются списки, а не строки.
Преимущества списков:

• Возможность создавать вложенные списки
• Использование выражений генераторов списков

col2 = [row[1] for row in M]

Словари (dictionary) — не являются последовательностями, это коллекции объектов, где доступ к ним осуществляется не по определенным смещениям от начала коллекции, а по ключам. Изменяемый тип. Также возможна вложенность.

D = {'food': 'Spam', 'quantity': 4, 'color': 'pink'}

или

D = {}
D['name'] = 'Bob'

Кортеж (tuple) — список, который невозможно изменить. Кортежи являются последовательностями, как списки, но они являются неизменяемыми, как строки. Возможна вложенность. Возможно одновременное хранение объектов разных типов.

T = (1, 2, 3, 4)

Объекты-файлы — это основной интерфейс между программным кодом на языке Python и внешними файлами на компьютере. Файлы являются одним из базовых типов, но они представляют собой нечто необычное, поскольку для файлов отсутствует возможность создания объектов в виде литералов. Вместо этого, чтобы создать объект файла, необходимо вызвать встроенную функцию open, передав ей имя внешнего файла и строку режима доступа к файлу.

f = open('data.txt', 'w') # Создается новый файл для вывода

Самый лучший на сегодняшний день способ чтения файлов состоит в том, чтобы не читать его содержимое целиком – файлы предоставляют итераторы, которые обеспечивают автоматическое построчное чтение содержимого файла в циклах for и в других контекстах.
Множества — это неупорядоченные коллекции уникальных и неизменяемых объектов. Множества создаются встроенной функцией set.

X = set('spam') # В 2.6 и 3.0 можно создавать из последовательностей
Y = {'h', 'a', 'm'} # В 3.0 можно определять литералы множеств
X, Y
({'a', 'p', 's', 'm'}, {'a', 'h', 'm'})
X & Y # Пересечение
{'a', 'm'}
X | Y # Объединение
{'a', 'p', 's', 'h', 'm'}
X – Y # Разность
{'p', 's'}

Let's block ads! (Why?)

Московская часть хакатона TADHack: уже завтра

Последняя неделя подготовки к любому крупному событию — это очень и очень больно. Мешки удлинителей из Ашана, суровый админ с WiFi на 200 человек, оптовый заказ пицц, видеообращение от Шаттлворта и множество других организационных моментов. Но, как говорил Иллидан, — вот теперь мы готовы! Регистрация все еще открыта и я буду очень рад видеть вас на этом первом в России хакатоне, который пройдёт одновременно в десятках городов по всему миру. TADHack соберет более 2'000 разработчиков, будет видео-трансляция между площадками, море фана, пицца от Papa John's и крутые призы. Присоединяйтесь!

Идея привезти TADHack в Москву посетила нас еще в прошлом году, когда мы выступали спонсорами мини-TADHack'а в Париже. Вечеринка тогда вышла колоритной:

TADHack, что любопытно, создан не эвент-агентством с целью заработать денег, а экспертом из телеком индустрии, который уже много лет работает с самыми передовыми технологиями на стыке телекома, веб и мобильной разработки. Алан производит впечатление айтишного Санта-Клауса: окладистая седая борода, неизменное «хо-хо-хо», ноутбук с убунтой и россыпь кастомных симок. Очень харизматичный товарищ и неплохой организатор: за несколько лет он в одиночку сделал TADHack, каждый год привлекает все больше спонсоров, освещает происходящее в прессе и действительно помогает разработчикам использовать последние достижения в области realtime communications.

Изюминка хакатона: он условно-одновременно стартует в нескольких десятках странах с кросс-трансляцией между площадками! Сейчас площадка разобрана, но к завтрашнему утру две плазмы будут транслировать коллег из Лондона и Берлина, а разработчики из других стран смогу смотреть, как мы пьем водку и за 24 часа превращаем идеи в работающие прототипы.

Распределение призов тоже любопытное. В воскресенье, когда команды начнут выступать со сцены и показывать свои творения, я буду синхронно переводить это на английский. И все будет записываться в общую таблицу всех выступлений. Когда ребята закончат выступать, наше жюри распределит локальные призы от Voximplant, NUMA, Бизнес-инкубатора МГУ. И мы разойдемся по домам.

После чего начнется самое интересное. Когда во всем мире завершатся выступления всех команд, организаторы возьмут таблицу, запасутся Red Bull и всю ночь будут смотреть выступления команд со всего мира, которые заявили их номинацию. У нас есть призовой фонд, и мы будем распределять его по командам. В понедельник выспавшиеся участники хакатона откроют сайт tadhack.com и увидят список победителей по всем странам! Деньги уже собраны у Алана, и будут переданы победителям банковскими переводами.

В этом году в призовой фонд вложились 9 компаний, включая нас. Список предоставленных API можно посмотреть вот тут. Несмотря на то, что название хакатона переводится как «Telecom Application Development Hackathon», гости могу создавать любые приложения. Использование API одного или нескольких спонсоров повышают шансы получить от них денежный приз, а вот локальный приз жюри могут вручить на свое усмотрение: за интересную идею, реализацию, выступление.

Жду в гости. До завтра!

Let's block ads! (Why?)