Cocoa-Way – compositor Wayland para executar apps Linux nativamente no macOS

 (github.com/J-x-Z)
2 pontos por GN⁺ 2026-03-30 | 1 comentários | Compartilhar no WhatsApp
  • Um compositor Wayland que permite executar aplicativos Linux no macOS sem máquina virtual, usando renderização baseada em Metal/OpenGL para se integrar naturalmente ao ambiente de janelas do macOS
  • Comunicação direta do protocolo Wayland via socket Unix para minimizar perda de desempenho, com suporte a otimização para telas HiDPI e decoração no lado do servidor
  • Escrito em Rust, oferecendo baixa latência e alta eficiência por meio de renderização com aceleração de hardware
  • Com SSH e waypipe-darwin, é possível exibir apps de um host Linux como janelas no macOS
  • Disponível sob licença GPLv3, com um roadmap em andamento que inclui expansão para backends de Windows e Android

Visão geral

  • Cocoa-Way é um compositor Wayland que permite executar aplicativos Linux no macOS como se fossem nativos
  • Integra-se naturalmente ao desktop do macOS por meio de renderização Metal/OpenGL e oferece conexão direta do protocolo Wayland por socket, sem máquina virtual
  • Inclui otimização para telas HiDPI, decoração no lado do servidor e renderização com aceleração de hardware
  • Escrito em Rust e distribuído sob licença GPLv3

Principais recursos

  • Integração nativa com o macOS: renderização baseada em Metal/OpenGL com compatibilidade total com o gerenciamento de janelas e os efeitos visuais do macOS
  • Zero VM Overhead: comunicação direta do protocolo Wayland via socket Unix sem virtualização, minimizando perda de desempenho
  • Suporte a HiDPI: escalonamento e precisão de pixels ajustados para telas Retina
  • UI mais refinada: inclui recursos de decoração no lado do servidor, como sombras e indicadores de foco
  • Aceleração de hardware: pipeline eficiente de renderização OpenGL para baixa latência e alto desempenho

Como instalar

  • Instalação via Homebrew (recomendado)

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

  • Download de binários

    • É possível baixar arquivos .dmg ou .zip na página de Releases do GitHub

  • Build a partir do código-fonte

Início rápido

  • Componente obrigatório: é necessário instalar waypipe-darwin
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • Executar o compositor 
    cocoa-way
  • Conectar um app Linux 
    ./run_waypipe.sh ssh user@linux-host firefox
  • Exibe aplicativos Wayland do host Linux como janelas no macOS via SSH

Arquitetura

  • No lado do macOS, há o compositor Cocoa-Way e o cliente waypipe
  • No lado da VM Linux ou do contêiner, há o servidor waypipe e os apps Linux
  • App Linux → protocolo Wayland → servidor waypipe → SSH/socket → cliente waypipe → Cocoa-Way → Metal/OpenGL → tela do macOS
  • Todo o caminho é conectado diretamente sem virtualização, oferecendo baixa latência e alta eficiência

Comparação

Solução Latência HiDPI Integração nativa Complexidade de configuração
Cocoa-Way ⚡ baixa ✅ suporte completo ✅ janela nativa 🟢 fácil
XQuartz 🐢 alta ⚠️ suporte parcial ⚠️ peculiaridades do X11 🟡 média
VNC 🐢 alta ❌ sem suporte ❌ apenas tela cheia 🟡 média
VM GUI 🐢 alta ⚠️ suporte parcial ❌ janela separada 🔴 complexa

Roadmap

  • ✅ Backend macOS (Metal/OpenGL)
  • ✅ Integração com Waypipe
  • ✅ Escalonamento HiDPI
  • 🚧 Backend Windows (win-way)
  • 📱 Backend Android NDK (planejado)
  • ⏳ Suporte a múltiplos monitores
  • ⏳ Sincronização da área de transferência

Contexto de pesquisa

  • Parte do projeto de pesquisa “Turbo-Charged Protocol Virtualization”, explorando virtualização Wayland multiplataforma com custo zero com uso de monomorfização de traits em Rust e conversão de pixels baseada em SIMD

Solução de problemas

  • Se ocorrer o erro de SSH “remote port forwarding failed”, a causa pode ser um arquivo de socket residual no host remoto
    • O script run_waypipe.sh trata isso automaticamente com a opção -o StreamLocalBindUnlink=yes
    • Em execução manual: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

Contribuição

  • Recomenda-se abrir uma issue e discutir antes de adicionar ou alterar recursos
  • Contribuições via Pull Request são bem-vindas

Licença

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

Leituras relacionadas

