Cocoa-Way – Ein Wayland-Compositor, der Linux-Apps nativ auf macOS ausführt

 (github.com/J-x-Z)
2 Punkte von GN⁺ 2026-03-30 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Wayland-Compositor, der es ermöglicht, Linux-Anwendungen auf macOS ohne virtuelle Maschine auszuführen, und sich dank Metal/OpenGL-basiertem Rendering nahtlos in die macOS-Fensterumgebung integriert
  • Direkte Wayland-Protokoll-Kommunikation über Unix-Sockets minimiert Performance-Verluste; unterstützt werden außerdem HiDPI-Display-Optimierung und serverseitige Dekorationen
  • In Rust geschrieben und mit hardwarebeschleunigtem Rendering für geringe Latenz und hohe Effizienz
  • Mit SSH und waypipe-darwin lassen sich Apps eines Linux-Hosts als macOS-Fenster anzeigen
  • Unter der GPLv3-Lizenz veröffentlicht; eine Roadmap mit Erweiterungen für Windows- und Android-Backends ist in Arbeit

Überblick

  • Cocoa-Way ist ein Wayland-Compositor, der Linux-Anwendungen auf macOS wie in einer nativen Umgebung ausführen kann
  • Durch Metal/OpenGL-Rendering fügt er sich natürlich in den macOS-Desktop ein und unterstützt direkte Wayland-Protokollverbindungen über Sockets ohne virtuelle Maschine
  • Enthält Funktionen wie HiDPI-Display-Optimierung, serverseitige Dekorationen und hardwarebeschleunigtes Rendering
  • Wurde in Rust geschrieben und wird unter der GPLv3-Lizenz verteilt

Hauptfunktionen

  • Native macOS-Integration: Metal/OpenGL-basiertes Rendering sorgt für vollständige Kompatibilität mit macOS-Fensterverwaltung und visuellen Effekten
  • Zero VM Overhead: Minimale Performance-Verluste durch direkte Wayland-Protokoll-Kommunikation über Unix-Sockets ohne Virtualisierung
  • HiDPI-Unterstützung: Skalierung und Pixelgenauigkeit für Retina-Displays
  • Höhere UI-Qualität: Enthält serverseitige Dekorationen wie Schatten und Fokusindikatoren
  • Hardwarebeschleunigung: Eine effiziente OpenGL-Rendering-Pipeline ermöglicht geringe Latenz und hohe Leistung

Installation

  • Installation über Homebrew (empfohlen)

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

  • Binärdatei herunterladen

    • Auf der GitHub-Releases-Seite können .dmg- oder .zip-Dateien heruntergeladen werden

  • Aus dem Quellcode bauen

Schnellstart

  • Erforderliche Komponente: waypipe-darwin muss installiert sein
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • Compositor starten 
    cocoa-way
  • Linux-App verbinden 
    ./run_waypipe.sh ssh user@linux-host firefox
  • Zeigt Wayland-Apps des Linux-Hosts über SSH als macOS-Fenster an

Architektur

  • Auf der macOS-Seite befinden sich der Cocoa-Way-Compositor und der waypipe-Client
  • Auf der Linux-VM- oder Container-Seite befinden sich der waypipe-Server und die Linux-App
  • Linux-App → Wayland-Protokoll → waypipe-Server → SSH/Socket → waypipe-Client → Cocoa-Way → Metal/OpenGL → macOS-Display
  • Der gesamte Pfad ist direkt ohne Virtualisierung verbunden und bietet dadurch geringe Latenz und hohe Effizienz

Vergleich

Lösung Latenz HiDPI Native Integration Einrichtungsaufwand
Cocoa-Way ⚡ niedrig ✅ vollständige Unterstützung ✅ native Fenster 🟢 einfach
XQuartz 🐢 hoch ⚠️ teilweise unterstützt ⚠️ X11-spezifische Eigenheiten 🟡 mittel
VNC 🐢 hoch ❌ nicht unterstützt ❌ nur Vollbild 🟡 mittel
VM GUI 🐢 hoch ⚠️ teilweise unterstützt ❌ separates Fenster 🔴 komplex

