Kakehashi позволяет запускать бинарники macOS ARM64 на Linux aarch64 без JIT

Разработчик опубликовал на Hacker News (Show HN) проект Kakehashi, экспериментальный слой трансляции в пространстве пользователя, без JIT-компиляции. Он загружает бинарники в формате Mach-O для macOS ARM64, подставляет облегчённую («freestanding») версию библиотеки libSystem и переводит системные вызовы BSD, чтобы гостевые программы для Darwin выполнялись на Linux aarch64. Работоспособность проверена на пробах clang, на архиваторе 7-Zip (утилита 7zz, включая многопоточное сжатие) и на curl; тесты прошли в Docker/Colima и в UTM на Linux aarch64. Установка, командой cargo install kakehashi (или сборкой из исходников через cargo install --path crates/kh-cli), требуется Rust версии 1.88 и выше.
По словам авторов, Kakehashi не эмулирует процессор, гостевой код выполняется нативно на CPU, а издержки возникают на границе системных вызовов (переключение TLS, альтернативный стек, сохранение/восстановление регистров NEON, диспетчеризация в коде на Rust) и растут пропорционально тому, как часто гостевая программа обращается к ядру. В тесте на bare-metal Ubuntu aarch64 (в UTM) авторы архивировали через 7zz дерево примерно из 8 тысяч файлов общим объёмом около 240 МиБ, но итогового числового соотношения скорости для этого конкретного случая в тексте не приводится. Для задач с интенсивным сжатием и малым числом файлов разрыв со скоростью нативного выполнения обычно намного меньше, около 1,1, 1,2 раза; по утверждению авторов, основной разрыв на больших многофайловых архивах вызван обходом путей и издержками на границе системных вызовов, а не ошибками в сжатии LZMA.
Главный сценарий применения, экономика CI. Цель проекта, не сравняться по скорости с нативным macOS, а дать возможность запускать CLI-инструменты Darwin на дешёвых Linux aarch64 раннерах вместо дефицитных и дорогих macOS-раннеров. На GitHub Actions минута стандартного macOS-раннера стоит примерно в 10, 12 раз дороже минуты Linux arm64 ещё до учёта разницы в скорости выполнения задачи. Поэтому, по иллюстративному расчёту авторов, даже если задача под Kakehashi на Linux выполняется в 5 раз медленнее, чем та же работа нативно на macOS-раннере, итоговый счёт всё равно может оказаться ниже: пример, 5 минут по $0,005 ≈ $0,025 против 1 минуты по $0,062 за macOS-раннер. Бесплатные минуты для публичных репозиториев и собственные Linux-раннеры увеличивают эту разницу ещё сильнее, а мощности macOS-раннеров, по наблюдению авторов, чаще стоят в очереди дольше и на GitLab SaaS доступны только в платных тарифах или как бета-функция.
Авторы прямо перечисляют, где преимущество остаётся за настоящим macOS: GUI-приложения, codesign и нотаризация, UI-тесты Xcode, любая нагрузка, которая не сводится к чистому CLI-бинарнику Darwin поверх облегчённой libSystem. Пока не реализованы полный набор функций curl (тела POST-запросов, прокси, сквозной HTTP/3, все схемы), настоящий Apple Security.framework, git и другие инструменты командной строки, GUI и codesign; следующим шагом заявлена поддержка git через команду kh install xcode-tools. Авторы отдельно отмечают, что проект не основан на Darling и не встраивает проприетарные SDK или бинарные блоки Apple; код распространяется под лицензией Apache 2.0.
Ключевые факты
- Kakehashi, экспериментальный слой трансляции в пространстве пользователя: загружает бинарники Mach-O для macOS ARM64, подставляет облегчённую версию libSystem и переводит системные вызовы BSD, чтобы запускать реальные Darwin-программы на Linux aarch64 без JIT-компиляции и без эмулятора инструкций.
- Работоспособность проверена на clang, 7-Zip (7zz, включая многопоточное сжатие) и curl; тесты прошли в Docker/Colima и в UTM на Linux aarch64.
- Главная цель, не догнать по скорости нативный macOS, а запускать CLI-инструменты Darwin на дешёвых Linux aarch64 раннерах CI вместо дефицитных и дорогих macOS-раннеров: минута стандартного macOS-раннера GitHub Actions стоит примерно в 10, 12 раз дороже минуты Linux arm64 ещё до учёта разницы в скорости выполнения.
- По иллюстративному расчёту проекта, задача, которая на Kakehashi выполняется в 5 раз медленнее, чем нативно на macOS, всё равно может обойтись дешевле: 5 минут по $0,005 ≈ $0,025 против 1 минуты по $0,062 на macOS-раннере.
- Проект пока не поддерживает GUI, codesign и нотаризацию, UI-тесты Xcode, полный набор функций curl (POST-запросы, прокси, сквозной HTTP/3, все схемы), настоящий Apple Security.framework и git, git обещают следующим шагом через команду
kh install xcode-tools.
Почему это важно
CI на GitHub Actions и похожих платформах берёт за macOS-раннеры на порядок больше, чем за Linux, а свободных macOS-раннеров банально не хватает, сказываются лицензионные ограничения на виртуализацию macOS и физическая нехватка Mac-железа у облачных провайдеров. Kakehashi предлагает обходной путь для узкого, но частого случая: если задаче нужно только собрать или прогнать CLI-бинарник macOS, а не GUI и не codesign, это можно сделать на обычном Linux ARM-раннере, который стоит в разы дешевле и доступнее. Сам подход, трансляция системных вызовов в пространстве пользователя без JIT и без полной эмуляции инструкций, встречается редко: большинство прослоек совместимости либо эмулируют процессор целиком, либо требуют настоящего macOS-хоста.
Кому это важно
Прежде всего командам, которые собирают или тестируют CLI-инструменты и библиотеки для macOS ARM64 в CI и хотят сократить счета за дефицитные macOS-раннеры GitHub Actions или GitLab SaaS. Пригодится авторам open-source проектов с ограниченным бюджетом на CI, а также разработчикам утилит вроде 7-Zip или curl, которым нужно кросс-платформенное тестирование без покупки или аренды Mac-железа.
Как это применить
Проект ставится командой cargo install kakehashi (или сборкой из исходников через cargo install --path crates/kh-cli); нужен Rust 1.88+ и Linux aarch64, bare-metal, контейнер или UTM. После установки kh bottle ensure разворачивает окружение («bottle»), команды kh install 7zip и kh install curl подкладывают гостевые бинарники macOS в /usr/local/bin внутри bottle, а kh run <программа> -- <аргументы> запускает их напрямую, например, kh run curl -- -sS http://example.com/. Файловая система Linux-хоста доступна гостю через путь /Volumes/linux/…. Для запуска в контейнере без ручной настройки есть готовые обёртки scripts/docker-7zz.sh и scripts/docker-curl.sh.
Можно ли доверять
Код открыт под лицензией Apache 2.0, авторы прямо пишут, что проект не основан на Darling и не встраивает проприетарные SDK или бинарные блоки Apple, гостевая библиотека libSystem собрана из исходников самого проекта. Корректность проверяется не сравнением с нативной скоростью, а тестовыми гейтами: cargo test, smoke-тест и контрольный прогон 7zz с многопоточным сжатием. При этом проект прямо помечен как экспериментальный: часть путей (например, конфигурация OpenSSL, отдельные Apple-фреймворки) закрыта «мягкими заглушками», а не полной реализацией, авторы честно называют это безобидным шумом в логах, а не скрывают.
Риски и подводные камни
Заявленный выигрыш не универсален: на нагрузках с большим числом файлов замедление может быть значительным, в иллюстративном примере до 5 раз, и итоговая экономия зависит от того, сколько именно стоит минута CI-раннера у конкретного провайдера; расчёт с $0,005 и $0,062 за минуту сами авторы называют иллюстративным, а не гарантированным. Для теста на дереве примерно из 8 тысяч файлов и объёмом около 240 МиБ на bare-metal Ubuntu aarch64 в тексте не приведено итогового числового соотношения скорости. Из функциональности пока недоступны GUI, codesign и нотаризация, UI-тесты Xcode, настоящий Apple Security.framework, git и полный набор функций curl (тела POST-запросов, прокси, сквозной HTTP/3, все схемы), для задач, которым нужно что-то из этого списка, Kakehashi не подходит уже сегодня.