كيفية تشغيل تطبيقات macOS على Linux باستخدام Darling في 2026

بدون هايبرفايزر، وبدون ترخيص macOS، وبدون قرص فيرتشوال ماشين بحجم 40 جيجابايت — فقط طبقة ترجمة تقف بين ملفات ماك التنفيذية ونواة لينكس لديك.

إذا وصلت إلى هذه المقالة، فمن المرجح أنك جربت من قبل تشغيل نظام ماك داخل فيرتشوال ماشين وكرهت التجربة — الأداء البطيء، حجم القرص الذي يتجاوز 40 جيجابايت، وحقيقة أنك تُشغّل نظام تشغيل آبل على عتاد لم تُصمَّم له أصلاً. لكن هناك مشروعاً أقل شهرة يتبع أسلوباً مختلفاً تماماً: بدلاً من محاكاة نظام تشغيل كامل داخل جهاز افتراضي، يقوم بترجمة استدعاءات نظام macOS (System Calls) إلى استدعاءات مكافئة في لينكس أثناء التشغيل مباشرة، بحيث يعمل الملف التنفيذي الخاص بماك مباشرة فوق نواة لينكس لديك. هذا المشروع اسمه Darling، وفي هذا الدليل سأوضح لك بالضبط ما يستطيع فعله وما لا يستطيعه في عام 2026 — وليس النسخة المتفائلة التي ستجدها في معظم صفحات التحميل.

سأقول هذا من البداية لأن معظم المقالات عن Darling تتجاهله: Darling ليست بديلاً بمستوى Wine لتطبيقات ماك. صفحة المشروع الرسمية على GitHub تنص بوضوح على أن معظم تطبيقات الواجهة الرسومية لا تعمل حالياً. إذا جئت إلى هنا أملاً في تشغيل Final Cut Pro أو بيئة Xcode الكاملة على أوبونتو، فهذا ليس ما يقدّمه المشروع اليوم. لكن ما هو مفيد فعلاً — أدوات سطر الأوامر، حزم Homebrew، بيئات تشغيل السكربتات، ومجموعة متنامية من البرامج النصية — لا يزال يستحق الفهم، خصوصاً إن كنت مطوراً تحتاج أحياناً لاختبار شيء مبني لنظام Darwin دون الاحتفاظ بجهاز ماك جانبك. يقف هذا المشروع إلى جانب أفضل أدوات مفتوحة المصدر لرفع الإنتاجية التقنية.

قضيتُ وقتاً في تجربة عملية بناء Darling من المصدر، ومراجعة توثيقه الرسمي وقوائم التوافق الخاصة به، وسأشرح لك خطوة بخطوة ما الذي يُثبَّت فعلاً، وما الذي يعمل فعلاً، وأين يعلق معظم المستخدمين عادةً. هذا ليس نسخاً من صفحة تسويق المشروع — هذا ما يحدث فعلياً عندما تتبع التعليمات على عتاد حقيقي.

أنا مصطفى أمان، وفي مدونة وادي التكنولوجيا أكتب أدلة عملية وخالية من المبالغة حول لينكس، الشبكات، والأدوات مفتوحة المصدر. لنبدأ.

Darling مقابل فيرتشوال ماشين macOS مقابل Wine: مقارنة سريعة

قبل أن تُخصّص عصراً كاملاً لبناء Darling من المصدر، من المفيد أن ترى كيف يُقارَن فعلياً بالخيارين اللذين يجربهما معظم الناس بدلاً منه: جهاز افتراضي (VM) يشغّل macOS، وطبقة توافق على طراز Wine.

أضفتُ Wine في هذا الجدول عمداً — كثير من الناس يخلطون بين الاثنين. Wine يترجم ملفات ويندوز التنفيذية لتعمل على لينكس؛ بينما يقوم Darling بنفس المهمة لملفات macOS التنفيذية. كلاهما يحل نفس نوع المشكلة لنظام تشغيل مصدر مختلف، وWine أكثر نضجاً بعقدين تقريباً من الزمن، وهذا بالضبط سبب تفوقه الكبير في دعم الواجهات الرسومية.

ما الذي يفعله Darling فعلياً (بالتجربة، لا بالتنظير)

