Go *

Мы делаем ЖМЯК — Свою игру в браузере: табло на телевизоре или ноутбуке, а кнопки — телефоны игроков. Ничего не нужно ставить, гости заходят по QR-коду и вводят только имя.

Главное в такой игре — кнопка. Вопрос прочитан, все тянутся к телефонам, кто-то нажал первым — он и отвечает. И вот тут быстро выясняется неприятное: в браузерной игре первым часто оказывается не самый быстрый игрок, а тот, у кого быстрее интернет.

В статье — как мы это чинили: синхронизация часов из уже существующего потока событий, метка времени нажатия, границы доверия клиенту, окно сбора нажатий и фальстарты. И немного реальных цифр: на проде уже 2,5 тысячи нажатий, и они кое-что рассказывают о людях.

Сколько у вас в инфраструктуре версий PostgreSQL? А какие из них уже не поддерживаются? А сколько CVE висит на том nginx, который «работает — не трогай»?

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

Когда в разгар отладки у консольного ИИ-агента кончается пятичасовой лимит, хочется пересесть на другого агента, у которого ещё есть лимиты. Популярный приём с выгрузкой сводки в файл HANDOFF.md часто подводит: качество пересказа силами самой модели оказывается не очень, теряются детали контекста, и задачу приходится объяснять заново следующему агенту (при этом ещё и тратятся лишние токены). В статье разберём, как забрать живую сессию из локальных логов без потери смысла и одной командой передать эстафету другому агенту или перенести работу вместе с несохранёнными файлами на другой ПК.

В прошлой статье я рассказывал про маршрутизацию и деньги в Keystone. The Model Switchboard. (KTMS), нашем open-source LLM-шлюзе на Go. Эта статья про эксплуатацию: как подключить свои видеокарты, что происходит, когда отказывает каждая зависимость, как менять ключи шифрования, как проверять, что вы скачали именно наш релиз, и как обновляться без простоя.

В YPtun появилась автоустановка серверов: вводите IP и пароль от VPS, нажимаете кнопку, и приложение само ставит сервер и заполняет поля подключения. Работает для семи движков на Android и ПК. Рассказываем, что происходит внутри и на чём мы спотыкались.

Про defer в Go до сих пор говорят, что он медленный и в горячем коде ему не место. Когда-то так и было: до Go 1.13 каждый defer означал аллокацию в куче. Но с тех пор компилятор научился реализовывать его тремя способами: open-coded, stack и heap. Первые два почти ничего не стоят, а в кучу defer попадает совсем не там, где обычно думают. Разбираемся, как компилятор выбирает между ними, почему defer в цикле всегда дорогой, а рекурсия, горутины и замыкания с захватом переменных на самом деле не страшны, и как посмотреть решение компилятора одной командой.

Я пишу d9c, терминальный менеджер Docker для удалённых серверов, и однажды заметил, что через него к моим серверам ходит уже не только я, но и Claude Code. Таблицы для людей агенту не подходят. Ему нужен JSON, ограничение на объём вывода, чёткая граница между «посмотреть» и «сломать» и человек, который подтверждает удаление. Рассказываю, как сделал для агентов CLI-режим, MCP-сервер и десять skills, почему инструментов двенадцать, а не сорок, и как агент всё-таки удалил стейджинг, не спросив меня, хотя задумано было ровно наоборот.

Всё началось с того, что я в очередной раз копировал описание задачи из YouTrack в Claude Code. Потом комментарии к ней. Потом ещё один комментарий, который кто‑то оставил, пока я копировал первые. Потом ждал, пока агент напишет код, открывал PR, возвращался в задачу, вставлял ссылку, менял статус на Fixed — и шёл за следующей.

В какой‑то момент я понял, что из всей этой цепочки самая бесполезная её часть — это я. Агент умеет писать код, YouTrack умеет хранить задачи, а я работаю буфером обмена с ногами.

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

Привет, Хабр!

