2 คะแนน โดย GN⁺ 2026-03-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น Wayland compositor ที่ทำให้สามารถ รันแอปพลิเคชัน Linux บน macOS ได้โดยไม่ต้องใช้ VM โดยใช้การเรนเดอร์บน Metal/OpenGL เพื่อผสานเข้ากับสภาพแวดล้อมหน้าต่างของ macOS ได้อย่างเป็นธรรมชาติ
  • ใช้ การสื่อสารโปรโตคอล Wayland โดยตรงผ่าน Unix socket เพื่อลดการสูญเสียประสิทธิภาพให้น้อยที่สุด พร้อมรองรับ การปรับแต่งสำหรับจอ HiDPI และ server-side decoration
  • เขียนด้วย Rust และมอบความหน่วงต่ำกับประสิทธิภาพสูงผ่าน การเรนเดอร์แบบเร่งด้วยฮาร์ดแวร์
  • สามารถใช้ SSH และ waypipe-darwin เพื่อ แสดงแอปจากโฮสต์ Linux เป็นหน้าต่างบน macOS ได้
  • เปิดเผยภายใต้ สัญญาอนุญาต GPLv3 และกำลังพัฒนาโรดแมปที่รวมถึงการขยายแบ็กเอนด์สำหรับ Windows และ Android

ภาพรวม

  • Cocoa-Way คือ Wayland compositor ที่ทำให้สามารถ รันแอปพลิเคชัน Linux บน macOS ได้ราวกับเป็นสภาพแวดล้อมเนทีฟ
  • ผสานเข้ากับเดสก์ท็อป macOS ได้อย่างเป็นธรรมชาติผ่าน การเรนเดอร์ด้วย Metal/OpenGL และรองรับการเชื่อมต่อโปรโตคอล Wayland โดยตรงผ่าน socket โดยไม่ต้องใช้ VM
  • มีฟีเจอร์ การปรับแต่งสำหรับจอ HiDPI, server-side decoration, และ การเรนเดอร์แบบเร่งด้วยฮาร์ดแวร์
  • เขียนด้วย Rust และเผยแพร่ภายใต้ สัญญาอนุญาต GPLv3

ฟีเจอร์หลัก

  • การผสานกับ macOS แบบเนทีฟ: การเรนเดอร์บน Metal/OpenGL ทำงานเข้ากันได้เต็มรูปแบบกับการจัดการหน้าต่างและเอฟเฟ็กต์ภาพของ macOS
  • Zero VM Overhead: ลดการสูญเสียประสิทธิภาพให้น้อยที่สุดด้วย การสื่อสารโปรโตคอล Wayland โดยตรงผ่าน Unix socket โดยไม่ต้องทำ virtualization
  • รองรับ HiDPI: ให้การสเกลและความแม่นยำระดับพิกเซลที่เหมาะกับจอ Retina
  • ยกระดับความสมบูรณ์ของ UI: มีฟีเจอร์ server-side decoration เช่น เงาและตัวบ่งชี้โฟกัส
  • เร่งด้วยฮาร์ดแวร์: ใช้ OpenGL rendering pipeline ที่มีประสิทธิภาพเพื่อให้ได้ความหน่วงต่ำและสมรรถนะสูง

วิธีติดตั้ง

  • ติดตั้งด้วย Homebrew (แนะนำ)

    • brew tap J-x-Z/tap
    • brew install cocoa-way waypipe-darwin
  • ดาวน์โหลดไบนารี

    • ดาวน์โหลดไฟล์ .dmg หรือ .zip ได้จากหน้า GitHub Releases
  • สร้างจากซอร์ส

เริ่มต้นอย่างรวดเร็ว

  • องค์ประกอบที่จำเป็น: ต้องติดตั้ง waypipe-darwin
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • รัน compositor
    cocoa-way
    
  • เชื่อมต่อแอป Linux
    ./run_waypipe.sh ssh user@linux-host firefox
    
  • แสดงแอป Wayland จากโฮสต์ Linux เป็นหน้าต่างบน macOS ผ่าน SSH

