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

Эта крошечная луна загадочного происхождения — тайна для нас, раскрытие появления и истории которой может сказать нам многое о Марсе и Солнечной системе в целом. Международная миссия Martian Moons eXploration (MMX), успешно запущенная 20 октября, намеревается исследовать эту тайну благодаря серии беспрецедентных приземлений на неизвестную нам поверхность Фобоса.

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

В 2001 году Джоэл Спольски, сочинения которого сильно повлияли на мою карьеру, написал великолепную статью Back to Basics. Суть её заключается в том, что практикующим программистам нужно разбираться в основах: какой бы абстрактной и далёкой от базовых алгоритмов ни казалась наша работа, от них неожиданно глубоко зависят наши проекты.

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

Удивительно, насколько часто паттерн маляры Шлемиля встречается даже в 2026 году.

Я езжу на Renault Latitude 2014 года. Это далеко не самая роскошная машина, да к тому же и не самая новая, но она доставляет меня из точки А в точку Б, да и с другим справляясь достаточно неплохо, жаловаться не на что.

Когда я покупал машину, её предыдущий владелец спросил, нужна ли мне «навигационная SD‑карта».

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

Так как навигационные карты на SD, по всей видимости, сильно устарели и работали неправильно, я решил, что они мне не нужны, и владелец выбросил карту памяти.

Мне она и не была особо нужна. На дисплее отображалось сообщение «Карты не найдены!», занимающее большую часть экрана, но это не сильно мне мешало.

Как и в большинстве европейских стран, в Эстонии используется перевод на летнее время, и недавно мы перешли с летнего времени (UTC+3) на «зимнее» (UTC+2), из‑за чего отображаемое на дисплее время стало торопиться на час. Я зашёл в меню настроек, надеясь с лёгкостью обнаружить там опцию «Настроить время».

Но её нигде не было.

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

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

База данных SQLite обладает высокой устойчивостью к повреждениям. В случае вылета приложения или операционной системы и даже при потере питания посередине транзакции частично записанная транзакция будет автоматически откачена при следующем доступе к файлу базы данных. Процесс восстановления происходит полностью автоматически и не требует никаких действий со стороны пользователя или приложения.

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

Помню как я, простая смертная, восхищённо смотрела на фотографии, отправляемые «Соджорнером» с поверхности Марса летом 1997 года. Серверы Лаборатории реактивного движения (JPL) НАСА начали тормозить, когда количество обращений для скачивания первых снимков красной планеты превысило 47 миллионов (рекордное число!). Проблема была ещё и в том, что в конце 1990-х Интернет всё ещё был молод, и большинство людей пользовалось аналоговыми модемами. Концу своей 83-дневной миссии «Соджорнер» отправил больше 550 фотографий и провёл более пятнадцати химических анализов марсианских пород и почвы.

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

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

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

Она замечательно работала в первой реализации tsk, написанной на Go (о которой я уже много раз рассказывал). В ней используется несколько базовых оптимизаций. Чтобы не выполнять поиск по нескольким процентам от общего числа слов (а их было несколько сотен тысяч), которые мы встраивали непосредственно в исполняемый файл (с самого начала одной из целей проектирования было поставлять всю программу в виде одного файла .exe, одного файла .app или одного статически скомпонованного исполняемого файла), мы установили ограничение: например, возвращать только первые 50 или 100 совпадений. Кроме того, мы просто заранее кэшировали все комбинации из 1, 2 и 3 символов. После этого за целый год интенсивного личного использования я больше ни разу не замечал сколько-нибудь ощутимых задержек в работе программы. При помощи подобных простых оптимизаций мы смогли сжать префиксное дерево примерно в 60 МБ.

Однако финский язык отличается чрезвычайно развитой агглютинацией. Одно-единственное исходное слово может иметь более сотни возможных окончаний, если учитывать все их комбинации. Причём эти комбинации не образуются по какому-то простому регулярному правилу!² Кроме того, чрезвычайно последовательная орфография финского языка означает, что написание слов точно отражает то, как носители языка действительно их произносят. Поэтому по мере добавления окончаний исходные слова причудливым образом удлиняются, изменяются и трансформируются, приобретая благозвучные формы. Всё это кажется совершенно естественным, если ты уже пару лет погружён в изучение языка. Но новичок, увидев предложение вроде «Opiskelijassammekin on leijonan sydän», с большой вероятностью споткнётся об одно конкретное слово. Одна из задач этой программы — помочь изучающему понять, где именно нужно правильно разделить слово на составляющие, и для этого она тоже включает в себя всю необходимую информацию.

