ricccrd/ddKernel Linux em espaço de usuário baseado em JIT que executa contêineres nativamente no macOS Apple Silicon sem uma VM. Substituição drop-in da API do Docker Engine com isolamento de contêineres, imagens overlay e publicação de portas.
Execute containers Linux no macOS — sem VM.
dd executa containers Linux nativamente no macOS Apple Silicon sem máquina virtual. Não há
kernel Linux nem hipervisor subjacente: um JIT traduz o código do container e trata suas
chamadas de sistema Linux em espaço de usuário (linhagem gVisor / PRoot). O JIT é o kernel Linux
convidado — namespaces, cgroups, camadas de imagem overlay e rede são mantidos como estado de espaço
de usuário. Ele fala a API do Docker Engine, então o CLI comum docker o utiliza.
A computação do container é executada como instruções nativas Apple Silicon; apenas suas chamadas de sistema são interpretadas. Sem VM para iniciar, sem daemon dentro de uma VM, sem custo de virtualização.
Site e documentação: https://ricccrd.github.io/dd/
make jit # build.rs compila + codesign os JITs
DD_IMAGES=/caminho/para/imagens cargo run -p dd-daemon # inicia o daemon
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
DOCKER_HOST para seu socket e
seus comandos docker run / ps / images / build existentes funcionam sem alterações.jit86) que decodifica x86, sintetiza suas flags e reduz SSE/x87 para NEON (binários glibc
funcionam); e convidados arm64 do macOS (ddcli mac) — sem VM em nenhum deles..wh. whiteout, getdents
mesclado), um VFS de confinamento de caminho livre de TOCTOU, namespaces PID / UTS / USER, uma netns
loopback privada com publicação de porta -p e limites de memória + pids via cgroup (OOM no limite).dd instalam um
daemon de fundo por usuário e um docker context — tudo em $HOME, nunca sudo.Qualquer outra forma de executar containers Linux em um Mac — Docker Desktop, Colima, Rancher, OrbStack — inicializa uma VM Linux sob um hipervisor e roda o daemon dentro dela. Essa VM é um imposto que você paga o dia todo. dd a elimina: um container é um processo macOS comum cujas chamadas de sistema são tratadas por um kernel Linux em espaço de usuário.
| dd — kernel em espaço de usuário (JIT) | Docker baseado em VM (Desktop / Colima / …) | |
|---|---|---|
| Modelo subjacente | Um JIT trata chamadas de sistema Linux em espaço de usuário (linhagem gVisor) | Um kernel Linux completo dentro de uma VM com hipervisor |
| RAM residente quando ocioso | Nenhuma — por container, liberada ao sair | Gigabytes reservados para a VM, sempre ligados |
| Inicialização | Spawn de processo — nenhuma VM para iniciar | Iniciar uma VM Linux + o daemon dentro da VM primeiro |
| Montagem bind / I/O de arquivos | Sistema de arquivos do host direto através de um confinamento de caminho | Ponte virtiofs/gRPC-FUSE através da fronteira da VM |
| Publicação de portas | Diretamente para sockets do host | Através da camada NAT/forwarding da VM |
| Custo de bateria / fundo | Nada executando quando não há container | Uma VM ociosa e consumindo bateria |
| Pegada para distribuir e corrigir | Nenhum kernel Linux — nada para rastrear CVE | Distribui, corrige e rastreia um kernel Linux completo |
| Observabilidade | Um processo macOS normal — amostra, depura, Monitor de Atividade | Uma VM opaca; a carga de trabalho é invisível para ferramentas do host |
A vantagem é estrutural: a computação do convidado roda como instruções nativas Apple Silicon (sem
camada de virtualização de hardware no caminho crítico), e o notório gargalo de compartilhamento de
arquivos do Docker Desktop — a ponte virtiofs/FUSE entre macOS e a VM — simplesmente não existe, pois
o VFS do dd é o sistema de arquivos do host protegido por um confinamento de caminho.
Compensação honesta: um kernel em espaço de usuário é tão completo quanto as chamadas de sistema que implementa, e hoje por padrão o convidado roda em um processo — rápido, e a decisão certa para código em que você confia (seu ambiente de desenvolvimento, CI, suas próprias ferramentas). Para código não confiável, há agora uma divisão sentry opcional (
DDJIT_UNTRUSTED): o convidado roda em um sandbox Seatbelt com negação padrão, sem autoridade de fs/rede do host, enquanto um processo sentry confiável possui os recursos reais e atende chamadas de sistema através de um anel de memória compartilhada — a forma gVisor. É cedo (as chamadas de sistema de arquivos principais — read/write/open/close/lseek — são encaminhadas hoje; sockets/exec/fork estão chegando), então para código totalmente hostil uma VM ainda expõe uma superfície mais estreita.
O mesmo binário Linux estático, executado de duas formas em um Apple M5 Pro (macOS 26.3): dentro
da VM Linux (como o Docker baseado em VM executa containers) vs. através do JIT do dd no host sem VM.
Mediana de 7 execuções (make bench). Menor tempo é melhor; "dd vs VM" > 1× significa que dd é mais
rápido. A faixa do dd ainda paga um pequeno imposto de ponte entre processos que o aplicativo real não
paga — portanto, estes são conservadores.
Containers x86-64 — dd vs emulação de VM (qemu-user; executar x86 no Apple Silicon significa traduzir de qualquer forma). O JIT do dd supera o qemu em 9 de 10 cargas de trabalho, dramaticamente em ponto flutuante:
| Carga de trabalho | VM (qemu) | dd (sem VM) | dd vs VM |
|---|---|---|---|
| float n-body | 5.39s | 0.23s | 24× mais rápido |
| mandelbrot | 7.81s | 0.83s | 9.4× mais rápido |
| matmul | 8.21s | 1.37s | 6.0× mais rápido |
| SQLite (600k linhas) | 2.99s | 1.01s | 3.0× mais rápido |
| qsort | 3.91s | 1.68s | 2.3× mais rápido |
| memcpy | 2.40s | 1.10s | 2.2× mais rápido |
| text-scan (wc/grep) | 1.42s | 1.11s | 1.3× mais rápido |
| int sieve | 1.31s | 1.04s | 1.25× mais rápido |
| SHA-256 | 2.72s | 2.44s | 1.1× mais rápido |
| base64 | 4.28s | 5.39s | 0.79× (1.26× mais lento) |