Обстоятельная статья о том, что нужно, чтобы быстро транспонировать матрицу. Андрей Гудков берёт самую наивную реализацию на C++ (два вложенных цикла, dst[c,r] = src[r,c]) и шаг за шагом разгоняет её на x86_64 до 25 раз.

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

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

🔘Наивная версия как точка отсчёта.
🔘Разворот порядка обхода.
🔘Блочная разбивка матрицы под размер кэш-линии.
🔘Программный префетч.
🔘 Векторизация на 64-битном SIMD, потом на 256-битном.
🔘 Буферизация вывода.

Полезного по дороге много. Например, наглядно показано, во сколько обходится промах кэша: попадание в L1d почти бесплатно (4-5 тактов), L2 уже 12-15, L3 — 40-45, а промах до RAM стоит до 300 тактов. И что любой доступ к одному байту на самом деле тянет в кэш всю 64-байтную линию, поэтому весь фокус в том, чтобы успеть подгрузить данные заранее.

Хорошее чтение на вечер, если интересна low-level оптимизация под x86_64. Со схемами, анимацией обхода кэша и кодом каждой версии.

https://gudok.xyz/transpose/

@prog_stuff

Большой разбор Cloudflare, почему серверы начали грузиться по четыре часа

Cloudflare разобрали, как обычное обновление firmware превратило перезагрузку bare-metal серверов в многочасовое ожидание. Отличный пример того, как маленькая деталь в UEFI boot order ломает rollout почти на 2 000 машин.

Суть проблемы: после обновления firmware серверы проходили POST нормально, но потом линейно перебирали неподходящие варианты сетевой загрузки. IPv4 HTTPS boot, IPv4 iPXE, снова таймауты — и только потом рабочий IPv6 HTTPS boot. Каждый неудачный network boot съедал примерно по 5 минут. На одном reboot неприятно, а в firmware upgrade automation, где несколько компонентов обновляются через последовательные перезагрузки, это раздувалось почти до 4 часов.

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

🔘 serial console вместо гадания по мониторингу;
🔘 как UEFI, PXE, iPXE и HTTPS boot участвуют в загрузке;
🔘 почему firmware начал перебирать интерфейсы не в том порядке;
🔘 как Cloudflare стала задавать network boot interface order заранее в pre-boot PXE stage;
🔘 какие ограничения всплыли: старые UEFI-версии не поддерживают boot ordering, а настройки могут сбрасываться после firmware upgrade;
🔘 как всё завели через существующий release pipeline без ручного похода в BIOS.

Главная цифра: firmware upgrade automation сократили с почти 4 часов до 3 минут, а последующий single boot — примерно с 20 минут до менее чем минуты.

Сохранять тем, кто отвечает за bare metal, firmware updates, PXE/iPXE-загрузку или просто любит production-разборы, где проблема прячется не в коде приложения, а в цепочке до старта ОС. Тут хорошо видно, почему boot order, таймауты и vendor quirks стоит тестировать так же внимательно, как обычный rollout.

@prog_stuff

Один клик по ссылке — и у атакующего твой GitHub-токен на чтение и запись всех репозиториев, включая приватные

Ammar Askar разобрал цепочку, которая складывается из вполне безобидных по отдельности фич. Началось всё с github.dev — это лёгкий VSCode прямо в браузере, который открывается, если в адресе репозитория поменять github.com на github.dev. Чтобы он мог коммитить и слать pull request от твоего имени, github.com по сети передаёт ему OAuth-токен. И вот ключевая деталь: токен не привязан к конкретному репозиторию. Он даёт доступ ко всему, к чему есть доступ у тебя.

VSCode рендерит превью Markdown и Jupyter-ноутбуки внутри webview — это iframe с отдельным origin, отрезанный от основного окна. Идея правильная: даже если в ноутбуке выполнится произвольный JavaScript, до ядра редактора он не дотянется. Но есть нюанс удобства. Чтобы горячие клавиши работали, когда фокус внутри webview, VSCode вешает там слушатель keydown и пробрасывает нажатия в основное окно сообщением did-keydown. Основное окно принимает их за реальный ввод пользователя. А значит, скрипт из недоверенного webview может сам сгенерировать keydown и «нажать» клавиши за тебя.

