ハクソク

世界を動かす技術を、日本語で。

Show HN: Kakehashi – macOSバイナリをLinux ARM上で実行するための実験的ユーザースペース

2026年8月3日原文(github.com)

概要

Kakehashi は、macOS ARM64ユーザ空間バイナリを Linux aarch64 環境でCLI中心に実行するトランスレーションレイヤー。 JITなし でMach-Oバイナリをロードし、libSystemやBSDシステムコールを翻訳。 Docker/ColimaやUTM での動作が確認済み。 7-Zipやcurlなど実際のDarwinバイナリ をLinux上で動作可能。 コスト効率の高いCI 運用や開発用途に最適。

Kakehashi: macOS ARM64 → Linux aarch64 トランスレーションレイヤー概要

  • CLIファースト 設計、JITなしでMach-OバイナリをLinux aarch64上で実行
  • libSystem.B.dylib を独立実装し、BSDシステムコールをLinuxにマッピング
  • 本物のDarwinバイナリ （例：7-Zip 7zz, curl, clang probes, スレッド対応）を実行
  • ライブ実行 ：Linux aarch64（ベアメタル、仮想環境、Colima/Docker）で稼働
  • Dry-load/インスペクト ：任意のホスト（macOS含む）でバイナリのロード・検査

インストール手順

  • Rust 1.88+ と Linux aarch64 が必要
  • インストールコマンド
    • cargo install kakehashi
    • またはローカルチェックアウトから: cargo install --path crates/kh-cli --force
  • bottle環境の初期化: kh bottle ensure
  • ゲストバイナリのインストール: kh install 7zip / kh install curl

ボトル（bottle）構成

  • デフォルトパス: ~/.local/share/kakehashi/bottle/
  • ホスト/ゲストのパス対応
    • /usr/local/bin/7zz（ホスト） → /usr/local/bin/7zz（ゲスト）
    • /Volumes/linux/… → ホストのルートディレクトリをゲストにブリッジ
  • -o/アーカイブパス はkhプロセスのカレントディレクトリ基準で解決

7-Zip（7zz）の利用例

  • バージョン表示: kh run 7zz -- --help
  • アーカイブ作成: kh run 7zz -- a demo.7z README.md
  • アーカイブ検査: kh run 7zz -- t demo.7z
  • 展開: kh run 7zz -- x -o./out demo.7z
  • マルチスレッド圧縮: kh run 7zz -- a -t7z -m0=lzma2 -mx=5 -mmt=4 mt.7z README.md
  • Dockerヘルパースクリプト: ./scripts/docker-7zz.sh

curlの利用例

  • バージョン表示: kh run curl -- --version
  • HTTP GET → ファイル: kh run curl -- -sS -o .tmp/kh-out/body http://example.com/
  • HTTP GET → 標準出力: kh run curl -- -sS http://example.com/ | head -c 80
  • HTTPS GET: kh run curl -- -sS -o .tmp/kh-out/https-body https://example.com/
  • Dockerヘルパースクリプト: ./scripts/docker-curl.sh

パス解決とファイルシステム

  • /Volumes/linux/ 以下がホストFSにブリッジ
    • 例: /Volumes/linux/src/README.md → <repo>/README.md
    • /Volumes/linux/out/demo.7z → <repo>/.tmp/kh-out/demo.7z

パフォーマンス・実測値

  • ネイティブCPU実行、命令レベルエミュレーションなし
  • 主なオーバーヘッドは システムコール境界 で発生
  • Ubuntu aarch64ベアメタルでの例
    • ネイティブLinux 7zz: 約22.5秒
    • Darwin 7zz（kh経由）: 約118秒（約5.2倍）
  • 少ファイル圧縮などでは1.1～1.2倍程度まで縮小
  • CI用途では コスト効率 が高い（Linux aarch64はmacOSの10分の1程度の単価）

制限事項・注意点

  • GUI、codesign/notarization、Xcode UIテストなどは非対応
  • Apple Security.frameworkや本物のmacOSフレームワークは未実装（ソフトスタブで回避）
  • 本プロジェクトは Darling とは無関係
  • プロプライエタリなApple SDKやバイナリの同梱禁止
  • Apache License 2.0（LICENSE.txtとNOTICE参照）

開発・テスト・CI向け利用方法

  • Docker/Colima でのクイックスタート
    • docker build -t kakehashi:dev -f Dockerfile.dev .
    • docker run --rm -v "$PWD":/src -w /src kakehashi:dev \ cargo test --workspace --exclude kh-libsystem
    • smokeテスト一式: ./scripts/docker-smoke.sh
  • ビルド・テスト
    • cargo build -p kakehashi --release
    • cargo test --workspace --exclude kh-libsystem
    • cargo clippy --workspace --exclude kh-libsystem --all-targets -- -D warnings
  • libSystem.B.dylibの更新
    • cargo build -p kh-libsystem --release --target aarch64-apple-darwin
    • ./scripts/stage-libsystem.sh

テストマトリクス

  • 単体テスト: cargo test --workspace --exclude kh-libsystem
  • Docker smokeテスト: ./scripts/docker-smoke.sh
  • フィクスチャテスト: kh run --expect-code … tests/fixtures/…
  • Clangプローブ: kh run --root tests/fixtures/bottle tests/clang-probe/puts_hello
  • 実バイナリテスト: ./scripts/docker-7zz.sh, ./scripts/docker-curl.sh

