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

Cocoa-Way – Linuxアプリをシームレスに実行するためのネイティブmacOS Waylandコンポジタ

概要

Cocoa-Way は、macOS上でLinuxアプリを ネイティブ描画 するためのWaylandコンポジタ VM不要 でUnixソケット経由の高速通信を実現 HiDPI対応サーバーサイド装飾 など洗練されたUI Homebrew やバイナリで簡単インストール Turbo-Charged Protocol Virtualization 研究の一環

Cocoa-Way:LinuxアプリをmacOSでネイティブ動作

  • macOS Metal/OpenGL対応 による高品質な描画とシームレスなデスクトップ統合
  • VM不要、WaylandプロトコルをUnixソケット経由で直接やり取り
  • Retinaディスプレイ最適化、HiDPIスケーリング対応
  • サーバーサイド装飾、影やフォーカスインジケーターによる洗練UI
  • OpenGLハードウェアアクセラレーション で高速描画
  • Homebrew推奨インストール、簡単なコマンドで導入可能
  • バイナリ配布 (.dmg/.zip)やソースビルドにも対応
    • 依存パッケージ:libxkbcommon、pixman、pkg-config
    • GitHubからクローンしてcargo build --releaseでビルド

クイックスタート

  • 必須:waypipe-darwinのインストール
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • コンポジタ起動 :cocoa-way
  • Linuxアプリ接続 :./run_waypipe.sh ssh user@linux-host firefox

アーキテクチャ

  • macOS側
    • Cocoa-Way(Waylandコンポジタ)
    • waypipeクライアント
  • Linux側(VM/Container)
    • waypipeサーバー
    • Linuxアプリ(Firefoxなど)
  • 通信経路
    • Linuxアプリ⇔Waylandプロトコル⇔waypipeサーバー⇔SSH/Socket⇔waypipeクライアント⇔Waylandプロトコル⇔Cocoa-Way⇔Metal/OpenGL⇔macOSディスプレイ

他方式との比較

| ソリューション | レイテンシ | HiDPI | ネイティブ統合 | セットアップ難易度 | |----------------|----------|-------|----------------|------------------| | Cocoa-Way | 低 | 対応 | ネイティブウィンドウ | 簡単 | | XQuartz | 高 | 部分 | X11固有の問題 | 中程度 | | VNC | 高 | 非対応| フルスクリーンのみ | 中程度 | | VM GUI | 高 | 部分 | 別ウィンドウ | 複雑 |

今後のロードマップ

  • macOSバックエンド(Metal/OpenGL)強化
  • waypipe統合
  • HiDPIスケーリング最適化
  • Windowsバックエンド(win-way)開発中
  • Android NDKバックエンド(計画中)
  • マルチモニター対応
  • クリップボード同期

研究背景

  • Turbo-Charged Protocol Virtualization プロジェクトの一部
    • Rustトレイトモノモルフィゼーション+SIMD最適化ピクセル変換によるゼロコストWaylandクロスプラットフォーム実現

トラブルシューティング

  • SSHで「remote port forwarding failed」発生時
    • リモート側に古いソケットファイルが残存
    • run_waypipe.shは -o StreamLocalBindUnlink=yes で自動処理
    • 手動実行時も同様のオプション付与で解決

コントリビューション・ライセンス

  • コントリビューション歓迎、大きな変更はIssueで事前相談推奨
  • ライセンス:GPL-3.0 (c)2024-2025 J-x-Z

Hackerたちの意見

すごく興味深いね。これってOrbstack内でWaydroidを使ってAndroidみたいなのを動かせるのかな?そうなったら、実質的にmacOS上でAndroidが動くことになるし、できる気がするんだけど。

無知を許してほしいけど、ネイティブのMacOSビルドがないグラフィカルなLinuxアプリって、みんな何を試してるの?俺の経験では、LinuxのGUIは一般的にQtかGTKで書かれてるから、どっちもマルチプラットフォームだし。存在するのは疑わないけど、人気のある例を思いつくのが難しいな。

Mac OSのダサい(俺の意見だけど)インターフェースの代わりにKDE Plasmaを使いたいんだ。

