dd

شغّل حاويات لينكس على macOS — دون آلة افتراضية.

---

ما هو dd؟

dd يشغّل حاويات لينكس بشكل أصلي على macOS بمعمارية Apple Silicon دون آلة افتراضية. لا يوجد نواة لينكس ولا هايبرفايزر تحتها: JIT يترجم كود الحاوية ويخدم استدعاءات النظام لينكس في مساحة المستخدم (سلالة gVisor / PRoot). JIT هو نواة لينكس للضيف — فضاءات الأسماء، cgroups، طبقات الصورة overlays، والشبكات تُحتفظ بها كحالة في مساحة المستخدم. يتحدث واجهة Docker Engine API، لذا فإن سطر الأوامر العادي docker يقودها.

حوسبة الحاوية تعمل كتعليمات أصلية لـ Apple Silicon؛ فقط استدعاءات النظام الخاصة بها تُفسّر. لا آلة افتراضية للإقلاع، لا خفيّ داخل آلة افتراضية، لا تكلفة افتراضية.

الموقع والوثائق: 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)'

الميزات

• لا آلة افتراضية. لا هايبرفايزر، لا نواة لينكس، لا آلة افتراضية مقيمة. تعليمات الضيف تعمل أصلياً على arm64؛ فقط حدود استدعاءات النظام يُلتقط ويُخدم في مساحة المستخدم.
• Docker قابل للتبديل الفوري. dd يطبّق واجهة Docker Engine API. وجّه DOCKER_HOST إلى مقبسها وستعمل أوامرك الحالية docker run / ps / images / build دون تغيير.
• JIT هو النواة. فضاءات الأسماء، cgroups، طبقات الصورة overlays، والشبكات هي حالات عادية في مساحة المستخدم — نواة مساحة مستخدم في سلالة gVisor / PRoot، دون أي تكلفة لآلة افتراضية.
• ثلاث بيئات تشغيل ضيف، محرك واحد. صور arm64 لينكس أصلية؛ صور x86-64 لينكس عبر JIT (jit86) الذي يفك تشفير x86، يصنع أعلامها، ويخفض SSE/x87 إلى NEON (ثنائيات glibc تعمل)؛ وضيوف macOS arm64 (ddcli mac) — لا آلة افتراضية في أي منها.
• عزل حاوية حقيقي. طبقات الصورة overlays (نسخ-لأعلى / .wh. whiteout، getdents مدمجة)، VFS سجن مسار خالٍ من TOCTOU، فضاءات أسماء PID / UTS / USER، netns loopback خاص مع نشر منفذ -p، وحدود cgroup للذاكرة والعمليات (OOM عند الحد).
• تطبيق سطح مكتب، بدون صلاحيات جذر. تطبيق GTK4 أصلي (dd-app) بالإضافة إلى واجهة سطر الأوامر dd يُثبّت خفيّاً خلفياً لكل مستخدم وdocker context — كل شيء تحت $HOME، أبداً sudo.

لماذا JIT وليس آلة افتراضية؟

كل طريقة أخرى لتشغيل حاويات لينكس على ماك — Docker Desktop، Colima، Rancher، OrbStack — تُقلّع آلة افتراضية لينكس تحت هايبرفايزر وتشغّل الخفيّ داخلها. تلك الآلة الافتراضية ضريبة تدفعها طوال اليوم. dd يلغيها: الحاوية هي عملية ماك عادية تحدث استدعاءات نظامها بالصدف أن تُخدم بواسطة نواة لينكس في مساحة المستخدم.

	dd — نواة مساحة مستخدم (JIT)	Docker القائم على آلة افتراضية (Desktop / Colima / …)
النموذج الأساسي	JIT يخدم استدعاءات نظام لينكس في مساحة المستخدم (سلالة gVisor)	نواة لينكس كاملة داخل آلة افتراضية تحت هايبرفايزر
الذاكرة المقيمة عند الخمول	لا شيء — لكل حاوية، تُحرر عند الخروج	غيغابايت محجوزة للآلة الافتراضية، دائماً قيد التشغيل
بدء التشغيل	إطلاق عملية — لا آلة افتراضية للإقلاع	إقلاع آلة افتراضية لينكس + الخفيّ داخلها أولاً
الربط-التركيب / إدخال-إخراج الملفات	نظام ملفات المضيف مباشر عبر سجن مسار	جسر virtiofs/gRPC-FUSE عبر حدود الآلة الافتراضية
نشر المنفذ	مباشرة إلى مقابس المضيف	عبر طبقة NAT/إعادة توجيه الآلة الافتراضية
تكلفة البطارية / الخلفية	لا شيء يعمل عندما لا توجد حاوية	آلة افتراضية خاملة وتستهلك البطارية
مساحة التوزيع والتصحيح	لا نواة لينكس — لا شيء لتتبّع CVEs	يوزّع ويصحّح ويتتبّع نواة لينكس كاملة
قابلية المراقبة	عملية ماك عادية — sample, debug, Activity Monitor	آلة افتراضية غير شفافة؛ عبء العمل غير مرئي لأدوات المضيف