Дальше Askar обходит защиты одну за другой, и это самая поучительная часть:

🔘Палитру команд (Ctrl+Shift+P) открыть получается, но напечатать в неё текст нельзя: поле ввода слушает не keydown, а обычный HTML-input, до которого синтетические события не доходят
🔘Тогда в дело идут встроенные хоткеи VSCode, которые висят прямо на keydown. Через .vscode/extensions.json репозиторий рекомендует «своё» расширение, всплывает уведомление, а Ctrl+Shift+A («принять основное действие уведомления») жмёт кнопку установки
🔘Система доверия к издателю (с версии 1.97) показала бы диалог подтверждения, но кнопку в нём синтетическим Enter не нажать. Обход — local workspace extensions: расширение прямо в .vscode/extensions в доверенном workspace ставится без проверки издателя, а github.dev доверенный всегда
🔘Последний барьер, CSP, ломал прямую загрузку. Решение изящное: расширение через package.json регистрирует свой keybinding на runCommands, который вызывает workbench.extensions.installExtension с флагом skipPublisherTrust. Своё нажатие клавиши воспроизводится железно, так что устанавливается уже что угодно

Итоговый payload прячется в Markdown-ячейке ноутбука как картинка с onerror, ждёт всплывающего уведомления, шлёт Ctrl+Shift+A, затем Ctrl+F1, и установленное расширение читает OAuth-токен и дёргает api.github.com за списком приватных репозиториев. CSRF-токенов у github.dev нет, поэтому редиректнуть жертву на атаку может любая ссылка.

Отдельно ценен раздел про то, что VSCode сделал правильно: именно defense-in-depth спас от худшего сценария. На странице расширения скрипты в Markdown-превью отрублены через script-src 'none', иначе это была бы 1-click RCE на десктопе. Microsoft выкатил фикс на следующий день (3 июня): подтверждение при открытии ноутбуков в вебе и запрет пробрасывать keydown из webview ноутбука.

Если защищаешься: очисти cookies и site data для github.dev. Тогда при заходе появится диалог, на котором можно уйти со страницы до запуска цепочки.

Сохранять тем, кто пишет приложения с webview, разбирает модели изоляции iframe или просто любит, когда сложную атаку собирают из десятка «удобных» мелочей.

https://blog.ammaraskar.com/github-token-stealing/

@prog_stuff

Под капотом RollerCoaster Tycoon: оптимизация как искусство сказать «нет»

RollerCoaster Tycoon (1999) до сих пор называют эталоном оптимизации. Крис Сойер написал игру почти целиком на ассемблере и заставил процессоры конца девяностых тащить парки с тысячами посетителей без единой просадки кадра — то, с чем многие современные градостроительные симуляторы справляются хуже на железе в сотни раз мощнее. Ларс Тофус в блоге Larst Of Us разобрал, как это устроено. Исходников игры нет, но есть почти эквивалент — OpenRCT2, побайтовая фанатская переразработка на годах реверс-инжиниринга. По ней и видно, насколько агрессивно вылизан каждый кусок.

Первое, что бросается в глаза, это типы данных под деньги. Сойер не брал один универсальный тип на все случаи, а подбирал размер под максимально ожидаемое значение. Общая стоимость парка может быть огромной, поэтому под неё отведено 4 байта. А цена товара в ларьке заведомо маленькая, под неё хватает одного байта. На современных процессорах разницы уже нет, поэтому в OpenRCT2 всё свели к 8-байтовым переменным, но в оригинале экономили каждый байт.

Второй приём — замена арифметики битовыми сдвигами. Вместо умножения на 4 в коде стоит сдвиг влево на две позиции, вместо деления на 8 — сдвиг вправо на три. Сдвиг намного дешевле для процессора. Интересна тут не сама техника, а то, как часто она применима: сдвигом можно умножать и делить только на степени двойки. То, что в коде это встречается постоянно, означает, что игровые формулы изначально проектировались под удобные числа. Представьте программиста, который просит геймдизайнера заменить 9,5 на 8, потому что так удобнее процессору. В обычной студии это невозможно. В RCT программист и дизайнер — один человек, и это открывает третий, самый глубокий слой оптимизаций.

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