بدلاً من البدء بتعريف نظري، إليك أبسط توضيح عملي لما يحدث خلف الكواليس في Darling. بمجرد التثبيت، هذه هي العملية الكاملة لتشغيل أول أمر macOS على لينكس:

$ darling shell echo Hello world
Hello world

هذا السطر الواحد يفعل شيئاً لا يستطيع أي فيرتشوال ماشين فعله: نفّذ فعلياً ملفاً تنفيذياً متوافقاً مع Darwin (وهو أمر echo)، من خلال محاكاة استدعاءات النظام ومكتبات وقت التشغيل الخاصة بـ Darling، دون أن يُقلع نظام تشغيل ثانٍ على الإطلاق. لا قرص افتراضي مُركَّب، ولا تسلسل إقلاع، ولا نواة منفصلة تعمل في الخلفية. العملية ذات النكهة macOS تتحدث مباشرة مع نواة لينكس لديك، وكل ما يحدث هو ترجمة فورية.

بنية الترجمة في Darling: يتم اعتراض استدعاءات Mach وواجهات Cocoa/Darwin وترجمتها مباشرة إلى عمليات نواة لينكس الأصلية.

هذا هو الفارق الجوهري الذي يستحق فهمه قبل تثبيت أي شيء: Darling طبقة توافق، وليست أداة محاكاة افتراضية. الفيرتشوال ماشين (أو الهايبرفايزر مثل KVM) يُنشئ جهازاً منفصلاً تماماً، بنواته الخاصة، يعمل بجانب نظامك. أما Darling فيُعيد بناء الأجزاء التي يحتاجها البرنامج من Darwin — النواة مفتوحة المصدر التي يُبنى عليها macOS — مثل Mach IPC، وطبقة POSIX، ومُحمِّل dyld، وlaunchd، بالإضافة إلى إعادة تنفيذ لأطر عمل آبل مثل Foundation وCoreFoundation. عندما يطلب ملف macOS التنفيذي شيئاً من "النواة"، يعترض Darling هذا الطلب ويُحوّله إلى نواة لينكس الحقيقية بصيغة تفهمها.

ما الذي يعمل فعلاً في 2026 (وهو الجزء الذي تتجاهله معظم المقالات)

هذا هو القسم الذي أردتُ كتابته أكثر من غيره، لأنه القسم الذي تتجاوزه كل مقالة أخرى عن Darling. قول "Darling يُشغّل تطبيقات ماك على لينكس" دون توضيح هذه الجملة يُعرّض القارئ لعصر محبط من التجربة والخطأ. إليك الصورة الصادقة، مباشرة من توثيق المشروع نفسه.

ما هو مؤكَّد أنه يعمل، بحسب ملاحظات التوافق الرسمية لـ Darling:

• Homebrew — مدير الحزم الخاص بماك يعمل فعلياً، وهذا يفتح الباب لتثبيت حزم أخرى موزَّعة عبر Homebrew.
• GNU Emacs 28.1 (نسخة الطرفية) — مُثبَّتة عبر Homebrew، ومؤكَّد أنها تعمل.
• Python 3 — كلٌّ من النسخة المُثبَّتة عبر Homebrew والنسخة 3.11 من python.org.
• CMake 3.23.2 — مُثبَّتة عبر Homebrew.
• GNUPlot — يعمل تحديداً عند التصدير إلى ملفات PNG بدلاً من نافذة تفاعلية.
• أدوات Xcode لسطر الأوامر — بما فيها مُصرِّف Clang، أي أنك تستطيع فعلياً تصريف وتشغيل ملف Mach-O تنفيذي من داخل Darling.
• EdenMath، آلة حاسبة علمية بسيطة — من التطبيقات الرسومية القليلة المؤكَّد عملها.

لاحظ النمط: كل ما في هذه القائمة هو أداة طرفية، أو بيئة تشغيل سكربتات، أو سلسلة أدوات بناء (Build Toolchain). هذا ليس صدفة. نظام "المكوّنات" (Components) الخاص بـ Darling يعكس هذا الواقع مباشرة — عند إعداد البناء، تختار المكوّنات التي تريد تصريفها، والمكوّنات المُوجَّهة لسطر الأوامر (core، system، cli) أكثر نضجاً بكثير من مكوّنات الواجهة الرسومية (gui، gui_frameworks).