Здесь префиксное дерево даёт сбой...

Это ещё одна моя статья о чипе арифметики с плавающей запятой Intel 8087¹. В 1980 году компания Intel представила процессор 8087, который сильно повысил скорость выполнения операций с плавающей запятой в IBM PC и других системах. В этой статье мы рассмотрим алгоритм, лежащий в основе команды вычисления тангенса. Один из распространённых подходов к реализации тригонометрических функций — это алгоритм CORDIC. Второй — это аппроксимация при помощи многочленов. Для обеспечения высокой точности и высокой производительности 8087 сочетал в себе оба этих подхода, создав огромный прирост скорости по сравнению с микропроцессором 8086: тангенс в нём вычислялся всего за 90 микросекунд вместо 13 тысяч микросекунд².

Изучив цепи и микрокод 8087, я смог объяснить алгоритм команды вычисления тангенса FPTAN. Для исследования электросхемы 8087 я при помощи стамески снял с чипа крышку и сделал микроскопом снимок высокого разрешения. ROM микрокода — это большая прямоугольная область в центре кристалла, содержащая 1 648 управляющих чипом микрокоманд. Нижняя часть чипа (в красном прямоугольнике) — это тракт данных: цепь, выполняющая вычисления с плавающей запятой над 80-битными значениями³.

На увеличенном снимке тракта данных видны соответствующие функциональные блоки. В exponent ROM хранятся значения экспонент, необходимые алгоритму. В constant ROM содержатся константы, в том числе и используемые алгоритмом CORDIC. Shifter (блок сдвига) — это большой компонент, выполняющий сдвиг 64-битного значения влево или вправо на произвольную величину. Adder (сумматор) — это ядро вычислений 8087; наряду с реализацией сложения и вычитания он применяется в цикле для умножения, деления и квадратных корней. В регистре B (B reg) хранится один из аргументов сумматора, а второй аргумент может браться из нескольких источников. В sum register хранится вывод сумматора. В восьми стековых регистрах и временных регистрах хранятся числа с плавающей запятой. Наконец, в сдвиговом регистре (shift reg) хранятся 16 бит состояния для вычислений CORDIC.

Я люблю фотографию. Есть что‑то волнующее в наблюдении за изображением через объектив, выстраивании кадра для получения композиции и работы над получившимся фото. Я менял зеркальные и беззеркальные камеры, пока, наконец, не влюбился в Canon AE-1P — аналоговую зеркалку, с которой мой отец путешествовал по миру, пока, наконец, не обосновался в Штатах.

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

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

Введение

В конце 80-х я кучу времени просидел скрючившись за своим ZX Spectrum, вводя программы на Sinclair BASIC и скопированные из журналов рудиментарные ассемблерные процедуры в попытках воссоздать интро крэков с Amiga, которые видел дома у друга. Разумеется, тогда я так и не смог добраться до этой цели, но теперь, спустя много десятков лет, мне наконец‑то это удалось! Я стал гордым автором написанного вручную ретро‑интро, работающего на стандартном Spectrum с 128 КБ. В нём есть все отличительные признаки демо конца 80-х: текст с плавным скроллингом (в крутых самодельных шрифтах!), трёхканальный саундтрек AY, скачущие индикаторы громкости и обязательное звёздное небо с параллаксом. Код занимает 10 287 байт, а полный образ плёнки — 19 552 байта; учитывая, что я работал над демо с 13 декабря прошлого года, средняя скорость написания кода составила приблизительно 455 байт в неделю!

В этом посте я расскажу, как добился этого, поделюсь изученными мной трюками и перечислю всё, чему мне пришлось научиться (и вспомнить) о Speccy и ассемблере Z80. Это один из моих самых любимых хобби‑проектов, но в то же время из‑за него мне зачастую хотелось пнуть монитор. Всем этим я поделюсь в конце статьи, а если вы просто хотите посмотреть на готовый результат, то скачайте образ кассетной плёнки .tap, который можно загрузить в любой эмулятор. Также можно посмотреть запись на YouTube, перейти по ссылке на pouet.net и запустить демо через браузер, зайдя на мой TNFS‑портал сайта и выбрав пункт 4 Recent uploads.

«П‑с-с‑с, хочешь, чтобы функция очистки массива была на 49% быстрее? Сдвинь массив на 4 байта».

Рассмотрим следующий код на Go:

const words = 1 << 19

type block struct {
n uint32
data [words]uint32
}
func (b *block) reset() {
b.data = [words]uint32{}
}

