dd

macOS पर Linux कंटेनर चलाएँ — बिना किसी VM के।

dd क्या है?

dd Apple-Silicon macOS पर बिना किसी वर्चुअल मशीन के मूल रूप से Linux कंटेनर चलाता है। इसके नीचे कोई Linux कर्नेल या हाइपरवाइज़र नहीं है: एक JIT कंटेनर के कोड का अनुवाद करता है और इसके Linux syscalls को userspace में सेवा प्रदान करता है (gVisor / PRoot वंशावली)। JIT ही अतिथि का Linux कर्नेल है — नेमस्पेस, cgroups, ओवरले इमेज लेयर और नेटवर्किंग को userspace स्थिति के रूप में बनाए रखा जाता है। यह Docker Engine API बोलता है, इसलिए सामान्य docker CLI इसे चलाता है।

कंटेनर का compute मूल Apple-Silicon निर्देशों के रूप में चलता है; केवल इसके syscalls की व्याख्या की जाती है। बूट करने के लिए कोई VM नहीं, VM में कोई डेमन नहीं, कोई वर्चुअलाइज़ेशन लागत नहीं।

वेबसाइट और दस्तावेज़: https://ricccrd.github.io/dd/

make jit                                          # build.rs JITs को संकलित और कोडसाइन करता है
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)'

विशेषताएँ

• कोई वर्चुअल मशीन नहीं। कोई हाइपरवाइज़र नहीं, कोई Linux कर्नेल नहीं, कोई VM स्थायी रूप से निवासी नहीं। अतिथि के निर्देश arm64 पर मूल रूप से चलते हैं; केवल syscall सीमा को userspace में ट्रैप और सेवा दी जाती है।
• ड्रॉप-इन Docker। dd Docker Engine API को लागू करता है। DOCKER_HOST को इसके सॉकेट पर इंगित करें और आपके मौजूदा docker run / ps / images / build कमांड बिना किसी बदलाव के काम करते हैं।
• JIT ही कर्नेल है। नेमस्पेस, cgroups, ओवरले इमेज लेयर और नेटवर्किंग सामान्य userspace स्थिति हैं — gVisor / PRoot वंशावली में एक userspace कर्नेल, जिसमें VM की कोई लागत नहीं है।
• तीन अतिथि रनटाइम, एक इंजन। मूल arm64 Linux इमेज; एक JIT (jit86) के माध्यम से x86-64 Linux इमेज जो x86 को डिकोड करता है, इसके फ़्लैग्स को संश्लेषित करता है, और SSE/x87 को NEON पर कम करता है (glibc बाइनरी चलती हैं); और macOS arm64 अतिथि (ddcli mac) — इनमें से किसी में भी कोई VM नहीं।
• वास्तविक कंटेनर आइसोलेशन। ओवरले इमेज लेयर्स (कॉपी-अप / .wh. व्हाइटआउट, मर्ज किया गया getdents), एक TOCTOU-मुक्त पथ-जेल VFS, PID / UTS / USER नेमस्पेस, -p पोर्ट पब्लिशिंग के साथ एक निजी लूपबैक netns, और cgroup मेमोरी + pids सीमाएँ (सीमा पर OOM)।
• डेस्कटॉप ऐप, कोई रूट नहीं। एक मूल GTK4 ऐप (dd-app) और एक dd CLI एक प्रति-उपयोगकर्ता बैकग्राउंड डेमन और एक docker context स्थापित करते हैं — सब कुछ के अंतर्गत, कभी नहीं।

JIT क्यों, VM क्यों नहीं?

Mac पर Linux कंटेनर चलाने का हर दूसरा तरीका — Docker Desktop, Colima, Rancher, OrbStack — एक हाइपरवाइज़र के नीचे एक Linux VM बूट करता है और उसके अंदर डेमन चलाता है। वह VM एक कर है जो आप पूरे दिन चुकाते हैं। dd इसे हटा देता है: एक कंटेनर एक सामान्य macOS प्रक्रिया है जिसके syscalls एक userspace Linux कर्नेल द्वारा सेवा किए जाते हैं।