Roadmap

  • ✅ macOS-Backend (Metal/OpenGL)
  • ✅ Waypipe-Integration
  • ✅ HiDPI-Skalierung
  • 🚧 Windows-Backend (win-way)
  • 📱 Android-NDK-Backend (geplant)
  • ⏳ Multi-Monitor-Unterstützung
  • ⏳ Zwischenablage-Synchronisierung

Forschungshintergrund

  • Teil des Forschungsprojekts „Turbo-Charged Protocol Virtualization“, das Zero-Cost-Cross-Platform-Wayland-Virtualisierung mithilfe von Rust-Trait-Monomorphisierung und SIMD-basierter Pixelkonvertierung untersucht

Problembehebung

  • Wenn der SSH-Fehler „remote port forwarding failed“ auftritt, ist oft eine verbliebene Socket-Datei auf dem Remote-Host die Ursache
    • Das Skript run_waypipe.sh behandelt dies automatisch mit der Option -o StreamLocalBindUnlink=yes
    • Bei manueller Ausführung: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

Beiträge

  • Vor dem Hinzufügen oder Ändern von Funktionen wird empfohlen, zunächst ein Issue zu eröffnen und die Änderung zu diskutieren
  • Beiträge per Pull Request sind willkommen

Lizenz

  • GPL-3.0
  • Copyright © 2024–2025 J-x-Z

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-30
Hacker-News-Kommentare

  • Ehrlich gesagt frage ich mich: Welche Linux-GUI-Apps gibt es eigentlich, die keinen nativen Build für macOS haben? Die meisten basieren auf Qt oder GTK und sind plattformübergreifend, aber mir fällt spontan keine wirklich populäre App ein

    • Darum geht es gar nicht. Das ist dafür gedacht, Apps von einem entfernten Linux-Host als lokale Fenster auszuführen. Zum Beispiel VS Code auf dem Mac als Fenster eines Remote-Servers anzeigen oder auf die Matlab-GUI eines Cluster-Systems im Labor zugreifen. Unter X11 kann man so etwas Ähnliches mit xpra machen
    • Wirklich populäre Apps gibt es nicht viele, aber im Bereich IC-Design gibt es viele Linux-exklusive Anwendungen. Ich habe versucht, sie auf dem Mac in einem Container laufen zu lassen, aber XQuartz war wirklich schlecht. Mit einem Wechsel zu Wayland könnte es deutlich besser werden. Einige bekommen inzwischen auch ARM-Builds, daher könnte es irgendwann sogar native Mac-GUIs geben
    • Ich finde das persönlich aus zwei Gründen interessant. Erstens würde ich gern eine Entwicklungsumgebung für Siri mit einem tiling window manager nutzen, bin aber an das Apple-Ökosystem gebunden, daher scheint so etwas ein brauchbarer Kompromiss zu sein. Zweitens gibt es Apps wie Iridiums Niagara Workbench, die nur unter Linux unterstützt werden, und seit dem Ende der Quartz-Unterstützung war das lästig
    • Ich will einfach nur KDE Plasma nutzen. Ich finde die macOS-Oberfläche ehrlich gesagt nicht besonders gut
    • Das ist nicht nur zum Ausführen von Linux-Apps nützlich, sondern auch dafür, grafische Apps eines entfernten Linux-Servers lokal auszuführen

  • Perfekt. Jetzt kann man GUI-Apps in Containern ausführen. Ich habe früher etwas Ähnliches mit X11 ausprobiert, aber es hat mir nicht gefallen. Es fühlt sich an, als würde Apples Stellung auf dem Desktop immer schwächer werden. Am Ende kommt wohl eine Zeit, in der jeder ein „Entwickler“ ist

    • Man sagt zwar, Apple werde auf dem Desktop schwächer, aber tatsächlich hatte Apple schon immer mehr Marktanteil als Linux. Große Veränderungen wird es da wohl nicht geben
    • Ich möchte pro Projekt isolierte Container-Umgebungen öffnen und nutzen. Das Ziel ist, Apps ähnlich wie im integrierten Fenstermodus von Parallels zu gruppieren, für Sicherheit und bessere Fokussierung

  • Dieses Projekt wirkt etwas dubios. Das README ist voller Emojis und erklärt die Implementierung überhaupt nicht. Es heißt zwar, es gebe ein Metal-Backend, aber in Wirklichkeit scheint es keines zu geben. Auch die Liste der Abhängigkeiten wirkt seltsam

    • Überhaupt nicht die Mühe wert. Es wird nicht einmal offengelegt, welcher Hypervisor verwendet wird. Ob QEMU oder Docker, weiß man nicht. Auch die Tabelle ist seltsam — eigentlich sind VMs am einfachsten einzurichten, hier steht aber das Gegenteil. Der Code verwendet außerdem OpenGL 3.3 Core, also etwas sehr Veraltetes. Wahrscheinlich ist das LLM-generierter Code. Ich finde, AI-Code wird derzeit überschätzt. Er sieht nur oberflächlich beeindruckend aus, hat aber wenig Substanz. Das erinnert mich an das Werbeprojekt von Anthropic für einen in Rust geschriebenen C-Compiler

  • So etwas braucht man auch für Android. termux-x11 ist zwar ein Anfang, aber wenn termux Wayland unterstützen oder die Linux-VM von Android einen Wayland-Socket nach außen reichen könnte, dann bräuchte man nur noch einen nativen Compositor für flüssiges Rendering

  • Es ist schade, dass macOS nicht in einen Darwin-Shell-Modus ohne GUI booten kann. Dann hätte es ein großartiges UNIX sein können, mit Desktop-Umgebungen wie KDE oder COSMIC und dem Paketmanager brew darüber

    • Dann fragt man sich aber, warum man überhaupt macOS verwenden sollte. Ohne die Oberfläche unterscheidet sich Darwin kaum von FreeBSD oder GNU
    • Der Mac-Kernel ist leistungsschwächer und das Paketmanagement ist nix unterlegen
    • Zu Zeiten der Intel-Macs gab es noch einen Single-User-Modus, aber selbst damals war keine Kontrolle über den Framebuffer möglich

  • Falls das möglich ist, frage ich mich, ob ein auf macOS basierender Wayland-Client eine EGL-Surface erzeugen kann

  • Ob man wohl mit Waydroid innerhalb von Orbstack eine Android-Umgebung ausführen kann? Theoretisch scheint das möglich zu sein

  • Wenn man macOS auf Windows-/Linux-Tastenkürzel umstellen könnte, wäre es deutlich weniger frustrierend

    • Das ist die falsche Sichtweise. Die Tastenkürzel von macOS sind für die Terminal-Arbeit optimiert. System-Shortcuts verwenden andere Tasten und kollidieren daher nicht mit control codes
    • In den Einstellungen kann man cmd und ctrl vertauschen oder mit Karabiner-Elements alles vollständig anpassen. Ich war anfangs auch verwirrt, aber nach einer Woche gewöhnt man sich daran. Inzwischen finde ich eher die Windows-Shortcuts unbequem. Auch die Geschichte der Command-Taste ist interessant
    • Dass man im Terminal ctrl+shift verwenden muss, ist wirklich schrecklich. Ich finde das Shortcut-System von macOS viel besser
    • Ich persönlich finde es besser, für die meisten Shortcuts die Super-Taste zu verwenden. Unter Windows ist sie nur für das Startmenü reserviert, was Verschwendung ist
    • Tatsächlich nutze ich Karabiner-Elements, um cmd, option und control jeweils auf ctrl, alt und super zu mappen. Mit den macOS-Standardeinstellungen geht schon einiges, aber wenn man linke und rechte Tasten unterschiedlich belegen will, braucht man Karabiner. Für ein Apple-Produkt ist das überraschend flexibel konfigurierbar

  • Ich frage mich, ob dieses Projekt auch nur ein wenig Interesse an GNUstep wecken kann