主要スクリプト一覧

  • stage-libsystem.sh: libSystem.B.dylibビルド＆配置
  • install-linux.sh: kh本体＆bottleセットアップ
  • docker-smoke.sh: Docker内smokeテスト
  • docker-7zz.sh / docker-curl.sh: Darwinバイナリのテスト実行
  • docker-curl-probe.sh: curlのプローブログ生成
  • docker-curl-options.sh: curlフラグ組み合わせテスト
  • docker-git.sh: Apple gitテスト
  • bench-fair-local.sh: ネイティブvs khパフォーマンス比較

今後の展望

  • curlの全機能対応 （POST、プロキシ、HTTP/3、各種スキームなど）
  • Apple Security.frameworkやgit/Xcodeツール群 の対応強化
  • GUIやcodesign等のmacOS固有機能への対応は未定

Kakehashi は、macOS ARM64バイナリをLinux aarch64上でコマンドライン主体に安全・効率的に実行したい開発者・CIユーザー向けの強力なツール。 コスト削減・クロスプラットフォーム検証 に最適な選択肢。

Hackerたちの意見

こんにちはHN、macOSのCLIバイナリをLinux ARMマシンでネイティブに動かす実験的なプロジェクトを始めました。今のところ、以下のプロトタイプが動いています：

  • 7-Zip：8万ファイルのツリーでマルチスレッド圧縮テストをパスしました。現在はネイティブLinux実行より約5.2倍遅いですが、このギャップを縮めるための明確な最適化プランはすでに立てています。
  • curl：200以上のコマンドとオプションが自動化されたDockerテストスクリプトを無事通過しました。
  • Xcode Tools Git：基本的なバージョン管理コマンド（init、add、commit）が動いていますが、100%の安定性はまだ保証されていません。 皆さんの建設的な批評やアーキテクチャのアイデア、フィードバックをいただけると非常にありがたいです！ありがとう！
└

最終的にはLinuxに存在しないバイナリをターゲットにする予定なんですか？どこから始めるつもりですか？

└

いろんなターゲットバージョンをサポートする予定ですか？それに、そのターゲットに似た制限を実装するつもりですか？例えば、古いmacOSでは書き込み可能な/usr/があったけど、新しいのでは手動でやらないと無理ですよね。それと、似たような機能を持つCLIツールも用意する予定ですか？（もしかして、ダーヴィンのソースから移植するかも？）例えば、macOS環境を期待する/bin/bashスクリプトを実行できるのか？「uname -o」から「Darwin」が取得できるのかな。

面白いプロジェクトですね！MacOSアプリケーションの長期的なビジョンは、WINEやProtonのWindowsアプリケーションの成功を考えると実現可能だと思います。Darlingプロジェクトについて知っていますか？ https://github.com/darlinghq/darling ARM64サポートのオープンPRがありますよ https://github.com/darlinghq/darling/pull/1753 力を合わせることはできそうですか？それとも目標があまりにも違いすぎますか？

└

GitHubの「ライセンス」セクションには「このプロジェクトはDarlingから派生したものではありません。」って書いてあるから、彼らはそれを知ってるみたいですね。

└

Wineはゲームからたくさんサポートを受けてるけど、今でも生産性アプリはあんまりサポートされてないことが多いね。

これはずっと待っていたものです。すごく興味を持って見守ります。もしこれが進展したら、yabridgeのようなものが実装されてAUバイナリをLinuxで動かせるようになるのを見たいです。

これが本当にクリーンルームプロジェクトで、ClaudeやあなたからのコードがDarlingプロジェクトに由来していないことをどうやって確認できますか？それ以外は素晴らしいプロジェクトですね。

└

Darlingは別の言語で書かれているので、LLMが直接コードをコピーすることはないと思います。でも、これは主要（唯一？）の先行技術なので、LLMがこれをどうやってやるかを知っているのはDarlingを読んで理解したからだと言えるかもしれません。つまり、Darlingが存在しなければ、最初から原理を理解しなければならなかったかもしれません。ここでそうなったとは言いませんが、面白い思考実験ですね：人気のオープンソースプロジェクトと同じ目標を達成するようにLLMに指示した場合、そのプロジェクトが直面した教訓や落とし穴を利用しつつ、コードをコピーしないようにすることはどうなるのか。実際、LLMのコードは今や人間のコードよりも優れていることが多いので、直接的なコードコピーは逆効果になるでしょう。人間はこういったプロジェクトから常にインスパイアを受けていて、それは盗作とは見なされません。

└

コメントありがとうございます！お察しの通り、開発中にLLMを使いました。AIが関与する場合、「クリーンルーム」デザインの厳密な定義は議論の余地がありますが、これは「ライトグレーなルーム」アプローチだと思っています。ここには直接的なコードの盗用はありません：KakehashiはRustでゼロから書かれていて、DarlingはC/objcで構築されています。さらに、アーキテクチャも根本的に異なります—Darlingはカーネルレベルのエミュレーションに依存していますが、KakehashiはLinux ARM向けの軽量ユーザースペースアプローチに完全に焦点を当てています。私のプロンプトでは、プロプライエタリなコンポーネントの使用を明示的に制限しました。最終的には、コードベースが自分自身を証明しますし、誰でもリポジトリを監査することを歓迎します！改めてありがとうございます！

これはずっと探していたものですが、リポジトリやドキュメントを見てみると、問題は大きくて解決策はまだ初期段階のようです。今後どう進めるのか気になります。見守っていますね。

└

ありがとうございます！

Hacker Newsで議論の続きを見る