जीत संरचनात्मक है: अतिथि का compute मूल Apple-Silicon निर्देशों के रूप में चलता है (हॉट पथ में कोई हार्डवेयर-वर्चुअलाइज़ेशन लेयर नहीं), और कुख्यात Docker-Desktop फ़ाइल-शेयरिंग अड़चन — macOS और VM के बीच virtiofs/FUSE ब्रिज — बस मौजूद नहीं है, क्योंकि dd का VFS है होस्ट फ़ाइल सिस्टम एक पथ जेल के पीछे।

ईमानदार समझौता: एक userspace कर्नेल केवल उतना ही पूर्ण है जितने कि वह syscalls लागू करता है, और आज डिफ़ॉल्ट रूप से अतिथि एक प्रक्रिया में चलता है — तेज़, और उस कोड के लिए सही कॉल जिस पर आप भरोसा करते हैं (आपका देव वातावरण, CI, आपके अपने टूल्स)। अविश्वसनीय कोड के लिए अब एक ऑप्ट-इन सेंट्री स्प्लिट है (DDJIT_UNTRUSTED): अतिथि एक डिफ़ॉल्ट-अस्वीकार Seatbelt सैंडबॉक्स में चलता है जिसमें कोई होस्ट fs/net अधिकार नहीं है, जबकि एक विश्वसनीय sentry प्रक्रिया वास्तविक संसाधनों की मालिक है और एक साझा-मेमोरी रिंग — gVisor आकार — में syscalls की सेवा करती है। यह शुरुआती है (कोर फ़ाइल syscalls — read/write/open/close/lseek — आज आगे बढ़ते हैं; sockets/exec/fork आ रहे हैं), इसलिए पूरी तरह से शत्रुतापूर्ण कोड के लिए एक VM अभी भी एक संकीर्ण सतह उजागर करता है।

प्रदर्शन

एक ही स्थैतिक Linux बाइनरी, दो तरीकों से चलाई गई एक Apple M5 Pro (macOS 26.3) पर: Linux VM के अंदर (VM-आधारित Docker कंटेनर कैसे चलाता है) बनाम dd के JIT के माध्यम से होस्ट पर बिना VM के। 7 का माध्य (make bench)। कम समय बेहतर है; "dd बनाम VM" > 1× का अर्थ है dd तेज़ है। dd लेन एक छोटा क्रॉस-प्रोसेस ब्रिज टैक्स भी चुकाता है जो वास्तविक ऐप नहीं करता — इसलिए ये रूढ़िवादी हैं।

x86-64 कंटेनर — dd बनाम VM एमुलेशन (qemu-user; Apple Silicon पर x86 चलाने का अर्थ है इसे अनुवाद करना किसी भी तरह से)। dd का JIT 10 में से 9 वर्कलोड पर qemu को हराता है, विशेष रूप से फ़्लोटिंग-पॉइंट पर नाटकीय रूप से:

aarch64 कंटेनर — dd बनाम एक मूल VM (VM arm64 को पूर्ण मूल गति पर चलाता है — सबसे कठिन बार):

dd arm64 compute को मूल गति पर चलाता है — int sieve + mandelbrot पर आगे, SHA-256, matmul, memcpy, n-body, और base64 पर समानता पर। शेष अंतर अप्रत्यक्ष-शाखा / syscall-भारी कार्य हैं — qsort (~1.3×), text-scan (~1.35×) और SQLite (~1.5×) — नवीनतम पासों द्वारा तेजी से कम किया गया (§B-off + चुराया गया x16/x17 SQLite को ~1.9× से ~1.5× पर ले गया)। बाकी को बंद करना (VDBE डिस्पैच) सक्रिय सीमा है; देखें docs/design/arm-sqlite-parity.md। (प्रत्येक वर्कलोड ≥0.45s चलने के लिए आकार दिया गया है, इसलिए हार्नेस का छोटा प्रति-रन ब्रिज टैक्स यहाँ नगण्य है।)

