Утром 12 апреля 1981 года, ровна 20 лет спустя после дня, когда Юрий Гагарин стал первым человеком в космосе, в небо Флориды с грохотом устремился космический шаттл. При первом взлёте шаттла им управляли командир Янг и пилот Криппен. Но на самом деле запуском, как и большей частью полёта, руководили четыре компьютера в отсеках авионики одной палубой ниже экипажа. Пятый компьютер был готов перехватить управление в случае катастрофического компьютерного сбоя. Эти компьютеры Model AP-101B относились к семейству IBM System/4 Pi.

Семейство System/4 Pi, впервые представленное примерно в 1967 году, было линейкой компактных мощных компьютеров, предназначенных для задач в сфере авионики. Военные использовали эти компьютеры везде, от истребителя F-4 и бомбардировщика B-52 до сонарных систем подводных лодок и противокорабельных ракет «Гарпун». Другие компьютеры семейства System/4 Pi играли более мирную роль в разработке GPS и дистанционного управления полётами. В космосе компьютеры System/4 Pi управляли первой американской космической станцией Скайлэб, а также многоразовой лабораторией Спейслэб, выводившейся в космос шаттлом.

Несмотря на важную роль компьютеров System/4 Pi, информацию о них сложно найти —в Википедии полностью отсутствуют данные о моделях CC, SP и ML¹. Однако я нашёл кучу маркетинговых брошюр и статей о 4 Pi, благодаря чему могу заполнить множество пробелов в истории System/4 Pi.

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

Первый пиксель-арт сцены почти всегда копировался (или, если точнее, плагиатился) из других источников. В частности, достаточно широко заимствовались иллюстрации, связанные с фэнтези- и научно-фантастической литературой. Любимцами были фэнтези-художники Борис Вальехо и Фрэнк Фразетта, а также любитель хромированных распутных роботов Хадзимэ Сораяма.

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

Рендерер Scratch имеет долгую историю связанных с SVG уязвимостей. Их источником становится то, что Scratch парсит сгенерированный пользователем (то есть контролируемый нападающими) контент в элемент <svg> и добавляет его в основной документ для выполнения различных операций (например, для измерения ограничивающего прямоугольника SVG более надёжным образом, чем viewbox или width/height).

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

Я считаю, что подход Scratch к санации SVG обречён на провал. Чтобы объяснить это, нам нужно совершить путешествие по истории санации SVG в Scratch и посмотреть, насколько хорошо он с этим справлялся.

«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон

Разрыв в производительности

Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза.

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

Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем.

В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные.

Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими:

В 4,5 раза быстрее и в 7 раз меньше промахов кэша.

В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.

Я наткнулся на видео Simple Lucas с упражнением для повышения внимания и продуктивности. Оно очень простое:

1. Не пользоваться никакими экранами/развлечениями, когда пытаешься сосредоточиться на работе.

2. Когда начинаешь ощущать моральное истощение, сядь и смотри на стену в течение X минут, чтобы вернуть сосредоточенность.

Я попробовал, и это оказалось очень эффективное (хотя и сложное) упражнение.

«Блокировки — это goto конкурентного программирования», — Морис Херлихи

Проблема 60%

Наша система логгинга тратила 60% своего времени на ожидание снятия блокировок. Не на выполнение полезной работы, только на одно ожидание.

Восемь ядер, пытавшихся записывать сообщения логов, имели общий кольцевой буфер. Реализация была простой: буфер защищался мьютексом. При высокой нагрузке, когда все ядра записывали логи одновременно, профилировщик демонстрировал ужасный паттерн: 60% тактов CPU тратилось на операции с мьютексом.

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

«Можно ли улучшить ситуацию, отказавшись от блокировок?», — спросил меня мой менеджер во время ревью производительности.

Этот вопрос привёл к полной смене архитектуры...

Не надо переписывать то, что не поломано

Код к этому посту доступен на Github.

Кодинг при помощи ИИ стал нормой; мы всё больше позволяем моделям наподобие Cursor, GitHub Copilot, Claude Code и Codex вмешиваться в наш код. Если вы в прошлом пользовались каким-то из этих инструментов, то, вероятно, сталкивались с чем-то подобным: вы просите модель устранить простой баг (допустим, ошибку смещения на единицу или не тот оператор). Модель устраняет баг, но половина функции оказывается переписанной. Появляется новая вспомогательная функция. Совершенно логичное имя переменной меняется на другое. Добавляется новая валидация ввода. И diff из-за этого становится огромным.

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

В своём посте я исследую эту проблему: имеют ли современные LLM склонность к избыточной редактуре и можем ли мы обучить модели редактировать код в должной мере?

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

Но как это работает на самом деле? Как разработчики обеспечивают возможность паузы в игре?

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

Гляньте-ка! Это я с сервером Minecraft, запущенным на компьютере UNIVAC 1219B:

