Denis Evsyukov

Perigee: своя читалка и разреженные строки

denis@evsyukov.org (Denis Evsyukov) — Sat, 31 Oct 2026 18:00:00 +0300

Я пишу читалку для Android, она называется Perigee¹. Сегодня вышла v0.1.0-rc5², и главное в ней — страницы без дыр между словами. Ниже расскажу, зачем понадобилась своя читалка, откуда берутся разреженные строки, какие способы мы перебрали и почему ни один готовый алгоритм не подошёл целиком.

Исследование вели два агента, Hermes и Claude Code. Я смотрел на страницы и принимал решения.

Зачем своя читалка

Книги у меня лежат на собственном сервере bookOrbit³. Он хранит библиотеку и прогресс чтения, у него есть веб-читалка, а официального приложения для Android, когда я начинал, не было.

Читать на телефоне мне нравится в ReadEra: она хорошо показывает текст и ею просто пользоваться. Но с bookOrbit она не синхронизируется. KOReader синхронизируется и даёт отличный движок, только настроек в нём столько, что читалка становится отдельным хобби.

Отсюда и цели Perigee:

Отображение важнее всего. Текст верстает crengine⁴, нативный движок KOReader: переносы по словарю языка книги, выравнивание по ширине, висячая пунктуация, сноски внизу страницы.
Просто, как в ReadEra. Настройки повторяют её набор: шрифт, размер, интервалы, поля. Сразу видно, как изменение меняет страницу.
Самостоятельное приложение. Локальная библиотека и каталоги OPDS работают без сервера.
Полная синхронизация с bookOrbit. В обе стороны ходят место чтения, выделения с заметками, закладки, статус и оценка, на сервер уходит время чтения.

PDF, DjVu, комиксов и аудиокниг нет: для них нужен второй движок. Первый коммит появился 12 октября, в репозитории Kotlin и Compose поверх C++ движка.

Проблема

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

Причина в том, как движок выравнивает текст. Он жадный: набирает в строку столько, сколько влезает, а остаток ширины поровну делит между промежутками. У сжатия есть предел, в Perigee пробел нельзя ужать меньше чем до 75 %. У растяжения предела нет. Если следующее слово длинное и не переносится, вся пустота достаётся промежуткам этой строки.

Я попросил это померить. Промежутки считали в em, это размер шрифта: у шрифтов из приложения собственный пробел занимает 0.20–0.29 em. Hermes собрал crengine на компьютере с патчами приложения и добавил запись в CSV на каждую выровненную строку. Книга для замера: 1800 абзацев моего блога, Roboto 18 dp на экране шириной 1440 пикселей, это около 42 символов в строке и примерно 13 300 строк.

Показатель	Значение
Медианный промежуток	0.35 em
99-й перцентиль	1.13 em
Самый широкий	5.48 em
Строк шире 0.5 em	20.0 %
Строк шире 0.75 em	4.4 %

Медиана в норме, плохо с хвостом. Цель из задачи звучала так: ни одного промежутка шире 0.75 em и не больше одной строки из пятидесяти шире 0.5 em⁵.

Что мы попробовали

Потолок

Самое простое решение: если промежуток в строке превысит потолок, строка не выравнивается и остаётся с естественными пробелами. Предел у пробела есть и в InDesign: по умолчанию он растягивается до 133 %⁶.

Потолок	Строк без правого края	p99	Самый широкий
нет	0	1.13 em	5.48 em
0.75 em	4.4 %	0.71 em	0.71 em
0.5 em	20.0 %	0.50 em	0.50 em

На картинке выше потолок 0.75 em справа убрал дыру. Вот все три варианта на той же странице, а ниже обычная страница:

Дыры пропали, зато вместо них появились короткие строки посреди абзаца. На обычной странице таких было шесть из тридцати. Глаз читает это как ошибку вёрстки.

Взгляд на строку вперёд

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

Первая версия не сдвинула ни одного разрыва на всей книге. Ранний разрыв только расширяет текущую строку, поэтому смотреть надо на следующую: дыра обычно стоит перед длинным словом. После исправления разрывы сместились в 1.1 % случаев, строк шире 0.75 em стало 545 вместо 587, а самый широкий промежуток остался 5.48 em.

На этой странице хорошо видно, почему так: дыра часто просто переезжает на строку выше. Окна в одну строку мало, остаток ширины накапливается за несколько строк. Цена за это — около 150 строк C++ и +15 % ко времени вёрстки.

Абзац целиком

Настоящий ответ индустрии давно известен. Кнут и Пласс в 1981 году описали разбивку всего абзаца как поиск пути с наименьшей суммарной «плохостью» строк⁷, этот алгоритм работает в TeX. Paragraph Composer в InDesign тоже оценивает все строки абзаца вместе⁸. Для самого crengine такую работу уже проделали в надстройке к KOReader⁹.

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

Вариант	p50	p99	Самый широкий	Шире 0.5 em	Шире 0.75 em	Вёрстка
сегодня	0.35	1.13	5.48	20.0 %	4.4 %
абзац целиком	0.39	0.85	2.75	23.9 %	2.2 %	+60 %

Хвост сократился вдвое, дыра в 5.48 em исчезла. Но вся страница стала немного рыхлее, и на моих глазах одна плохая строка превращалась в несколько средних. Вёрстка книги при этом стала дольше на 60 %. Hermes предложил другую мысль: считать абзац, но менять только те строки, где есть проблема. Её мы и довели до конца.

Что нашлось по дороге

Прежде чем делать новый вариант, я проверил полный алгоритм на странном случае. Если убрать ограничения, он должен быть не хуже жадного: жадный путь для него доступен. А он оказался хуже: 951 строка шире 0.75 em против 517.

