Cocoa-Way – Kompositor Wayland yang Menjalankan Aplikasi Linux Secara Native di macOS

 (github.com/J-x-Z)
2 poin oleh GN⁺ 23 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Kompositor Wayland yang memungkinkan menjalankan aplikasi Linux tanpa virtual machine di macOS, menggunakan rendering berbasis Metal/OpenGL agar terintegrasi mulus dengan lingkungan jendela macOS
  • Meminimalkan kehilangan performa melalui komunikasi protokol Wayland langsung via Unix socket, serta mendukung optimasi layar HiDPI dan dekorasi sisi server
  • Ditulis dengan Rust dan menawarkan rendering berakselerasi perangkat keras untuk latensi rendah dan efisiensi tinggi
  • Dengan SSH dan waypipe-darwin, aplikasi dari host Linux dapat ditampilkan sebagai jendela macOS
  • Dirilis dengan lisensi GPLv3, dan roadmap pengembangannya mencakup ekspansi backend Windows dan Android

Gambaran umum

  • Cocoa-Way adalah kompositor Wayland yang memungkinkan menjalankan aplikasi Linux di macOS seolah-olah native
  • Terintegrasi alami dengan desktop macOS melalui rendering Metal/OpenGL, serta mendukung koneksi protokol Wayland langsung melalui socket tanpa virtual machine
  • Mencakup optimasi layar HiDPI, dekorasi sisi server, dan rendering berakselerasi perangkat keras
  • Ditulis dengan Rust dan didistribusikan dengan lisensi GPLv3

Fitur utama

  • Integrasi native macOS: Rendering berbasis Metal/OpenGL menjaga kompatibilitas penuh dengan pengelolaan jendela dan efek visual macOS
  • Zero VM Overhead: Meminimalkan kehilangan performa melalui komunikasi protokol Wayland langsung via Unix socket tanpa virtualisasi
  • Dukungan HiDPI: Menyediakan scaling dan presisi piksel yang disesuaikan untuk layar Retina
  • Penyempurnaan UI: Mencakup fitur dekorasi sisi server seperti bayangan dan indikator fokus
  • Akselerasi perangkat keras: Mewujudkan latensi rendah dan performa tinggi dengan pipeline rendering OpenGL yang efisien

Cara instalasi

  • Instalasi Homebrew (disarankan)

    • brew tap J-x-Z/tap
    • brew install cocoa-way waypipe-darwin

  • Unduh biner

    • File .dmg atau .zip dapat diunduh dari halaman GitHub Releases

  • Build dari source

Mulai cepat

  • Komponen wajib: perlu menginstal waypipe-darwin
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • Menjalankan kompositor 
    cocoa-way
  • Menghubungkan aplikasi Linux 
    ./run_waypipe.sh ssh user@linux-host firefox
  • Menampilkan aplikasi Wayland dari host Linux sebagai jendela macOS melalui SSH

Arsitektur

  • Di sisi macOS terdapat kompositor Cocoa-Way dan klien waypipe
  • Di sisi Linux VM atau container terdapat server waypipe dan aplikasi Linux
  • Aplikasi Linux → protokol Wayland → server waypipe → SSH/socket → klien waypipe → Cocoa-Way → Metal/OpenGL → layar macOS
  • Seluruh jalur terhubung langsung tanpa virtualisasi, sehingga memberikan latensi rendah dan efisiensi tinggi

Perbandingan

Solusi Latensi HiDPI Integrasi native Kompleksitas pengaturan
Cocoa-Way ⚡ Rendah ✅ Dukungan penuh ✅ Jendela native 🟢 Mudah
XQuartz 🐢 Tinggi ⚠️ Dukungan parsial ⚠️ Ada kekhasan X11 🟡 Sedang
VNC 🐢 Tinggi ❌ Tidak didukung ❌ Hanya layar penuh 🟡 Sedang
VM GUI 🐢 Tinggi ⚠️ Dukungan parsial ❌ Jendela terpisah 🔴 Rumit

Roadmap

  • ✅ Backend macOS (Metal/OpenGL)
  • ✅ Integrasi Waypipe
  • ✅ Scaling HiDPI
  • 🚧 Backend Windows (win-way)
  • 📱 Backend Android NDK (direncanakan)
  • ⏳ Dukungan multi-monitor
  • ⏳ Sinkronisasi clipboard

Latar belakang riset

  • Bagian dari proyek riset “Turbo-Charged Protocol Virtualization”, yang mengeksplorasi virtualisasi Wayland lintas platform zero-cost dengan memanfaatkan monomorfisasi trait Rust dan konversi piksel berbasis SIMD

Pemecahan masalah

  • Jika muncul error SSH “remote port forwarding failed”, penyebabnya bisa berupa file socket yang tersisa di host remote
    • Skrip run_waypipe.sh menanganinya secara otomatis dengan opsi -o StreamLocalBindUnlink=yes
    • Saat menjalankan manual: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

Kontribusi

  • Disarankan membuka issue dan berdiskusi terlebih dahulu sebelum menambahkan atau mengubah fitur
  • Kontribusi melalui Pull Request sangat diterima

Lisensi

  • GPL-3.0
  • Hak cipta © 2024–2025 J-x-Z

Bacaan terkait