А ниже будет эмулятор NES с первым отрендеренным кадром Pinball.

… и селфи, напечатанное на телетайпе при помощи техники многократной печати «overstrike».

Мы сделали ещё кучу безумных штук, и в том числе:

• Программы OCaml (!)

• Веб-сервер

• Шифрование Curve25519 + AES

• Интерпретатор BASIC

• ELIZA

• Игры наподобие Oregon Trail, Wordle и Battleship

… а также многое другое! И всё это на компьютере из 1960-х с частотой 250 кГц и всего с 90 КБ ОЗУ. Ради такого я и живу! Я одержим запуском кода в странных местах и преодолением технических ограничений. Этот проект стал для меня самым амбициозным на данный момент, он отнял у меня и других примерно восемь месяцев.

Исходники проекта я выложил на Github. Также можете посмотреть видео TheScienceElf об этом проекте!

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

Великое предательство: как наши любимые инструменты обернулись против нас

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

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

От переводчика: оригинал этой статьи был опубликован 30 марта 2026 года, за день до запуска миссии. Несмотря на её успешное завершение, приведённые в статье доводы не теряют актуальности.

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

В среду 1 апреля НАСА попытается отправить четырёх космонавтов в миссию Артемида-2 вокруг Луны. Это будет вторым полётом ракеты SLS НАСА и первым случаем, когда двадцатилетняя капсула Орион будет лететь с людьми на борту.

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

Первым делом НАСА попыталось прикрыть проблему. В первых пресс-релизах агентство подчёркивало, что и ракета, и космический аппарат превосходно справились с задачей, в то же время отказываясь публиковать послеполётный отчёт. Впервые повреждения экрана упомянул руководитель программы «Орион» Говард Ху при разговоре с репортёрами в марте 2023 года. Ху сказал: «мы наблюдали более существенные изменения теплозащитного экрана, чем ожидалось; часть обуглившегося материала абляционно разрушилась иначе, чем предсказывали наши компьютерные модели и наземные испытания».

Я по горло сыт стандартно выглядящими приложениями. Сегодня все десктопные приложения Windows выглядят одинаково, да и внутри устроены одинаково: их создают на основе дурацких браузерных обёрток React, Electron, electronbun и Tauri, имитирующих реальные десктопные приложения. Они медленно работают и занимают кучу памяти — по сути, это bloatware. Блокнот — это, блин, приложение для простых ЗАМЕТОК, а не замена Word, калькулятор — это калькулятор, а не планировщик лунной миссии НАСА. На каком-то этапе Microsoft сбилась с курса, как будто сдалась и передала бразды правления куче веб-разработчиков, незнакомых с концепцией оптимизации.

Чёртов Блокнот занимает в памяти почти 50 МБ, хотя эквивалентное приложение, написанное на чистом Win32 C, занимает 1,8 МБ. Вроде бы, по современным меркам 50 МБ — это не так много, но в том-то и смысл: эти мегабайты постепенно накапливаются. Недавно я купил новый Intel Ultra 9 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.

Программирование на Win32 API — утерянное ныне искусство; я с ностальгией вспоминаю, как когда-то программировали приложения для Windows. Процесс был запутанным, но обеспечивал полный контроль.

«Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимосвязях», — Линус Торвальдс

Споры о планировщике

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

Вставлять новые задачи с приоритетом (O(log n))

Запрашивать задачу с наибольшим приоритетом (O(1))

Удалять задачу с наибольшим приоритетом (O(log n))

Кто-то предложил: «Давайте используем отсортированный массив». Но вставка будет занимать O(n) — придётся сдвигать элементы.

Кто-то ещё сказал: «Возьмём связанный список». Однако поиск наибольшего выполняется за O(n) — необходимо сканировать весь список.

Третий вспомнил о двоичном дереве поиска. Но из Главы 9 мы уже знаем, что BST ужасно ведут себя с кэшем.

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

На неделе годовщины запуска и аварии Аполлона-13 я понял, что меньше думаю о взрыве кислородного бака, чем о том, что удалось сделать и до него, и после. Короткие моменты истории демонстрируют ценность надёжных систем более наглядно, чем этот полёт.

Наблюдая на прошлой неделе за миссией Артемида-2, я был поражён некоторыми параллелями и различиями между ней и Аполлоном-13. Космический аппарат Integrity Артемиды-2 приземлился 11 апреля, в тот же день, когда был запущен Odyssey Аполлона-13. Внешне эти две капсулы выглядят похоже, но Integrity больше и несёт в себе экипаж из четырёх астронавтов, а не трёх. Однако внутри их разделяет больше полувека технологического прогресса. Наиболее очевидно это на примере имеющейся у астронавтов вычислительной мощности. Сегодня компьютеры захватили мир, но в 1960-х они были на ранних этапах своего развития, и прилунение стало не только триумфом труда, изобретательности и упорства человека, но и триумфом одного из самых новых инструментов человечества — компьютера.

