ricccrd/ddПользовательское ядро Linux на основе JIT, которое запускает контейнеры нативно на macOS с Apple Silicon без виртуальной машины. Замена Docker Engine API с возможностью прямой подстановки, обеспечивающая изоляцию контейнеров, оверлейные образы и публикацию портов.
Запуск контейнеров Linux на macOS без виртуальной машины.
dd запускает контейнеры Linux нативно на macOS с Apple Silicon без виртуальной машины. Нет
ядра Linux и нет гипервизора под капотом: JIT транслирует код контейнера и обрабатывает его
системные вызовы Linux в пользовательском пространстве (линия gVisor / PRoot). JIT является
ядром Linux для гостя — пространства имён, cgroups, слои оверлейных образов и сеть поддерживаются
как состояние пользовательского пространства. Он говорит на Docker Engine API, так что обычный
CLI docker управляет им.
Вычисления контейнера выполняются как нативные инструкции Apple Silicon; только его системные вызовы интерпретируются. Нет VM для загрузки, нет демона-в-VM, нет затрат на виртуализацию.
Сайт и документация: https://ricccrd.github.io/dd/
make jit # build.rs компилирует и подписывает JIT
DD_IMAGES=/path/to/images cargo run -p dd-daemon # запуск демона
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
DOCKER_HOST на его сокет, и ваши существующие команды docker run / ps / images / build будут работать без изменений.jit86), который декодирует x86, синтезирует флаги и снижает SSE/x87 на NEON (бинарники glibc работают); и гости macOS arm64 (ddcli mac) — ни в одном из них нет VM..wh. whiteout, объединённые getdents), VFS с изоляцией путей без TOCTOU, пространства имён PID / UTS / USER, частная loopback netns с публикацией портов -p и ограничения памяти + процессов через cgroups (OOM при достижении лимита).dd устанавливают фоновый демон для каждого пользователя и docker context — всё работает из $HOME, никогда не требуется sudo.Любой другой способ запуска контейнеров Linux на Mac — Docker Desktop, Colima, Rancher, OrbStack — загружает Linux VM под гипервизором и запускает демон внутри неё. Эту VM вы оплачиваете весь день. dd избавляется от неё: контейнер — обычный процесс macOS, чьи системные вызовы обслуживаются ядром Linux в пользовательском пространстве.
| dd — ядро в пользовательском пространстве (JIT) | VM-based Docker (Desktop / Colima / …) | |
|---|---|---|
| Базовая модель | JIT обслуживает системные вызовы Linux в пользовательском пространстве (линия gVisor) | Полноценное ядро Linux внутри гипервизора VM |
| Потребление RAM в простое | Нет — освобождается при выходе из контейнера | Гигабайты зарезервированы для VM, всегда включены |
| Запуск | Запуск процесса — не нужно загружать VM | Сначала загрузить Linux VM + демон внутри |
| Bind-mount / файловый ввод-вывод | Прямая работа с файловой системой хоста через изоляцию путей | Мост virtiofs/gRPC-FUSE через границу VM |
| Публикация портов | Напрямую к сокетам хоста | Через слой NAT/форвардинга VM |
| Потребление батареи / в фоне | Ничего не выполняется, когда нет контейнера | VM работает вхолостую и расходует батарею |
| Размер для распространения и обновления | Нет ядра Linux — не нужно отслеживать CVE | Включает, обновляет и отслеживает целое ядро Linux |
| Наблюдаемость | Обычный процесс macOS — sample, debug, Activity Monitor | Непрозрачная VM; нагрузка невидима для инструментов хоста |
Выигрыш структурный: вычисления гостя выполняются как нативные инструкции Apple Silicon (нет слоя аппаратной виртуализации на горячем пути), а пресловутое узкое место общего доступа к файлам Docker Desktop — мост virtiofs/FUSE между macOS и VM — просто не существует, потому что VFS dd является файловой системой хоста за изоляцией путей.
Честный компромисс: ядро в пользовательском пространстве настолько полно, насколько реализованы системные вызовы, и сегодня по умолчанию гость работает в одном процессе — это быстро и правильно для кода, которому вы доверяете (ваше окружение разработки, CI, ваши собственные инструменты). Для недоверенного кода теперь существует опциональный разделённый sentry (
DDJIT_UNTRUSTED): гость работает в песочнице Seatbelt с запретами по умолчанию, не имея полномочий на файловую систему/сеть хоста, а доверенный процесс sentry владеет реальными ресурсами и обслуживает системные вызовы через кольцо разделяемой памяти — форма gVisor. Это рано (основные системные вызовы для файлов — read/write/open/close/lseek — уже работают; сокеты/exec/fork внедряются), так что для полностью враждебного кода VM всё ещё предоставляет меньшую поверхность атаки.
Один и тот же статический бинарник Linux, запущенный двумя способами на Apple M5 Pro (macOS 26.3): внутри Linux VM (как VM-основанные Docker запускают контейнеры) и через JIT dd на хосте без VM. Медиана из 7 замеров (make bench). Меньшее время лучше; «dd vs VM» > 1× означает, что dd быстрее. Замеры dd дополнительно платят небольшой налог на межпроцессное взаимодействие, которого нет у реального приложения — так что эти цифры консервативны.
Контейнеры x86-64 — dd vs эмуляция VM (qemu-user; запуск x86 на Apple Silicon означает трансляцию в любом случае). JIT dd побеждает qemu на 9 из 10 нагрузок, особенно в вычислениях с плавающей точкой:
| Нагрузка | VM (qemu) | dd (без VM) | dd vs VM |
|---|---|---|---|
| float n-body | 5.39s | 0.23s | быстрее в 24× |
| mandelbrot | 7.81s | 0.83s | быстрее в 9.4× |
| matmul | 8.21s | 1.37s | быстрее в 6.0× |
| SQLite (600k строк) | 2.99s | 1.01s | быстрее в 3.0× |
| qsort | 3.91s | 1.68s | быстрее в 2.3× |
| memcpy | 2.40s | 1.10s | быстрее в 2.2× |
| text-scan (wc/grep) | 1.42s | 1.11s | быстрее в 1.3× |
| int sieve | 1.31s | 1.04s | быстрее в 1.25× |
| SHA-256 | 2.72s | 2.44s | быстрее в 1.1× |
| base64 | 4.28s | 5.39s | 0.79× (в 1.26× медленнее) |