Tart: VMs no macOS usando o Virtualization.Framework nativo da Apple

Artigo original ↗ Discussão no Hacker News ↗

Desenvolvedores estão analisando o Tart, uma ferramenta para macOS que encapsula o Virtualization.framework da Apple para executar VMs de macOS e Linux e distribuir imagens via registries de container, como uma forma simplificada de automatizar CI e ambientes de desenvolvimento em Apple Silicon. Grande parte do debate gira em torno de desempenho e trade-offs de arquitetura—virtualização vs emulação completa para x86 em ARM, o papel do Rosetta 2 para executar binários Intel dentro de VMs Linux, desempenho de filesystem e Docker no macOS, e até onde máquinas com 8GB podem realisticamente ser levadas. O licenciamento também é um ponto sensível, com o modelo “Fair Source” não-OSS e baseado em cores do Tart levando alguns a preferirem alternativas abertas como UTM, Lima/Colima, VirtualBuddy ou configurações QEMU personalizadas.

Visão geral do Tart e sua proposta

  • Ferramenta de CLI que encapsula o Virtualization.framework da Apple para executar VMs de macOS e Linux em Apple Silicon.
  • Diferencial principal: usa registries OCI/container para imagens de VM, permitindo fluxos de trabalho semelhantes aos de imagens de container (build, push, pull, reuse).
  • Usuários elogiam a CLI limpa, a facilidade de scripting e as integrações (plugin do Packer, GitLab/Buildkite, CI).
  • Especialmente valorizado por ambientes de teste reproduzíveis de macOS e pela configuração rápida de IPSW para VM.

Licenciamento e modelo de negócios

  • Usa uma licença no estilo Fair Source com “seats” por core para organizações; uso pessoal e pequenas instalações em servidores são gratuitos até um limite de cores.
  • Alguns veem a licença como restritiva/confusa, preocupam-se com conformidade organizacional e não gostam de termos não-OSI “à la BSL”.
  • Outros observam que o LICENSE e o site são explícitos, e que usuários comerciais devem sempre verificar os termos.
  • Versões anteriores eram AGPLv3; esses commits permanecem no repositório e podem ser reutilizados ou bifurcados.

Virtualização vs. emulação vs. containers

  • Longo subthread debatendo terminologia:
    • Um lado: no uso atual da indústria, “virtualização” implica executar código guest diretamente na CPU do host (mesma ISA), distinta de emulação.
    • Outro lado: historicamente, emulação é uma técnica dentro da virtualização; as categorias se sobrepõem e o marketing distorceu os termos.
    • Há acordo geral de que containers são distintos (isolamento em nível de SO, kernel compartilhado), embora alguns observem que stacks modernos de containers usam virtualização por baixo.

x86_64 no Apple Silicon e Rosetta

  • Múltiplas explicações de que guests completos de SO x86 exigem emulação; tradução binária no estilo Rosetta é adequada apenas para userspace, não para kernels.
  • Abordagem recomendada: executar uma VM Linux aarch64 e usar Rosetta 2 dentro da VM (via suporte documentado da Apple) ou mecanismos semelhantes para rodar binários x86_64; muito mais rápido do que emulação QEMU em sistema completo.
  • Usuários relatam a emulação x86_64 do UTM como “praticamente inutilizável” para cargas de trabalho mais pesadas; VMs ARM nativas funcionam bem.

Comparações de ecossistema e alternativas

  • Alternativas mencionadas: os próprios frameworks Virtualization/Hypervisor da Apple (faça você mesmo), virt, Lima/Colima (focados em Linux), UTM, VirtualBuddy, Viable, VMTek, OrbStack, Multipass.
  • Tart é visto como distinto principalmente pelo suporte a guest macOS, além de fluxos de trabalho com registry de imagens e tooling de CI.
  • Alguns argumentam que é possível obter a maior parte da funcionalidade com QEMU/Hypervisor.framework se você investir tempo; outros valorizam a UX polida do Tart.

Desempenho, hardware e experiência de desenvolvimento

  • Preocupações com desempenho de filesystem em VMs de macOS e Docker; o VirtioFS melhorou as coisas, mas ainda fica atrás do Linux nativo.
  • Sugestões: usar ferramentas de sync como Mutagen; ou executar Docker inteiramente dentro de uma VM Linux.
  • Debate sobre a adequação de 8GB de RAM: alguns relatam workloads tranquilos (até edição de vídeo), outros consideram IDEs modernas e projetos maiores inutilizáveis e recomendam 16GB+ para uso intensivo de VM/desenvolvimento.

Casos de uso e notas legais

  • Usado intensivamente para Mac CI, gestão/fluxos de trabalho de testes, cenários de enrollment semelhantes a DEP do macOS e boot rápido em Recovery para ajustar configurações de segurança.
  • Imagens de macOS no GHCR levantam dúvidas; um comentário cita exceções da EULA do macOS para “Permitted Developer Services” como CI, embora o suporte a layering no Tart esteja atualmente ausente.
  • O passthrough de GPU para guests macOS é limitado a uma GPU paravirtual; a adequação para workloads de LLM não está clara.