Учась в школе, я обнаружил очень простую математическую формулу, о которой не перестаю думать и сегодня. Смысл её в следующем: представьте, что у вас есть 3D-точка в воображаемом 3D-пространстве за экраном. Для проецирования этой 3D-точки на экран нужно взять её координату X, поделённую на Z, и аналогично её Y / Z. И в результате вы получите проекцию точки на экран: и . А если у вас есть множество точек в этом 3D-пространстве за экраном, и вы начнёте их анимировать и вращать их, а потом воспользуетесь этой формулой для рендеринга всех точек на экране, то это будет выглядеть, как 3D-сцена или 3D-объект. Давайте попробуем эту формулу в деле.

Когда-то давно мне подарили кучу VoIP-телефонов, которые списали на моей старой работе. Среди них были два Snom 360 Business, выпущенные в 2005 году. Изначально я хотел настроить АТС на основе Asterisk для всех доставшихся мне телефонов, но в процессе обновления прошивки на одном из аппаратов Snom 360 мне пришла в голову идея получше. У телефона есть экран и клавиатура... получится ли на нём запустить Doom?

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

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

Разумеется, сначала я обвинил в этом React.

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

Чтобы подтвердить свою теорию, я рассказал Claude¹, что загрузка дэшборда тормозит и что проблемы наверняка в React, попросив проанализировать их и ранжировать по степени серьёзности. Конечно же, Claude обнаружил в React кучу подозрительных аспектов — ненужный повторный рендеринг, отсутствующие мемоизации и так далее. К тому же он подсказал, что мы всё ещё не используем React Compiler. Я попросил Claude выполнить первый проход решения самых простых и самых серьёзных проблем React, но…

Практически ничего не поменялось. Возможно, дело всё-таки не в React.

Итак, я закатал рукава и начал тщательное расследование.

Обычно в Интернете на вопрос «почему небо синее?» отвечают «из-за рэлеевского рассеяния». Это правильный, но не особо полезный ответ. Знание терминологии сильно отличается от понимания явления. Но если понимание заключается не в знании терминов... то в чём? Я отвечаю на это так: в существовании модели, позволяющей нам создавать прогнозы. Если мы надёжным образом можем прогнозировать что-то, то, вероятно, понимаем это. В этой статье я исследую, почему небо синее; но мы настолько углубимся в эту тему, что после прочтения вы сможете прогнозировать, какой цвет неба будет на других планетах.

Давайте для начала зададимся вопросом: какого цвета ДОЛЖНО быть небо?

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

В 1978 году Intel представила процессор 8086 — революционный чип, приведший к созданию современной архитектуры x86. Однако в отличие от современных 64-битных процессоров, 8086 был 16-битным. Его арифметически-логическое устройство (АЛУ, ALU) работает с 16-битными значениями, выполняя арифметические операции (например, сложение и вычитание), а также логические операции, включающие побитовые AND, OR и XOR. АЛУ процессора 8086 — сложная часть чипа, выполняющая 28 операций¹.

В этом посте я расскажу об управляющих АЛУ схемах, генерирующих сигналы управления конкретных операций. Этот процесс сложнее, чем можно было бы ожидать. Во-первых, команда машинного кода приводит к исполнению множества команд микрокода. Использование АЛУ — это двухэтапный процесс: одна команда микрокода (микрокоманда) конфигурирует АЛУ под нужную операцию, а вторая микрокоманда получает результаты из АЛУ. Кроме того, на основании микрокоманды и команды машинного кода схема управления отправляет в АЛУ сигналы управления, переконфигурируя его под нужную операцию. Таким образом, эта схема становится источником «клея» между микрокомандами и АЛУ.

На фотографии показан процессор 8086 под микроскопом. Я разметил основные функциональные блоки. Архитектурно чип разделён на блок интерфейса шины (Bus Interface Unit, BIU) в верхней части и блок исполнения (Execution Unit, EU) внизу. BIU занимается действиями с шиной и памятью, а также упреждающей выборкой команд, а EU исполняет команды. В правом нижнем углу находится ROM микрокода, хранящее микрокоманды. АЛУ (ALU) находится в левом нижнем углу; биты 7-0 расположены сверху, биты 15-8 — снизу, а между ними расположена схема флагов состояний. Темой этой статьи станет схема управления АЛУ, выделенная внизу красным цветом.

