ricccrd/ddKernel Linux in userspace basato su JIT che esegue contenitori nativamente su macOS con Apple Silicon senza una VM. Sostituto drop-in dell'API di Docker Engine con isolamento dei contenitori, immagini overlay e pubblicazione delle porte.
Esegui container Linux su macOS — senza VM.
dd esegue container Linux in modo nativo su macOS con Apple Silicon senza una macchina virtuale. Non c'è
kernel Linux né hypervisor sottostante: un JIT traduce il codice del container e gestisce le sue
chiamate di sistema Linux nello spazio utente (la discendenza gVisor / PRoot). Il JIT è il kernel Linux dell'ospite —
namespace, cgroups, layer di immagini overlay e rete sono mantenuti come stato dello spazio utente. Parla
l'API Docker Engine, quindi la normale CLI docker lo comanda.
Il calcolo del container viene eseguito come istruzioni native Apple Silicon; solo le sue chiamate di sistema vengono interpretate. Nessuna VM da avviare, nessun demone in una VM, nessun costo di virtualizzazione.
Sito web e documentazione: https://ricccrd.github.io/dd/
make jit # build.rs compiles + codesigns the JITs
DD_IMAGES=/path/to/images cargo run -p dd-daemon # start the daemon
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
DOCKER_HOST al suo socket e i tuoi comandi docker run / ps / images / build esistenti funzionano invariati.jit86) che decodifica x86, sintetizza i suoi flag e abbassa SSE/x87 su NEON (i binari glibc funzionano); e ospiti macOS arm64 (ddcli mac) — nessuna VM in nessuno di essi..wh. whiteout, getdents uniti), un VFS path-jail senza TOCTOU, namespace PID / UTS / USER, una netns di loopback privata con pubblicazione della porta -p, e limiti cgroup di memoria + pids (OOM al limite).dd installano un demone in background per utente e un docker context — tutto sotto $HOME, mai sudo.Ogni altro modo per eseguire container Linux su un Mac — Docker Desktop, Colima, Rancher, OrbStack — avvia una VM Linux sotto un hypervisor e fa funzionare il demone al suo interno. Quella VM è una tassa che paghi tutto il giorno. dd la elimina: un container è un normale processo macOS le cui chiamate di sistema vengono servite da un kernel Linux in spazio utente.
| dd — kernel in spazio utente (JIT) | Docker basato su VM (Desktop / Colima / …) | |
|---|---|---|
| Modello sottostante | Un JIT gestisce le chiamate di sistema Linux nello spazio utente (discendenza gVisor) | Un kernel Linux completo all'interno di una VM con hypervisor |
| RAM residente quando inattivo | Nessuna — per container, liberata all'uscita | Gigabyte riservati per la VM, sempre accesa |
| Avvio | Creazione di un processo — nessuna VM da avviare | Avviare prima una VM Linux + il demone dentro la VM |
| Bind-mount / I/O file | Filesystem host diretto attraverso un path jail | Ponte virtiofs/gRPC-FUSE attraverso il confine della VM |
| Pubblicazione porta | Direttamente ai socket host | Attraverso il layer NAT/forwarding della VM |
| Costo batteria / background | Niente in esecuzione quando nessun container è attivo | Una VM inattiva che consuma batteria |
| Impronta da distribuire e aggiornare | Nessun kernel Linux — niente da tracciare per CVE | Distribuisce, aggiorna e traccia un intero kernel Linux |
| Osservabilità | Un normale processo macOS — sample, debug, Activity Monitor | Una VM opaca; il carico di lavoro è invisibile agli strumenti host |
Il vantaggio è strutturale: il calcolo dell'ospite viene eseguito come istruzioni native Apple Silicon (nessun layer di virtualizzazione hardware nel percorso critico), e il famigerato collo di bottiglia della condivisione file di Docker Desktop — il ponte virtiofs/FUSE tra macOS e la VM — semplicemente non esiste, perché il VFS di dd è il filesystem host dietro un path jail.
Compromesso onesto: un kernel in spazio utente è completo solo quanto le chiamate di sistema che implementa, e oggi Per impostazione predefinita, l'ospite viene eseguito in un processo — veloce, e la scelta giusta per codice di cui ti fidi (il tuo ambiente di sviluppo, CI, i tuoi strumenti). Per codice non fidato ora c'è una scissione sentry opzionale (
DDJIT_UNTRUSTED): l'ospite viene eseguito in un sandbox Seatbelt con negazione predefinita senza autorità di filesystem/rete, mentre un processo sentry fidato possiede le risorse reali e serve le chiamate di sistema tramite un anello di memoria condivisa — la forma gVisor. È presto (le chiamate di sistema principali per file — read/write/open/close/lseek — vengono inoltrate oggi; socket/exec/fork stanno arrivando), quindi per codice completamente ostile una VM espone ancora una superficie più ristretta.
Lo stesso binario Linux statico, eseguito in due modi su un Apple M5 Pro (macOS 26.3): dentro la VM Linux (come Docker basato su VM esegue i container) vs. tramite il JIT di dd sull'host con nessuna VM. Mediana di 7 (make bench). Tempo minore è migliore; "dd vs VM" > 1× significa dd è più veloce. La corsia dd paga persino un piccolo costo di ponte cross-process che l'app reale non paga — quindi questi sono conservativi.
Container x86-64 — dd vs emulazione VM (qemu-user; eseguire x86 su Apple Silicon significa tradurlo in ogni caso). Il JIT di dd batte qemu in 9 su 10 carichi di lavoro, in modo drammatico sulla virgola mobile:
| Carico di lavoro | VM (qemu) | dd (no VM) | dd vs VM |
|---|---|---|---|
| float n-body | 5.39s | 0.23s | 24× più veloce |
| mandelbrot | 7.81s | 0.83s | 9.4× più veloce |
| matmul | 8.21s | 1.37s | 6.0× più veloce |
| SQLite (600k righe) | 2.99s | 1.01s | 3.0× più veloce |
| qsort | 3.91s | 1.68s | 2.3× più veloce |
| memcpy | 2.40s | 1.10s | 2.2× più veloce |
| text-scan (wc/grep) | 1.42s | 1.11s | 1.3× più veloce |
| int sieve | 1.31s | 1.04s | 1.25× più veloce |
| SHA-256 | 2.72s | 2.44s | 1.1× più veloce |
| base64 | 4.28s | 5.39s | 0.79× (1.26× più lento) |