🔘 У поиска пути есть жёсткий лимит глубины обхода сети дорожек, и при его достижении поиск просто сдаётся и возвращает неудачу.
🔘 По умолчанию гостю можно пройти лишь до глубины в 5 развилок. Когда гость жалуется, что не может найти выход, это буквально работа алгоритма, который мог бы искать дальше, но не стал ради кадров.
🔘 Механик важнее обычного гостя, ему лимит подняли до 8 развилок.
🔘 Гость, купивший карту парка в киоске, получает лимит 7 вместо 5, и ему легче найти выход. Техническое ограничение превратили в игровую механику.

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

Сохранять тем, кто любит истории про low-level инженерию, ценит дизайн, продиктованный железом, и хочет показать коллегам, что значит «оптимизировано до предела».

https://www.larstofus.com/the-gold-standard-of-optimization-a-look-under-the-hood-of-rollercoaster-tycoon

@prog_stuff

Сколько стоит прочитать одну страницу в 8 КБ из Postgres — трассировка по всем слоям кэшей

Свежий разбор, который хочется выдать каждому, кто проектирует базы «на глазок». Автор словил в продакшене инцидент с IOPS, воспроизвёл ту же патологию на домашнем сервере и померил, во сколько обходится чтение одной и той же страницы на каждом уровне: shared buffers, page cache операционки, локальный NVMe и сетевой диск AWS EBS.

Числа красивые своей наглядностью, каждый слой стоит примерно на порядок дороже предыдущего:

🔘страница в shared buffers — около 1,1 мкс;
🔘в page cache ОС — около 4 мкс;
🔘холодное чтение с локального NVMe — около 78 мкс;
🔘сетевой EBS в продакшене — около 497 мкс, в 124 раза дороже page cache.

Самая поучительная деталь — про порядок чтения. Те же 500 холодных страниц в отсортированном порядке (bitmap heap scan) читаются за 2,8 мс, а в случайном (index scan) — за 39,5 мс. Разница в 14 раз на ровно тех же данных, всю работу делает readahead ядра.

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

Полная статья: https://frn.sh/8kb-read/

@prog_stuff

Софт рождается между коммитами — Zed представила DeltaDB, контроль версий для эпохи агентов

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

Что это даёт:

🔘с любой строки кода можно перейти к диалогу, в котором она появилась, и ко всем последующим обсуждениям;
🔘ссылки на код привязаны к дельтам, а не к номерам строк, поэтому не ломаются, когда код переезжает;
🔘рабочие деревья построены на CRDT: несколько людей и агентов правят одни файлы на разных машинах без конфликтов;
🔘коллега может подключиться к работе, поговорить с агентом и оставить пометки, не дожидаясь commit и push;
🔘агенты получают контекст: могут «спросить» предыдущих агентов, почему код написан именно так.

Git при этом не выбрасывается — остаётся для CI и связи с внешним миром, просто перестаёт быть единственной точкой совместной работы. Бета обещана в ближайшие недели, открыт список ожидания.

Сохранять тем, кто много работает с кодящими агентами и уже ловил себя на том, что контекст решений теряется между сессиями.

Полная статья: https://zed.dev/blog/introducing-deltadb

@prog_stuff

Хватит использовать Conventional Commits — провокационное эссе с аргументами, которые сложно отмахнуть

Автор бьёт по стандарту, который многие команды внедрили не задумываясь. Главный тезис: Conventional Commits фокусируют на неважном и обесценивают важное. Тип коммита (fix, feat, chore) стоит на первом месте и обязателен, а scope — область, которую трогает коммит — опционален и прячется в скобках. По мнению автора, всё должно быть наоборот.

Аргументация по пунктам:

🔘всем читателям истории важнее «где», чем «что за тип»: контрибьютор ищет изменения в конкретной подсистеме, дебажащий ищет по компоненту, дежурный при инциденте смотрит на область, где всплеск ошибок;
🔘тип часто избыточен: в fix(compiler): prevent SVG elements from being stripped и без префикса видно, что это багфикс;
🔘обещания стандарта не выполняются: автогенерация changelog ломается на многокоммитных фичах и ревертах, автоопределение semver даёт ложные срабатывания, а триггерить CI по docs: в сообщении опасно — честнее смотреть на изменённые файлы;
🔘ИИ-ассистенты по привычке генерируют Conventional Commits, чем разносят антипаттерн дальше.

Взамен предлагаются scoped commits: префикс с областью и описание. Это даже не новый стандарт — так десятилетиями живут Linux (i2c: virtio: mark device ready...), Git, Go (net/http/cookiejar: add godoc links), FreeBSD, Node.js и nixpkgs.

Текст вышел 5 июня и уже собрал жаркие обсуждения. Сохранять тем, кто пишет гайдлайны для команды: даже если останетесь на Conventional Commits, аргументы стоит знать.

Полная статья: https://sumnerevans.com/posts/software-engineering/stop-using-conventional-commits/

@prog_stuff

Семь ошибок в архитектурных диаграммах, которые делают почти все

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

🔘подписи типом вместо имени: на диаграмме «Amazon S3» и «AWS Lambda», и непонятно, какой именно бакет и какая функция. Лечится суффиксом типа: Orders Table, Results Bucket;
🔘висящие ресурсы: компонент нарисован, но ни с чем не соединён, и его роль приходится угадывать;
🔘«мастер-диаграмма»: попытка уместить всю систему в одну схему, где смешаны runtime-зависимости, DNS, CDN и деплой. Решение — несколько диаграмм с разных точек зрения;
🔘синдром конвейера: поведение системы рисуют как поток слева направо, хотя реальные взаимодействия ходят туда-обратно. Для этого есть sequence-диаграммы;
🔘бессмысленные анимации: мелькающие стрелки дублируют то, что и так видно, и нужны только для маркетинга;
🔘fan trap: продюсеры и консьюмеры сходятся в одном брокере сообщений, и кто с кем реально общается — не видно. Лечится отрисовкой топиков внутри брокера;
🔘вера, что ИИ построит качественную диаграмму из исходников: на выходе размытые схемы с галлюцинациями и теми же ошибками из пунктов выше, потому что модель не умеет стратегически решать, что включить, а что выкинуть.

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

Полная статья: https://www.ilograph.com/blog/posts/more-common-diagram-mistakes/

@prog_stuff

RCE, которую AMD не хотела чинить: история одного разбора

Автор разозлился на всплывающее консольное окно на игровом ПК, отследил его до AMD AutoUpdate и в наказание декомпилировал программу. Внутри нашлась цепочка на удалённое выполнение кода: список обновлений приходит по HTTPS, но ссылки на сами исполняемые файлы в нём — обычный HTTP, а проверки подписи нет вообще. Атакующий в той же сети подменяет ответ, и апдейтер скачивает и сразу запускает любой бинарник.

Как развивались события:

🔘27 января — уязвимость найдена, 6 февраля — отчёт в AMD;
🔘в тот же день AMD закрывает его со статусом «не будем чинить»: MITM-атаки вне скоупа их баг-баунти;
🔘на следующий день после публикации блог-поста компания передумала и попросила пост убрать;
🔘дальше четыре месяца продлений эмбарго: «затронуты ещё несколько инструментов», «клиенты просят время»;
🔘9 июня, через 124 дня, эмбарго снято и присвоен CVE.

Детали финала достойны отдельного абзаца. Вместо криптографической подписи AMD добавила проверку CRC-32, которая от подмены не защищает. Выплата за находку — ноль долларов: формально вне скоупа. А эксплуатировать дыру всё это время было нельзя по смешной причине: апдейтер падал из-за другого, никем не замеченного бага с редиректом.