Рыхлая страница оказалась следствием одной константы. За два переноса подряд алгоритм добавлял 10000. Число взято из TeX, но там оно складывается с квадратами штрафов и равно одной строке с плохостью 100. У нас штраф линейный, и эта добавка перевешивала всё остальное. При значении 1000 тот же алгоритм становится лучше сегодняшней страницы целиком: на «Под Куполом» Кинга строк шире 0.5 em 10.2 % против 12.5 %. Вывод предыдущего раунда описывал константу, а не метод.

Блог сильно завышал проблему. Мой блог полон названий и путей, а настоящие книги устроены иначе. В семи книгах прозы шире 0.75 em оказалось от 0.3 до 1.2 % строк, а не 5 %. Цель «одна строка из пятидесяти шире 0.5 em» недостижима ни для одного варианта: даже лучший алгоритм даёт 4–11 %.

Латиница в русских книгах не переносилась. Из 295 строк, оставшихся шире 0.75 em после полного алгоритма, у 88 в следующем слове была латиница: Wordpress, Amazon, pages.github.com. Для языка ru движок берёт Russian.pattern, где латинских шаблонов нет, хотя в приложении уже лежит Russian_EnUS.pattern.

Что мы выбрали

Выбрали точечную правку и другой словарь для русских книг. Без настройки и без потолка.

Сначала, как и раньше, считаются жадные строки. Если в абзаце нет промежутка шире 0.75 em, движок работает как обычно. Если такая строка есть, вокруг неё открывается окно: четыре строки до и две после. Только внутри окна алгоритм рассматривает другие разрывы и расставляет переносы, снаружи разрывы остаются жадными, поэтому эти строки не могут измениться.

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

Девять книг в той же настройке. В таблице жадная вёрстка и правка, размеры в em:

Книга	Шире 0.75 em: было	стало	Самый широкий: было	стало	Шире 0.5 em: было	стало
Кинг, «Под Куполом»	1.0 %	0.5 %	2.05	1.46	12.5 %	12.5 %
Петросян, «Дом, в котором…»	1.0 %	0.5 %	1.52	1.52	11.0 %	10.9 %
Макьюэн, «Невыносимая любовь»	1.2 %	0.3 %	1.78	1.30	11.7 %	11.6 %
Саймак, «Город»	1.2 %	0.6 %	1.28	1.28	12.6 %	12.6 %
Брэдбери, «Марсианские хроники»	1.1 %	0.5 %	1.25	1.01	12.7 %	12.7 %
Аллен, GTD	4.1 %	1.6 %	2.15	2.15	20.0 %	20.7 %
Мой блог	5.1 %	2.1 %	4.94	2.43	21.2 %	20.3 %
«Война и мир», английский перевод	0.9 %	0.3 %	2.47	1.54	9.6 %	9.6 %
«Гордость и предубеждение»	0.3 %	0.1 %	1.11	1.00	7.3 %	7.3 %

Хвост в прозе падает примерно вдвое и догоняет полный алгоритм, а основная масса строк почти не меняется. На «Под Куполом» правка затронула 534 строки примерно из 47 000. Время вёрстки выросло на 13–18 % вместо 68–74 % у полного алгоритма. Текст проверен хешем на трёх книгах: все символы на месте, изменилась только разбивка на строки.

Шире всего проверили по матрице из 288 прогонов: четыре книги, четыре шрифта, размеры 16, 18 и 24 dp, две ширины, всего 1.7 млн строк.

Вариант	Шире 0.5 em	Шире 0.75 em	Шире 1 em	Самый широкий	С переносом
сегодня	17.3 %	3.69 %	19 257	8.36 em	35.1 %
правка	17.5 %	2.03 %	6 543	3.54 em	35.8 %

Цена тоже есть: переносов на 0.7 пункта больше, а в одной из настроек прозы рост доходил до 1.8. Страниц стало почти столько же, разница не больше 0.33 %.

Обычная страница «Гордости и предубеждения»: слева как было, в середине после правки. Изменились три строки, а один перенос вообще исчез. Правая панель с потолком 1 em ничем не отличается, потому что на таких страницах ему нечего делать:

Самый тяжёлый случай, который нашёлся, — страница блога. Дыры ушли, но оба абзаца переработаны, переносов больше, и первый стал на строку длиннее:

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

Потолок мы оставили за бортом. В прозе он сработал бы примерно на одной строке из 550, а строка без правого края мне не понравилась сразу. Остаются редкие строки вроде первой строки абзаца из длинных слов или строки перед адресом: двигать там нечего.

Как это сделано

Движок лежит сабмодулем и не форкнут. Приложение несёт к нему патчи: при сборке CMake копирует нужные файлы движка в каталог сборки, накладывает на них патчи и компилирует копии. Вторым таким патчем стала правка, она меняет только форматирование абзаца в lvtextfm.cpp. Документ при этом не трогается, поэтому закладки, выделения и места чтения, которые ходят на сервер, указывают на тот же текст.

Словарь выбирает небольшая функция в JNI-слое при открытии книги. Рядом появился тест, который на настоящем экране эмулятора мерит пустые колонки внутри строки. Без патча он падает: 65 пикселей против предела в 47. Заодно пришлось заново принять контрольные страницы, с которыми сверяется вёрстка.

Измерительный стенд остался в репозитории: патч с записью в CSV накладывается поверх патчей приложения и может отключить правку, так что сравнение с жадной вёрсткой всегда воспроизводится. Весь разбор с цифрами лежит в docs/spikes/word-gaps-preview.md¹⁰.

Релиз собирается только в GitHub Actions: тег v0.1.0-rc5, подписанные APK для трёх ABI, заметки из коммитов. Перед тегом прошли сборка, линтер и unit-тесты, а на эмуляторе тесты движка, экранов и синхронизации с bookOrbit.

Так выглядит контрольная страница из тестов приложения, это PT Serif на узкой странице, самом неудобном случае. Строка путешественники переговаривались больше не разорвана пустотой, а цена видна сразу: переносов стало больше.

