Cocoa-Way – Trình tổng hợp Wayland chạy ứng dụng Linux gốc trên macOS

 (github.com/J-x-Z)
2 điểm bởi GN⁺ 24 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là trình tổng hợp Wayland cho phép chạy ứng dụng Linux trên macOS mà không cần máy ảo, sử dụng kết xuất dựa trên Metal/OpenGL để tích hợp tự nhiên với môi trường cửa sổ của macOS
  • Giao tiếp trực tiếp giao thức Wayland qua Unix socket giúp giảm thiểu hao hụt hiệu năng, đồng thời hỗ trợ tối ưu cho màn hình HiDPI và trang trí phía máy chủ
  • Được viết bằng Rust, cung cấp độ trễ thấp và hiệu quả cao thông qua kết xuất tăng tốc phần cứng
  • Có thể dùng SSH và waypipe-darwin để hiển thị ứng dụng từ máy chủ Linux trong các cửa sổ macOS
  • Được phát hành theo giấy phép GPLv3, đồng thời lộ trình phát triển đang tiến hành mở rộng backend cho Windows và Android

Tổng quan

  • Cocoa-Way là trình tổng hợp Wayland cho phép chạy ứng dụng Linux trên macOS như trong môi trường gốc
  • Tích hợp tự nhiên với desktop macOS thông qua kết xuất Metal/OpenGL, đồng thời hỗ trợ kết nối trực tiếp giao thức Wayland qua socket mà không cần máy ảo
  • Bao gồm các tính năng tối ưu cho màn hình HiDPI, trang trí phía máy chủ, và kết xuất tăng tốc phần cứng
  • Được viết bằng Rust và phân phối theo giấy phép GPLv3

Tính năng chính

  • Tích hợp macOS gốc: Kết xuất dựa trên Metal/OpenGL giúp duy trì khả năng tương thích hoàn toàn với quản lý cửa sổ và hiệu ứng hiển thị của macOS
  • Zero VM Overhead: Không cần ảo hóa, giao tiếp trực tiếp giao thức Wayland qua Unix socket giúp giảm thiểu tổn thất hiệu năng
  • Hỗ trợ HiDPI: Cung cấp khả năng scale và độ chính xác điểm ảnh phù hợp với màn hình Retina
  • Hoàn thiện giao diện tốt hơn: Bao gồm các tính năng trang trí phía máy chủ như đổ bóng, chỉ báo focus
  • Tăng tốc phần cứng: Triển khai đường ống kết xuất OpenGL hiệu quả để đạt độ trễ thấp và hiệu năng cao

Cách cài đặt

  • Cài đặt bằng Homebrew (khuyến nghị)

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

  • Tải binary

    • Có thể tải tệp .dmg hoặc .zip từ trang GitHub Releases

  • Build từ mã nguồn

Bắt đầu nhanh

  • Thành phần bắt buộc: Cần cài đặt waypipe-darwin
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • Chạy compositor 
    cocoa-way
  • Kết nối ứng dụng Linux 
    ./run_waypipe.sh ssh user@linux-host firefox
  • Hiển thị ứng dụng Wayland từ máy chủ Linux trong cửa sổ macOS qua SSH

Kiến trúc

  • Phía macOS gồm có compositor Cocoa-Way và client waypipe
  • Phía Linux VM hoặc container gồm có server waypipe và ứng dụng Linux
  • Ứng dụng Linux → giao thức Wayland → server waypipe → SSH/socket → client waypipe → Cocoa-Way → Metal/OpenGL → màn hình macOS
  • Toàn bộ đường đi là kết nối trực tiếp không qua ảo hóa, mang lại độ trễ thấp và hiệu quả cao

So sánh

Giải pháp Độ trễ HiDPI Tích hợp gốc Độ phức tạp cấu hình
Cocoa-Way ⚡ thấp ✅ hỗ trợ đầy đủ ✅ cửa sổ gốc 🟢 dễ
XQuartz 🐢 cao ⚠️ hỗ trợ một phần ⚠️ có đặc thù X11 🟡 trung bình
VNC 🐢 cao ❌ không hỗ trợ ❌ chỉ toàn màn hình 🟡 trung bình
VM GUI 🐢 cao ⚠️ hỗ trợ một phần ❌ cửa sổ riêng 🔴 phức tạp

