Доктор технических наук, профессор Юрий Рябцев — выпускник МФТИ, многолетний сотрудник ИТМиВТ и ИНЭУМ. В 1976 году он стал лауреатом государственной премии за разработку вычислительного комплекса для С-300, в 1986-м — лауреатом Ленинской премии за разработку «Эльбруса-2». В интервью из нашей исторической серии Юрий Степанович рассказывает, как готовили инженеров для передовых оборонных программ, объясняет, как в СССР взаимодействовали институты и целые отрасли, делится мнением о крупных советских проектах в области ИТ.

Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». У нас более 7 тыс. физических серверов, 11 тыс. контейнеров в нашем облаке и 200 приложений, которые в различной конфигурации формируют 700 различных кластеров. Подавляющее большинство серверов работают под управлением CentOS 7.
14 августа 2018 г. была опубликована информация об уязвимости FragmentSmack
(CVE-2018-5391) и SegmentSmack (CVE-2018-5390). Это уязвимости с сетевым вектором атаки и достаточно высокой оценкой (7.5), которая грозит отказом в обслуживании (DoS) из-за исчерпания ресурсов (CPU). Фикс в ядре для FragmentSmack на тот момент предложен не был, более того, он вышел значительно позже публикации информации об уязвимости. Для устранения SegmentSmack предлагалось обновить ядро. Сам пакет с обновлением был выпущен в тот же день, оставалось только установить его.
Нет, мы совсем не против обновления ядра! Однако есть нюансы…

Недавно я вернулся к анализу погрешностей чисел с плавающей запятой, чтобы усовершенствовать некоторые детали в следующей редакции книги Physically Based Rendering. Числа с плавающей запятой — интересная область вычислений, полная сюрпризов (хороших и плохих), а также хитрых трюков, позволяющих избавиться от неприятных неожиданностей.

В процессе работы я наткнулся на этот пост на StackOverflow, из которого узнал об изящном алгоритме точного вычисления $$.

Но прежде чем приступать к алгоритму, нужно понять, что же такого хитрого в выражении $$? Возьмём $$, $$, $$ и $$. (Это реальные значения, которые получились у меня во время запуска pbrt.) При 32-битных значениях float получаем: $$ и $$. Выполняем вычитание, и получаем $$. Но если выполнить вычисления с двойной точностью, а в конце преобразовать их во float, то получится $$. Что произошло?

Проблема в том, что значение каждого произведения может сильно выйти за нижнюю границу $$, где расстояние между представимыми значениями с плавающей запятой очень велико — 64. То есть при округлении $$ и $$ по отдельности до ближайшего представимого float, они превращаются в числа, кратные 64. В свою очередь, их разность будет кратной 64, и не останется никакой надежды, что она станет к $$ ближе, чем $$. В нашем случае результат оказался ещё дальше из-за того, как два произведения были округлены в $$. Мы напрямую столкнёмся со старым добрым катастрофическим сокращением¹.

Те, кто работает с данными, отлично знают, что не в нейросетке счастье — а в том, как правильно обработать данные. Но чтобы их обработать, необходимо сначала проанализировать корреляции, выбрать нужные данные, выкинуть ненужные и так далее. Для подобных целей часто используется визуализация с помощью библиотеки matplotlib.



Встретимся «внутри»!

В статье приводится опасный антипаттерн «Зомби», в некоторых ситуациях естественным образом возникающий при использовании std::enable_shared_from_this. Материал — где-то на стыке техники современного C++ и архитектуры.

Привет, меня зовут Аня, я из Мосигры и изредка буду в наш блог что-то писать.

Вопрос, во что с детьми надо играть, особо никого не беспокоил века так до семнадцатого. Есть даже теория, что в Средневековье детей воспринимали как маленьких взрослых и воспитывали как в армии. Про это писал Филипп Арьес в книге «Ребенок и семейная жизнь при Старом порядке». Он сделал такой вывод, потому что насмотрелся старинных миниатюр и икон и обнаружил, что дети на них — какие-то старики, в игры почти не играют и вообще отличаются от взрослых только ростом. (Про это ещё есть кайфовая статья поподробнее.)

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

Короче, известно одно: обращение с детьми было такое себе.

Введение

Большинство разработчиков однозначно слышали о довольно значимых open-source разработках таких, как система LLVM и компилятор clang. Однако LLVM сейчас не только непосредственно сама система для создания компиляторов, но уже и большая экосистема, включающая в себя множество проектов для решения различных задач, возникающих в процессе любого этапа создания компилятора (обычно у каждого такого проекта существует свой отдельный репозиторий). Часть инфраструктуры естественно включает в себя средства для тестирования и бенчмаркинга, т.к. при разработке компилятора его эффективность является очень важным показателем. Одним из таких отдельных проектов тестовой инфраструктуры LLVM является test-suite (официальная документация).

LLVM test-suite

При первом беглом взгляде на репозиторий test-suite кажется, что это просто набор бенчмарков на C/C++, но это не совсем так. Помимо исходного кода программ, на которых будут производиться измерения производительности, test-suite включает гибкую инфраструктуру для их построения, запуска и сбора метрик. По умолчанию он собирает следующие метрики: время компиляции, время исполнения, время линковки, размер кода (по секциям).

