Всем привет! В этом обзорном посте собрал для вас подборку всевозможных произведений кинематографа, так или иначе затрагивающих тему OSINT-исследований. Среди почти двух десятков вариантов найдутся кинокартины на любой вкус: от документалок по следам громких расследований и скандалов в информационную эпоху до художественных сериалов, по-разному обыгрывающих заданную тему.

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

Недавно мы проводили вебинар «Обкафкился по полной. Фейлы с Apache Kafka». На нём спикер Всеволод Севостьянов, Engineering Manager в HelloFresh, поделился фейлами из личной практики, а ещё рассказал, как мастерски ходить по тонкому льду Kafka и прокачать свой бэкенд. Для тех, кто пропустил или предпочитает читать, а не смотреть, подготовили текстовый вариант.

Зачем менять ZooKeeper на встроенный лог Apache Kafka® для управления метаданными? В этой статье вы узнаете, зачем нужна была эта замена, какие преимущества даёт протокол консенсуса на основе кворума, вроде Raft, и как работает контроллер кворума поверх протоколов KRaft.

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

Администратор баз данных в Southbridge и ведущий инженер компании Data Driven Lab Иван Чувашов занимается базами данных 15 лет и сегодня хочет поговорить про оптимизацию запросов. Разбирать все будет на примере PostgreSQL, так как именно с этой базой он сейчас работает плотнее всего.

Эта статья — конспект бесплатного вебинара об оптимизации PostgreSQL от «Слёрма». Если вам удобнее смотреть, а не читать, переходите на YouTube.

Суффиксное дерево (Suffix Tree, ST) – это структура данных, которая позволяет "проиндексировать" строку за линейное время от её длины, чтобы потом быстро находить подстроки (за время О(длина искомой подстроки)).

Тема построения Suffix Tree и его применения хорошо раскрыта в Интернет (википедия, статья на хабр про алгоритм Вейнера, язык Си, и статья на хабр про алгоритм Укконена). Но всегда есть соблазн поучаствовать в соревновании "написать проще и яснее", хотя шансов мало. Тем не менее, рискну.

Несмотря на сложность, алгоритм построения ST умещается в 35 строк на python (см. ниже метод _build_tree). Их буквально можно выучить и воспроизводить по памяти как некое произведение искусства, как воплощенный в набор символов труд человеческой мысли, причём не одного человека, и первые из них точно гении. :) Есть соблазн, всматриваясь в код, прикоснуться к великому и чему-то научиться.

https://fakt309.github.io/thisisthewall/

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

Но вот что если мы хотим не просто получать дискретное значение (true / false), а дифференцированное, например в процентах. Ведь согласитесь строки test и testing гораздо ближе к друг другу, чем test и abcd. Для данной проблемы существует множество решений, мы поговорим о самый популярных алгоритмах (также об их модификациях):

Расстояние Хэмминга

Расстояние Левенштейна

Сходство Джаро — Винклера

Коэффициент Сёренсена

Почему так сложно понять asyncio?

Асинхронное программирование традиционно относят к темам для "продвинутых". Действительно, у новичков часто возникают сложности с практическим освоением асинхронности.

Но будь я автором самого толстого в мире учебника по python, я бы рассказывал читателям про асинхронное программирование уже с первых страниц. Вот только написали "Hello, world!" и тут же приступили к созданию "Hello, asynchronous world!". А уже потом циклы, условия и все такое.

Привет, Хабр! Очень часто я на просторах интернета натыкаюсь на такой вопрос: «А какое готовое решение по детекции лиц лучше всего использовать?» Так вот, я отобрал 5 решений с Github, которые показались мне хорошими, относительно новыми и лёгкими в использовании, и хотел бы сравнить их между собой. Всем, кому интересно, что из этого вышло, добро пожаловать под кат!

Налоговая отдаёт данные ЕГРЮЛ  по организации в виде PDF. Посредники за автоматический доступ по API хотят денег. На многих сайтах часть данных закрыто, часть функций недоступны бесплатно, и полно рекламы. 

Особенно интересно, что на некоторых сайтах предоставляющих данные по API имеется логотип Сколково. Это такой высокотехнологический бизнес, наверное, открытые данные продавать.