Что такое Moltbook, и почему она привлекла наше внимание?

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

Мы выявили принадлежащую Moltbook неправильно сконфигурированную базу данных Supabase, обеспечивающую полный доступ на чтение и запись ко всем данным платформы. Дыра позволила обнаружить 1,5 миллиона токенов аутентификации API, 35 тысяч почтовых адресов и личную переписку между агентами. Мы немедленно сообщили о находке команде Moltbook, которая с нашей помощью закрыла её в течение считаных часов, а все данные, доступ к которым был получен в процессе поиска и проверки исправления, удалены.

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

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

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

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

Десятки лет robots.txt управлял поведением веб-краулеров. Но сегодня, когда беспринципные ИИ-компании стремятся к получению всё больших объёмов данных, базовый общественный договор веба начинает разваливаться на части.

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

Файл называется robots.txt; обычно он находится по адресу вашвебсайт.com/robots.txt. Этот файл позволяет любому, кто владеет сайтом, будь то мелкий кулинарный блог или многонациональная корпорация, сообщить вебу, что на нём разрешено, а что нет. Какие поисковые движки могут индексировать ваш сайт? Какие архивные проекты могут скачивать и сохранять версии страницы? Могут ли конкуренты отслеживать ваши страницы? Вы сами решаете и объявляете об этом вебу.

Эта система неидеальна, но она работает. Ну, или, по крайней мере, работала. Десятки лет основной целью robots.txt были поисковые движки; владелец позволял выполнять скрейпинг, а в ответ они обещали привести на сайт пользователей. Сегодня это уравнение изменилось из-за ИИ: компании всего мира используют сайты и их данные для коллекционирования огромных датасетов обучающих данных, чтобы создавать модели и продукты, которые могут вообще не признавать существование первоисточников.

Файл robots.txt работает по принципу «ты — мне, я — тебе», но у очень многих людей сложилось впечатление, что ИИ-компании любят только брать. Cегодня в ИИ вбухано так много денег, а технологический прогресс идёт вперёд так быстро, что многие владельцы сайтов за ним не поспевают. И фундаментальный договор, лежащий в основе robots.txt и веба в целом, возможно, тоже утрачивает свою силу.

Я выбрал Artix, кстати.

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

Почти все элементы мира хайтека, от самых современных ИИ-систем крупнейших компаний до обычных кусков кода, написанных студентами, аннотируются и описываются в одном простом текстовом формате. Когда вы пытаетесь дать сложные инструкции ChatGPT, хотите поделиться списком покупок в Apple Notes или скопировать чью-то домашнюю работу в Google Документах, вы пользуетесь одним и тем же форматом. Самое безумное заключается в том, что этот формат придумал не конгломерат технологических корпораций, а ворчун с добрым сердцем, который сейчас, вероятно, пересматривает фильм Кубрика или болеет за любимую спортивную команду. Но нам стоит разобраться, как родились столь простые текстовые файлы; не только для того, чтобы я мог похвастаться щедростью и умом моих друзей, но и чтобы напомнить вам, как работает Интернет на самом деле: умные люди придумывают хорошие вещи, а затем отдают их бесплатно, снова и снова, пока их технология не захватит мир и не сделает его лучше для всех.

Leica G9ii

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

Камера названа так, потому что внутренности взяты у Lumix G9ii, а корпус — это реплика Leica M, изготовленная на станке с ЧПУ. Также я изготовил новые гибкие кабели для соединения сменивших положение кнопок и колёс управления.

Зачем?

Много лет у меня была мечта написать собственное ПО для камеры или, по крайней мере, спрятать неиспользуемые меню; я хотел избавиться от бойлерплейта и оставить только самое необходимое. Я фотограф-любитель, поэтому, например, практически не использую никаких других режимов, кроме A и M. Хоть я и программист, такая задача была бы для меня невыполнимой: мне не хватает навыков в реверс-инжиниринге двоичных файлов, работе с шестнадцатеричным кодом; кроме того, если что-то пойдёт не так, я рискую превратить камеру в кирпич.

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