На данный момент LLVM стала уже очень популярной системой, которую многие активно используют для создания различных компиляторов, анализаторов и т.п. Уже написано большое количество полезных материалов по данной тематике, в том числе и на русском языке, что не может не радовать. Однако в большинстве случаев основной уклон в статьях сделан на frontend и middleend LLVM. Конечно, при описании полной схемы работы LLVM генерация машинного кода не обходится стороной, но в основном данной темы касаются вскользь, особенно в публикациях на русском языке. А при этом у LLVM достаточно гибкий и интересный механизм описания архитектур процессоров. Поэтому данный материал будет посвящен несколько обделенной вниманием утилите TableGen, входящей в состав LLVM.

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

Томными зимними вечерами, когда солнце лениво пробегало сквозь пелену дней — я нашел в себе силы заняться реализацией давней мечты: разобраться как же устроены процессоры. Эта мечта привела меня к написанию формальной спецификации RISC-V процессора. Проект на Github

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

Если логирование хорошо организовано, то позволяет понимать, что, когда и как идет не так, как задумано, и передавать нужную информацию людям, которым предстоит эти ошибки исправлять. Для системы, в которой каждую секунду отправляется 100 тысяч сообщений в 10 дата-центрах на 190 стран, а 350 инженеров каждый день что-то деплоят, система логирования особенно важна.



Иван Летенко — тимлид и разработчик в Infobip. Чтобы решить проблему централизованной обработки и трассировки логов в микросервисной архитектуре при таких огромных нагрузках, в компании пробовали различные комбинации стека ELK, Graylog, Neo4j и MongoDB. В итоге, спустя много грабель, написали свой лог-сервис на Elasticsearch, а как БД для дополнительной информации взяли PostgreSQL.

Под катом подробно, с примерами и графиками: архитектура и эволюция системы, грабли, логирование и трассировка, метрики и мониторинг, практика работы с кластерами Elasticsearch и их администрирования в условиях ограниченных ресурсов.

Введение

Мобильные устройства — смартфоны, планшеты и прочие мобильные устройства — становятся неотъемлемой частью жизни людей. Почти у 67% людей в мире есть хотя бы один смартфон; к 2025 году прогнозируется 5,8 миллиардов активных мобильных устройств [1].

По данным IDC [2], среди всех проданных в третьем квартале 2018 года мобильных устройств 86,8% были оборудованы ОС Android. Количество пользователей использующих ОС Android более 1.4 миллиардов. По данным Securelist [3], за 2018 год было обнаружено 5,3 миллионов вредоносных программных пакетов для ОС семейства Android. Поэтому специалисту, в области компьютерной криминалистики, приходится для каждого устройства использовать разные методы извлечения копии памяти.

В настоящее время способа однообразного получения копии памяти с устройств под управлением ОС Android не существует. В связи с этим, специалисту в области компьютерной криминалистики приходится использовать множество различных методов, где он и сталкивается с технически-ми проблемами. В первую очередь проблемы связанны с отсутствием драйвера или с неисправностью USB разъема, используемых в традиционных методах для извлечения данных. Однако для получения и передачи копии памяти можно использовать беспроводные каналы связи [4].

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

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

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


Реальный пример работы нашей нейросети. Картинка кликабельна.

Основные требования и ограничения

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

Эволюция современных графических процессоров началась с появления в 1995 году первых 3D-карт, за которым последовало широкое распространение 32-битных операционных систем и недорогих персональных компьютеров.

До этого индустрия графики в основном состояла из более прозаичных двухмерных неперсональных компьютерных архитектур. Графические платы чаще всего были известны по алфавитно-цифровым обозначениям чипов и отличались огромной стоимостью. 3D-игры и компьютерная графика постепенно объединились, возникнув из таких разнообразных источников, как аркадные и консольные игры, проекты оборонной промышленности, робототехника и космические симуляторы, а также медицинская визуализация.

Первые дни потребительской 3D-графики были Диким Западом конкурирующих идей: от способов реализации оборудования до использования различных техник рендеринга и интерфейсов приложений и данных. У первых графических систем имелся фиксированный конвейер функций (fixed function pipeline, FFP) и архитектура, следовавшая по очень строгому пути обработки; при этом графические API практически у каждого производителя 3D-чипов были собственные.

3D-графика превратила довольно унылую PC-индустрию в шоу света и магии, но своим существованием она обязана многим поколениям инноваций. В этой серии статей мы подробно рассмотрим историю GPU: первые дни потребительской 3D-графики, совершившую переворот 3Dfx Voodoo, консолидацию отрасли в начале века и современные GPGPU.

Последние достижения в области глубокого обучения привносят существенные улучшения в развитие систем синтеза речи (далее – TTS). Это происходит благодаря применению более эффективных и быстрых методов изучения голоса и стиля говорящих, а также благодаря синтезу более естественной и качественной речи.