Сборку rc5 я проверил на своём телефоне, и она мне понравилась. Время первого открытия на телефоне мы не замеряли, цифры выше сняты на компьютере.

Perigee пока называется рабочим именем и в магазинах его нет, сборки лежат в релизах на GitHub. Лицензия GPL-3.0.

juev/perigee, репозиторий проекта. ↩︎
Perigee 0.1.0-rc5, подписанные APK. ↩︎
bookOrbit, сервер библиотеки. ↩︎
koreader/crengine, движок вёрстки KOReader. ↩︎
Issue #99, вся история замеров в комментариях. ↩︎
Настройки выравнивания в InDesign, по умолчанию межсловный пробел от 80 до 133 %. ↩︎
Donald Knuth, Michael Plass, Breaking Paragraphs into Lines, 1981; краткое описание алгоритма. ↩︎
Set text composition, описание Paragraph Composer. ↩︎
koreader-knuth-justification, постраничная разбивка для KOReader. ↩︎
word-gaps-preview.md, разбор с таблицами и командами для воспроизведения. ↩︎

Читайте оригинал на странице: Perigee: своя читалка и разреженные строки (Denis Evsyukov)

Ссылки #414

denis@evsyukov.org (Denis Evsyukov) — Sat, 31 Oct 2026 07:06:23 +0300

На этой неделе в подборке: Claude, формально доказавший безопасность 123 open-source библиотек, почтовый сервер Stalwart v1.0, обогнавший Postfix и Dovecot, расследование инцидента безопасности Tailscale SSH и двенадцать лет распределённого SQLite в rqlite.

🤖 ИИ

LLMs are making formal software verification feasible at a much larger scale \ Anthropic Claude формально доказал свойства безопасности в скомпилированном коде 123 библиотек с открытым исходным кодом. В ходе проверки он обнаружил ошибки, которые годами оставались незамеченными.

🖥️ Инфраструктура

Stalwart v1.0: The Fastest Mail Server on the Planet | Stalwart Stalwart v1.0 — первый стабильный выпуск почтового сервера после пяти лет разработки; в нём зафиксирована схема базы данных и переписан поисковый движок. По результатам тестирования с профилированием и нагрузочными испытаниями Stalwart показал более высокую производительность, чем Postfix и Dovecot, в 35 из 38 тестов.

🔐 Безопасность

Tailscale SSH: Investigation and remediation update Обновление посвящено расследованию безопасности Tailscale SSH и ходу работ по устранению проблем. Также в нём говорится, что клиенты могут сделать сейчас, но конкретные меры и результаты в кратком описании не указаны.

🗄️ Базы данных

Twelve years of distributed SQLite – Philip O’Toole rqlite — проект, объявленный в 2014 году: он добавляет журнал Raft перед SQLite и реплицирует каждую запись между узлами кластера. Цель такого подхода — сохранить данные при потере узла, однако в исходном описании представлена идея проекта, а не результаты его дальнейшей работы.

А ещё

За прошедшую неделю собрал 39 ссылок.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #414 (Denis Evsyukov)

go-cache-lru: три версии за день и сутки под лимитом

denis@evsyukov.org (Denis Evsyukov) — Thu, 29 Oct 2026 17:00:00 +0300

Позавчера я писал про go-cache-lru, реализацию GOCACHEPROG, которая держит кеш сборки Go в заданном размере. Тот пост заканчивался списком того, что не проверено: вытеснение в реальной работе ни разу не срабатывало, а Windows не поддерживалась. 28 октября вышли версии 0.2.0, 0.3.0 и 0.4.0¹. Ниже — что в них изменилось и как кеш прожил следующие сутки.

0.2.0: вытеснение без пауз и тихий демон

Утром 28 октября кеш дошёл до 25 ГиБ из 30, не вытеснив ни одной записи². Первый прогон вытеснения должен был удалить около 5 ГиБ, и тут всплыла проблема: файлы объектов удалялись под мьютексом кеша. Пока шла пачка из 256 удалений, ждали все get и put всех команд go. Теперь под блокировкой объект только помечается, а файл удаляется после её снятия. Бенчмарк на 2000 объектах по 256 КиБ показал, как изменилась задержка get во время вытеснения:

	До	После
Максимальная задержка `get`	30–38 мс	0.12–0.16 мс
`get` дольше 1 мс	4	0
`get`, обслуженных за время вытеснения	около 650	около 30 000

Само вытеснение быстрее не стало, но сборки его больше не ждут.

Запись объектов стала дешевле. Тело put приходит в base64 и декодируется кусками не больше 768 байт, а io.Copy превращал каждый кусок в отдельный системный вызов write. На холодной сборке, которая положила в кеш 1.8 ГиБ, демон потратил на эти вызовы 12.7 с из 16 с процессорного времени³. Буфер перед временным файлом поднял скорость записи в бенчмарке со 156–175 до 486–500 МБ/с. Второе узкое место — сокет между командой go и демоном: macOS даёт unix-сокетам буферы по 8 КиБ, и данные шли мелкими порциями. Обе стороны теперь просят 1 МиБ. На холодном go test -race большого сервиса процессорное время демона упало с 8.5 до 7.8 с, а промежуточного процесса — с 3.4 до 2.1 с.

Демон перестал просыпаться без дела. Без единой команды go он всё равно просыпался примерно раз в секунду: индекс сбрасывался по таймеру каждые 100 мс, метка go clean -cache проверялась каждые 2 с, а stats.json перезаписывался каждые 30 с. Теперь каждый таймер работает только при наличии работы. По top -stats idlew за три минуты простоя после сборки было 129 пробуждений, стало 0.