ये compute माइक्रो-बेंचमार्क हैं — वे dd के संरचनात्मक लाभों (बूट करने के लिए कोई VM नहीं, कोई निवासी RAM नहीं, प्रत्यक्ष होस्ट-फ़ाइलसिस्टम I/O) को भी कैप्चर नहीं करते हैं। सभी संख्याएँ मापी गईं, 7 का माध्य। पुनरुत्पादन: make bench।

लक्ष्य VM को हर बेंचमार्क पर हराना है। dd पहले से ही ऊपर प्रत्येक x86-64 वर्कलोड जीतता है और मूल arm64 से मेल खाता है या हराता है; जहाँ यह अभी भी पीछे है — syscall/आवंटन-भारी arm64 SQLite, और x86 अनुवादक से अधिक निचोड़ना — वही अनुकूलन सीमा है (टियर-2 ट्रेस ऑप्टिमाइज़र और jit86 प्रदर्शन कार्य)। हर जगह समानता-या-बेहतर बार है।

यह कैसे काम करता है

dd एक Linux कंटेनर को userspace में इसके कर्नेल होने के द्वारा चलाता है। एक JIT अतिथि की मशीन कोड का अनुवाद करता है और प्रत्येक syscall निर्देश को ट्रैप करता है; ट्रैप हैंडलर — dd-jit/src/runtime/os/linux/ में service() — है Linux syscall ABI, macOS होस्ट के विरुद्ध कार्यान्वित।

1. लोड अतिथि ELF (static-PIE, या इसके ld.so के माध्यम से गतिशील) और प्रारंभिक स्टैक का निर्माण करें।
2. अनुवाद और डिस्पैच ब्लॉक-दर-ब्लॉक अतिथि PC; समान-ISA कोड ज्यादातर लिप्यंतरित होता है, x86-64 को डिकोड किया जाता है और arm64 पर पुनः उत्सर्जित किया जाता है।
3. चलाएँ अनुवादित ब्लॉक को मूल होस्ट कोड के रूप में जब तक एक टर्मिनेटर (शाखा / अप्रत्यक्ष जंप / syscall) न हो।
4. सेवा syscall — प्रत्येक पथ कंटेनर VFS जेल से गुज़रता है; नेमस्पेस और cgroups केवल प्रक्रिया स्थिति हैं।

उदाहरण

# 1. डेमन शुरू करें, docker को इस पर इंगित करें
make jit
DD_IMAGES=/path/to/images cargo run -p dd-daemon
export DOCKER_HOST=unix://$PWD/dd.sock

# 2. यह बस Docker है
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
docker ps
docker images
docker run --rm -it ubuntu bash

# 3. या स्थापित डेस्कटॉप ऐप के माध्यम से (प्रति-उपयोगकर्ता, कोई रूट नहीं)
dd install                                  # LaunchAgent + docker context
dd app                                       # GUI खोलें
docker --context dd run alpine echo hi

स्थापना

dd Apple-Silicon macOS (arm64, macOS 12+) को लक्षित करता है। JIT को Xcode Command Line Tools (clang + codesign) की आवश्यकता है।

ऐप डाउनलोड करें (अनुशंसित)

नवीनतम .dmg को रिलीज़ पेज से प्राप्त करें, इसे खोलें, और dd को Applications में खींचें। फिर एक टर्मिनल में:

dd install     # ~/.dd ट्री + प्रति-उपयोगकर्ता LaunchAgent + `docker context create dd`
dd app         # GUI खोलें
dd doctor      # सॉकेट / एजेंट / कॉन्टेक्स्ट / ऐप क्वारंटाइन जाँचें

गेटकीपर: DMG अहस्ताक्षरित (ad-hoc) है। पहले लॉन्च पर, राइट-क्लिक करें ऐप पर → Open, या चलाएँ xattr -dr com.apple.quarantine /Applications/dd-app.app (dd doctor इसका पता लगाता है और फिक्स प्रिंट करता है)।