Lộ trình

  • ✅ Backend macOS (Metal/OpenGL)
  • ✅ Tích hợp Waypipe
  • ✅ Scale HiDPI
  • 🚧 Backend Windows (win-way)
  • 📱 Backend Android NDK (đang lên kế hoạch)
  • ⏳ Hỗ trợ đa màn hình
  • ⏳ Đồng bộ clipboard

Bối cảnh nghiên cứu

  • Là một phần của dự án nghiên cứu “Turbo-Charged Protocol Virtualization”, khám phá ảo hóa Wayland đa nền tảng zero-cost bằng cách tận dụng trait monomorphization của Rust và chuyển đổi pixel dựa trên SIMD

Khắc phục sự cố

  • Nếu gặp lỗi SSH “remote port forwarding failed”, nguyên nhân có thể là tệp socket còn sót lại trên máy từ xa
    • Script run_waypipe.sh sẽ tự động xử lý bằng tùy chọn -o StreamLocalBindUnlink=yes
    • Nếu chạy thủ công: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

Đóng góp

  • Khuyến nghị tạo issue và thảo luận trước khi thêm hoặc thay đổi tính năng
  • Hoan nghênh đóng góp qua Pull Request

Giấy phép

  • GPL-3.0
  • Bản quyền © 2024–2025 J-x-Z

Bài viết liên quan