Что, если я скажу вам, что всего лишь добавив 4 байта заполнения (padding) между n и data, вы ускорите функцию reset на 49% (по крайней мере, на машинах с Intel)? Звучит безумно?

Есть всего три претендента на звание самого популярного ПО для работы с электронными таблицами: VisiCalc — первая электронная таблица, становившаяся причиной для покупки некоторых домашних компьютеров конца 1970-х, Lotus 1-2-3, доминировавшая на первых PC в 1980-х, а после них — Microsoft Excel (которому очень недолго предшествовал Multiplan). Excel доминировал на рынке с 1990-х, поэтому можно запросто вообразить, что он существовал всегда, но даже внутри Excel скрываются кое‑какие особенности его предшественников.

Одна из них задокументирована в официальном документе по устранению неполадок Microsoft Excel...

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

Перенесёмся в настоящее: теперь у меня даже не один, а два калькулятора Casio Pocket Computer (заказанных за большие деньги из Японии), для которых я разработал четыре программы (одна уже опубликована на Github, остальные будут выложены в опенсорс!) и я создал (при помощи ИИ) калькуляторный фанарт. Я глубоко и полностью околдован ими.

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

Всего лишь из‑за BASIC и RS232.

В процессе подготовки к соревнованиям по системному программированию на C++ я начал заново изучать CMake, потому что Cargo сильно меня избаловал. При этом я заметил в туториале интересное утверждение:

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

CMake Language Fundamentals

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

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

Код выложен на Github.

Сегодня я получил от друга примерно такое сообщение: «Знаю, что мы собирались встретиться в Эдинбурге, но не заинтересует ли тебя съездить в Портобелло и попробовать починить часы в старом полицейском участке?»

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

Многие говорят о том, что современный пиксель‑арт часто выглядит неправильно. Например, пользователь TikTok mylifeisanrpg записал популярное видео, в котором объясняет, что раньше пиксельные художники учитывали физические свойства электронно‑лучевых трубок (ЭЛТ). Размытость ЭЛТ сглаживала грубые края пикселей низкого разрешения, благодаря чему объекты казались гораздо менее квадратными, чем на современных плоских дисплеях.

Это правда. Я тоже соглашусь, что современный блочный пиксель‑арт часто становится неточной, анахронической ностальгией. Однако у пиксель‑арта и старого игрового оборудования есть гораздо больше аспектов, чем просто размытие ЭЛТ.

Недавно я посмотрел интересное видео YouTube‑канала «Physics for the Birds». Это видео посвящено матрицам, но для объяснения некоторых операций с матрицами автор использовал флаги. Он показал, как можно разбить флаги по осям, чтобы представить их в виде матриц и сэкономить место на диске. В конце этот пример был применён к реальным матрицам и вычислениям с ними.

Однако это видео дало мне вдохновение: часто флаги бывают очень простыми — несколько разноцветных полос, распространённые элементы наподобие звезды, полумесяца или креста. Если использовать какую‑нибудь схему кодирования, то удастся ли описать флаг Франции

в формате «три полосы: синяя, белая, красная», чтобы декодеру и рендереру достаточно было всего нескольких бит? Как может выглядеть такое кодирование?

Я решил создать нечто подобное.

Я выполнил реверс‑инжиниринг оборудования и прошивки своего электросамоката Egret GT. В статье будет рассказано о том, как мне удалось забраться внутрь, проанализировать обмен данными между компонентами и отреверсить прошивку.

Чтобы всё ещё ощущать себя человеком, по выходным я пишу код вручную.

Недавно я поставил перед собой задачу создания интерпретатора в 512 1024 байта старого доброго кода на C. И да, без хитростей с макросами и библиотеками.

def buzz():
for n in range(101):
if n % 15 == 0:
print("FizzBuzz")
else:
if n % 3 == 0:
print("Fizz")
else:
if n % 5 == 0:
print("Buzz")
else:
print(n)
buzz()

Наверно, мне не удастся уместить весь язык Python в интерпретатор такого размера. Так что же можно уместить в этот код?

Эта программа fizzbuzz явно выглядит, как Python. В ней есть def, двоеточия, отступы и отсутствуют скобки в операторах if. Мне кажется, это вполне походит на Python! Разумеется, наряду с использованием только подмножества синтаксиса придётся добавить и другие ограничения.

Но моя первая попытка оказалась неудачной.

Развитие ИИ движется вперёд, но практически весь видимый прогресс происходит в сфере работы со знаниями, то есть действий, происходящих внутри компьютера.

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

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

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

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

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

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