स्रोत से निर्माण

xcode-select --install                       # clang + codesign
# Rust (stable) और Nix (GTK4 देव शेल के लिए) स्थापित करें
git clone https://github.com/ricccrd/dd && cd dd
make app       # बिल्ड + असेंबल & ad-hoc-साइन target/dd-app.app
make dmg       # -> target/dist/dd-<ver>-<arch>.dmg
make install   # Applications में कॉपी करें और `dd install` चलाएँ

make app/dmg Nix देव शेल (nix/flake.nix) के अंदर बंडलिंग चलाते हैं, जो GTK4 + dylibbundler / create-dmg प्रदान करता है। बंडल GTK dylib ग्राफ को Contents/Frameworks में स्थानांतरित करता है, GTK रनटाइम डेटा को स्टेज करता है, और आंतरिक→बाहरी ad-hoc-साइन करता है।

वर्कस्पेस

एक Cargo वर्कस्पेस।

• dd-jit/ — JIT रनटाइम (C, src/runtime/ के अंतर्गत) साथ ही इसके Rust बाइंडिंग्स। build.rs प्रति अतिथि आर्किटेक्चर (aarch64, x86_64) एक JIT बाइनरी संकलित और कोडसाइन करता है; src/lib.rs Guest + टाइप किया गया SpawnConfig लॉन्च कॉन्ट्रैक्ट उजागर करता है। aarch64 अतिथि पूरी तरह से विघटित है (jit/ इंजन + os/linux/ व्यक्तित्व + frontend/aarch64/); x86-64 अतिथि (jit86) os/linux/ परत साझा करता है।
• dd-daemon/ — Docker Engine API डेमन। प्रत्येक इमेज के अतिथि आर्किटेक्चर को उसके ELF से पहचानता है, मिलान करने वाला JIT चुनता है, और इसे के माध्यम से लॉन्च करता है।

डेमन ~/.dd/run/docker.sock पर सुनता है; GUI और docker --context dd दोनों इसका उपयोग करते हैं। स्थिति ~/.dd/state.json में बनी रहती है।

परीक्षण

make test                       # इंजन × केस मैट्रिक्स, समूहीकृत रिपोर्ट
make test ENGINE=x86_64         # एक इंजन
make test FILTER=container      # एक समूह / नाम से मेल खाने वाले मामले
cargo run -p dd-tests -- --list # समूह + मामले सूचीबद्ध करें
make test-ci                    # cargo-test पथ (CI)

मामले dd-tests/src/cases/ में घोषित किए गए हैं। एक मामला एक अतिथि प्रोग्राम + अभिकथन है; aarch64 अतिथि को मौके पर संकलित किया जाता है (gcc -static-pie) और एक मूल ओरेकल के विरुद्ध विभेदित किया जाता है, x86-64 अतिथि पूर्व-निर्मित फिक्स्चर से आते हैं। प्रत्येक मामला हर इंजन पर चलता है जिसके लिए उसके पास एक अतिथि है।

स्थिति

• अतिथि: Linux aarch64 (विघटित, पूर्ण कंटेनर इंजन) + x86-64 (jit86, glibc चलाता है)।
• होस्ट: macOS arm64 (Apple Silicon)। JIT को clang + codesign (Xcode CLT) की आवश्यकता है।
• कंटेनर: rootfs + ओवरले इमेज लेयर्स (कॉपी-अप/व्हाइटआउट), बाइंड वॉल्यूम, पोर्ट पब्लिशिंग (-p), निजी-लूपबैक netns, cgroup मेमोरी+pids सीमाएँ, UTS/PID/USER नेमस्पेस।
• रोडमैप: OCI रजिस्ट्री पुल/अनपैक, साझा इंजन पर jit86 डिडुप, एक पूर्ण बाहरी नेटस्टैक, और अविश्वसनीय इमेज के लिए सेंट्री स्प्लिट। विस्तृत लेखन के लिए docs/ देखें।

लेखक

Richard Hutta — [email protected]

लाइसेंस

MIT।