1 bình luận

 
GN⁺ 24 ngày trước
Ý kiến trên Hacker News

  • Thành thật mà nói tôi có chút thắc mắc. Không biết trong số các ứng dụng GUI Linux, có ứng dụng nào không có bản build native cho macOS không. Đa số đều dựa trên Qt hoặc GTK nên là đa nền tảng, mà tôi không nghĩ ra được ứng dụng phổ biến nào như vậy

    • Mấu chốt không nằm ở đó. Cái này dùng để chạy ứng dụng từ host Linux từ xa dưới dạng cửa sổ cục bộ. Ví dụ, mở VS Code trên máy Mac nhưng cửa sổ thực ra đến từ máy chủ từ xa, hoặc truy cập GUI Matlab trên cụm máy trong phòng lab. Với X11 thì có thể làm tương tự bằng xpra
    • Ứng dụng phổ biến thì không nhiều, nhưng trong lĩnh vực thiết kế mạch tích hợp có khá nhiều ứng dụng chỉ dành cho Linux. Tôi đã thử chạy chúng trong container trên Mac, nhưng XQuartz quá tệ. Nếu chuyển sang Wayland thì có thể sẽ tốt hơn nhiều. Một số ứng dụng thậm chí đã có bản build ARM, nên biết đâu một ngày nào đó cũng sẽ có GUI native trên Mac
    • Cá nhân tôi thấy thú vị vì hai lý do. Thứ nhất, tôi muốn dùng môi trường phát triển cho Siri với kiểu quản lý cửa sổ xếp ô, nhưng lại bị trói trong hệ sinh thái Apple nên cách này có vẻ là một giải pháp thay thế ổn. Thứ hai, có những ứng dụng như Niagara Workbench của Iridium chỉ hỗ trợ Linux, nên từ sau khi Quartz bị ngừng hỗ trợ thì khá bất tiện
    • Tôi chỉ đơn giản là muốn dùng KDE Plasma. Thành thật mà nói tôi thấy giao diện macOS không hay lắm
    • Không chỉ để chạy ứng dụng Linux, mà còn có thể dùng để chạy ứng dụng đồ họa từ máy chủ Linux từ xa trên máy cục bộ

  • Quá hoàn hảo. Giờ thì có thể chạy ứng dụng GUI bên trong container. Trước đây tôi từng thử thứ tương tự với X11 nhưng không thích. Cảm giác như vị thế desktop của Apple đang dần yếu đi. Cuối cùng có lẽ sẽ đến thời mà ai cũng trở thành “developer”

    • Người ta hay nói Apple đang yếu đi trên thị trường desktop, nhưng thật ra từ xưa đến nay họ vẫn có thị phần cao hơn Linux. Có lẽ sẽ không có thay đổi lớn nào đâu
    • Tôi muốn mở các môi trường container cách ly theo từng dự án. Mục tiêu là nhóm ứng dụng lại với nhau để tăng bảo mật và tập trung, kiểu như chế độ tích hợp cửa sổ của Parallels

  • Dự án này có vẻ hơi đáng ngờ. README đầy emoji mà không có giải thích triển khai gì cả. Họ nói có backend Metal nhưng có vẻ thực ra không có. Danh sách phụ thuộc cũng kỳ lạ

    • Hoàn toàn không đáng để dùng. Họ cũng không nói dùng hypervisor nào. Là QEMU hay Docker thì không rõ. Bảng so sánh cũng kỳ — VM vốn mới là thứ dễ cấu hình nhất, nhưng ở đây lại viết ngược lại. Mã nguồn còn dùng OpenGL 3.3 Core nên quá lỗi thời. Rất có thể đây là mã do LLM sinh ra. Dạo này tôi thấy mã do AI tạo ra đang bị đánh giá quá cao. Nhìn thì bóng bẩy nhưng chẳng có thực chất. Nó làm tôi nhớ đến dự án quảng bá compiler C viết bằng Rust mà Anthropic từng đưa ra

  • Cần có thứ như thế này cho Android nữa. termux-x11 có thể là điểm khởi đầu, nhưng nếu termux hỗ trợ Wayland hoặc có thể để Linux VM trên Android lộ ra socket Wayland, thì phần còn lại chỉ là một compositor native để render mượt mà

  • Tôi thấy hơi tiếc là nếu macOS có thể khởi động vào chế độ shell Darwin không GUI, thì nó đã có thể trở thành một UNIX tuyệt vời với môi trường desktop như KDE hoặc COSMIC cùng trình quản lý gói brew

    • Nếu vậy thì tôi lại thấy chẳng có lý do gì để dùng macOS. Bỏ phần giao diện đi thì Darwin đâu khác FreeBSD hay GNU là mấy
    • Kernel của Mac hiệu năng cũng kém, còn quản lý gói thì thua cả nix
    • Thời Mac Intel từng có chế độ single-user, nhưng ngay cả lúc đó cũng không thể điều khiển framebuffer

  • Nếu điều này khả thi, tôi cũng tò mò liệu client Wayland trên macOS có thể tạo EGL surface hay không

  • Liệu có thể dùng Waydroid trong Orbstack để chạy môi trường Android không? Về lý thuyết có vẻ là được

  • Nếu có thể đổi macOS sang phím tắt kiểu Windows/Linux thì chắc sẽ bớt khó chịu hơn nhiều

    • Cách nghĩ đó không đúng đâu. Phím tắt của macOS được tối ưu cho công việc trong terminal. Phím tắt hệ thống dùng các phím khác nên không xung đột với control code
    • Trong phần cài đặt có thể đổi cmd và ctrl cho nhau, hoặc dùng Karabiner-Elements để tùy biến hoàn toàn. Lúc đầu tôi cũng thấy rối, nhưng chỉ một tuần là quen. Giờ thì ngược lại tôi lại thấy phím tắt của Windows bất tiện hơn. Lịch sử của phím Command cũng khá thú vị
    • Việc phải dùng ctrl+shift trong terminal thật sự quá tệ. Tôi nghĩ hệ thống phím tắt của macOS tốt hơn nhiều
    • Cá nhân tôi thấy dùng phím Super cho hầu hết phím tắt sẽ tốt hơn. Trên Windows nó chỉ dành cho menu Start nên quá lãng phí
    • Thực tế tôi đang dùng Karabiner-Elements để map cmd, option, control lần lượt thành ctrl, alt, super. Chỉ với cài đặt mặc định của macOS cũng làm được phần nào, nhưng nếu muốn đổi khác nhau giữa phím trái và phải thì cần Karabiner. Khá bất ngờ là với một sản phẩm của Apple thì thiết lập này linh hoạt hơn tôi tưởng

  • Tôi tò mò không biết dự án này có thể khiến mọi người chú ý hơn dù chỉ một chút đến GNUstep hay không