Сегодня мы рады представить вам нашу очередную новинку, которая украсит полку профессионального бэкенд-разработчика: «Высокопроизводительный Go. Руководство по оптимизации». Она продолжает сразу два направления нашей работы и ориентирована как на современных бэкендеров, всё активнее переходящих на Go, так и просто на ответственных разработчиков, желающих систематизировать проверенные практики повышения производительности. Книга сложилась из заметок и кода, над которыми много лет работал Александр Ставонин – выдающийся специалист по Go, C++, IoT и высокопроизводительным вычислениям. В своё время Александр давал на Хабре подробное интервью для компании Getmatch, в котором рассказывал о личном опыте обустройства в Сингапуре. Англоязычные черновики книги, которые легли в основу русского издания, выложены на сайте goperf.dev.

С друзьями давно играем в «Свою игру». SIGame — отличная штука, но каждый раз начинается одно и то же: «скачай», «а у меня мак», «а я с телефона», «какой пароль от комнаты», «у меня не нажимается пробел». Половина вечера уходит на настройку.

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

Так появился ЖМЯК. Это бесплатная «Своя игра» в браузере: создаёшь лобби, выводишь табло на телевизор, друзья сканируют QR-код — и их телефоны превращаются в кнопки.

В статье расскажу, как это устроено внутри и на какие грабли я наступил. Главная тема — как понять, кто нажал первым, когда у одного игрока Wi‑Fi в той же комнате, а другой сидит на мобильном интернете в электричке.

Привет, Хабр! На связи Илья Данилкин, тимлид в Авито Авто. В этом материале я собрал подборку важных новостей из мира Go. Разберём, откуда берутся типичные утечки горутин и чем встроенный в рантайм детектор принципиально отличается от uber-go/goleak. Посмотрим, как устроен механизм GOEXPERIMENT и какие эксперименты стоит попробовать. Измерим, сколько реально даёт флаг GOAMD64 на современном железе. А также расскажу, почему языковые модели перестали быть просто предметом обсуждения и стали участниками самого процесса разработки — от поиска уязвимостей до профилирования сборщика мусора.

Самая дорогая строчка в микросервисе с LLM — model="gpt-4o". За ней тянутся свой ключ вендора, свои ретраи и счёт, который потом некому разобрать.

Расскажу об одной идее, которая это убирает: сервис не должен знать, какая модель ему отвечает. Вокруг неё четыре механизма: правила маршрутизации, автоматический выбор сложности, поведение при сбоях вендоров и контроль денег. Примеры — из нашего open-source шлюза Keystone (KTMS) на Go, но схему можно повторить в любом шлюзе.

17 октября Mozilla заблокировала восемь промежуточных CA eMudhra: их приватные ключи были меньше 256 и восстанавливались из сертификата за микросекунды. Команда Go выпустила 1.27.3 и 1.26.10 меньше чем за семь с половиной часов, и это первый релиз по новому треку URGENT.

Разбираем хронологию из поста Go Security и дополняем её: восстанавливаем слабый ECDSA-ключ на Go, объясняем, почему из-за кросс-подписей не помогает удалить корень, собираем deny-list по SPKI через VerifyConnection и разбираемся, что не так с отзывом сертификатов в Linux.

Каждый SRE хотя бы раз просыпался в три часа ночи от алерта о том, что Harbor опять упал, PostgreSQL реестра съел весь диск, а миграция после обновления сломала половину образов. Мы строим Kubernetes, чтобы забыть про серверы — а потом ставим реестр, который заставляет вспомнить про них снова. Только теперь их не один, а восемь, и у каждого свои логи, свои секреты и свои причины не запускаться. Эта статья — про то, как перестать содержать реестр как отдельный продукт и начать использовать его как инструмент: без фанатизма, без гигабайтов RAM и без молитв CSI-провайдеру перед каждым бэкапом. Разберём связку rgstr v1.10.1 и rgstroperator v0.5.1 — не как «Harbor для бедных», а как осознанный инженерный выбор для тех, кто считает TCO, а не гигабайты.