إذا كنت لا تزال تُقيّم ما إذا كانت هذه هي الأداة المناسبة لما تحاول فعله، من المفيد أن تقرأ أيضاً هذا الدليل الأوسع حول ما الذي يتغيّر عند الانتقال من ويندوز إلى لينكس — الكثير من أسئلة "هل برنامجي سيعمل فعلاً؟" تنطبق هنا أيضاً.

تثبيت Darling على لينكس — الشرح الكامل خطوة بخطوة

Darling لا يأتي كحزمة جاهزة لمعظم التوزيعات — ستحتاج لبنائه من المصدر. لا تدع هذا يُخيفك؛ العملية قابلة للتكرار، تحتاج فقط وقتاً ومساحة قرص. إليك ما تحتاجه قبل البدء:

• توزيعة لينكس 64-بت (x86)، بنواة 5.0 أو أحدث. لا يدعم Darling أنظمة 32-بت إطلاقاً، حتى لتشغيل تطبيقات macOS القديمة ذات 32-بت.
• معالج يدعم SSE3 — أي معالج بيع خلال آخر 15+ سنة يستوفي هذا الشرط.
• Clang 11 أو أحدث للتصريف.
• على الأقل 4 جيجابايت رام للبناء، وحوالي 5 جيجابايت مساحة قرص لشجرة المصدر، بالإضافة إلى حتى 16 جيجابايت فارغة أثناء عملية البناء نفسها.

الخطوة 1: تثبيت متطلبات البناء

قائمة المتطلبات طويلة لأن Darling يُعيد بناء جزء كبير من بيئة تشغيل نظام تشغيل كامل. إليها لأكثر التوزيعات شيوعاً:

sudo apt install cmake automake clang-15 bison flex libfuse-dev libudev-dev pkg-config \
libc6-dev-i386 gcc-multilib libcairo2-dev libgl1-mesa-dev curl libglu1-mesa-dev \
libtiff5-dev libfreetype6-dev git git-lfs libelf-dev libxml2-dev libegl1-mesa-dev \
libfontconfig1-dev libbsd-dev libxrandr-dev libxcursor-dev libgif-dev libavutil-dev \
libpulse-dev libavformat-dev libavcodec-dev libswresample-dev libdbus-1-dev \
libxkbfile-dev libssl-dev libstdc++-12-dev

sudo dnf install make cmake clang bison dbus-devel flex glibc-devel.i686 fuse-devel \
systemd-devel elfutils-libelf-devel cairo-devel freetype-devel.{x86_64,i686} \
libjpeg-turbo-devel.{x86_64,i686} fontconfig-devel.{x86_64,i686} \
libglvnd-devel.{x86_64,i686} mesa-libGL-devel.{x86_64,i686} \
mesa-libEGL-devel.{x86_64,i686} mesa-libGLU-devel.{x86_64,i686} \
libtiff-devel.{x86_64,i686} libxml2-devel libbsd-devel git git-lfs libXcursor-devel \
libXrandr-devel giflib-devel pulseaudio-libs-devel libxkbfile-devel openssl-devel \
llvm libcap-devel libavcodec-free-devel libavformat-free-devel

sudo pacman -S --needed make cmake clang flex bison icu fuse gcc-multilib \
lib32-gcc-libs pkg-config fontconfig cairo libtiff mesa glu llvm libbsd libxkbfile \
libxcursor libxext libxkbcommon libxrandr ffmpeg git git-lfs

إذا كنت لا تزال تُقرّر أي توزيعة تستخدم لهذا الغرض أصلاً، فإن مقارنتنا لأفضل توزيعات لينكس للابتوب نقطة بداية جيدة — أوبونتو وفيدورا كلاهما لديه قوائم متطلبات ممتازة هنا، وهذا مهم عندما تُصرِّف مشروعاً بهذا الحجم.

الخطوة 2: استنساخ المصدر

يعتمد Darling على Git Submodules وGit LFS، لذا فإن أمر git clone العادي سيتركك بشجرة ملفات غير مكتملة. (إذا احتجت لمراجعة سريعة على سير عمل Git، راجع دليلنا للمبتدئين في Git وGitHub). تأكّد من تثبيت git-lfs أولاً، ثم استنسخ المستودع بشكل تكراري (Recursive):

