Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
сама возможность стабильно гонять Darwin CLI на дешевом Linux arm64.
Если имеется в виду запуск на компьютерах архитектуры ARM, отличающихся от Mac, то большинство специфических маковских программ так работать вряд ли смогут в силу использования специфических возможностей Apple Silicon (GPU, Neural Engine и т.д.) А переносимую программу легче просто перекомпилировать под Linux.
Спасибо за комментарий. Вы правы про перекомпиляцию (смысла в очередном curl, git и 7zip нету конечно), но просто они использовались как стресс тесты, своеобразные вехи. Как бы мне хотелось бы добиться именно уникальных проприетарных бинарников, например для сборки apple приложений. Просто если сразу пойти на такое, будет тяжелее будто. Проще по ступенькам снизу вверх идти. А про GPU, NE вы правы, но я не уверен что в 99% процентах CLI утилит они не понадобятся, кроме может очень редких исключений. Да и GPU в теории можно было-бы сделать - типа moltenvk наоборот, но цель такое делать сейчас не стоит. Еще раз спасибо
Мне довольно сложно представить приложение для Mac, которое не было бы завязано на маковскую аппаратную архитектуру и при этом не существовало бы в версии для Linux в силу возможности перекомпиляции (хотя наоборот – бывает: скажем, ffmpeg умеет работать с Silicon GPU, и это на порядок повышает его производительность).
Какое, например, приложение вы в идеале хотели бы исполнять таким образом? Если это система сборки приложений Apple, то подозреваю, что она не будет работать без подсистемы безопасности Mac.
Также согласен, но опять же вы сами упомянули ненадобность того, что можно самому скомпилировать (тот же ffmpeg). Конечно, в тех случаях, где критически важны аппаратные особенности Apple Silicon GPU, скорость на стороннем железе без нативных блоков будет проседать. Но задача Kakehashi не в том, чтобы прыгнуть выше головы и выдать скорость на уровне натива, а в том, чтобы добиться стабильной работы с терпимой производительностью для CLI-задач. Кроме того, если программа использует GPU на Mac — то в 100% случаев под капотом это Metal, эмуляция которого сейчас в проекте даже не планируется.
Проблемы с криптографией и безопасностью мне тоже не кажутся непреодолимыми. Если Kakehashi некорректно транслирует системные вызовы безопасности — гостевая программа либо откажется идти дальше, либо упадет (как и в случае с любыми другими недописанными функциями).
Тот факт, что я тестирую проект внутри Linux-контейнера на Mac (где физически присутствует Apple Silicon), действительно может скрывать какие-то скрытые зависимости в некоторых ситуациях. Но для отлова таких нюансов как раз и существуют подробное логирование сисколлов, баг-репорты и пул-реквесты.
Тут дело не только в сисколлах, но и в системе команд.
Я правильно понимаю что вы про вещи типа AMX говорите? Если да, то возможно это также обойти, но точно не знаю. Так как я не тащу фреймворки apple, а пишу работоспособные заглушки, то в теории можно такие сигналы перехватывать и обходить. Конечно может немного производительность проседать, но основная цель - работоспособность. Если вы про что-то другое говорите, то уточните пожалуйста.
Настоящая ценность этого проекта будет, если получится завести проприетарные тулчейны сборки под ios прямо внутри стандартных линуксовых раннеров
Буду рад фидбеку и конструктивной критике
Начните со списка программ, которых пока нету под линукс. Небольшой каталог типа wine с зелеными и красными клетками. Комьюнити наполнит.
Для облегчения запуска тестов желательно понизить версию, а не как сейчас: error: cannot install package kakehashi 0.1.7, it requires rustc 1.97 or newer, while the currently active rustc version is 1.92
Сделал. Минимальная версия 1.92 теперь. Clippy ошибок не показывает. Надеюсь ничего не сломается. Спасибо за комментарий
Если прям заморачиваться, то можно попробовать прогнать проект через cargo-msrv.
Мы как-то пытались затащить Darling в пайплайны на CI, так он просто положил в панику хостовую ноду и уронил весь кластер. Так что подход без рута одобряю
Фишка с маппингом памяти один в один красивая, но интересно как будешь обходить конфликты ASLR, если хостовое ядро решит положить что-то свое по нужным адресам)
Спасибо за комментарий! Пока, к счастью, такого не происходило, но если все же произойдет - естественно, придется разбираться.
Тут как с многопоточностью: какое-то время назад у меня hypercall падал бесконечно. Сколько сеансов отладки ни проводил - всё без толку. В какой-то момент я уже даже думал перейти на KVM, но в итоге всё-таки удалось заставить работать ее.
Интересный проект, я думаю что было бы классно попытаться завести AppleClang
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kakehashi: запуск macOS бинарников на Linux ARM. Часть 1: рабочий 7zip, curl и успехи с Apple Git