1 komentar

 
GN⁺ 23 hari lalu
Komentar Hacker News

  • Sejujurnya saya penasaran. Saya bertanya-tanya, dari aplikasi GUI Linux, apa yang sebenarnya tidak punya build native untuk macOS. Kebanyakan berbasis Qt atau GTK jadi lintas platform, dan saya tidak langsung terpikir aplikasi populer yang seperti itu

    • Intinya bukan itu. Ini ditujukan untuk menjalankan aplikasi dari host Linux jarak jauh sebagai jendela lokal. Misalnya, membuka VS Code di Mac sebagai jendela dari server jarak jauh, atau mengakses GUI Matlab di klaster lab. Di X11, hal serupa bisa dilakukan dengan xpra
    • Aplikasi populer memang tidak banyak, tetapi di bidang desain sirkuit terpadu ada banyak aplikasi yang khusus Linux. Saya pernah menjalankannya di container pada Mac, tapi XQuartz sangat buruk. Jika beralih ke Wayland, mungkin akan jauh lebih baik. Beberapa juga mulai punya build ARM, jadi suatu hari GUI Mac native mungkin saja memungkinkan
    • Secara pribadi ada dua alasan kenapa ini menarik. Pertama, saya ingin memakai lingkungan pengembangan untuk Siri dengan manajemen jendela tiling, tetapi karena terikat ekosistem Apple, pendekatan seperti ini tampaknya alternatif yang cukup baik. Kedua, ada aplikasi yang hanya mendukung Linux seperti Niagara Workbench dari Iridium, jadi setelah dukungan Quartz dihentikan, ini jadi merepotkan
    • Saya cuma ingin memakai KDE Plasma. Menurut saya antarmuka macOS, terus terang, kurang bagus
    • Ini bukan cuma untuk menjalankan aplikasi Linux, tetapi juga bisa dipakai untuk menjalankan aplikasi grafis dari server Linux jarak jauh secara lokal

  • Sempurna. Sekarang GUI app bisa dijalankan di dalam container. Dulu saya pernah mencoba hal serupa dengan X11 tetapi tidak suka hasilnya. Terasa semakin posisi desktop Apple makin melemah. Pada akhirnya rasanya kita akan masuk ke era ketika semua orang menjadi “developer”

    • Orang bilang Apple melemah di pasar desktop, tetapi sebenarnya sejak dulu pangsa pasarnya tetap lebih tinggi daripada Linux. Sepertinya tidak akan banyak berubah
    • Saya ingin membuka lingkungan container yang terisolasi untuk setiap proyek. Tujuannya mirip mode integrasi jendela di Parallels, yaitu mengelompokkan aplikasi demi keamanan dan fokus

  • Proyek ini agak mencurigakan. README-nya penuh emoji dan tidak ada penjelasan implementasi. Katanya ada backend Metal, tetapi sepertinya sebenarnya tidak ada. Daftar dependensinya juga aneh

    • Sama sekali tidak layak dipakai. Bahkan tidak dijelaskan memakai hypervisor apa. Tidak jelas ini QEMU atau Docker. Tabelnya juga aneh — VM biasanya justru yang paling mudah disetel, tetapi di sini ditulis sebaliknya. Kodenya juga memakai OpenGL 3.3 Core, jadi terasa sangat usang. Kemungkinan besar ini kode buatan LLM. Belakangan saya merasa kode AI terlalu dilebih-lebihkan. Dari luar terlihat rapi, tapi isinya kosong. Ini mengingatkan saya pada proyek promosi compiler C buatan Anthropic yang ditulis dalam Rust

  • Hal seperti ini juga dibutuhkan untuk Android. termux-x11 bisa jadi titik awal, tetapi kalau termux mendukung Wayland atau VM Linux di Android bisa mengekspos soket Wayland, maka yang tersisa hanyalah compositor native untuk rendering yang mulus

  • Kalau saja macOS bisa boot ke mode shell Darwin tanpa GUI, rasanya itu bisa menjadi UNIX yang keren dengan desktop environment seperti KDE atau COSMIC ditambah package manager brew

    • Kalau begitu, jadi tidak jelas mengapa masih perlu memakai macOS. Tanpa antarmukanya, Darwin tidak jauh berbeda dari FreeBSD atau GNU
    • Kernel Mac performanya juga lebih buruk dan pengelolaan paketnya kalah dibanding nix
    • Di era Mac Intel dulu memang ada mode single-user, tetapi bahkan saat itu pun kontrol framebuffer tidak memungkinkan

  • Kalau ini memang mungkin, saya juga penasaran apakah klien Wayland berbasis macOS bisa membuat permukaan EGL

  • Apakah mungkin menjalankan lingkungan Android lewat Waydroid di dalam Orbstack? Secara teori sepertinya memungkinkan

  • Kalau macOS bisa diubah memakai shortcut keyboard Windows/Linux, rasanya akan jauh lebih tidak menjengkelkan

    • Menurut saya itu pemikiran yang keliru. Shortcut macOS dioptimalkan untuk pekerjaan terminal. Shortcut sistem memakai tombol yang berbeda sehingga tidak bentrok dengan control code
    • Di pengaturan, tombol cmd dan ctrl bisa ditukar, atau dikustomisasi penuh dengan Karabiner-Elements. Awalnya saya juga bingung, tetapi dalam seminggu sudah terbiasa. Sekarang malah shortcut Windows terasa tidak nyaman. Sejarah tombol Command juga menarik
    • Harus memakai ctrl+shift di terminal itu benar-benar mengerikan. Menurut saya sistem shortcut macOS jauh lebih baik
    • Secara pribadi saya merasa memakai tombol Super untuk sebagian besar shortcut lebih baik. Di Windows itu terbuang hanya untuk menu Start
    • Saya memang memakai Karabiner-Elements untuk memetakan cmd, option, dan control masing-masing menjadi ctrl, alt, dan super. Dengan pengaturan bawaan macOS pun sebagian bisa dilakukan, tetapi kalau ingin membedakan tombol kiri dan kanan, Karabiner diperlukan. Cukup mengejutkan, untuk produk Apple pengaturannya lumayan fleksibel

  • Saya penasaran apakah proyek ini bisa membangkitkan sedikit saja minat pada GNUstep