GIT_CLONE_PROTECTION_ACTIVE=false git clone --recursive https://github.com/darlinghq/darling.git
cd darling

الخطوة 3: الإعداد والبناء

mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

بضع ملاحظات عملية كنتُ أتمنى معرفتها قبل بدء هذا بنفسي:

• make -j$(nproc) يوازي عملية البناء عبر أنوية معالجك — على خيط تنفيذ واحد قد يستغرق هذا البناء أكثر من ساعة بكثير. لا تتجاوز ضعف عدد الأنوية تقريباً وإلا ستُرهق ذاكرة الرام بدلاً من تسريع العملية.
• إذا لم تستطع إعداد مكتبات multilib لـ 32-بت، أضف -DTARGET_i386=OFF إلى أمر cmake لبناء مكوّنات 64-بت فقط. RHEL 10 يتطلّب هذا فعلياً، لأن مكتبات 32-بت أُزيلت تماماً من ذلك الإصدار.
• تحتاج الأساسيات فقط؟ مرّر -DCOMPONENTS=cli,python لتخطّي مكوّنات الواجهة الرسومية الثقيلة والحصول على شِل يعمل بشكل أسرع بكثير.
• تثبيت Darling غير قابل للنقل — مسار التثبيت مُضمَّن بشكل ثابت داخل الملفات التنفيذية. إذا احتجت لنقله لاحقاً، احذفه أولاً باستخدام tools/uninstall وأعِد البناء بمسار CMAKE_INSTALL_PREFIX جديد.

تشغيل أول برنامج macOS على Darling

بمجرد انتهاء التثبيت، يُنشئ Darling ما يُسمّى DPREFIX — وهو من الناحية المفاهيمية مطابق لبادئة Wine (Wine Prefix)، بيئة شبيهة بـ chroot ذات هيكل ملفات على طراز macOS يتم تثبيت البرامج بداخلها. يُنشأ تلقائياً في ~/.darling عند أول استخدام لـ Darling.

من هنا، الدخول إلى شِل Darling وتثبيت Homebrew هي الخطوة الأولى الأكثر موثوقية، لأنها تفتح الباب لأكبر مجموعة من البرامج المؤكَّد عملها:

$ darling shell
Darling [~]$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Darling [~]$ brew install python3

يمكنك أيضاً تثبيت حزم .pkg القياسية مباشرة باستخدام أداة installer الخاصة بـ Darling، وتركيب أقراص .dmg باستخدام hdiutil — كلاهما يعمل من داخل الشِل، بنفس الطريقة التي تتعامل بها معهما على ماك حقيقي.

التصريف باستخدام سلسلة أدوات آبل نفسها

من الأشياء المثيرة للإعجاب فعلياً في Darling أنه يتيح لك تصريف وتشغيل ملف Mach-O تنفيذي باستخدام مُصرِّف Clang الحقيقي الخاص بآبل — المُستخرَج من أرشيف Xcode بصيغة .xip ويعمل عبر أداة unxip الخاصة بـ Darling:

cd /Applications
unxip Xcode_11.3.xip
export SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
echo 'void main() { puts("Hello world"); }' > helloworld.c
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang helloworld.c -o helloworld
./helloworld

هذا الأمر الأخير يُصرِّف وينفِّذ فعلياً ملفاً تنفيذياً حقيقياً لماك، مبنياً بمُصرِّف آبل نفسه، ويعمل على لينكس دون أي محاكاة افتراضية. إنه اختبار ممتاز للتأكد من نجاح البناء لديك، وهو أقرب شيء إلى "Xcode على لينكس" موجود حالياً — لاحظ أن بيئة Xcode المرئية (IDE) نفسها لا تعمل، بل فقط سلسلة أدواتها لسطر الأوامر.

معضلة Apple Silicon: هل يستطيع Darling تشغيل تطبيقات macOS بمعمارية ARM64 على لينكس؟

مع انتقال آبل بالكامل إلى معالجات Apple Silicon (سلسلة M)، أصبحت شبه كل برمجيات macOS الحديثة مُصرَّفة لمعمارية ARM64 (aarch64). سؤال شائع بين مطوري لينكس هو هل يستطيع Darling تشغيل هذه الملفات التنفيذية الحديثة لماك على أجهزة PC بمعمارية x86_64 القياسية.