Приятно видеть знакомые фамилии в списке Acknowledgments официального релиза PostgreSQL 12. Мы решили свести вместе попавшие в релиз новшества и некоторые багфиксы, над которыми трудились наши разработчики.

1. Поддержка JSONPath

(В Release Notes это звучит как Add support for the SQL/JSON path language (Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova)

Сам этот патч, возможности JSONPath и история вопроса обсуждались в деталях в отдельной статье здесь на хабре. JSONPath — серьезное достижение Postgres Professional и одно из главных новшеств PostgreSQL 12 вообще.

В 2014 году А.Коротковым, О.Бартуновым и Ф.Сигаевым было разработано расширение jsquery, вошедшее в результате в версию Postgres Pro Standard 9.5 (и в более поздние версии Standard и Enterprise). Оно дает дополнительные, очень широкие возможности для работы с json(b).

Когда появился стандарт SQL:2016, оказалось, что его семантика не так уж сильно отличается от нашей в расширении jsquery. Не исключено, что авторы стандарта даже поглядывали на jsquery, изобретая JSONPath. Нашей команде пришлось реализовывать немного по-другому то, что у нас уже было и, конечно, много нового тоже.

Хотя специальный патч с функциями до сих пор не закоммичен, в патче JSONPath уже есть ключевые функции для работы с JSON(B), например:

jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)') возвращает 3, 4, 5
jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)') возвращает 0 записей

Кроме того, были оптимизированы и некоторые функции, которые уже работали с JSON раньше. Этим успешно занимался Никита Глухов.

Например, оператор #>>, соответствующий функциям jsonb_each_text() и jsonb_array_elements_text(), раньше достаточно быстро преобразовывал JsonbValue в text, но работал неторопливо с другими типами. Сейчас всё работает быстро.

Эта неделя была короткой, в понедельник и вторник я продолжал работать над системой 2D-освещения. Остальное время я потратил на реализацию деревьев квадрантов (quadtree).

В этой статье я поделюсь своей реализацией и мыслями, возникшими в процессе её проектирования.

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

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

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

Описание концепции VDP

• VDP
  • "Video Display Processor"
  • Чип видеоконтроллера, занимающийся работой с тайловой графикой, плоскостями скроллинга и спрайтами Genesis. На самом деле не является процессором.
• VRAM
  • "Video RAM"
    • RAM (ОЗУ), используемая VDP
    • Содержит тайлы (изображения размером 8x8 пикселей)
• Два основных типа консолей
  • Консоли NTSC
    • «Sega Genesis», 60-герцовые машины, в основном распространённые в США
    • Разрешения
      • Режим H40 — 320x224 пикселя (40x28 тайлов). Самый распространённый режим разрешения
      • Режим H32 — 256x224 пикселей (32x28 тайлов). Менее популярный режим разрешения
    • Наша студия Mega Cat выпускает NTSC-игры, поэтому использует эти разрешения!
  • Консоли PAL
    • «Sega Mega Drive», 50-герцовые машины, продавались во всём остальном мире
    • Разрешение
      • Режим H40 — 320x240 пикселей (40x30 тайлов). Самый распространённый режим разрешения
      • Режим H32 — 256x240 пикселей (32x30 тайлов). Менее популярный режим разрешения

Слева: NTSC Model 2 Sega Genesis, справа: PAL Model 2 Mega Drive (европейская)

Жил был Роберт Бонд — 65-летний программист из Калифорнии. И была у него жена-садовница, которая очень любила свою чистенькую лужайку. Но это Калифорния, там нет двухметровых заборов с системой защиты от котов. На лужайку ходят соседские коты и гадят!



Проблему нужно было решать. Как же решил её Роберт? Он докупил немного железа к своему компьютеру, подключил к нему камеру наружного наблюдения, смотрящую за лужайкой, и дальше проделал несколько необычную вещь, он загрузил доступный бесплатный Open Source софт — нейросеть, и начинал обучать её распознавать котов на изображении с камеры. И задача в начале кажется тривиальной, ведь если чему-то учить и легко — это котам, потому что котами завален Интернет, их там десятки миллионов. Если было всё так просто, но дела обстоят хуже, в реальной жизни коты ходят гадить в основном ночью. Картинок ночных котов, писающих на лужайке, в Интернете практически нет. И некоторые из котов умудряются даже пить из системы полива во время работы, но всё же потом сваливают.

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

Николай Николаевич Носов в русской литературе фигура особенная. Его, в отличие от многих, становится чем дальше, тем больше. Он один из немногих писателей, книги которых действительно читало (добровольно читало!), и с теплотой вспоминает все население страны. Более того – хотя советская классика едва не вся осталась в прошлом, и давно не переиздается, спрос на книги Носова не только не упал ни на йоту, но и постоянно растет.

Де-факто его книги стали символом успешно продающейся литературы.

Достаточно вспомнить громкий уход Пархоменко и Горностаевой из издательской группы «Азбука-Аттикус», который объяснялся идеологически расхождениями с руководством издательства, которое «не готово выпускать ничего, кроме 58-го издания «Незнайки на Луне»».

Но при этом о самом авторе никто не знает почти ничего.


Н.Носов с внуком Игорем

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

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