Из книги Big Secrets и нескольких выпусков журнала 2600 я знал пару фактов о кредитных картах. Номера карт American Express всегда состояли из 15 цифр и начинались с тройки, а номера карт Visa состояли из 16 цифр и начинались с четвёрки. Первая пара цифр обозначала банк-эмитент, затем шёл номер счёта; последняя цифра вычислялась при помощи алгоритма Луна и использовалась как контрольная сумма всех предыдущих цифр.

С тех пор, как я научил графические карты AMD, Intel и Nvidia работать с Raspberry Pi, меня мучил вопрос:

Какой в этом смысл?

У Raspberry Pi есть только одна линия шины PCIe Gen 3, доступная для подключения к eGPU. Этого очень мало, особенно учитывая, что у современного десктопа есть как минимум один разъём с 16 линиями шины PCIe Gen 5. То есть разница составляет 8 Гт/с (гигатранзакций/с) против 512 Гт/с. Бой явно неравный.

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

Я хотел наконец покончить с вопросом о полезности, протестировав четыре задачи на разнообразных GPU для сравнения производительности на Raspberry Pi 5 и на современном десктопном PC.

Близятся Новый год и Рождество, а значит, ёлки и всё связанное с ними: гирлянды, украшения и, разумеется, игрушки. Праздник слишком уж весёлый, и я решил, что ему не хватает мрачной игры, поэтому напечатал маленькую ёлочную игрушку в виде модели IBM PC, засунул в неё самый маленький ЖК-дисплей, который смог найти, добавил туда процессор и логику, а также аккумулятор. Это устройство может висеть на ёлке и показывать демонстрационный режим Doom со звуком и музыкой. Но и это ещё не всё: если подключить ней любую BLE-клавиатуру или джойстик, то можно будет самому убивать миллиметровых зомби, какодемонов и импов.

Несколько месяцев назад я писал о прокси-войне, которую Google ведёт против открытого веба при помощи XSLT. Совершенно неудивительно, что Google продолжает продвигать отказ от него, по-прежнему не давая никаких весомых причин, за исключением «мы наживались на FLOSS-библиотеке, в которой наконец нашли достаточное количество багов безопасности, чтобы это служило оправданием». Компания не объяснила, почему решила не устранять проблемы в самой библиотеке или использовать более современную библиотеку, написанную на безопасном языке, воспользовавшись возможностью проапгрейдить поддержку XSLT до более свежей, мощной и простой версии стандарта.

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

NanoKVM — это аппаратный KVM-переключатель, разработанный китайской компанией Sipeed. Это устройство, выпущенное в прошлом году, позволяет удалённо управлять компьютером или сервером при помощи виртуальной клавиатуры, мыши и монитора. Благодаря своему компактному размеру и низкой стоимости устройство быстро привлекло внимание Интернета, особенно когда компания пообещала выпустить его код в опенсорс. Однако, как мы увидим, это устройство обладает серьёзными проблемами безопасности.

Вчера до вершины популярности Hacker News добрался этот пост Джоны Гловера:

Может ли Claude воссоздать веб-сайт Space Jam из 1996 года? Нет. Или, по крайней мере, не с моими навыками промптинга. Требуется помощь, потому что я хочу сохранить этот веб-сайт навечно, но это никак нельзя сделать, кроме как попросить Claude воссоздать его из скриншота. Поверьте мне, я менеджер по разработке со степенью по computer science. Пожалуйста, помогите 😞

Чтобы уточнить подробности своей просьбы, Джона передал Claude Code (Opus 4.1) скриншот лэндинга, папку с изображениями и следующий промпт:

Я даю тебе:

1. Полный скриншот страницы лэндинга Space Jam.

2. Папку с сырыми графическими ресурсами**, извлечёнными с исходного сайта

Твоя задача — максимально точно воссоздать страницу лэндинга в полном соответствии со скриншотом.

С подобными задачами кодинг-агенты справляются идеально. Как я часто говорю, все задачи — это задачи поиска, но этот принцип не всегда просто применить на практике. Однако в данном случае применить его очень просто! У нас есть скриншот, поэтому diff пикселей сильно упрощает работу!

Вообще, можно сказать, что сам по себе Claude Code не смог бы с этим справиться. Но Claude с конфигурациями nori¹ просто обязан это сделать.

Так что вызов принят.

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

«Зачем беспокоиться о том, чего не произойдёт?»

Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации.

За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни.

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

Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.