Lock-free очередь на C++ с нуля — подробный разбор того, как собрать MPMC-очередь, которая обгоняет std::queue под std::mutex в восемь раз при 16 потоках.

Автор идёт от наивной реализации к финальной и на каждом шаге объясняет, что и почему ломается:

🔘mutex-вариант разваливается из-за context switch в ядре;
🔘наивный CAS-подход спотыкается о ABA и use-after-free;
🔘батчинг по 1024 слота на узел убирает аллокатор с горячего пути и чинит cache locality;
🔘hazard pointers безопасно освобождают память без локов;
🔘thread-local кэш узлов окончательно убирает кучу с быстрого пути.

По ходу хорошо разобраны мелочи: alignas(64) против false sharing, выбор между compare_exchange_strong и weak, индивидуальный подбор acquire/release/relaxed/seq_cst под каждую операцию, паттерн DEFER в духе Go для парного Protect/Release.

Бенчмарки на 5 млн элементов и 16-ядерном CPU:

🔘2P/2C — 150 мс против 250 мс у мьютекса;
🔘8P/8C — 309 мс против 2152 мс;
🔘16P/16C — 299 мс против 2600 мс;
🔘1P/8C — 254 мс против 3138 мс.

В конце автор замечает: для пары потоков std::mutex остаётся правильным выбором, lock-free нужен там, где много контеншена — рендеринг, HFT, аудио, массовый ingestion.

Полная версия: https://jaysmito.dev/blog/blog/04-fast-lockfree-queues/

@prog_stuff

Как вызвать API из письма без JavaScript — инженер из Redo рассказывает, как они шлют миллионы интерактивных писем (отложить подписку, отменить заказ) без редиректа и скриптов.

Подход — два несвязанных куска:

🔘AMP Email от Google. Работает в Gmail и Yahoo, итого около 25% покрытия. Автор честно расписывает, чем AMP бесит: жёсткая валидация, нет :has, prefers-color-scheme, !important, @keyframes, ::before/::after, баги годами не чинят, одобрение домена занимает пять дней через Google Form с CAPTCHA.
🔘CSS-трюки добивают покрытие до 70%. Прячем <input type="checkbox">, связываем с <label>, а в #cb:checked ~ .card { background-image: url(...); } подсовываем URL своего API. Браузер лениво загружает картинку только после клика — это и есть тихий GET-запрос. Сервер отдаёт прозрачный пиксель и делает нужный side effect.

Подвохи у CSS-фокуса:

🔘ловится только первый клик по кнопке. Обходится цепочкой одинаковых кнопок, которые скрывают предыдущую и показывают следующую;
🔘поведение лениво подгружаемого background-image не специфицировано. Теоретически Apple Mail может однажды начать бот-кликать CSS-урлы, как уже делает с <img>. У Redo на этот случай висит «Interactive Email Doomsday» мониторинг.

В тексте есть рабочий пример карточки «отложить подписку на неделю или месяц» с полным HTML и CSS, копируется и работает в AMP, Apple Mail, Thunderbird и новом Outlook.

Полная статья: https://redo.com/eng-blog/how-to-call-an-api-from-an-email/

@prog_stuff

Unicode 18.0 готовится к релизу 15 сентября 2026 года. Сейчас это beta/draft, но набор новых символов уже заморожен.

Главное: стандарт добавляет 13 047 символов. Всего в Unicode будет 172 848 символов.

Что появится:

🔘 4 новые письменности: Chisoi, Jurchen, Seal и архаические клинописные числа.
🔘 Seal — самое крупное добавление: больше 11 тысяч символов древней китайской «малой печати».
🔘 Эмодзи тоже обновятся: cracking face, жесты большим пальцем влево/вправо, гусеница монарха, pickle, маяк, метеор, ластик и сачок.

Для разработчиков важнее не эмодзи. Unicode 18 меняет правила переноса строк, разбиения текста на графемы, сортировки, security/confusables и variation sequences.

Это может влиять на поиск, username, домены, markdown/rendering, редакторы, шрифты, regex и любые системы, которые режут текст «по символам».

Обычным приложениям можно ждать, пока Unicode 18 доедет через ОС, браузеры, ICU и языковые рантаймы. А если вы делаете редактор, текстовый движок, font tooling, security-проверки идентификаторов или поддержку CJK, beta уже стоит прогнать на тестах.

@prog_stuff

Обстоятельная статья о том, что нужно, чтобы быстро транспонировать матрицу. Андрей Гудков берёт самую наивную реализацию на 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