Ещё два изменения про удобство. Демон замечает, что его бинарник заменили, и завершается, так что после обновления больше не нужен go-cache-lru stop. stats -v показывает, чем занят кеш: объекты по размеру и по времени последнего обращения. Раньше для этого приходилось лезть в index.db через sqlite3, и так выяснилось, что 72 % кеша в 25 ГиБ занимали 407 архивов пакетов примерно по 90 МиБ⁴.

0.3.0: история по часам

Накопительные счётчики плохо показывают, как кеш работает сейчас: в процент попаданий с первого запуска входит прогрев. На одной машине stats давал 96.7 % за 22 часа, хотя за последние три с половиной часа было 98.7 %⁵. Увидеть второе число можно было, только вычитая два снимка руками.

Теперь демон хранит изменения счётчиков по часам за 7 дней в той же базе SQLite, вместе с пиковым размером кеша за час. stats показывает текущий час, сутки и неделю, stats -v добавляет почасовую таблицу. По этой истории stats даёт совет про --max-size. Пока часов с командами go меньше 24, он ждёт данных. Если вытеснений не было, а пик не дошёл до 60 % лимита, совет — пик плюс 25 %. Если вытеснения были, он сравнивает долю промахов в час после вытеснения с обычной. Когда после трёх и более вытеснений промахов в полтора раза больше, он предлагает лимит на 50 % выше. Пороги — первая прикидка, их надо проверить на настоящей истории.

Обновление стало мягче. В 0.2.0 демон, заметив новый бинарник, сразу переставал принимать подключения, и новые команды go ждали, пока закончатся старые. Теперь он продолжает обслуживать и выходит в первый момент, когда к нему не подключена ни одна команда go.

Управляющим командам больше не нужен --dir. stats, trim, clean и stop берут флаги из GOCACHEPROG в окружении или в go env, поэтому статистика теперь — просто go-cache-lru stats.

0.4.0: Windows

Блокировка демона и запуск в фоне работали через flock и setsid, которых в Windows нет. Теперь там используются LockFileEx и отдельная группа процессов, а различия собраны в файлах *_windows.go. По дороге нашлись две ошибки: путь с буквой диска ломал URI базы SQLite, а два одновременных put одного объекта переименовывали второй файл поверх первого, что Windows запрещает, пока файл кто-то читает. Содержимое у них одинаковое, поэтому теперь остаётся файл, который уже лежит на диске. Тесты гоняются в CI и на Windows, бинарники выходят zip-архивами.

Сутки на 0.4.0

Демон v0.4.0 запустился 28 октября в 17:22, через несколько секунд после тега, и проработал без перезапуска до вечера 29-го. Лимит прежний: --max-size=30GiB, --target-size=25GiB. Вот stats -v на 29 октября, 17:10, путь к домашнему каталогу заменён на ~:

$ go-cache-lru stats -v
daemon pid 48388, version v0.4.0, up 23h47m56s, 0 active sessions
directory ~/.cache/go-lru
size 25.8 GiB of 30.0 GiB (target 25.0 GiB), 86.0%
entries 76155 actions, 14056 objects, 0 pinned
counters since 2026-10-27 16:38:51
hits 3542620 (97.4%), 775.3 GiB served
misses 95312
puts 174754, 80.3 GiB written
evictions 66727 entries, 50.6 GiB
cleans 0 explicit, 1 by go clean -cache
sessions 2337
this hour no go commands
last 24 hours hit rate 98.0%, 1639228 gets, 28.7 GiB written, 6 evictions
last 7 days hit rate 97.9%, 2169649 gets, 38.5 GiB written, 7 evictions
advice not enough history yet: 12 of 24 active hours

objects by size
 < 64 KiB 5675 43.2 MiB 0.2%
 64 KiB - 1 MiB 5823 2.4 GiB 9.3%
 1 MiB - 10 MiB 2096 4.8 GiB 18.7%
 10 MiB - 100 MiB 460 18.3 GiB 70.9%
 >= 100 MiB 2 253.8 MiB 1.0%

objects by last access
 < 1h 1127 375.2 MiB 1.4%
 1h - 6h 12929 25.4 GiB 98.6%
 6h - 24h 0 0 B 0.0%
 >= 24h 0 0 B 0.0%

hourly, last 24 hours
 hour gets hit rate written evictions peak size
 18:00 710 99.7% 2.0 MiB 0 29.4 GiB
 09:00 9140 98.3% 94.2 MiB 0 29.5 GiB
 10:00 43177 99.6% 60.8 MiB 0 29.5 GiB
 11:00 303009 97.7% 5.0 GiB 1 30.0 GiB
 12:00 437705 97.8% 8.2 GiB 2 30.0 GiB
 13:00 152856 97.1% 3.5 GiB 1 30.0 GiB
 14:00 332627 98.3% 6.9 GiB 1 30.0 GiB
 15:00 352247 98.3% 5.0 GiB 1 30.0 GiB
 16:00 7757 99.6% 5.3 MiB 0 25.8 GiB

Главное здесь — столбец peak size. С 11 до 16 часов в кеш записали 28.6 ГиБ, а пик за каждый час остался на 30.0 ГиБ. Шесть раз кеш упирался в лимит, и шесть раз демон сжимал его до цели, убирая по 5–5.5 ГиБ за прогон. За всё время счётчиков вытеснено 66 727 записей, 50.6 ГиБ. До go-cache-lru кеш на этой машине дорастал до 66–85 ГБ и забивал диск.

Точнее, в байтах пик выходит за лимит на 0.4–31 МиБ. Вытеснение стартует в фоне после записи, которая перешагнула лимит, и пока оно идёт, успевают лечь ещё несколько объектов. В пересчёте на 30 ГиБ это меньше 0.1 %.

Доля попаданий от вытеснения не просела: в часы с вытеснением она 97.1–98.3 %, за сутки — 98 %. Кеш отдал 775.3 ГиБ при 80.3 ГиБ записанного.

