Como a virtualização chegou aos Macs com Apple Silicon

Artigo original ↗ Discussão no Hacker News ↗

A virtualização em Macs com Apple Silicon está amadurecendo rapidamente, com os frameworks da Apple alimentando ferramentas como Docker e hipervisores de terceiros, mas os usuários ainda esbarram em limitações de emulação x86, passthrough de USB e aceleração de GPU — especialmente em fluxos de trabalho específicos como desenvolvimento de FPGA ou execução de versões antigas do macOS. Os comentaristas contrastam a virtualização verdadeira com a emulação mais lenta de CPU, observando que, embora QEMU e configurações semelhantes consigam executar sistemas operacionais Intel, o desempenho e a compatibilidade costumam ser ruins para trabalho sério. O tópico também se amplia para como essas restrições técnicas influenciam decisões de compra entre Macs e iPads, e como projetos como Asahi Linux e ferramentas como OpenCore Legacy Patcher ou Retroactive são usados para prolongar a vida útil de hardware e software.

Meta e recepção do artigo

  • Vários comentários elogiam o site Eclectic Light e o design da página vinculada.
  • Há alguma discussão meta sobre remetentes prolíficos do HN, mas nada técnico nisso.

Virtualização vs. emulação no Apple Silicon

  • A distinção é apresentada de forma clara:
    • Virtualização = mesma arquitetura de CPU, velocidade quase nativa, usa suporte de hardware.
    • Emulação = arquiteturas de CPU diferentes, tradução de instruções, normalmente bem mais lenta.
  • O Apple Silicon não consegue virtualizar o macOS Intel; só consegue emulá-lo (por exemplo, via QEMU), o que as pessoas relatam como “usável apenas para terminal” ou pior.
  • O passthrough de USB em VMs ARM do macOS é atualmente limitado (por exemplo, o Parallels não consegue anexar dispositivos USB genéricos a um guest do macOS). As alternativas sugeridas são compartilhamentos de rede ou caminhos do host.

Docker, frameworks de virtualização da Apple e ferramentas

  • O Docker Desktop no macOS já usa os frameworks de virtualização da Apple; não se espera uma grande mudança com base apenas neste artigo.
  • Ferramentas alternativas mencionadas para diferentes casos de uso: QEMU/UTM, OrbStack, VMware Fusion e LiViable (o aplicativo do autor do artigo).

Linux x86 / FPGA e ferramentas pesadas em Macs com série M

  • Rodar VMs Linux x86_64 para FPGA e outras ferramentas de código fechado é visto como possível, mas problemático:
    • O Rosetta dentro de VMs Linux suporta apenas x86 de 64 bits e carece de partes do conjunto de instruções (por exemplo, AVX2), causando incompatibilidades.
    • O suporte a x86 de 32 bits exige outros emuladores (por exemplo, FEX) com impactos de desempenho notáveis.
    • As ferramentas de FPGA são intensivas em CPU e frequentemente mal otimizadas, então o desempenho deve ser significativamente pior do que em x86 nativo.
    • O passthrough de USB e drivers proprietários dentro do guest são apontados como pontos prováveis de falha.
  • Alternativas sugeridas: contêineres Docker/OrbStack quando apenas shells/ferramentas de CLI são necessários, ou usar uma máquina x86 remota.

iPad Pro, virtualização e debate sobre “daily driver”

  • Há especulação de que futuros iPad Pros, com OLED e novos teclados, poderiam se tornar substitutos de MacBook de alto preço e capazes de virtualização; outros duvidam fortemente que esses grandes aumentos de preço aconteçam.
  • As experiências com o iPad Pro de 12,9" divergem bastante:
    • Lado pró-iPad: com Magic Keyboard, Stage Manager, conectividade celular e longa duração de bateria, ele pode ser um computador móvel principal para muitas tarefas que não envolvem desenvolvimento.
    • Lado cético: multitarefa do iPadOS, atalhos de teclado, descarregamento agressivo de apps e limitações de “não ser um sistema operacional completo” tornam-no frustrante para produtividade; muitas vezes fica restrito a mídia, anotações, marcação de PDF e desktop remoto.
  • Comparações com tablets Surface destacam a troca: melhor UX de tablet no iPad versus um “sistema operacional real” mais aberto (e com capacidade de VM) no Surface, embora com suporte de hardware/app mais fraco em alguns casos.

Rodando macOS/iTunes antigos e macOS mais novo em Macs antigos

  • Para um MacBook Pro de 2015:
    • Ele pode rodar oficialmente até o macOS Monterey sem hacks.
    • Para apps antigos como o iTunes, o Retroactive é recomendado para corrigi-los e executá-los em versões mais novas do macOS.
    • Para rodar a versão mais recente do macOS em hardware sem suporte, o OpenCore Legacy Patcher (OCLP) é recomendado, com fortes avisos para fazer backup completo e entender as peculiaridades da instalação (por exemplo, necessidade de periféricos com fio durante a instalação).
  • Alguns usuários preferem a interface da era Mojave e o gerenciamento unificado de mídia do iTunes e a navegação inteligente em vez dos aplicativos mais novos Music/TV/Books, que são criticados por recursos reduzidos para usuários avançados e UI inconsistente.

Linux no Apple Silicon: VMs vs. Asahi

  • Um usuário quer Linux como um daily driver quase bare-metal via VM, com tela cheia exclusiva e aceleração por GPU, e a UI do host totalmente fora do caminho.
  • As respostas observam:
    • O Asahi Linux está avançando e está “quase” pronto para uso diário, com pedidos de contribuições.
    • As VMs atuais hospedadas no macOS são do tipo 2; não há hipervisores do tipo 1 conhecidos.
    • Os frameworks da Apple podem paravirtualizar a GPU, com alegações de velocidade quase nativa para convidados suportados.
    • O VMware Fusion em ARM, segundo relatos, oferece bom Linux em tela cheia com roteamento configurável de gestos e atalhos, embora ainda apareça a moldura da UI do macOS nas bordas da tela.

Diversos

  • Um comentário fora de contexto sobre um site de lofi/ATC parece ter sido postado por engano de outro tópico do HN e é corrigido.