الإجابة المختصرة هي: Darling طبقة ترجمة واجهات برمجية (API)، وليس محاكياً لتعليمات المعالج. فهم هذا الفارق أمر أساسي:

• كيف يعمل Darling: على نظام لينكس بمعمارية x86_64، ينفّذ Darling ملفات Mach-O التنفيذية بمعمارية x86_64 مباشرة على المعالج الفعلي لديك. هو يترجم استدعاءات نظام التشغيل (Mach وPOSIX)، لكنه لا يُحوّل تعليمات معالج ARM إلى تعليمات x86. لا يملك محرك ترجمة معالج مدمجاً مثل Rosetta 2 من آبل.
• الملفات التنفيذية الشاملة (Universal 2 / "Fat"): كثير من حزم macOS تُوزَّع كملفات Universal، تحتوي على شفرة آلة لكل من arm64 وx86_64. مُحمِّل Darling الديناميكي (dyld) يفحص الملف تلقائياً، ويستخرج شريحة x86_64، ويُشغّلها دون مشاكل. يمكنك فحص أي ملف تنفيذي باستخدام أمر lipo -info binary_name.
• الملفات التنفيذية المخصصة لـ ARM64 فقط: إذا صرّف مطوّر أداة سطر أوامر لماك حصرياً لمعمارية Apple Silicon دون شريحة x86_64، فسيُظهر Darling على PC بمعمارية x86_64 خطأ Bad CPU type in executable. لتشغيل ملفات macOS التنفيذية بمعمارية ARM64 فقط على لينكس، ستحتاج إما لتشغيل Darling على لوحة لينكس بمعمارية ARM64 (مثل Ampere أو راسبيري باي بنسخ تجريبية)، أو إضافة طبقة محاكاة QEMU في وضع المستخدم أسفل Darling.

إدارة واستكشاف أخطاء خدمة darlingserver

خلف كل جلسة darling shell تعمل خدمة خلفية أساسية تُدعى darlingserver. تعمل كمُنسِّق لنواة Mach، وتُحاكي التواصل بين العمليات في Darwin (Mach IPC)، ودورة حياة العمليات، وأنظمة launchd الفرعية. عندما يتعلّق Darling أو يتصرّف بشكل غير متوقّع، تكون المشكلة غالباً خدمة darlingserver عالقة أو يتيمة.

كيفية إعادة تعيين جلسة Darling عالقة

إذا كان تنفيذ darling shell يتعلّق بلا نهاية أو يُظهر رسالة Cannot connect to darlingserver، اتبع سلسلة الاستعادة التالية في طرفية لينكس:

# 1. محاولة إيقاف نظام Darling الفرعي بشكل سليم
darling shutdown

# 2. إذا ظل عالقاً، أنهِ العمليات اليتيمة للخدمة
killall -9 darlingserver 2>/dev/null

# 3. تنظيف مقابس (Sockets) يونكس القديمة وأقفال IPC
rm -rf /tmp/darling-$USER /run/user/$(id -u)/darling*

# 4. تحقّق من عدم وجود تركيبات overlay متبقية
grep -E 'darling|overlay' /proc/mounts

التشغيل داخل Docker أو حاويات CI/CD: إذا كنت تُصرِّف أو تختبر Darling داخل حاوية Docker، فإن darlingserver يحتاج صلاحيات (Capabilities) معيّنة من نواة لينكس. تأكّد من تشغيل الحاوية بالخيارات --cap-add=SYS_ADMIN --cap-add=SYS_PTRACE --security-opt seccomp=unconfined، وإلا سيفشل تواصل IPC بصمت أثناء تهيئة البادئة (Prefix).

هل هذا قانوني؟ التفصيل الذي تتجاهله معظم المقالات

هذا السؤال يتكرر في كل نقاش تقريباً حول Darling، لذا يستحق تناولاً مباشراً بدلاً من التجاهل. Darling نفسه — شفرة المشروع — قانوني ومفتوح المصدر. مبني من أجزاء Darwin التي أطلقتها آبل علناً كبرمجيات مفتوحة المصدر، بالإضافة إلى إعادة تنفيذ من المجتمع لأطر عمل أعلى مستوى مثل Cocoa (بالاستناد إلى مشروعي The Cocotron وGNUstep). فريق المشروع واضح بأنهم يستخدمون فقط مكوّنات Darwin التي أطلقتها آبل فعلياً كبرمجيات حرة.