Две строки стоит прочитать отдельно. В objects by last access всё, что осталось, использовалось за последние шесть часов, более старое вытеснено. Сборка ветки, к которой я не прикасался со вчера, начнёт с промахов. Стоит ли это лишних гигабайт на диске, должен ответить совет: на момент снимка у него 12 часов с командами go из 24 нужных. А objects by size подтверждает картину из 0.2.0: 460 объектов от 10 до 100 МиБ занимают 71 % места, и сколько всего поместится под лимит, решают они.

Что не проверено

Совет по размеру ещё ни разу не выдал рекомендацию, и пороги в нём пока не сверены с настоящей историей. Запуск с холодным page cache по-прежнему не замерен.

Релизы go-cache-lru, бинарники для macOS, Linux и Windows. ↩︎
Issue #3, удаление файлов вне блокировки кеша. ↩︎
Issue #12, профиль и замеры записи объектов. ↩︎
Issue #5, stats -v и флаг --version. ↩︎
Issue #14, почасовая статистика и правила совета. ↩︎

Читайте оригинал на странице: go-cache-lru: три версии за день и сутки под лимитом (Denis Evsyukov)

Hermes в телефоне: свой клиент вместо мессенджеров

denis@evsyukov.org (Denis Evsyukov) — Wed, 28 Oct 2026 17:30:00 +0300

Работать с Hermes через мессенджеры неудобно, поэтому я написал для него свой клиент под Android. Сегодня вышла первая сборка, v0.1.0-rc1¹.

Что такое Hermes

Hermes — открытый агент от Nous Research под лицензией MIT². Он работает на сервере, а не на ноутбуке: модель выбирается любая (OpenRouter, OpenAI, свой endpoint и другие), инструменты выполняются в выбранном окружении — локально, в Docker, по SSH. У агента есть память, навыки, которые он сам создаёт и правит, поиск по прошлым сессиям, планировщик cron и подключение MCP-серверов.

С агентом можно говорить из терминала (hermes), а можно запустить шлюз (hermes gateway) и писать ему из мессенджеров. Список каналов большой: Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost, Email, SMS, Microsoft Teams и ещё десяток платформ³. Шлюз — один процесс: он держит подключения ко всем каналам, ведёт сессии по каждому чату, запускает задачи cron и доставляет их результаты в нужный канал.

Третий способ — веб-панель hermes dashboard. В ней есть чат, а ещё настройки: модель, config.yaml, секреты, задачи cron, навыки, каналы, журналы.

У меня Hermes крутится в контейнере на домашнем сервере, каналов два: бот в Telegram и бот на моём Matrix-сервере. Память агенту даёт memcue, о ней я писал вчера.

Чем неудобны мессенджеры

Неудобства сводятся к двум вещам: отдельный разговор трудно начать и потом трудно найти.

Треды. Каждой задаче нужна своя сессия, иначе контексты разных разговоров смешиваются. В личке с ботом мессенджер даёт для этого треды, но их надо создавать руками. В Telegram это темы в личке: режим включается командой /topic, а новая тема создаётся кнопкой «+»⁴. Эта схема у меня ещё и ломалась: мобильный клиент иногда присылает первое сообщение новой темы без номера темы, и ответ уходит в общий чат. Разбор этой истории — в отдельном посте. В Matrix Hermes по умолчанию не заводит треды в личке, их включает отдельная настройка, либо тред приходится начинать самому⁵.

Поиск. Через неделю нужно вернуться к разговору, а где он был? В Telegram или в Matrix, в какой теме или треде? Поиск мессенджера находит сообщение, но про сессии Hermes ничего не знает и ищет только в своём канале. Команда /sessions search фильтрует сессии лишь по названию или идентификатору³, а содержимое разговоров ей не видно.

Hermes for Android

Приложение — клиент для hermes dashboard, проверенное на Hermes v0.22.5⁶. Сервер ставить отдельно не нужно: приложение пользуется тем же API, что и веб-панель. Код на Kotlin и Jetpack Compose, лицензия MIT.

Чат

Чат устроен как в приложении ChatGPT. Список чатов — в боковой панели. Каждый чат — отдельная сессия, и новый открывается кнопкой с карандашом или если потянуть ленту вверх за последнее сообщение. Создавать тред руками больше не нужно. Ответ приходит потоком через WebSocket панели: Markdown, рассуждения модели над ответом, а вызовы инструментов свёрнуты в одну строку, которую можно раскрыть. Код в ответе копируется одним нажатием. На вопросы агента и запросы на подтверждение отвечают кнопками на панели, которая выезжает снизу чата.

В боковой панели чаты сгруппированы по дате и по источнику: свои, из Telegram, из Matrix. Закреплённые чаты сверху, архив и запуски cron — в отдельных разделах. Поиск идёт по полнотекстовому индексу на сервере, то есть по тексту разговоров, и находит в том числе то, что писалось из Telegram и Matrix.

Вложения: фото, камера, любой файл. Картинки, PDF, Markdown, текст и код, аудио и видео открываются внутри приложения, в том числе файлы, которые прислал сам агент. Диктовка отправляется в тот провайдер распознавания речи, который настроен в Hermes.

Работа в фоне и уведомления

Ход агента не обрывается, если свернуть приложение: сокет держит foreground-сервис, а ответ приходит уведомлением. На запрос подтверждения можно ответить прямо из уведомления.

Чтобы узнавать о готовых ответах без постоянного соединения, в репозитории лежит плагин hermes-push для сервера. Он отправляет Web Push после каждого хода в приложении, в Telegram, в Matrix или в cron. Доставка идёт через UnifiedPush, например через ntfy. Сообщение шифруется ключами телефона (RFC 8291), так что сервер push видит только шифротекст. Без плагина приложение проверяет новости периодически, не чаще раза в 15 минут, или держит постоянное соединение, если его включить: своего push у панели нет.

Управление сервером