人気のアプリ?あんまり多くはないかも。でも、集積回路設計の分野ではLinux専用のアプリがたくさんあるよ。いくつかをMacのコンテナで動かそうとしたけど、XQuartzは最悪だった。もしWaylandに移行したら、これらのアプリをMacでうまく動かせるかもしれない。一方で、いくつかはARMビルドが始まってるから(特定のクラウド環境でシミュレーションを動かすために)、いつかネイティブのMac GUIビルドも実現するかもしれないね。

これは必ずしもLinuxだけのものじゃなくて、コンテナ化したいものなんだ。(そしてそれは本質的にLinux上で動いてる。)

このソフトウェアには多くのユースケースがあると思う。例えば、セキュリティや隔離、テストの目的で、Mac上で直接グラフィカルアプリを動かしたくない場合があるよね。このソフトがRDPやCRDよりもレイテンシが低いなら、リモートのグラフィカルワークステーションにアクセスするのにすごく便利だと思う(例えば、データセンターのパワフルなマシンで重いソフトを動かす代わりに、スリムなノートパソコンのリソースを使わずに済む)。

これは私にとって非常に興味深いです。理由は二つあります。1. Siriのタイルウィンドウ管理のために開発環境を整えたいと思っているんですが、良くも悪くも他のすべてのことに関してはAppleのエコシステムにどっぷり浸かっているので、これが本当に良い方法になりそうです(マルチモニターサポートが入ったらさらに良いかも)。2. Linuxビルドをサポートしているアプリがいくつかあるのに、macOSのサポートがないものもあります(例えば、IridiumのNiagara Workbenchアプリはビル管理システムの設定に使われます)。AppleがQuartzのサポートを終了してから、これがちょっと面倒になっています。

単にLinuxアプリを動かすだけでなく、これを使ってLinuxサーバー上でグラフィカルアプリケーションをリモートで実行することもできます。X11フォワーディングみたいな感じですね。

macOSでInkscapeやGIMPをソースからビルドしてみてください。GTKアプリが実際にどれだけ「マルチプラットフォーム」か感じられると思いますか?Macビルドが存在しても、奇妙にスキンされていたり、誰かが古いフォークに対してMacパッチを持っていなければならないので、遅れることが多いです。これは長期的な話です。コンポジターパスはボランティアによるポートの混乱を回避し、Linuxビルドを直接実行するので、あまりメンテナンスされていないニッチなGUIツールや開発アプリにはずっと魅力的です。macOSは言うまでもなく。

EmacsはLinuxのVMでずっと速くて快適に動くよ。クライアントごとにVMを持ってるし。

それは使い方じゃないよ。使い方は、リモートのLinuxホストからアプリをローカルウィンドウとして実行すること。特定のウィンドウのための高性能なVNCって感じかな。例えば、そのマシンでVS Codeを立ち上げて、Macのウィンドウとして表示することができる。もっと現実的な例だと、研究室のクラスターでGUI(例えば、Matlab)にアクセスする人たちがいるよね。x11の最も近いセットアップは、xpraを使ったx11フォワーディングになると思う。

macOSでのネイティブGTKアプリは、VMやParallelsで動かすよりも壊れてることが多い気がする。以前、macOSでGitgを使ってたけど、全然良い体験じゃなかった。

もしMacOSがWin/Linuxのキーボードコマンドを使えるようになったら、MacOSもそんなに耐え難くなくなるのに。

まあ、Linuxを使えば、そんなハックをする必要もないよね…

スーパキーは、ほとんどのキーバインドにおいてWindowsよりずっといいと思います。Windowsではスタートメニューを開くために完全に無駄になってますからね。Linuxではデスクトップ環境に応じていくつかの機能が追加されますが、あまり変わりません。

多くのキーボードコマンドは設定でカスタマイズできて、cmdとctrlキーを入れ替えることもできます。切り替えるときに1、2週間で慣れると思います。私も何年か前にそうしたので、今ではWin/Linuxが混乱していて、Macのコマンドキーの位置がもっとエルゴノミックに感じます。ここにコマンドキーの歴史があります。 https://www.folklore.org/Swedish_Campground.html https://en.wikipedia.org/wiki/Command_key

