ricccrd/ddKernel de Linux en espacio de usuario basado en JIT que ejecuta contenedores de forma nativa en macOS con Apple Silicon sin una máquina virtual. Reemplazo directo de la API del motor Docker con aislamiento de contenedores, imágenes superpuestas y publicación de puertos.
Ejecuta contenedores de Linux en macOS — sin VM.
dd ejecuta contenedores de Linux de forma nativa en macOS con Apple Silicon sin una máquina virtual. No hay núcleo de Linux ni hipervisor subyacente: un JIT traduce el código del contenedor y procesa sus llamadas al sistema de Linux en espacio de usuario (linaje gVisor / PRoot). El JIT es el núcleo de Linux del invitado: los namespaces, cgroups, capas de imágenes overlay y la red se mantienen como estado de espacio de usuario. Habla la API del Motor Docker, por lo que el CLI docker habitual lo maneja.
La computación del contenedor se ejecuta como instrucciones nativas de Apple Silicon; solo sus llamadas al sistema son interpretadas. Sin VM que arrancar, sin demonio en una VM, sin costo de virtualización.
Sitio web y documentación: https://ricccrd.github.io/dd/
make jit # build.rs compila + firma los JITs
DD_IMAGES=/path/to/images cargo run -p dd-daemon # inicia el demonio
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
DOCKER_HOST a su socket y tus comandos existentes docker run / ps / images / build funcionan sin cambios.jit86) que decodifica x86, sintetiza sus flags y baja SSE/x87 a NEON (los binarios glibc funcionan); e invitados macOS arm64 (ddcli mac) — sin VM en ninguno de ellos..wh., getdents fusionados), un VFS de jaula de rutas libre de TOCTOU, namespaces PID / UTS / USER, una netns de loopback privada con publicación de puertos -p, y límites de cgroup de memoria + pids (OOM en el límite).dd instalan un demonio en segundo plano por usuario y un docker context — todo bajo $HOME, nunca sudo.Cualquier otra forma de ejecutar contenedores de Linux en un Mac — Docker Desktop, Colima, Rancher, OrbStack — arranca una VM de Linux bajo un hipervisor y ejecuta el demonio dentro de ella. Esa VM es un impuesto que pagas todo el día. dd la elimina: un contenedor es un proceso normal de macOS cuyas llamadas al sistema son gestionadas por un núcleo de Linux en espacio de usuario.
| dd — núcleo en espacio de usuario (JIT) | Docker basado en VM (Desktop / Colima / …) | |
|---|---|---|
| Modelo subyacente | Un JIT procesa llamadas al sistema de Linux en espacio de usuario (linaje gVisor) | Un núcleo completo de Linux dentro de una VM de hipervisor |
| RAM residente en reposo | Ninguna — por contenedor, liberada al salir | Gigabytes reservados para la VM, siempre encendida |
| Arranque | Spawn de proceso — sin VM que arrancar | Arrancar primero una VM Linux + el demonio dentro de la VM |
| Montaje enlace / E/S archivos | Sistema de archivos anfitrión directo a través de una jaula de rutas | Puente virtiofs/gRPC-FUSE a través del límite de la VM |
| Publicación de puertos | Directo a sockets del anfitrión | A través de la capa NAT/reenvío de la VM |
| Costo de batería / fondo | Nada ejecutándose cuando no hay contenedor | Una VM inactiva que agota la batería |
| Espacio para distribuir y parchear | Sin núcleo de Linux — nada que rastrear por CVE | Distribuye, parchea y rastrea un núcleo completo de Linux |
| Observabilidad | Un proceso normal de macOS — samplear, depurar, Monitor de Actividad | Una VM opaca; la carga de trabajo es invisible para las herramientas del anfitrión |
La ventaja es estructural: la computación del invitado se ejecuta como instrucciones nativas de Apple Silicon (sin capa de virtualización de hardware en la ruta crítica), y el conocido cuello de botella de intercambio de archivos de Docker Desktop — el puente virtiofs/FUSE entre macOS y la VM — simplemente no existe, porque el VFS de dd es el sistema de archivos del anfitrión detrás de una jaula de rutas.
Compensación honesta: un núcleo en espacio de usuario solo es tan completo como las llamadas al sistema que implementa, y hoy Por defecto, el invitado se ejecuta en un proceso — rápido, y la decisión correcta para código de confianza (tu entorno de desarrollo, CI, tus propias herramientas). Para código no confiable ahora hay una división de centinela optativa (
DDJIT_UNTRUSTED): el invitado se ejecuta en una caja de arena Seatbelt con denegación por defecto que no tiene autoridad de sistema de archivos/red del anfitrión, mientras que un proceso centinela de confianza posee los recursos reales y sirve las llamadas al sistema a través de un anillo de memoria compartida — la forma de gVisor. Es temprano (las llamadas al sistema de archivos principales — read/write/open/close/lseek — se reenvían hoy; sockets/exec/fork están llegando), así que para código completamente hostil, una VM todavía expone una superficie más reducida.
El mismo binario estático de Linux, ejecutado de dos formas en un Apple M5 Pro (macOS 26.3): dentro de la VM de Linux (cómo los Docker basados en VM ejecutan contenedores) vs. a través del JIT de dd en el anfitrión sin ninguna VM. Mediana de 7 (make bench). Un tiempo menor es mejor; "dd vs VM" > 1× significa que dd es más rápido. El carril de dd incluso paga un pequeño impuesto de puente entre procesos que la aplicación real no tiene — por lo que son conservadores.
Contenedores x86-64 — dd vs emulación en VM (qemu-user; ejecutar x86 en Apple Silicon significa traducirlo de cualquier manera). El JIT de dd supera a qemu en 9 de 10 cargas de trabajo, dramáticamente en punto flotante: