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

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

FF DA - Маркер "начало скана"

00 0C - Поле длины в big endian (12 байт); включает и свою длину

03 - Количество каналов в скане (3)

01 - Глобальный id первого включённого канала

00 - Индекс 1 таблицы Хаффмана (DC: 0, AC: 0)

02 - Глобальный id второго включённого канала

10 - Индекс 2 таблицы Хаффмана (DC: 1, AC: 0)

03 - Глобальный id третьего включённого канала

10 - Индекс 2 таблицы Хаффмана (DC: 0, AC: 0)

00 - Начальный коэффициент DCT (DC)

00 - Конечный коэффициент DCT (тоже DC)

01 - Точность: половинная, предыдущие данные отсутствуют.

f8ad 512d d3f1 cd96 - Зашифрованные кодом Хаффмана коэффициенты DCT

bcb0 58df 53d5 5d97 [...и так далее]

В него включён самый низкочастотный коэффициент (DC-компонент) преобразования Фурье для всех трёх цветовых каналов.

В качестве трёх цветовых каналов вместо привычного RGB используется YCbCr. Яркость (Luminance, Y) отделена, потому что должна иметь высокое качество, а цвета можно передавать кое-как и они всё равно будут выглядеть неплохо.

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

Для кого этот учебник?

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

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

• Для людей вне сферы финтеха. Чтобы понять, как и почему разработка ПО для финансовых систем отличается от привычной вам.

«Существуют три вида лжи: ложь, наглая ложь и бенчмарки», — почти Марк Твен

В два часа ночи ведущий архитектор процессорного стартапа Сара Чен получила письмо, которое изменит траекторию движения её компании. Конкурент опубликовал подробный технический анализ, развенчивающий заявления о производительности флагманского продукта компании. Заголовок был жёстким: «Маркетинговый хайп против реальности: как X искусственно увеличила результаты бенчмарков на 300%».

Проблема заключалась не в том, что процессор был медленным; на самом деле, он был вполне хорош. Проблема заключалась в бенчмарке Dhrystone, который компания выбрала для демонстрации. Конкурент подробно показал, как современные компиляторы могут оптимизировать бóльшую часть работы Dhrystone, из‑за чего его результаты становятся бессмысленными. Хуже того: конкурент продемонстрировал это на реальных нагрузках, с которыми работают заказчики, и все преимущества в производительности процессора испарились.

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

TL;DR

• Microsoft Paint поддерживает и локальную, и облачную генерацию изображений

• Paint и Photos также имеют в комплекте локальные модели ИИ

• Эти приложения отправляют промпт удалённому серверу для модерации

• Вместе с отмодерированным промптом сервер возвращает GUID

• GUID встраивается в локально сгенерированное изображение в качестве невидимого водяного знака

• Переключаемая в настройках функция видимого водяного знака не управляет этим невидимым водяным знаком

• На PC с Copilot+ генерация изображений выполняется локально, но модерация промптов остаётся удалённой

• Microsoft раскрывает, что Paint добавляет к сгенерированным ИИ изображениям метаданные C2PA

• Сгенерированные ИИ изображения можно сохранять только в форматы, поддерживающие C2PA: PNG, JPEG, GIF и .paint

«Управление сложностью — сама суть программирования компьютеров.» — Брайан Керниган

Стадия финального тестирования

Мы находились на этапе финального тестирования проекта IoT‑датчика — устройства для умного дома с 128 КБ ОЗУ, которое отслеживает температуру, влажность и качество воздуха. Прошивка прошла все функциональные тесты. Юнит‑тесты: зелёные. Интеграционные тесты: зелёные. Энергопотребление: в пределах спецификации.

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

Спустя три дня я пришёл в лабораторию, ожидая собрать логи тестирования и завершить проект.

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

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

[72:14:23] malloc failed: out of memory
[72:14:23] Fragmentation: 45%
[72:14:23] System halted

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

Перехват DNS — забавный вид атаки. Мне уже удавалось перехватывать разные домены .gov и .edu, но я сразу сообщала об этом. Этот же случай оказался другим: я захватила домены инфраструктуры телефонной сети (e164.arpa) целых территорий и случайно сохранила логи сотен тысяч телефонных звонков на военные базы. Но давайте начнём с самого начала.

Свой пост я написал после участия в соревнованиях gralhix 004, организованных Софией Сантос | Gralhix.

Задача

Это фотография островного курорта.

Вопросы:

а) Как называется курорт?

б) Каковы координаты острова?

в) В какую сторону света была направлена камера, когда делали снимок?

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

Этот значок на компьютере моего коллеги выглядит лучше

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

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

Если прищуриться или отойти подальше, то изображение из Chrome выглядит толще. Это немного странно, но если заменить картинку на SVG, то проблема исчезнет. Однако мне всё равно стало любопытно: почему она вообще так рендерится?

Я провёл исследование и обнаружил в Chrome изящную оптимизацию, используемую для рендеринга JPEG в мелком масштабе.