الجزء الأكثر غموضاً هو البرنامج الذي تختار تشغيله داخل Darling. اتفاقية ترخيص برمجيات macOS من آبل تُقيّد تاريخياً تشغيل برمجيات ماك على عتاد غير آبل، وهي نفس المنطقة الرمادية التي تنطبق على تشغيل فيرتشوال ماشين macOS على عتاد غير آبل، أو ما يُعرف بـ Hackintosh. Darling يتفادى جزءاً من هذا النقاش لأنه لا يُشغّل برمجيات نظام macOS المرخّصة فعلياً من آبل — بل يُعيد بناء البيئة التي تتوقّعها تلك التطبيقات. لكن إذا ثبّتَّ تطبيقاً مملوكاً معيّناً لماك داخل Darling، فإن شروط ترخيص ذلك التطبيق نفسه لا تزال تنطبق عليك، تماماً كما في أي مكان آخر.

لستُ محامياً، وهذا ليس استشارة قانونية — إذا كنت تفعل أي شيء يتجاوز التجربة الشخصية بأدوات سطر أوامر مفتوحة المصدر، يستحق الأمر قراءة الترخيص المحدد لأي برنامج تُشغّله.

5 أخطاء يقع فيها المستخدمون عند تجربة Darling

1. توقّع دعم كامل لتطبيقات الواجهة الرسومية. هذا هو المصدر الأكبر للإحباط. ادخل التجربة متوقعاً بيئة شِل أفضل وسلسلة أدوات Clang تعمل، لا سطح مكتب ماك.
2. تجربة هذا على مجلد رئيسي مُشفَّر. نظام DPREFIX الخاص بـ Darling يعتمد على overlayfs، ويفشل بصمت على المجلدات الرئيسية المُشفَّرة بـ eCryptfs أو المُركَّبة عبر NFS. تحقّق من هذا قبل أن تُمضي ساعة في تصحيح بناء نجح فعلياً.
3. استخدام git clone عادي بدلاً من استنساخ تكراري. يعتمد Darling بشكل كبير على الـ Submodules. الاستنساخ السطحي وغير التكراري يترك نصف شجرة المصدر مفقوداً ويفشل البناء بطرق مُربكة.
4. ذاكرة رام غير كافية أثناء البناء. تحت 4 جيجابايت، إما يفشل التصريف مباشرة أو يبدأ النظام بالتبديل (Swap) بشكل مفرط لدرجة يبدو فيها متعلّقاً لساعات. إذا كنت على فيرتشوال ماشين أو حاوية قليلة الذاكرة، ابنِ في مكان آخر أو أضف ذاكرة Swap أولاً.
5. نقل مجلد التثبيت لاحقاً. يُضمِّن Darling مسار التثبيت بشكل ثابت داخل الملفات التنفيذية نفسها. إذا نقلت المجلد بدلاً من إلغاء التثبيت وإعادة البناء بشكل صحيح، ستحصل على أخطاء غامضة من نوع "cannot mount overlay" دون سبب واضح.

تحتاج تطبيقات ماك الرسومية كاملة؟ بدائل الفيرتشوال ماشين الحديثة (Docker-OSX مقابل OSX-KVM)

إذا كان هدفك الفعلي تشغيل برمجيات رسومية — مثل لوحة Storyboard/SwiftUI الكاملة في Xcode، أو Sketch، أو Final Cut Pro، أو Safari — فلن يُلبّي Darling احتياجك اليوم. بدلاً من قضاء ساعات في محاولة إجبار أطر عمل الواجهة الرسومية على العمل داخل Darling، توفّر أدوات المحاكاة الافتراضية الحديثة المُسرَّعة بـ KVM أداءً قريباً من الأصلي على محطات عمل لينكس.

1. Docker-OSX (SickCodes)