Налоговая просит 150 000 рублей в год за доступ к данным ЕГРЮЛ в виде сваленных в архивы XML-файлов. У ФНС классный бизнес. Вы проявляйте должную осмотрительность при выборе поставщиков, но доступ к данным за деньги. Если вы хотите получить доступ и к реестру индивидуальных предпринимателей (ЕГРИП), то платите ещё 150 000 рублей в год. Согласитесь 300 000 рублей в год приличная сумма.

Остальные реестры данных у налоговой доступны бесплатно. Однако, без базы ЕГРЮЛ их вряд ли можно использовать. Самая частая операция в бизнесе подставить реквизиты из ЕГРЮЛ по ИНН.

Сформировалась целая отрасль, можно сказать, торговцев воздухом открытыми данными, создающих ВВП из воздуха как бухгалтеры, работающие руками там, где должны работать программы. Сколько компаний платит налоговой по 300 000р. в год?! Сколько программистов занято написанием одинаковых по функциям парсеров, которые переводят данные из XML налоговой в SQL и JSON?! Сколько серверов заняты под одинаковые функции?! Где добавочная стоимость? Все вроде при деле, а за чей счёт банкет?

Ну, ладно, “скандалить, критиковать каждый может”(с) как говорил бессмертный товарищ Райкин. “А что ты предлагаешь?” — резонно вы меня спросите. А я вам отвечу.

2021 год в машинном обучении ознаменовался мультимодальностью — активно развиваются нейросети, работающие одновременно с изображениями, текстами, речью, музыкой. Правит балом, как обычно, OpenAI, но, несмотря на слово «open» в своём названии, не спешит выкладывать модели в открытый доступ. В начале года компания представила нейросеть DALL-E, генерирующую любые изображения размером 256×256 пикселей по текстовому описанию. В качестве опорного материала для сообщества были доступны статья на arxiv и примеры в блоге. 

С момента выхода DALL-E к проблеме активно подключились китайские исследователи: открытый код нейросети CogView позволяет решить ту же проблему — получать изображения из текстов. Но что в России? Разобрать, понять, обучить — уже, можно сказать, наш инженерный девиз. Мы нырнули с головой в новый проект и сегодня рассказываем, как создали с нуля полный пайплайн для генерации изображений по описаниям на русском языке.

В проекте активно участвовали команды SberAI, SberDevices, Самарского университета, AIRI и SberCloud.

Мы обучили две версии модели разного размера и дали им имена великих российских абстракционистов – Василия Кандинского и Казимира Малевича:

1. ruDALL-E Kandinsky (XXL) с 12 миллиардами параметров;

2. ruDALL-E Malevich (XL), содержащая 1,3 миллиарда параметров.

Некоторые версии наших моделей доступны в open source уже сейчас:

1. ruDALL-E Malevich (XL) [GitHub, HuggingFace]

2. Sber VQ-GAN [GitHub, HuggingFace]

3. ruCLIP Small [GitHub, HuggingFace]

4. Super Resolution (Real ESRGAN) [GitHub, HuggingFace]

Две последние модели встроены в пайплайн генерации изображений по тексту (об этом расскажем ниже).

Версии моделей ruDALL-E Malevich (XL), ruDALL-E Kandinsky (XXL), ruCLIP Small, ruCLIP Large, Super Resolution (Real ESRGAN) также скоро будут доступны в DataHub.

Обучение нейросети ruDALL-E на кластере Christofari стало самой большой вычислительной задачей в России: 

1. Модель ruDALL-E Kandinsky (XXL) обучалась 37 дней на 512 GPU TESLA V100, а затем ещё 11 дней на 128 GPU TESLA V100 — всего 20 352 GPU-дней;

2. Модель ruDALL-E Malevich (XL) обучалась 8 дней на 128 GPU TESLA V100, а затем еще 15 дней на 192  GPU TESLA V100 – всего 3 904 GPU-дня.

Таким образом, суммарно обучение обеих моделей заняло 24 256 GPU-дней.

Разберём возможности наших генеративных моделей.

Прим. перев.: эту статью написал автор Open Source-утилиты HTTP Toolkit, предназначенной для исследования и модификации HTTP(S)-трафика для нужд отладки и тестирования. В материале собраны примечательные особенности стандарта HTTP, которые долгие годы живут вместе с нами, однако не каждый догадывается об их существовании.

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

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

Предисловие

О чем же все это говорит?

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

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

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

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