1 comentários

 
GN⁺ 2026-03-30
Comentários do Hacker News

  • Sinceramente, tenho uma dúvida. Quais apps GUI de Linux não têm build nativa para macOS? A maioria é baseada em Qt ou GTK e, portanto, multiplataforma, mas não consigo pensar em nenhum app popular de imediato

    • Esse não é o ponto principal. Isso serve para executar apps de um host Linux remoto como janelas locais. Por exemplo, abrir o VS Code no Mac como uma janela de um servidor remoto, ou acessar a GUI do Matlab em um cluster de laboratório. No X11 dá para fazer algo parecido com xpra
    • Talvez não haja muitos apps populares, mas na área de projeto de circuitos integrados há muitos apps exclusivos de Linux. Tentei rodar em contêineres no Mac, mas o XQuartz era muito ruim. Com a migração para Wayland, isso pode melhorar bastante. Alguns já estão ganhando builds para ARM, então talvez um dia também tenham GUI nativa para Mac
    • Pessoalmente, acho isso interessante por dois motivos. Primeiro, quero usar um ambiente de desenvolvimento para Siri com gerenciamento de janelas em mosaico, mas estou preso ao ecossistema da Apple, então isso parece uma alternativa razoável. Segundo, existem apps como o Niagara Workbench da Iridium, que só têm suporte para Linux, e isso ficou inconveniente depois do fim do suporte ao Quartz
    • Eu só quero usar o KDE Plasma. Sinceramente, acho a interface do macOS bem ruim
    • Isso não serve apenas para executar apps Linux, mas também para executar localmente apps gráficos de um servidor Linux remoto

  • Perfeito. Agora finalmente dá para rodar apps com GUI dentro de contêineres. Já tentei algo parecido com X11 antes, mas não gostei. Cada vez mais parece que a presença da Apple no desktop está enfraquecendo. No fim, acho que estamos caminhando para uma era em que todo mundo será “desenvolvedor”

    • Dizem que a Apple está enfraquecendo no mercado de desktop, mas, na prática, ela já tinha participação maior que a do Linux há muito tempo. Não acho que vá haver uma grande mudança
    • Quero abrir ambientes isolados em contêineres para cada projeto. A ideia é agrupar apps por segurança e foco, como no modo de integração de janelas do Parallels

  • Este projeto parece meio suspeito. O README está cheio de emojis e não explica a implementação. Dizem que há um backend Metal, mas aparentemente ele não existe. A lista de dependências também é estranha

    • Não vale a pena usar isso. Nem dizem qual hipervisor está sendo usado. Não dá para saber se é QEMU ou Docker. A tabela também está estranha — VM normalmente é a opção mais fácil de configurar, mas aqui está escrito o contrário. O código também usa OpenGL 3.3 Core, então parece antiquado demais. Há uma boa chance de ser código gerado por LLM. Ultimamente, tenho achado que código de IA está supervalorizado. Parece bonito por fora, mas não entrega substância. Isso me lembra um projeto promocional antigo da Anthropic para um compilador C feito em Rust

  • Precisamos de algo assim também para Android. O termux-x11 já é um começo, mas se o termux passar a oferecer suporte a Wayland, ou se a VM Linux do Android puder expor um socket Wayland, então só faltaria um compositor nativo para renderização fluida

  • Fico pensando como seria se o macOS pudesse inicializar em um modo shell do Darwin sem GUI. Poderia ter sido um UNIX incrível, com um ambiente desktop como KDE ou COSMIC por cima e o gerenciador de pacotes brew

    • Nesse caso, nem faria muito sentido usar macOS. Sem a interface, o Darwin não é tão diferente de FreeBSD ou GNU
    • O kernel do Mac tem desempenho pior e o gerenciamento de pacotes também é inferior ao nix
    • Na época dos Macs Intel existia o modo single-user, mas mesmo então não era possível controlar o framebuffer

  • Se isso for possível, fico curioso se um cliente Wayland no macOS consegue criar uma superfície EGL

  • Será que daria para usar o Waydroid dentro do Orbstack e rodar um ambiente Android? Em teoria, parece possível

  • Se desse para mudar o macOS para atalhos de teclado de Windows/Linux, acho que seria muito menos frustrante

    • Isso é um equívoco. Os atalhos do macOS são otimizados para trabalho no terminal. Os atalhos do sistema usam teclas diferentes, então não entram em conflito com códigos de control
    • Dá para trocar as teclas cmd e ctrl nas configurações, ou personalizar tudo com o Karabiner-Elements. No começo eu também me confundia, mas em uma semana a gente se adapta. Hoje, os atalhos do Windows é que me parecem desconfortáveis. A história da tecla Command também é interessante
    • Ter que usar ctrl+shift no terminal é realmente horrível. Acho o esquema de atalhos do macOS muito melhor
    • Pessoalmente, acho melhor usar a tecla Super para a maioria dos atalhos. No Windows ela fica desperdiçada só para o menu Iniciar
    • Na prática, uso o Karabiner-Elements para mapear cmd, option e control como ctrl, alt e super, respectivamente. Dá para fazer parte disso nas configurações padrão do macOS, mas para diferenciar as teclas da esquerda e da direita é preciso o Karabiner. Surpreendentemente, é uma configuração bem flexível para um produto da Apple

  • Fico curioso se este projeto poderia despertar ao menos um pouco de interesse pelo GNUstep