สถาปัตยกรรม

  • ฝั่ง macOS มี Cocoa-Way compositor และ waypipe client
  • ฝั่ง Linux VM หรือคอนเทนเนอร์มี waypipe server และ แอป Linux
  • แอป Linux → โปรโตคอล Wayland → waypipe server → SSH/socket → waypipe client → Cocoa-Way → Metal/OpenGL → จอแสดงผล macOS
  • เส้นทางทั้งหมดเป็น การเชื่อมต่อโดยตรงโดยไม่ทำ virtualization จึงให้ความหน่วงต่ำและประสิทธิภาพสูง

การเปรียบเทียบ

โซลูชัน ความหน่วง HiDPI การผสานแบบเนทีฟ ความซับซ้อนในการตั้งค่า
Cocoa-Way ⚡ ต่ำ ✅ รองรับเต็มรูปแบบ ✅ หน้าต่างแบบเนทีฟ 🟢 ง่าย
XQuartz 🐢 สูง ⚠️ รองรับบางส่วน ⚠️ มีลักษณะเฉพาะของ X11 🟡 ปานกลาง
VNC 🐢 สูง ❌ ไม่รองรับ ❌ ใช้ได้เฉพาะเต็มหน้าจอ 🟡 ปานกลาง
VM GUI 🐢 สูง ⚠️ รองรับบางส่วน ❌ หน้าต่างแยกต่างหาก 🔴 ซับซ้อน

โรดแมป

  • ✅ แบ็กเอนด์ macOS (Metal/OpenGL)
  • ✅ การผสานรวมกับ Waypipe
  • ✅ การสเกลแบบ HiDPI
  • 🚧 แบ็กเอนด์ Windows (win-way)
  • 📱 แบ็กเอนด์ Android NDK (อยู่ในแผน)
  • ⏳ รองรับหลายจอภาพ
  • ⏳ การซิงก์คลิปบอร์ด

พื้นหลังการวิจัย

  • เป็นส่วนหนึ่งของโครงการวิจัย “Turbo-Charged Protocol Virtualization” ที่สำรวจ Wayland virtualization ข้ามแพลตฟอร์มแบบ zero-cost โดยอาศัย Rust trait monomorphization และ การแปลงพิกเซลด้วย SIMD

การแก้ปัญหา

  • หากเกิดข้อผิดพลาด SSH ว่า “remote port forwarding failed” สาเหตุอาจมาจากไฟล์ socket ที่ยังค้างอยู่บนโฮสต์ระยะไกล
    • สคริปต์ run_waypipe.sh จะจัดการให้อัตโนมัติด้วยออปชัน -o StreamLocalBindUnlink=yes
    • หากรันเองแบบแมนนวล:
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...
      

การมีส่วนร่วม

  • แนะนำให้ เปิด issue เพื่อหารือก่อน เพิ่มฟีเจอร์หรือเปลี่ยนแปลงใด ๆ
  • ยินดีรับการมีส่วนร่วมผ่าน Pull Request

สัญญาอนุญาต

  • GPL-3.0
  • ลิขสิทธิ์ © 2024–2025 J-x-Z