يُغلِّف Docker-OSX تثبيت macOS كامل مُحاكى عبر QEMU/KVM داخل حاوية Docker. يُؤتمت العملية بأكملها — إنشاء القرص، تحميل المُثبِّت، وإعداد محمّل الإقلاع — بأمر واحد. مع تمرير عرض X11/Wayland وتوجيه صوت PulseAudio، يُشغّل أسطح مكتب macOS Sonoma/Sequoia كاملة مباشرة في نافذة لينكس بسرعات معالج قريبة من الأصلية.

2. OSX-KVM (kholia)

للمستخدمين المتقدمين وأجهزة الهايبرفايزر المخصصة (مثل خوادم المختبرات المنزلية التي تُشغّل Proxmox VE)، يُعَدّ OSX-KVM المعيار الذهبي. يوفّر سكربتات QEMU خام مع محمّلات إقلاع OpenCore، ويتيح تمرير كروت PCIe مخصصة (كروت AMD Radeon) للحصول على تسريع رسومي حقيقي بمعيار Metal 3.

3. Sosumi (حزمة Snap)

إذا كنت على أوبونتو وتريد فيرتشوال ماشين macOS رسومياً بدون إعدادات معقّدة وبدون كتابة خيارات QEMU مُعقّدة، فإن Sosumi متاح كحزمة Snap بنقرة واحدة (sudo snap install sosumi). يُدير صور القرص وتخصيص الذاكرة تلقائياً، ويوفّر بوابة سهلة للتجربة.

متى تستخدم Darling ومتى تُشغّل فيرتشوال ماشين ببساطة

من واقع ما رأيته، القرار عادةً ما يعتمد على سؤال واحد: هل تحتاج تطبيق ماك محدداً، أم تحتاج بيئة بنكهة Darwin؟ إذا كان الأول — تحتاج تطبيق ماك رسومي حقيقي يفتح ويعمل بشكل طبيعي — فإن Darling ليس هناك بعد، وفيرتشوال ماشين macOS حقيقي (يعمل بشكل قانوني على عتاد آبل) أو استعارة وقت على جهاز ماك فعلي لا يزال هو الحل العملي. أما إذا كان الثاني — تريد اختبار سكربت بناء، أو تصريف شيء مقابل SDKs خاصة بماك، أو تشغيل أداة سطر أوامر تُوزَّع لـ Darwin فقط — فإن Darling يُوفِّر عليك عبء تشغيل وصيانة فيرتشوال ماشين كامل.

إذا كان اهتمامك بـ Darling نابعاً من تجربة لينكس بشكل عام أكثر من احتياج توافق محدد مع ماك، يستحق الأمر أيضاً استعراض ما يستحق إعداده بعد تثبيت جديد — دليلنا حول ما يجب فعله بعد تثبيت لينكس يغطّي القائمة الأوسع، وإذا كانت المحاكاة الافتراضية بشكل عام هدفك أكثر من ماك تحديداً، فإن مقارنتنا بين VMware وProxmox نقطة بداية أفضل من Darling تماماً.

خلاصة القول

Darling من تلك المشاريع التي يسهل تضخيمها بقدر ما يسهل التقليل من شأنها — ولا واحد من الأمرين منصف له. لن يُغنيك عن جهاز ماك، ولن يُشغّل تطبيق التصميم المفضل لديك مساء الغد. لكن كطريقة للحصول على شِل حقيقي متوافق مع Darwin، وتشغيل Homebrew، والتصريف مقابل SDKs الخاصة بآبل نفسها دون لمس هايبرفايزر، فهو يفعل شيئاً لا تُقدّمه حالياً أي أداة فيرتشوال ماشين أو أداة على طراز Wine على لينكس. بعد اثني عشر عاماً من التطوير، لا يزال مشروعاً للمطورين والهواة أكثر من كونه حلاً جاهزاً للمستخدم العادي — والصراحة بهذا من البداية ستُوفّر عليك عصراً محبطاً أول تجربة لك معه.

إذا نجحت في تشغيله، ابدأ صغيراً: تثبيت Homebrew وتصريف "Hello world" عبر Clang الخاص بآبل هدف واقعي ومُرضٍ كبداية. مطاردة تطبيق رسومي كامل من اليوم الأول هي أسرع طريقة للاستسلام أمام مشروع هندسي مفتوح المصدر مثير للاهتمام فعلاً.

الأسئلة الشائعة