Сохранять тем, кто пишет автообновления (HTTPS и подпись бинарников обязательны), и тем, кто хочет понимать, как на самом деле выглядит ответственное разглашение.

Полная статья: https://mrbruh.com/amd2/

@prog_stuff

Почему случайные UUID в роли первичного ключа убивают вставки в SQLite

Разбор с бенчмарками и профилированием о том, как выбор типа первичного ключа меняет скорость записи в разы. Суть проблемы: первичный ключ задаёт физический порядок хранения строк в B-дереве. Случайный UUID4 означает вставки в случайные места дерева, а это бесконечные сплиты страниц и ребалансировки.

Автор вставляет 10 миллионов строк пакетами по миллиону и сравнивает:

🔘обычный INTEGER-ключ: стабильные ~715 мс на миллион, эталон;
🔘UUID4 с WITHOUT ROWID: первый миллион 2649 мс, десятый уже 12586 мс — деградация нелинейная, чем больше таблица, тем хуже, итог до 18 раз медленнее эталона;
🔘UUID7 с WITHOUT ROWID: стабильные ~1250 мс на миллион без всякой деградации.

Весь фокус в том, что UUID7 содержит таймстемп в старших битах, поэтому новые ключи монотонно растут и ложатся в конец дерева, как автоинкремент. UUID4 при этом остаётся медленнее целого числа примерно на 70%: ключ занимает 16 байт против 8, строк на страницу помещается меньше.

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

Выводы переносятся на любую БД с кластерным индексом, от MySQL InnoDB до SQL Server. Сохранять всем, кто сейчас выбирает схему ключей для нового сервиса.

Полная статья: https://andersmurphy.com/2026/06/05/the-perils-of-uuid-primary-keys-in-sqlite.html

@prog_stuff

CSS: какие части языка неустранимо плохие и как с ними жить

Разбор от Алекса Кладова (matklad, автор rust-analyzer) — взгляд бэкендера, которому пришлось стилизовать свой блог. Он разложил CSS на части, которые работают предсказуемо, и части, которые подведут в самый неожиданный момент, и для каждой плохой нашёл обходной путь.

Главные практические выводы:

🔘первая строка любого CSS-файла — * { box-sizing: border-box; }, иначе padding ломает размеры элементов;
🔘вместо обёрток и div-супа — семантические теги main, article, nav, details: с ними простой classless CSS работает сам;
🔘отступы между детьми удобно задавать через owl-селектор section > *+* { margin-top: 1rem; } — родитель контролирует расстояния, дети ни о чём не знают;
🔘явные media-запросы для простых страниц не нужны: flexbox и max-width на главной колонке дают отзывчивость бесплатно;
🔘браузерные дефолты — ловушка: проблема не в правиле, которое вы написали, а в правиле, на которое вы полагаетесь, не написав его;
🔘font-size задаёт размер виртуальной коробки вокруг глифа, а не сам глиф — выровнять два шрифта помогает font-size-adjust.

Для блога автору хватило примерно 200 строк читаемого CSS без фреймворков.

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

Полная статья: https://matklad.github.io/2026/06/04/css-unavoidable-bad-parts.html

@prog_stuff

Algorithm Visualizer — сайт, где 30+ алгоритмов разобраны пошаговой анимацией

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

Что внутри:

🔘поиск пути и обходы графов: BFS, DFS, Dijkstra, Bellman-Ford;
🔘остовные деревья Краскала и Прима, компоненты связности, потоки в сетях (Edmonds-Karp, Ford-Fulkerson);
🔘сортировки, бинарное дерево поиска, связные списки, дерево рекурсии;
🔘классика собеседований и олимпиад: N-Queens, выпуклая оболочка, машина Тьюринга.

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

Работает прямо в браузере, ничего ставить не нужно. Сохранять студентам перед сессией, всем, кто готовится к алгоритмическим секциям собеседований, и менторам — объяснять джуну Дейкстру по анимации сильно проще, чем по псевдокоду.

Полная ссылка: https://tamimehsan.github.io/AlgorithmVisualizer/

@prog_stuff