Раздел сервера показывает состояние и позволяет менять то, ради чего раньше открывался SSH: шлюз, модель, config.yaml (по схеме или сырым YAML), секреты .env, задачи cron, навыки, наборы инструментов, MCP-серверы и каналы. Здесь же журналы и расход токенов. Всё, что может сломать или удалить что-то на сервере, сначала спрашивает подтверждение.

Соединение

У каждого сервера свой маршрут:

Маршрут	Когда
Напрямую	Телефон видит панель сам: публичный адрес, приложение Tailscale, домашний Wi-Fi
Встроенный Tailscale	Приложение само входит в tailnet через `tsnet`, слот VPN не нужен
SOCKS5, HTTP	Есть прокси, который видит сервер; логин по желанию

Встроенный Tailscale — это узел Tailscale, собранный из Go через gomobile и запущенный внутри процесса приложения. VpnService он не использует, поэтому работает рядом с любым другим VPN. Узлу нужен адрес control-сервера Tailscale или Headscale и, по желанию, pre-auth ключ; без ключа приложение покажет ссылку для входа. Журналы узла остаются на телефоне.

Сервер можно добавить по ссылке, чтобы не набирать ключ на телефоне:

org.evsyukov.hermes://add-server?url=hermes.example.org&route=tailscale&control=https://hs.example.org&key=<pre-auth key>

Вход идёт через поток native_pkce панели. Если сервер доступен напрямую, вход открывается в Custom Tab, и там работают passkey. Если сервер за прокси или во встроенном tailnet, страница входа открывается во WebView, чей трафик идёт тем же маршрутом.

Интерфейс и язык

Интерфейс на английском с русским переводом. На Android 13 и новее язык приложения можно выбрать отдельно от системного.

Ограничения и статус

Это первая сборка, и пока выходят только release candidate. Приложение совсем новое, и проверено оно пока на одном сервере — моём. Известные ограничения перечислены в README:

без плагина hermes-push новости приходят с задержкой или требуют постоянного соединения;
на обычном hermes dashboard REST-методы сессий не трогают сессии, созданные в процессе панели. Поэтому переименование, архив и удаление идут через сокет, а закрепить такой чат может не получиться: метода для этого в сокете нет;
режим панели со шлюзом (session_authority) поддержан только для основных вызовов.

APK подписан, собран для arm64 и требует Android 12 или новее. Скачать можно на странице релизов¹.

Попробуйте

Если вы держите Hermes у себя и пишете ему с телефона, поставьте приложение и скажите, что не так. Что неудобно, чего не хватает, на каком сервере и маршруте что-то сломалось — всё это лучше всего оставлять в issue в juev/hermes. Пожелания по функциям туда же: приложение только начинается, и сейчас самое время решить, каким оно будет.

Hermes 0.1.0-rc1, pre-release, файл hermes-0.1.0-rc1.apk. ↩︎ ↩︎
NousResearch/hermes-agent, README и документация. ↩︎
Messaging Gateway, список платформ и команд внутри чата, в том числе /sessions, /resume, /approve, /deny. ↩︎ ↩︎
Telegram, раздел про темы в личке и режим /topic. ↩︎
Matrix: треды в личке включают MATRIX_DM_AUTO_THREAD или MATRIX_DM_MENTION_THREADS, по умолчанию обе выключены. ↩︎
juev/hermes, README. ↩︎

Читайте оригинал на странице: Hermes в телефоне: свой клиент вместо мессенджеров (Denis Evsyukov)

go-cache-lru: кеш сборки Go с ограничением по размеру

denis@evsyukov.org (Denis Evsyukov) — Tue, 27 Oct 2026 17:45:00 +0300

go-cache-lru — реализация GOCACHEPROG, которая держит кеш сборки Go в заданном размере¹. Один демон на каталог кеша обслуживает все команды go, а когда кеш перерастает лимит, удаляет записи, к которым дольше всего не обращались. Есть второй уровень хранения: каталог на сетевом диске или S3-совместимое хранилище. Сегодня вышла версия 0.1.0². Ниже — откуда взялась задача, почему первая версия индекса жила в файлах и почему вторая живёт в SQLite.

Проблема

Я работаю с git worktree: каждая задача живёт в своей копии репозитория, параллельно их бывает несколько, и в каждой постоянно идут сборки и тесты. На ноутбуке это быстро съедает диск. 14 октября кеш сборки дорос до 85 ГБ за пять дней. 20 октября на диске в 460 ГБ кеш занимал 66 ГБ, свободного места оставалось 4.7 ГБ, и make test падал на линковке:

ld: write() failed, errno=28 (No space left on device)

go clean -cache вернул 78 ГБ свободного места, но через несколько дней картина повторяется.

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

Попытка с `-trimpath`

Первым подозреваемым был путь к исходникам. Без -trimpath абсолютный путь к пакету входит в ключ кеша, поэтому каждый worktree собирает свою копию всего. Я замерил это на рабочем репозитории: вторая копия добавляла в кеш 721 МБ, с флагом — 3 МБ. 14 октября GOFLAGS=-trimpath попал в мой конфиг окружения.

Копии между worktree флаг действительно убрал. Но через шесть дней кеш снова занимал 66 ГБ: рост остался, просто медленнее. В ключ входят не только пути. Разные флаги сборки дают разные записи: на том же репозитории холодный кеш после сборки и тестов занимал 1 383 МБ без -race и 2 263 МБ, когда -race включён только в тестах. Каждая новая ветка, каждое изменение зависимостей и каждый прогон с другими флагами добавляют новые записи, а старые живут свои пять дней. -trimpath уменьшает объём, но не ограничивает его.

GOCACHEPROG

С Go 1.24 команде go можно подставить внешнюю программу вместо встроенного кеша: переменная GOCACHEPROG указывает на бинарник, go запускает его и общается с ним по stdin/stdout простым JSON-протоколом³. Программа отвечает на get и put и возвращает путь к файлу на диске, откуда go прочтёт объект.