المكسب هيكلي: حوسبة الضيف تعمل كـ تعليمات أصلية لـ Apple Silicon (لا طبقة افتراضية للأجهزة في المسار الساخن)، واختناق مشاركة الملفات الشهير في Docker-Desktop — جسر virtiofs/FUSE بين ماك والآلة الافتراضية — ببساطة غير موجود، لأن VFS الخاص بـ dd هو نظام ملفات المضيف خلف سجن مسار.

مقايضة صادقة: نواة مساحة المستخدم كاملة فقط بقدر استدعاءات النظام التي تنفذها، واليوم افتراضياً يعمل الضيف في عملية واحدة — سريع، والقرار الصحيح للكود الذي تثق به (بيئة التطوير، CI، أدواتك الخاصة). للكود غير الموثوق يوجد الآن انقسام حارس اختياري (DDJIT_UNTRUSTED): يعمل الضيف في صندوق رمل Seatbolt يمنع افتراضياً بدون أي صلاحيات مضيف لنظام الملفات/الشبكة، بينما عملية حارس موثوقة تمتلك الموارد الحقيقية وتخدم استدعاءات النظام عبر حلقة ذاكرة مشتركة — شكل gVisor. لا يزال مبكراً (استدعاءات نظام الملفات الأساسية — read/write/open/close/lseek — توجّه اليوم؛ المقابس/exec/fork قيد التطوير)، لذا للكود المعادي بالكامل لا تزال الآلة الافتراضية تعرض سطحاً أضيق.

الأداء

نفس ثنائي لينكس الثابت، يُشغّل بطريقتين على Apple M5 Pro (macOS 26.3): داخل آلة افتراضية لينكس (كيف تشغّل Docker القائمة على آلة افتراضية الحاويات) مقابل عبر JIT الخاص بـ dd على المضيف بدون آلة افتراضية. متوسط 7 (make bench). الوقت الأقل أفضل؛ "dd مقابل VM" > 1× يعني dd أسرع. حارة dd تدفع حتى ضريبة جسر عبر عملية صغيرة لا يدفعها التطبيق الحقيقي — لذا فهذه متحفّظة.

حاويات x86-64 — dd مقابل محاكاة آلة افتراضية (qemu-user؛ تشغيل x86 على Apple Silicon يعني ترجمتها في كلتا الحالتين). JIT الخاص بـ dd يتفوق على qemu في 9 من 10 أعباء العمل، بشكل كبير في الفاصلة العائمة:

عبء العمل	آلة افتراضية (qemu)	dd (بدون آلة افتراضية)	dd مقابل آلة افتراضية
float n-body	5.39s	0.23s	أسرع بـ 24×
mandelbrot	7.81s	0.83s	أسرع بـ 9.4×
matmul	8.21s	1.37s	أسرع بـ 6.0×
SQLite (600k rows)	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×)

حاويات aarch64 — dd مقابل آلة افتراضية أصلية (الآلة الافتراضية تشغّل arm64 بسرعة أصلية كاملة — أصعب معيار):

عبء العمل	آلة افتراضية (أصلية)	dd (بدون آلة افتراضية)	dd مقابل آلة افتراضية
int sieve	0.75s	0.48s	أسرع بـ 1.58×
mandelbrot	0.79s	0.77s	أسرع بـ 1.03×
matmul	0.66s	0.66s	~تكافؤ
memcpy	0.55s	0.56s	~تكافؤ
base64	0.68s	0.68s	~تكافؤ
float n-body	0.17s	0.17s	~تكافؤ
SHA-256	0.80s	0.82s	~تكافؤ
qsort	0.83s	1.10s	أبطأ بـ 1.33×
text-scan (wc/grep)	0.51s	0.68s	أبطأ بـ 1.35×
SQLite (600k rows)	0.36s	0.62s	أبطأ بـ 1.71×