すごいLな意見だね。macOSのキーボードコマンドはターミナルで作業するのに最高だよ。システムショートカットが別のキーを使うから、コントロールコードと干渉しないし。

毎日MacOS(仕事用)とLinux(自分のPC)を行き来してる者として、Linuxでも逆にできたらいいのにと思う。MacOSのショートカットは直感的で、アプリ間での一貫性も高いからさ。

ごめん、ターミナルでctrl+shiftを使うのは本当に最悪だよ。macOSのキーボードショートカットが最強だね。

いいけど、ウィンドウを「シームレス」にした方が良くない?つまり、別のウィンドウに収めるんじゃなくて。

完璧だ…これでコンテナ内でGUIアプリを動かせるようになります。X11でも似たようなことをしたけど、あまり好きじゃなかったです。少しずつ、Appleはデスクトップの地位を失いつつあります。すべては開発者から始まります。すぐに、誰もが「開発者」になるでしょう。

その使い捨てアカウントへの返信だけど。サンドボックス化したいものや「グループ化」したいもの。プロジェクトに取り組む -> 関連するコンテナを開く。パラレルズのウィンドウ統合モードに似てるね。データやアプリケーションに階層的なビューを持つことの欠点から来てるんだ。目標は:隔離。セキュリティ面でも、集中力の面でも。

すごい。これでmacOSベースのWaylandクライアントがEGLサーフェスを作成できるようになるのかな?

もしmacOSがGUIなしでDarwinシェルに落ちることができたら…KDEやCOSMICみたいなものを使った素敵なUNIXができて、brewをパッケージマネージャーにできるのに…夢みたいだね。

でもなんでMacOSなの?インターフェースを取り除いたら、DarwinとFreeBSDやGNUの違いは何なの?

これがGNUstepに少しでも興味を引き寄せるといいな。

これ、なんかひどくない?READMEが絵文字だらけで、内容もめちゃくちゃだし、実装の詳細もないし、存在しないMetalバックエンドがあるって言ってるし、依存関係のリストも…なんか変だよね。https://github.com/J-x-Z/cocoa-way/tree/main/vendor

これは絶対に使う価値ないね。どのハイパーバイザーを使ってるのかすら書いてないし。QEMU?Docker?Podman?Lima?Colima?それに、このチャートもすごく変だよ: 解決策 | レイテンシ | HiDPI | ネイティブ統合 | セットアップの複雑さ Cocoa-Way | 低 | はい | ネイティブウィンドウ | 簡単 XQuartz | 高 | 部分的 | X11の癖 | 中くらい VNC | 高 | なし | フルスクリーン | 中くらい VM GUI | 高 | 部分的 | 別ウィンドウ | 複雑

標準のVMが一番簡単にセットアップできるのは間違いないし、レイテンシも4つの中で同じはずだよ。結局、ローカルマシンで動いてるVMなんだから。正直、「レイテンシ」って何を意味するのかもよくわからないし、コードも見たけど、OpenGL 3.3 Coreを使ってるって…めっちゃ古いよね。でも、これがLLM生成だって考えると納得できる。だって、ほとんどのトレーニングデータがOpenGL 3.3 Coreのコードだろうし…。全体的にこのプロジェクトはすごく変だよ。自分のスキルに自信が持てるようになった。AIってそんなにすごくないし、ただのハイプだよ。HNのフロントページに載ることもできるし、もしピーター・スタインバーガーなら、OpenAIに10億ドルで買収されることもあるけど、そこまでだよ。コードは全然良くならないし、AnthropicのRustでのCコンパイラの宣伝みたいだね。中身がない。ただの見出しだよ。

こういうの、Android用に欲しいな。termux-x11はいいスタートだけど、termuxがWaylandサポートを得るか、AndroidのネイティブLinux VMからWaylandソケットを公開する方法があれば、あとはネイティブレンダリングコンポジタがあればもっとスムーズになるんだけど。