ИИтог

Shitty: новый терминал на GPU, быстрее конкурентов, но memory-unsafe

инструментыРедакция ИИтогHacker News🔥63Рейтинг ИИтог63Влияние45Новизна60Релевантность65Неожиданность50Участники25Достоверность82
Shitty: новый терминал на GPU, быстрее конкурентов, но memory-unsafe

На Hacker News в разделе Show HN опубликован проект Shitty (исполняемый файл называется st), терминальный эмулятор с рендерингом на GPU, написанный на C++23. Это не разработка с нуля, а хард-форк и полная переработка терминала Zutty, автором которого был Том Силадьи (Tom Szilagyi); Shitty сохраняет историческую атрибуцию оригинала, но меняет архитектуру, рендерер, интеграцию с платформой, тестирование и весь остальной код проекта.

Отрисовка идёт нативными GPU-бэкендами, Vulkan на Linux и Metal на macOS, а состояние терминала держится на CPU. В README заявлено, что терминал быстрый, стартует мгновенно и предсказуемо расходует ресурсы; для сравнения скорости все терминалы в тесте были уравнены по настройкам, шрифт Menlo 12pt, ячейка 14×28 пикселей, сетка 80×24, 500 строк истории прокрутки, через GUI прогонялось 100 МБ текста, бралось лучшее время из трёх прогонов. Сами цифры времени или throughput в доступном тексте не приведены, только описание методики измерения; отдельно отмечается, что kitty на тесте со случайными байтами вообще не рисует контент, а реагирует на встроенные управляющие последовательности сменой заголовка окна и звуковыми сигналами.

Ключевая заявленная особенность, более 5000 тестов на совместимость, собранных из более чем десятка чужих наборов (kitty, esctest, vttests xterm, vttest, tack, libvterm, libtsm, alacritty, ghostty, contour, konsole, mosh), которые прогоняются «вчёрную» через реальный PTY. Автор описывает парсер как «неразрушимый»: конечный автомат тотален и фаззится с закоммиченными корпусами, а cat /dev/urandom в проекте считается не поводом для краша, а обычным бенчмарком. При этом сам проект прямо называет себя memory-unsafe уже в подзаголовке репозитория: гарантии безопасности памяти, в отличие от терминалов на Rust, языком не обеспечиваются.

Из прочих особенностей, юникодные графемные кластеры вместо кодпоинтов (эмодзи-последовательности, комбинирующие знаки, широкие CJK-символы), один самодостаточный бинарник без внешнего GUI-тулкита со встроенными шрифтами (терминал стартует даже на машине вообще без установленных шрифтов) и политика безопасности по умолчанию: приложения не могут читать выделение текста или управлять окном хоста, если это явно не разрешено. Список поддерживаемых протоколов широкий, от VT52 до VT5xx и распространённых расширений xterm, включая OSC 52 и OSC 8. Проект переходит с импортированной GPL-кодовой базы на код только под MIT: новый код лицензируется двойной лицензией GPLv3-or-later/MIT, но пока в дереве остаётся GPL-only материал из исходного форка Zutty, распространение собранного продукта пока всё ещё подпадает под GPL.

Из прямо признанных ограничений, Shitty пока не реализует двунаправленный текст (bidi) и протоколы инлайн-графики вроде sixel; часть исторических расширений DEC и xterm сознательно оставлена за бортом.

Ключевые факты

  • Shitty, хард-форк и полная переработка терминала Zutty (автор оригинала, Tom Szilagyi), написан на C++23, рендерит через GPU (Vulkan на Linux, Metal на macOS)
  • Заявлено более 5000 тестов на совместимость, собранных из более чем десятка других терминальных наборов, плюс фаззинг парсера случайными данными
  • Проект прямо называет себя memory-unsafe; при этом не реализует двунаправленный текст и протоколы вроде sixel
  • Лицензия переходит с GPL на MIT-only, но пока распространение сборки подпадает под GPL из-за импортированного кода Zutty
  • Числа замеров скорости (время, throughput) в доступном тексте не раскрыты, описана только методика уравнивания настроек терминалов перед тестом

Почему это важно

Терминальные эмуляторы почти не меняются десятилетиями (xterm и его многочисленные форки), поэтому Shitty, редкий пример полной переработки с нуля под GPU-рендеринг и агрессивное тестирование (5000+ тестов из чужих наборов плюс фаззинг парсера). Это нишевая инженерная история про инфраструктуру для разработчиков, без отношения к ИИ, но показательная как подход: скорость и совместимость через строгое тестирование, а не через маркетинговые заявления.

Кому это важно

Разработчикам и опытным пользователям Linux и macOS, которые проводят в терминале много времени (логи, tmux, большие выводы команд) и готовы мириться с отсутствием гарантий безопасности памяти ради скорости и низкой задержки.

Как это применить

На macOS Shitty ставится через Homebrew-tap (brew install pg83/tap/shitty), бинарник портативный, ничего не слинковано динамически вне системных библиотек. Сборка из исходников требует Clang с поддержкой C++26 для встроенной стандартной библиотеки проекта (системный Clang от Apple её не знает, нужен LLVM из Homebrew), а также Python 3, Ragel 6, glslangValidator, librsvg, pkg-config, utf8proc версии 2.9 и новее, POSIX-потоки и поддержку PTY; на Linux дополнительно нужны FreeType, HarfBuzz, заголовки Wayland, xkbcommon и Vulkan-заголовки с загрузчиком. Есть flake для Nix (nix build, nix run, nix develop). При использовании стоит учитывать переходный статус лицензии: пока в дереве остаётся GPL-only материал, распространение собранного бинарника подчиняется GPL, а не заявленной целевой MIT.

Можно ли доверять

Материал, авторское описание проекта в README, опубликованное как Show HN; независимой проверки заявлений о скорости и надёжности в доступном тексте нет. Конкретные цифры замеров (время, throughput) в источнике не приведены, только методика уравнивания условий теста, а из терминалов для сравнения по имени назван лишь kitty. Число тестов (более 5000) и их происхождение из чужих наборов, тоже утверждение автора, без указания на сторонний аудит. Роль пользователя, опубликовавшего пост на Hacker News (автор проекта, мейнтейнер или просто нашедший его человек), в тексте не указана.

Риски и подводные камни

Проект сам заявляет о себе как memory-unsafe: типичные для C++ классы уязвимостей (переполнения буфера, use-after-free и подобные) остаются на усмотрение авторов и тестов, а не гарантируются языком, как в терминалах на Rust. Не поддерживаются двунаправленный текст и графические протоколы вроде sixel, это может быть блокером для части пользователей. Лицензионный статус переходный: часть кода всё ещё под GPLv3-or-later, и пока это так, распространение собранного продукта юридически остаётся под GPL. Сборка требует нетривиального набора системных зависимостей (Vulkan или Metal, Ragel, glslangValidator и другие), что поднимает порог входа для самостоятельной проверки заявлений автора.