Готовые реализации уже есть, я посмотрел четыре: tailscale/go-cache-plugin, platacard/cacheprog, richardartoul/gobuildcache и bradfitz/go-tool-cache⁴. Все они про общий удалённый кеш для CI, где каталог живёт одну задачу. Ни одна не ограничивает локальный диск. В README platacard/cacheprog прямо сказано, что сборки мусора на диске нет, в README gobuildcache — что нет никакой автоматической чистки ни локального, ни удалённого кеша. Мне нужно обратное: долгоживущий локальный кеш с жёстким лимитом. Так появился go-cache-lru.

Как устроено

go build ──stdin/stdout──▶ go-cache-lru ──unix socket──┐
go test ──stdin/stdout──▶ go-cache-lru ──unix socket──┼──▶ daemon ──▶ local dir
go vet ──stdin/stdout──▶ go-cache-lru ──unix socket──┘ │ (LRU, pins)
 └────▶ remote (optional)

Каждая команда go запускает свой экземпляр go-cache-lru, но этот процесс только пересылает байты демону через unix-сокет. Первая команда запускает демон, остальные подключаются к нему, в том числе параллельные сборки из разных worktree. Один демон на каталог гарантирует flock на файле блокировки. Блокировка умирает вместе с процессом, поэтому после падения следующий запуск не застревает.

Что делает демон:

Держит лимит. Выше --max-size (по умолчанию 30 ГиБ) он удаляет записи, к которым дольше всего не обращались, пока кеш не сожмётся до --target-size (25 ГиБ). Удаление идёт в фоне, пачками по 256 записей.
Не удаляет файлы в работе. Протокол требует, чтобы возвращённый файл существовал, пока команда go не закроет сессию. Поэтому каждый выданный объект закреплён до конца сессии, и вытеснение его пропускает.
Хранит объект один раз. Файл называется по хешу содержимого, и одинаковые результаты разных действий делят один файл. Перед записью демон проверяет, что тело совпадает с SHA-256 из имени.
Понимает go clean -cache. Эта команда GOCACHEPROG не запускает, а просто удаляет подкаталоги GOCACHE. Демон держит в одном из них файл-метку и проверяет его раз в две секунды. Пропала метка — значит, была чистка, и демон приводит индекс в порядок.
Завершается аккуратно. По SIGTERM или go-cache-lru stop он перестаёт принимать подключения, ждёт запущенные команды go (по умолчанию минуту), дописывает очередь загрузок и сохраняет статистику.

Удалённое хранилище — второй уровень за локальным диском. Команда go читает объекты только из локальных файлов, поэтому диск всегда основной. При промахе демон спрашивает удалённое хранилище (таймаут 10 секунд) и копирует объект на диск, а после локальной записи загружает объект в фоне. Поддерживаются file:// для каталога, например сетевой шары, и s3:// для AWS S3, Cloudflare R2, MinIO и других S3-совместимых сервисов. Новый драйвер реализует интерфейс из трёх методов (Get, Put, Close) и регистрирует свою схему URL.

Первый индекс: файлы

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

Сначала я выбрал файлы: на каждую запись индекса отдельный маленький файл, а время последнего обращения — его mtime. Доводы были такие. Каждая запись появляется одним атомарным rename, и каталог всегда согласован сам с собой. База данных дала бы два источника правды: go clean -cache удаляет файлы, но не строки, а падение между rename и коммитом оставляет файл без строки или строку без файла. Пишет только демон, так что многопроцессные блокировки SQLite не нужны. И SQLite в Go — это либо cgo, либо заметно более тяжёлый бинарник.

Цена — время запуска: при старте демон читает все записи индекса. Чтобы понять масштаб, я написал тест TestOpenScale, который генерирует синтетический кеш и замеряет открытие. Размер взял по первой реальной статистике: 177.9 МиБ в 875 объектах, около 200 КиБ на объект и две записи индекса на объект. Полный кеш в 30 ГиБ — это примерно 150 000 объектов и 300 000 записей индекса, всего 450 000 файлов.

На Mac с Apple Silicon (12 ядер, APFS) открытие такого кеша с прогретым page cache заняло от 6.6 до 15.4 секунды за шесть прогонов. По профилю CPU 97 % времени уходило в системные вызовы, 84 % — в чтение записей индекса по одной: open, read, close и stat на каждый файл. Разброс шёл за нагрузкой на машину. Демон открывает кеш до того, как начинает слушать сокет, поэтому после перезагрузки или stop первая команда go ждала всё это время. Холодный page cache сразу после загрузки я не замерял: для purge нужен root, и там будет медленнее.

Второй индекс: SQLite

После этого замера индекс переехал в SQLite. Драйвер — modernc.org/sqlite на чистом Go, без cgo. В базе одна строка на действие: идентификатор объекта, размер, время записи и время последнего обращения.

Чтобы кеш не ждал базу, горячий путь не изменился. get и put работают с индексом в памяти под одним мьютексом. Изменения встают в очередь, а фоновая горутина раз в 100 мс пишет их одной транзакцией. При завершении демон дописывает остаток очереди.

Расхождение базы и файлов никуда не делось, его пришлось обрабатывать явно. go clean -cache удаляет файлы, а падение теряет до 100 мс изменений из очереди. Поэтому при каждом старте и после каждой обнаруженной go clean -cache демон сверяет одно с другим. Он перечисляет файлы объектов по именам через ReadDir, не открывая их и не вызывая stat. Строки без объекта удаляются, объекты без строки тоже. Падение стоит не больше последних 100 мс записей в кеш, но согласованность не теряется.

Замер на той же машине, тот же синтетический кеш на 300 000 записей и параллельный бенчмарк пакета кеша (12 горутин, объекты по 4 КиБ, три прогона по 3 секунды):

	Индекс в файлах	Индекс в SQLite
