ricccrd/ddNoyau Linux en espace utilisateur basé sur JIT qui exécute les conteneurs nativement sur macOS Apple Silicon sans VM. Remplacement de l'API Docker Engine intégré avec isolation des conteneurs, images overlay et publication de ports.
Exécutez des conteneurs Linux sur macOS — sans machine virtuelle.
dd exécute des conteneurs Linux nativement sur macOS Apple Silicon sans machine virtuelle. Il n'y a pas de noyau Linux ni d'hyperviseur en dessous : un JIT traduit le code du conteneur et prend en charge ses appels système Linux dans l'espace utilisateur (filiation gVisor / PRoot). Le JIT est le noyau Linux de l'invité — les espaces de noms, cgroups, couches d'images overlay et le réseau sont maintenus comme un état dans l'espace utilisateur. Il parle l'API Docker Engine, donc le client docker ordinaire le pilote.
Le calcul du conteneur s'exécute comme des instructions natives Apple Silicon ; seuls ses appels système sont interprétés. Pas de VM à démarrer, pas de démon dans une VM, pas de coût de virtualisation.
Site web & docs : https://ricccrd.github.io/dd/
make jit # build.rs compile et signe les JIT
DD_IMAGES=/path/to/images cargo run -p dd-daemon # démarre le démon
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
DOCKER_HOST vers son socket et vos commandes docker run / ps / images / build existantes fonctionnent sans modification.jit86) qui décode le x86, synthétise ses flags et abaisse SSE/x87 sur NEON (les binaires glibc fonctionnent) ; et invités macOS arm64 (ddcli mac) — aucune VM dans aucun d'eux..wh. whiteout, getdents fusionné), un VFS de type jail de chemins sans TOCTOU, espaces de noms PID / UTS / USER, un netns loopback privé avec publication de ports -p, et limites de mémoire + pids via cgroups (OOM à la limite).dd installent un démon en arrière-plan par utilisateur et un docker context — tout sous $HOME, jamais sudo.Toute autre façon d'exécuter des conteneurs Linux sur un Mac — Docker Desktop, Colima, Rancher, OrbStack — démarre une VM Linux sous un hyperviseur et exécute le démon à l'intérieur. Cette VM est un impôt que vous payez toute la journée. dd la supprime : un conteneur est un simple processus macOS dont les appels système sont traités par un noyau Linux dans l'espace utilisateur.
| dd — noyau en espace utilisateur (JIT) | Basé sur VM (Docker Desktop / Colima / …) | |
|---|---|---|
| Modèle sous-jacent | Un JIT prend en charge les appels système Linux dans l'espace utilisateur (filiation gVisor) | Un noyau Linux complet à l'intérieur d'une VM hyperviseur |
| RAM résidente au repos | Aucune — par conteneur, libérée à la sortie | Gigaoctets réservés pour la VM, toujours allumée |
| Démarrage | Création de processus — pas de VM à démarrer | Démarrer une VM Linux + le démon dans la VM d'abord |
| Montage de volume / I/O fichier | Système de fichiers hôte direct via une jail de chemins | Pont virtiofs/gRPC-FUSE à travers la frontière de la VM |
| Publication de ports | Directement sur les sockets de l'hôte | Via la couche NAT/forwarding de la VM |
| Coût batterie / arrière-plan | Rien qui tourne quand aucun conteneur n'est actif | Une VM au ralenti qui vide la batterie |
| Empreinte à distribuer & corriger | Pas de noyau Linux — rien à suivre pour les CVE | Distribue, corrige et suit tout un noyau Linux |
| Observabilité | Un processus macOS normal — samplez, déboguez, Activity Monitor | Une VM opaque ; la charge de travail est invisible pour les outils de l'hôte |
Le gain est structurel : le calcul de l'invité s'exécute en instructions natives Apple Silicon (aucune couche de virtualisation matérielle dans le chemin critique), et le célèbre goulot d'étranglement du partage de fichiers de Docker Desktop — le pont virtiofs/FUSE entre macOS et la VM — n'existe tout simplement pas, car le VFS de dd est le système de fichiers hôte derrière une jail de chemins.
Compromis honnête : un noyau dans l'espace utilisateur est seulement aussi complet que les appels système qu'il implémente, et aujourd'hui par défaut l'invité s'exécute dans un seul processus — rapide, et le bon choix pour du code auquel vous faites confiance (votre environnement de développement, CI, vos propres outils). Pour du code non fiable, il existe désormais une séparation sentinelle optionnelle (
DDJIT_UNTRUSTED) : l'invité s'exécute dans un sandbox Seatbelt en mode refus-par-défaut ne détenant aucune autorisation hôte fs/réseau, tandis qu'un processus sentinelle de confiance possède les vraies ressources et sert les appels système via un anneau mémoire partagée — la forme gVisor. C'est encore tôt (les appels système fichier de base — read/write/open/close/lseek — sont transférés aujourd'hui ; sockets/exec/fork arrivent), donc pour du code totalement hostile, une VM expose toujours une surface plus restreinte.
Le même binaire Linux statique, exécuté de deux manières sur un Apple M5 Pro (macOS 26.3) : à l'intérieur de la VM Linux (comment les Docker basés sur VM exécutent les conteneurs) vs. via le JIT de dd sur l'hôte sans VM. Médiane de 7 (make bench). Un temps plus bas est meilleur ; « dd vs VM » > 1× signifie que dd est plus rapide. La voie dd paie même un petit coût de pont inter-processus que la vraie application ne paie pas — ce sont donc des chiffres conservateurs.
Conteneurs x86-64 — dd vs émulation VM (qemu-user ; exécuter x86 sur Apple Silicon signifie traduire de toute façon). Le JIT de dd bat qemu sur 9 des 10 charges de travail, de manière spectaculaire sur les calculs en virgule flottante :