В середине 90-х самым крутым, что можно купить для PC, если не считать невероятно дорогой Intel Pentium, был привод CD-ROM. Благодаря ёмкости дисков в 640 МиБ (в три раза больше, чем жёсткий диск PC на то время), CD позволяли любителям технологий погрузиться в мир мультимедиа, состоящий из фотографий с 256 индексированными цветами и высоким разрешением 640x480^[1], саундтреками VOC и плавными видео Video For Windows с частотой 12 кадров в секунду в разрешении 240x179^[2][3], длящимися аж десятки секунд.

С точки зрения разработчиков видеоигр, CD-ROM был странным носителем. Его ёмкость намного превосходила качество ресурсов, которые они могли создать. Некоторые игры, например, 7th Guest (1993 год), Wing Commander III: Heart of the Tiger (1994 год) и Phantasmagoria (1995 год), познакомили игроков с Full Motion Video (в мире, где анимированной могла быть только часть экрана). В других играх появилась высококачественная музыка. Самым запомнившимся мнением по этой теме стало высказывание ведущего разработчика id Software Джона Кармака.

Люди ожидают, что в CD-играх будет куча оцифрованной речи и видео [...] Смешно то, что если мы когда-нибудь выпустили бы CD-версию DOOM, то там была бы только игра и часовой фильм «Как мы делали DOOM» с участием разработчиков.

Джон Кармак в интервью «ATARI EXPLORER ONLINE», январь 1994 года

Хорошо в теории, плохо на CD

К июню 1996 года, спустя три года упорного труда, id Software завершила свой новый проект — Quake. Как и в случае с Doom, компания собиралась выпустить и shareware-версию, и полную версию игры. Так как она занимала всего 22 МиБ, люди из id Software решили попробовать занять оставшееся свободным место на CD-ROM. Почему бы не записать туда зашифрованные версии всего каталога игр id? Это позволит не только избавиться от посредников, но и мгновенно покупать игры, совершив лишь один телефонный звонок и воспользовавшись кредитной картой.

В итоге эту концепцию реализовали. О выпуске CD было объявлено^[4] 3 июля 1996 года, а сам он выпущен 30 августа^[5]. Всего 39 дней спустя^[6] хакерская группа GNOMON выпустила Quakecrk.zip. В архиве содержался инструмент QCRACK.EXE, позволявший расшифровать все игры с CD-ROM.

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

В то же время я заметил, что каждый месяц всё быстрее исчерпываю свои кредиты Copilot. Это заставило меня выбрать его в качестве главного кандидата для моих экспериментов. Я решил подробно исследовать VS Code и Copilot.

В старой резервной копии базы данных 0.mk хранится 657 958 ссылок, созданных с 2009 по 2014 год, а также количество нажатий на них. В августе 2026 года мы восстановили 657 607 из этих записей в виде ссылок до 2015 года и прошли по каждой из них. Из 655 178 безопасных записей ссылок с возможностью перехода 76,7% больше не возвращало загружающуюся страницу.

Большинство из пользователей 0.mk находится в Македонии, поэтому это исследование не отражает картину для всего веба. Это большой архив того, чем в тот период делилось одно онлайн-сообщество, в том числе сборник местных новостей, фотохостингов, форумов и популярных на то время платформ.

Основанный в 2009 году 0.mk был любительским проектом команды из трёх человек. Мы работали над ним в свободное от работы время, обычно по несколько часов в день. Спустя семнадцать лет один из нас нашёл на диске резервную копию базы данных и решил вернуть её к жизни.

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

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

Эта система на основе Waveshare ESP32-S3 выполняет мониторинг концентрации пыли PM2.5, индекса качества воздуха (Air Quality Index, AQI), температуры, влажности и атмосферного давления при помощи специальных датчиков окружающей среды. Все собираемые данные отображаются локально на ЖК‑дисплее устройства; кроме того, к ним можно получить удалённый доступ при помощи Arduino IoT Cloud, что позволяет пользователям отслеживать состояние окружающей среды и управлять очистителем через смартфон.

Ядром AirSense служит HEPA‑фильтр Xiaomi Air Purifier 4 Lite, способный фильтровать до 99,97% частиц размером вплоть до 0,3 мкм, включая пыль, пыльцу, частицы дыма и другие распространённые загрязнители воздуха. Система оснащена мощным вытяжным вентилятором размером 150 мм, непрерывно пропускающим воздух через цилиндрический фильтр.

Чтобы проект выглядел как изготовленный профессионально, конструкцию всего корпуса я создал в Autodesk Fusion 360. Система объединяет в себе HEPA‑фильтр, вентилятор, датчики, дисплей и электронику.

← Девятая часть

В предыдущих постах мы подробно разбирали каждый слой: CPU, арифметику, скриптовый интерпретатор, оборудование. Вот, что окончательный отчёт о синтезе Quartus сообщает обо всех них: в готовой архитектуре используется 1593 логические ячейки из доступных в EP2C5 4608 (35% чипа) с 594 выделенными логическими регистрами и 17 блоками памяти M4K. Сам модуль CPU занимает 1173 из этих логических ячеек и 400 регистров. Остальная логика отдана периферии: драйверу ЖК‑дисплея (154 логические ячейки), сканеру клавиатуры (97), интерфейсу термопринтера (64), таймеру CTC (49) и аппаратному PRNG (20). 12 блоков памяти M4K занимает ROM микрокода (49152 бит: это полная программа калькулятора), 2 блока — ROM скриптинга (8192 бита), 1 — ROM BCD‑констант, 1 — таблица поиска для BCD‑умножения внутри CPU и 1 блок — ОЗУ. Меня это очень радует: полнофункциональный научный калькулятор уместился в 35% небольшой дешёвой FPGA.

В детстве я учился программированию на старом IBM PC с монохромным зелёным монитором, поэтому давно хотел создать программу для этой системы. За последние пятнадцать лет я написал более чем сотню небольших интро. В последнее время я был не так активен, но потрясающее интро «Rainbow Surf» автора Plex размером всего 16 байт мотивировало меня снова вернуться к старым наброскам и взяться за работу.

Создание этой программы сопровождалось привычными экспериментами. Я развлекался с клеточными автоматами в графике и звуке, а также исследовал трюки sizecoding. В частности: а) полиморфные ассемблерные команды (наподобие add [bx+si],al, имеющую машинный код 0x0000) б) переход в середины команд для экономии байт и многократного использования опкодов. Из сотен мелких экспериментов мне приглянулся один, интересный одним только своим названием.

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

В моём интро «M8trix» 2014 года по экрану уже бегали псевдослучайные буквы (в 8 байтах, а потом и в 7), но мне всегда было интересно, как добавить к ним красивый звук. Но хронологически в разработке «wakeup» я сначала занимался звуком. Хорошим подзаголовком к статье мог бы быть «16 байт, превращающие звук треугольника Серпинского в дождь символов из „Матрицы“».

Примечание: на каждом такте времени новая строка треугольника Серпинского а) воспроизводится через динамик б) отрисовывается на экране с шагом 56. Можно ощутить движение, но не увидеть его, потому что оно имеет «ширину» 8192 пикселей, но одна строка символов состоит всего из 80 байт. Если бы экран был гораздо больше, то можно было бы увидеть треугольник. Или если не пропускать пиксели и рисовать и все одновременно, он тоже был бы виден.

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

Стандартное деление на 255

pixels = img / 255.0
result = process(pixels)
output = np.trunc(result * 255 + 0.5)

Альтернативное деление на 256

pixels = (img + 0.5) / 256.0
result = process(pixels)
output = np.trunc(result * 256)

Я предполагаю, что в обоих случаях выходные значения ограничиваются перед окончательным преобразованием типов:

# Ограничение и преобразование в 8 бит
output_8bit = output.clip(0, 255).astype(np.uint8)

В стандартном случае целочисленный 0 соответствует 0.0, а 255 соответствует 1.0. Это работает абсолютно нормально и именно так всё реализовано в GPU. В альтернативном случае прибавляется смещение на 0,5 и деление происходит на 256, поэтому целочисленный 0 соответствует 0.5/256=0.001953125. Это неудобно, потому что код обработки изображений, например, без знания константы не сможет обнаруживать чёрные пиксели. Из‑за этого мы привязываем логику к 8-битным значениям, даже если вычисления выполняются с плавающей запятой. В стандартном решении всегда можно предполагать, что чёрный соответствует 0.0.

Однако некоторых программистов всё равно притягивает альтернативное решение. В чём дело? Чем оно им так нравится?

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

Конечно, я шучу. Мне даже неизвестно, читают ли веб‑краулеры посты, чтобы узнавать такую информацию.

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

Вот некоторые факты, о которых ниже будет рассказано подробнее:

 ● Всего за один день к моему сайту обратились 3,6 миллиона запросов китайских ботов.

 ● Cloudflare сообщает, что краулеры Anthropic выполняют примерно три тысячи операций краулинга на однго приведённого посетителя. У меня этот показатель составил 35 тысяч:1.

 ● Два дня назад я заблокировал поисковый ИИ‑краулер Amazon. Он считывал по 117 тысяч страниц в день, но не направил мне ни одного посетителя.

 ● Показатель решения моей CAPTCHA равен 0,24%. Боты даже не пытаются её решать.

 ● В конце перечислены все используемые мной правила файрволла.

Диэдральная группа — это математическое обозначение всех поворотов и отражений правильного многоугольника. Для n‑стороннего многоугольника всегда существует n возможных поворотов и n отражений, что даёт нам 2n возможных симметрий.

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

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

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

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

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

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

← Восьмая часть

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

Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.

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

Мне нравится создавать ASCII-арт в Vim. Я не пользуюсь никакими плагинами: в Vim уже есть множество встроенных фич, очень полезных при рисовании ASCII!

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

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

Рекомендую сначала освоить основы (например, открытие файла, переключение между режимами, сохранение и выход). Если вы новичок в Vim, то можете обучиться основам при помощи vimtutor!