1 ความคิดเห็น

 
GN⁺ 2026-03-30
ความเห็นจาก Hacker News
  • พูดตามตรงก็สงสัยอยู่อย่างหนึ่ง ว่ามีแอป GUI บน Linuxตัวไหนบ้างที่ไม่มี native build สำหรับ macOS ส่วนใหญ่ก็ใช้ Qt หรือ GTK เลยรองรับหลายแพลตฟอร์ม นึกแอปยอดนิยมที่เป็นข้อยกเว้นไม่ค่อยออก

    • ประเด็นหลักไม่ใช่อันนั้น เครื่องมือนี้เอาไว้สำหรับรันแอปจากโฮสต์ Linux ระยะไกลให้แสดงเป็นหน้าต่างบนเครื่องโลคัล เช่น เปิด VS Code บน Mac แต่เป็นหน้าต่างจากเซิร์ฟเวอร์ระยะไกล หรือเข้าใช้งาน Matlab GUI จากคลัสเตอร์ในห้องแล็บ แบบคล้าย ๆ กันนี้บน X11 ก็ทำได้ด้วย xpra
    • แอปยอดนิยมอาจมีไม่มาก แต่ในวงการออกแบบวงจรรวมมีแอปที่รองรับเฉพาะ Linux อยู่เยอะ เคยลองรันในคอนเทนเนอร์บน Mac แล้วรู้สึกว่า XQuartz แย่มาก ถ้าเปลี่ยนไปใช้ Wayland ก็อาจดีขึ้นมาก บางตัวยังเริ่มมีบิลด์สำหรับ ARM แล้วด้วย เลยอาจได้เห็น native GUI บน Mac ในสักวัน
    • ส่วนตัวสนใจเพราะมีอยู่สองเหตุผล อย่างแรกคืออยากใช้สภาพแวดล้อมพัฒนาสำหรับ Siriร่วมกับระบบจัดการหน้าต่างแบบ tiling แต่ก็ยังผูกติดกับ ecosystem ของ Apple เลยคิดว่าวิธีนี้น่าจะเป็นทางออกที่ดี อย่างที่สองคือมีแอปที่รองรับแค่ Linux อย่าง Iridium Niagara Workbench ทำให้หลังจาก Quartz เลิกซัพพอร์ตแล้วใช้งานลำบากมาก
    • ฉันแค่อยากใช้KDE Plasma เฉย ๆ คิดตรง ๆ ว่าอินเทอร์เฟซของ macOS ไม่ค่อยดีเท่าไร
    • ไม่ได้ใช้แค่รันแอป Linux เท่านั้น แต่ยังใช้สำหรับรันแอปกราฟิกจากเซิร์ฟเวอร์ Linux ระยะไกลบนเครื่องโลคัลได้ด้วย
  • สมบูรณ์แบบเลย ตอนนี้สามารถรันแอป GUI ในคอนเทนเนอร์ได้แล้ว เมื่อก่อนเคยทำอะไรคล้าย ๆ กันด้วย X11 แต่ไม่ค่อยชอบ รู้สึกว่าสถานะของ Apple บนเดสก์ท็อปกำลังอ่อนลงเรื่อย ๆ สุดท้ายเหมือนเราจะเข้าสู่ยุคที่ทุกคนกลายเป็น “นักพัฒนา”

    • แม้จะบอกว่า Apple อ่อนลงในตลาดเดสก์ท็อป แต่จริง ๆ แล้วส่วนแบ่งก็สูงกว่า Linux มาตั้งนานแล้ว คงไม่ได้มีอะไรเปลี่ยนใหญ่โตนัก
    • ฉันอยากเปิดใช้สภาพแวดล้อมคอนเทนเนอร์แบบแยกขาดตามโปรเจกต์ เป้าหมายคือจัดกลุ่มแอปเพื่อความปลอดภัยและช่วยให้มีสมาธิ คล้ายโหมดผสานหน้าต่างของ Parallels
  • โปรเจกต์นี้ดูน่าสงสัยอยู่พอสมควร README เต็มไปด้วยอีโมจิและแทบไม่มีคำอธิบายการทำงาน บอกว่ามี Metal backend แต่ดูเหมือนจริง ๆ จะไม่มี รายการ dependency ก็ดูแปลก ๆ

    • ไม่มีค่าพอจะใช้เลย ไม่ยอมบอกด้วยซ้ำว่าใช้hypervisorอะไร จะเป็น QEMU หรือ Docker ก็ไม่รู้ ตารางก็แปลก — ปกติ VM ควรเป็นอย่างที่ตั้งค่าง่ายที่สุด แต่ที่นี่กลับเขียนตรงกันข้าม โค้ดก็ใช้ OpenGL 3.3 Core ซึ่งเก่าเกินไปมาก เป็นไปได้สูงว่าโค้ดถูกสร้างโดย LLM ช่วงนี้รู้สึกว่า AI code ถูกประเมินค่าสูงเกินจริง ภายนอกดูหรูหราแต่ข้างในไม่มีอะไร ทำให้นึกถึงโปรเจกต์โปรโมต C compiler ที่ Anthropic ทำด้วย Rust ก่อนหน้านี้
  • อยากได้อะไรแบบนี้สำหรับAndroidด้วย termux-x11 เป็นจุดเริ่มต้นที่ดี แต่ถ้า termux รองรับ Wayland หรือถ้า Linux VM บน Android เปิดเผย Wayland socket ได้ สิ่งที่เหลือก็มีแค่ native compositor สำหรับการเรนเดอร์ที่ลื่นไหล

  • ถ้า macOS บูตเข้าโหมดDarwin shellแบบไม่มี GUI ได้ ก็คงเป็น UNIX ที่ยอดเยี่ยมมากตัวหนึ่ง โดยมีเดสก์ท็อปอย่าง KDE หรือ COSMIC แล้ววาง package manager อย่าง brew ทับลงไป น่าเสียดายที่ไม่ได้เป็นแบบนั้น

    • ถ้าเป็นแบบนั้นจริง ก็ไม่ค่อยเห็นเหตุผลว่าทำไมต้องใช้ macOS ถ้าตัดอินเทอร์เฟซออก Darwin ก็แทบไม่ต่างจาก FreeBSD หรือ GNU
    • เคอร์เนลของ Mac ประสิทธิภาพก็แย่กว่า และการจัดการแพ็กเกจก็ด้อยกว่า nix
    • สมัย Mac Intel เคยมี single-user mode แต่ถึงตอนนั้นก็ยังควบคุม framebuffer ไม่ได้อยู่ดี
  • ถ้าทำแบบนี้ได้ ก็สงสัยเหมือนกันว่า Wayland client บน macOS จะสามารถสร้าง EGL surfaceได้หรือไม่

  • หรือว่าจะรันสภาพแวดล้อม Androidด้วย Waydroid ภายใน Orbstack ได้? ตามทฤษฎีแล้วก็น่าจะเป็นไปได้

  • ถ้าปรับ macOS ให้ใช้คีย์ลัดแบบ Windows/Linuxได้ ก็น่าจะอึดอัดน้อยลงเยอะ

    • นั่นเป็นความคิดที่ผิด คีย์ลัดของ macOS ถูกออกแบบมาเหมาะกับการทำงานบนเทอร์มินัล เพราะคีย์ลัดของระบบใช้ปุ่มคนละชุด เลยไม่ชนกับ control code
    • ในการตั้งค่าสามารถสลับปุ่ม cmd กับ ctrl ได้ หรือจะปรับแต่งทั้งหมดด้วย Karabiner-Elements ก็ได้ ตอนแรกฉันก็สับสนเหมือนกัน แต่ใช้แค่อาทิตย์เดียวก็ชินแล้ว ตอนนี้กลับรู้สึกว่าคีย์ลัดของ Windows ใช้ยากกว่าเสียอีก ประวัติของปุ่ม Command ก็อ่านสนุกดี
    • การต้องใช้ ctrl+shift ในเทอร์มินัลนี่แย่มากจริง ๆ ฉันคิดว่าระบบคีย์ลัดของ macOSดีกว่ามาก
    • ส่วนตัวมองว่าการใช้ปุ่ม Super กับคีย์ลัดส่วนใหญ่นั้นดีกว่า บน Windows เอาไว้เปิดเมนู Start อย่างเดียวถือว่าเสียของ
    • ตอนนี้ก็ใช้ Karabiner-Elements แมปปุ่ม cmd, option, control ให้เป็น ctrl, alt, super ตามลำดับอยู่จริง ๆ การตั้งค่าพื้นฐานของ macOS เองก็ทำได้ระดับหนึ่ง แต่ถ้าอยากแยกซ้ายขวาให้ต่างกันก็ต้องใช้ Karabiner ถือว่าตั้งค่าได้ยืดหยุ่นกว่าที่คิดสำหรับผลิตภัณฑ์ของ Apple
  • สงสัยว่าโปรเจกต์นี้จะช่วยกระตุ้นความสนใจในGNUstepได้บ้างหรือเปล่า