Открытие, прогретый page cache	6.6–15.4 с за 6 прогонов	0.55–0.57 с за 9 прогонов
Put	251–265 мкс	110–117 мкс
Get, попадание	4.5–4.9 мкс	1.43–1.47 мкс
Память под индекс	около 150 МиБ	около 100 МиБ
Индекс на диске	300 000 файлов	`index.db` на 54 МБ
Размер бинарника	11.6 МиБ	17.4 МиБ

Запуск стал быстрее в 12–28 раз и перестал зависеть от нагрузки на машину. Горячий путь тоже ускорился: put больше не пишет и не переименовывает файл индекса под блокировкой, а get не обновляет mtime файла. Платой стали 5.8 МиБ бинарника и требование Go 1.26 для сборки из исходников — его просит драйвер SQLite. Самой команде go, которая пользуется кешем, достаточно 1.24.

Старый индекс в файлах импортируется в базу при первом запуске. На кеше в 300 000 записей импорт один раз занял 42 секунды. Если перед переходом выполнить go clean -cache, импортировать нечего.

Вся история от кодека протокола до релиза уложилась в один день: 15 коммитов 27 октября, с 16:00 до 17:40. Замер с индексом в файлах я записал в README в 17:01 вместе с объяснением, почему не SQLite. Через 13 минут индекс уже был в SQLite.

Как подключить

Готовые бинарники для macOS и Linux (amd64, arm64) лежат на странице релизов. Можно собрать из исходников:

go install github.com/juev/go-cache-lru/cmd/go-cache-lru@latest

Дальше указать бинарник в GOCACHEPROG. Флаги идут в ту же переменную:

export GOCACHEPROG="$HOME/go/bin/go-cache-lru \
 --dir=$HOME/.cache/go-lru \
 --max-size=30GiB \
 --target-size=25GiB"

То же для fish:

set -gx GOCACHEPROG "$HOME/go/bin/go-cache-lru --dir=$HOME/.cache/go-lru --max-size=30GiB --target-size=25GiB"

GOFLAGS=-trimpath стоит оставить: без него каждый worktree по-прежнему заполняет кеш своими копиями, и до лимита кеш дойдёт быстрее.

Отдельный каталог через --dir лучше, чем GOCACHE. Команда go всё равно открывает GOCACHE для корпуса фаззинга и отметки устаревания тестового кеша, и остатки её собственного кеша там не смешаются с файлами go-cache-lru. Перед переходом эти остатки стоит один раз удалить через go clean -cache.

Каждый флаг можно задать и переменной окружения: GOCACHELRU_DIR, GOCACHELRU_MAX_SIZE, GOCACHELRU_REMOTE и так далее. Флаг важнее переменной. Удалённое хранилище подключается одним флагом:

--remote=file:///Volumes/share/go-cache
--remote='s3://my-bucket/go-cache?region=eu-central-1'
--remote='s3://my-bucket/go-cache?endpoint=<account-id>.r2.cloudflarestorage.com&region=auto'

Ключи S3 берутся из AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY, из файла учётных данных или из метаданных инстанса. Удалённые объекты go-cache-lru никогда не удаляет, для этого нужно правило жизненного цикла бакета.

Две оговорки. Демон запоминает лимиты, с которыми запущен, поэтому после их изменения нужен go-cache-lru stop: следующая команда go поднимет демон с новыми значениями. То же после обновления бинарника. И программы, запущенные не из шелла, например IDE из Dock, переменную не видят и пользуются встроенным кешем.

Как следить

Управляющим командам нужен тот же --dir, что и в GOCACHEPROG. Главная из них — stats. Так выглядит мой кеш через час после перехода:

$ go-cache-lru --dir=$HOME/.cache/go-lru stats
daemon pid 12299, version v0.0.0-20261027142116-62b694c9a6b6 62b694c9a6b6, up 25m49s, 0 active sessions
directory ~/.cache/go-lru
size 4.4 GiB of 30.0 GiB (target 25.0 GiB), 14.7%
entries 17740 actions, 6020 objects, 0 pinned
counters since 2026-10-27 16:38:51
hits 25955 (73.8%), 5.4 GiB served
misses 9199
puts 22017, 5.1 GiB written
evictions 0 entries, 0 B
cleans 0 explicit, 1 by go clean -cache
sessions 21

Счётчики переживают перезапуск демона. stats -json отдаёт то же для скриптов, stats -reset обнуляет счётчики. Остальные команды:

go-cache-lru --dir=$HOME/.cache/go-lru trim # сжать до --target-size сейчас
go-cache-lru --dir=$HOME/.cache/go-lru clean # удалить всё, что не используется
go-cache-lru --dir=$HOME/.cache/go-lru stop # аккуратно остановить демон
go-cache-lru --dir=$HOME/.cache/go-lru serve # запустить демон на переднем плане

Журнал демона пишется в <dir>/gocacheprog/daemon.log.

Что не проверено

Вытеснение в реальной работе ещё не срабатывало: в статистике выше 4.4 ГиБ из 30 и ноль вытеснений. Его покрывают тесты, в том числе сквозные с настоящей командой go, но на живом кеше лимит я ещё не набрал. Запуск с холодным page cache не замерен. Windows пока не поддерживается.

juev/go-cache-lru, репозиторий с README, где описаны устройство и замеры. ↩︎
go-cache-lru v0.1.0, бинарники для macOS и Linux. ↩︎
cmd/go/internal/cacheprog, описание протокола GOCACHEPROG. ↩︎
tailscale/go-cache-plugin, platacard/cacheprog, richardartoul/gobuildcache, bradfitz/go-tool-cache; README смотрел в октябре 2026. ↩︎

Читайте оригинал на странице: go-cache-lru: кеш сборки Go с ограничением по размеру (Denis Evsyukov)