Когда я жила в Нэшвилле, мы с моими подругами часто выезжали на «экскурсии» по штату. Однажды мы поехали искать белоголовых орланов в западном Теннесси; в туалете национального парка нам встретилась женщина с кучерявыми волосами, которая сообщила, что вчера видела 113 орланов. Мы же за всю поездку увидели... двух.

Летом 2017 года мы поехали на ещё одну экскурсию на завод Манхэттенского проекта в Ок-Ридже. В 1942 году Ок-Ридж был выбран в качестве места создания завода по обогащению плутония и урана в рамках Манхэттенского проекта — совершенно секретного мероприятия по разработке первой атомной бомбы. Маленькое сельское поселение, расположенное в долине западного Теннесси, благодаря срочному проекту по созданию атомной бомбы превратилось в тайный посёлок под названием «Site X», увеличив своё население с трёх тысяч человек в 1942 году до 75 тысяч к 1945 году. Наряду с ростом населения были построены огромные здания комплекса.

Я только что выпустил обновление моей игры Blackshift, в котором, среди прочего, были добавлены эти тайлы песка:

Всё было хорошо, пока не начали поступать отчёты о багах.

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

Этот пост предназначен исключительно для образовательных целей. Denuvo считается одним из самых успешных решений для управления цифровыми правами, поэтому оно многим интересно. В этом посте представлен большой объём моих личных заметок и переписки с другими реверс-инженерами (см. раздел «Благодарности»), содержащий информацию о последних версиях Denuvo; многое из этого раньше не публиковалось.

Я не стремлюсь нанести какой-либо ущерб Irdeto, поэтому часть информации была вырезана из поста.

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

Однако всё это неправда. На самом деле, написание драйвера для USB-устройства не намного сложнее, чем написание приложения, использующего Sockets.

Этот пост будет высокоуровневым введением в использование USB для разработчиков, мало работавших с оборудованием и просто желающих применить эту технологию. Существуют потрясающие ресурсы наподобие USB in a NutShell, подробно объясняющие работу USB (изучите их, если вам нужна дополнительная информация), но они довольно сложны для тех, кто раньше ни разу не работал с USB и не имеет опыта в сфере «железа». Чтобы пользоваться USB, не нужно быть разработчиком встраиваемых систем; точно так же, как не нужно быть специалистом по сетям для использования Sockets и Интернета.

Вселенная остаётся безмолвной. Несмотря на десятки лет поисков, мы ещё ни разу не обнаружили сообщений от нечеловеческих форм жизни. Одно из потенциальных объяснений этого предлагает гипотеза «тёмного леса». Согласно ей, Вселенная молчит, потому что она подобна тёмной и тенистой лесной местности, в которой могут таиться хищники. Поэтому разумные виды вряд ли сообщат о себе из страха, что более совершенная или враждебная цивилизация мгновенно их уничтожит. Гипотеза позаимствовала своё название из романа Лю Цысиня «Тёмный лес», но сама идея предшествовала книге.

Астроном Вишал Гаджар — исследователь из Института SETI и участник Breakthrough Listen Program — самого большого научного проекта по поиску разумной жизни. В моём недавнем интервью с ним он упомянул гипотезу «тёмного леса». Гаджар — соавтор научной статьи в The Astrophysical Journal, согласно которой космическая погода вокруг звёзд может препятствовать получению нами сигналов от инопланетных форм жизни. Я задал ему вопрос: если однажды мы обнаружим сообщения от инопланетян, должны ли мы ответить им?

Он ответил, что для человечества Вселенная по-прежнему остаётся очень тёмным лесом. «Если находишься в кромешно тёмном лесу, не стоит издавать звуки, чтобы привлечь к себе внимание. Аналогично, я бы не советовал передавать сигналы инопланетянам». 

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

Мы обсудили с Гаджаром его находки, его оптимистичный настрой и те типы сигналов, которые нам нужно искать. Также мы обсудили теории заговоров, связанные с НЛО, фильм «День независимости» и возможный внешний вид инопланетян.

Я работал над Pizza Legacy — опенсорсным воссозданием игры 1994 года Pizza Tycoon для DOS. В игре есть вид на улицы города, при скроллинге которого игрок наблюдает постоянный поток машин. Это примерно 20-30 маленьких спрайтов, однако они едут по дорожной сети, создают очереди на перекрёстках и в целом выглядят как оживлённый город. Да, симуляция иногда глючит, машины проезжают друг через друга, но этого достаточно, чтобы придать карте ощущение жизни. И всё это на процессоре 386 с частотой 25 МГц.

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

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

Всё это время мне не давала покоя одна мысль: если оригинальная Pizza Tycoon работала на процессоре с частотой 25 МГц, то почему мои версии всегда оказывались столь сложными?

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