Посчитал нагрузку на сокращатель ссылок по главе 2 «System Design Interview» Алекса Сюя, записал ожидание (500 RPS, p95 ≈ 20 мс), собрал стенд в Docker и дал нагрузку через k6. Получил 24 RPS и p95 22 секунды при нуле ошибок. В статье — расчёт, стенд, EXPLAIN, почему оценка по книге не может предсказать такое, и почему кэш чинит один профиль нагрузки, а индекс — оба. Стенд открыт, можно повторить у себя.

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

Keystone. The Model Switchboard. (KTMS) убирает это из кода. Сервис говорит, насколько сложна задача, а шлюз решает, какую модель позвать, с каким ключом и не отдать ли запрос вашей собственной GPU. В простое он занимает 7 МиБ памяти, а с версии 1.0 его API в пределах 1.x не ломается.

Вместе со шлюзом 1.0 вышли веб-консоль ktms-admin и учёт расходов light-tokenmeter, все три на Go и под Apache 2.0. Возможности ниже описаны по актуальной версии 1.3.

В первой части я разобрал аллокатор и GC однопоточного процесса. Здесь расскажу, что пришлось изменить после появления потоков и горутин.

Пока процесс однопоточный, сборщик мусора имеет дело с одним стеком, одним набором регистров и одной точкой выполнения. Как только появляется второй поток, он уже может одновременно менять кучу на другом процессорном ядре. А после появления горутин выполнение Go-кода вообще перестаёт быть жёстко связано с одним стеком нативного потока.

В релизе GoOS 0.2.8 сперва появились нативные потоки пользовательского пространства, позже поверх них я реализовал собственный M:N runtime для горутин. После этого сборщик мусора тоже пришлось дорабатывать, так как перед освобождением объекта нужно быть уверенным, что ссылка на него не осталась в стеке другого потока, в сохранённом контексте горутины, в XMM-регистре или в промежуточном состоянии переключения контекста. Для этого пришлось согласовать работу сборщика с планировщиком, аллокатором и кодом сохранения контекста.

Как я за неделю сделал хэллоуинский ивент для браузерной драки Brawl Town: сезон, который включается и выключается сам по календарю, протокол, на котором старые и новые клиенты живут на одном сервере, Тыквенный король со скелетной анимацией в Pixi и шагом без скольжения, проба баланса на Go и нагрузочный тест на 2000 игроков на одной улице.

Недавно я познакомился с Golang и в качестве практики решил реализовать алгоритмы rate limiting'а из статьи с arxiv. Сегодня мы рассмотрим написание rate-limiter'а в виде отдельно-стоящего сервиса и в виде middleware, используя in-memory кэш или Redis, добавим поддержку REST и gRPC, подключим Prometheus и поймём как добиться атомарности операций с минимальными задержками.

В первой статье про GoOS я довольно подробно прошёлся по загрузке, SMP, IPC, capabilities, сети, Linux ABI и устройству сервисов. А в комментариях довольно быстро всплыл вопрос, который я тогда сознательно обошёл стороной: что в системе происходит с динамической памятью и сборщиком мусора.

Вопрос был вполне по делу. Я пишу ОС преимущественно на Go, компилирую её TinyGo, но обычный Go runtime мне тут никто не выдаёт. Значит, фраза «Go сам разберётся с памятью» тут совершенно не работает. Кто-то должен дать new, make, слайсам, map, channel и остальным объектам кучу. Кто-то должен вернуть память после того, как объект перестал быть нужен. А если в системе появляется GC, он должен понимать, где искать корни, как останавливаться относительно потоков и что делать с указателями, которые в момент остановки лежат не на стеке, а в регистрах процессора.

На момент той дискуссии ответ был сильно проще. Ядро было и остаётся собрано TinyGo с gc: leaking: его Go-куча умеет только выделять. В повторяющихся путях ядра динамические аллокации запрещены архитектурно, а объекты для таких путей заранее выделяются, переиспользуются или живут в специальных таблицах и пулах. В userspace ситуация была хуже: там уже существовал собственный runtime, но runtime.alloc по сути был bump allocator, а runtime.free и runtime.GC были заглушками.

В одном из ответов я тогда написал: «И таки да, следующим релизом я этот вопрос решу».

0.2.8 — как раз этот самый релиз.