WSL Containers مقابل Docker Desktop على ويندوز 11: هل wslc جاهز في 2026؟

مايكروسوفت أدخلت محرك حاويات لينكس حقيقياً داخل WSL نفسه — بدون Docker Desktop على الإطلاق. هذا ما اكتشفته بعد اختباره فعلياً.

إذا كنت تُشغّل Docker Desktop على ويندوز لمجرد تشغيل حاوية Linux بسيطة، فهذا لم يعد الخيار الوحيد المتاح أمامك بعد الآن. أضافت مايكروسوفت محرك حاويات أصلياً مدمجاً مباشرة داخل Windows Subsystem for Linux، أطلقت عليه اسم WSL Containers (أداة سطر الأوامر الخاصة به هي wslc). الأداة تسحب صور OCI، تُشغّلها، وتدير دورة حياتها بالكامل — دون الحاجة لتثبيت أي محرك خارجي من طرف ثالث.

قضيتُ أسبوعاً كاملاً في اختبار wslc على جهاز حقيقي يعمل بنظام ويندوز 11: التثبيت، قياسات الأداء، حاويات GPU، الشبكات، التكامل مع VS Code، وفجوة أداة Compose التي كانت أكبر شكوى منذ إطلاقه. باختصار — الأداة جيدة فعلاً للعمل البرمجي اليومي، لكن فيها علة تُسرّب الذاكرة، وبعض السلوكيات الافتراضية التي ستوقعك في حيرة إن لم يُنبّهك أحد لها مسبقاً. وهذا بالضبط ما سيغطيه هذا الدليل.

أنا مصطفى أمان، وفي مدونة وادي التكنولوجيا أكتب أدلة عملية ومُختبَرة فعلياً حول ويندوز، لينكس، والأدوات التي تربط بينهما. لنبدأ.

WSL Containers مقابل Docker Desktop مقابل Podman Desktop — مقارنة سريعة

قبل الدخول في التفاصيل الكاملة، إليك كيف تقف الطرق الثلاث الرئيسية لتشغيل حاويات لينكس على ويندوز أمام بعضها البعض في الوقت الحالي:

ما هو WSL Containers فعلياً؟

تخيّل المشهد التالي: تفتح الطرفية على نسخة ويندوز 11 حديثة التثبيت، بلا Docker Desktop، بلا Podman، بلا أي شيء إضافي مُنزَّل. تكتب أمراً واحداً، وبعد ثوانٍ قليلة تجد نفسك داخل shell حقيقي للينكس، مدعوم بنواة Linux فعلية — ليست طبقة ترجمة، وليست محاكاة توافقية. هذا هو جوهر فكرة WSL Containers بالكامل، وهو تحوّل معماري أكبر بكثير مما يوحي به الاسم.

WSL Containers — ويُختصر غالباً إلى wslc أو WSLC — هو محرك حاويات بنته مايكروسوفت مباشرة داخل Windows Subsystem for Linux. أُعلن عنه كإصدار تجريبي عام (Public Preview) خلال مؤتمر Build 2026، وهو يعيش حالياً في القناة التجريبية (Pre-release) من WSL. للاطّلاع على التوثيق الرسمي، يمكنك زيارة توثيق مايكروسوفت الرسمي لـ WSL. تأتي الأداة على جزأين:

• أداة سطر الأوامر. wslc.exe، ولها اسم مستعار هو container.exe. بناء أوامرها يُحاكي عمداً بناء أوامر Docker — wslc run، wslc build، wslc pull — بحيث تنتقل عادتك السابقة معك بشكل شبه كامل، عدا بعض الأوامر التي انتقلت لبنية قائمة على الأسماء (Noun-based) مثل wslc container list بدلاً من docker ps.
• واجهة برمجية (API). حزمة NuGet بروابط C وC++ وC#، بحيث يستطيع مطوّرو تطبيقات ويندوز تشغيل حاوية لينكس بصمت داخل تطبيقهم لتنفيذ كود يعمل فقط على لينكس، ثم إغلاقها، دون أن يطلبوا من المستخدم تثبيت أي شيء.

الجزء الأهم في كيفية تصرّف الأداة يومياً هو البنية المعمارية نفسها. Docker Desktop يُشغّل محرّكه كتوزيعة داخل الآلة الافتراضية المشتركة الواحدة لـ WSL — أي كل حاوية تُشغّلها تعيش في نفس تلك الآلة الافتراضية إلى جانب توزيعات WSL الأخرى لديك. أما WSL Containers فيفعل العكس تماماً: كل جلسة تحصل على آلة افتراضية جديدة ومعزولة بالكامل، تُسمّى باسم حساب مستخدم ويندوز الخاص بك. هذا العزل هو سبب وجودها من الأساس، وهو أيضاً مصدر أغلب الغرائب التي سنتحدّث عنها في هذا الدليل.

إذا كنت لا تزال تُقرّر إلى أي مدى تريد التعمّق في الفرضنة (Virtualization) على ويندوز بشكل عام، فإن دليلنا حول الترقية إلى Windows Server 2025 يغطّي تغييرات Hyper-V التي تنعكس على طريقة عمل WSL نفسه من تحت الغطاء.

متطلبات التشغيل: إصدارات ويندوز 11 ومتطلبات الفرضنة

قبل أن تُسرع لتحديث حزم WSL لديك، من المهم فهم إصدار ويندوز الدقيق ومتطلبات الفرضنة على مستوى العتاد. ورغم أن WSL 2 أصبح منتشراً في كل مكان على ويندوز، فإن WSL Containers يفرض متطلبات مختلفة قليلاً بسبب بنيته القائمة على آلة افتراضية خفيفة لكل جلسة.

ويندوز 11 Home مقابل Pro مقابل Enterprise

من أكثر الأسئلة تكراراً بين المطورين: هل يحتاج WSL Containers إلى ترخيص ويندوز 11 Pro أو Enterprise المدفوع؟ الإجابة المختصرة: الأداة تعمل على إصدارات Home وPro وEnterprise وEducation جميعها، لكن متطلبات الإعداد تختلف قليلاً بينها.

• ويندوز 11 Home: يعتمد بالكامل على ميزة Virtual Machine Platform الاختيارية. لست بحاجة لأدوات إدارة Hyper-V، لكن يجب تفعيل الفرضنة على مستوى العتاد (VT-x أو AMD-V) من إعدادات BIOS/UEFI في اللوحة الأم.
• ويندوز 11 Pro / Enterprise: يستخدم بنية Hyper-V الأصلية مباشرة، ما يمنحك خيارات ضبط أداء أفضل، مثل تحديد حدود صريحة للذاكرة عبر سياسات النظام.

متطلبات العتاد والبرامج الثابتة

بما أن كل أمر wslc يُنشئ آلة افتراضية دقيقة (Micro-VM) مخصّصة، يجب أن يستوفي جهازك المواصفات الأساسية التالية:

1. تفعيل الفرضنة على مستوى العتاد: يجب تفعيل ميزة الفرضنة على مستوى المعالج (Intel VT-x أو AMD-V) من إعدادات BIOS/UEFI. إذا لم يسبق لك ضبط إعدادات الفرضنة من قبل، اقرأ دليلنا الكامل حول الفرق بين BIOS وUEFI وإعدادات الفرضنة.
2. إصدار ويندوز 11: يجب أن يكون 22H2 أو 23H2 أو 24H2 (البناء 22621 أو أحدث). لا تتوفر الأداة على إصدارات ويندوز 10 القديمة.
3. الحد الأدنى من الذاكرة: يُنصح بشدة بتوفّر 16 جيجابايت. الأجهزة ذات 8 جيجابايت يمكنها تشغيل حاوية واحدة، لكن بصمة الذاكرة لكل آلة افتراضية جديدة قد تُسبب سريعاً استخداماً مكثفاً لملف الترحيل (Swap) على الأجهزة محدودة الذاكرة.

كيفية تثبيت WSL Containers على ويندوز 11

استغرقت هذه العملية بالكامل أقل من دقيقتين على اتصال إنترنت جيد لديّ. الأداة تأتي حالياً فقط ضمن القناة التجريبية (Pre-release)، لذا عليك الانضمام إليها أولاً.

1. افتح Windows Terminal أو PowerShell كمسؤول. اضغط بزر الفأرة الأيمن على زر Start واختر "Terminal (Admin)".
2. انتقل إلى القناة التجريبية وحدّث WSL:

   wsl --update --pre-release

3. أعد تشغيل WSL حتى يسري التحديث:

   wsl --shutdown

   أغلق الطرفية وأعد فتحها بعد هذه الخطوة.
4. تأكّد من نجاح التثبيت:

   wslc --version

   رقم إصدار 2.9.3.0 أو أحدث يؤكّد أن WSL Containers أصبح جاهزاً.
5. تحقّق من قائمة الأوامر المتاحة:

   wslc --help

   إذا ظهرت قائمة الأوامر وطريقة استخدامها، فأنت جاهز لسحب أول صورة (Image).
6. شغّل أول حاوية لك:

   wslc run -it debian bash

   بمجرد الدخول، نفّذ الأمر uname -a. ظهور نص نواة WSL2 Linux يؤكّد أنك فعلاً داخل بيئة لينكس حقيقية، وليست محاكاة.

الصورة 1: تحديث WSL للقناة التجريبية والتحقق من تثبيت wslc بالإصدار v2.9.3.0 في Windows Terminal.

ادّعاءات السرعة لا تُطابق ما قسته فعلياً

حين بدأ الحديث عن wslc ينتشر، كان الرقم الذي يُكرّره الجميع أنه يُشغّل الحاويات في أقل من ثانية واحدة، مقابل 3 إلى 8 ثوانٍ لـ Docker Desktop. أردتُ التحقق من هذه الفجوة بنفسي، فشغّلتُ الأداتين عبر سكربت قياس واحد باستخدام نفس صورة Alpine الخفيفة، بدايةً باردة (Cold) وبدايةً دافئة (Warm)، تباعاً. من واقع اختباري على نسخة المعاينة الحالية، هذه الفجوة ببساطة لم تعد موجودة.

من دافئ إلى دافئ، يتفوّق wslc بفارق نحو 60 ملّي ثانية فقط — وهو فرق لن يشعر به أي إنسان فعلياً أثناء العمل. من بارد إلى بارد، كانت النتيجتان متقاربتين لدرجة اعتبارهما تعادلاً. المكان الوحيد الذي تأخّر فيه Docker Desktop فعلاً كان عندما لا يُغلق بشكل نظيف: الانهيار أو الإيقاف القسري جعل بدايته التالية أبطأ بشكل ملحوظ، جزئياً لأن خدمته المساعدة ذات الصلاحيات المرتفعة على ويندوز تحتاج رسالة موافقة جديدة.

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

علة تسريب الذاكرة، وكيفية إصلاحها تلقائياً عبر .wslconfig

هذا هو الجزء الذي أُريد فعلاً تنبيهك له قبل أن تُثبّت الأداة على جهاز يهمّك. توثيق مايكروسوفت يقول إن الحاويات من المفترض أن تُنظّف نفسها بعد انتهائك منها. في اختباري، الحاوية نفسها تختفي فعلاً — لكن الآلة الافتراضية الخاصة التي كانت تستضيفها لا تختفي. إنها تنجو حتى من تنفيذ يدوي لأمر wsl --shutdown، محتفظة بصمت بنحو 1.5 جيجابايت من الذاكرة لكل جلسة.

الصورة 2: مدير مهام ويندوز يكشف عن 3.4 جيجابايت من الذاكرة مستهلَكة بواسطة آلات WSL افتراضية معزولة (vmmemWSL).

wslc system session terminate

والمشكلة تتفاقم بسرعة أيضاً. تشغيل حاوية wslc واحدة فقط في اختباري أدّى أيضاً إلى تشغيل نسخة جديدة من آلة WSL المشتركة الافتراضية، وأعاد تسجيل توزيعة Ubuntu الموجودة لديّ مسبقاً على أنها "تعمل"، رغم أنني لم ألمسها إطلاقاً. هذا يعني نحو 3.4 جيجابايت من الذاكرة مُستهلَكة من أجل ما بدا، ظاهرياً، مجرد سطر أوامر خامل واحد. على جهاز بذاكرة 16 جيجابايت، هذا ليس خطأً تقريبياً بسيطاً — إنه جزء معتبر من مساحتك الحرّة يختفي بصمت.

الحل الدائم: استرداد الذاكرة تلقائياً عبر .wslconfig

الاعتماد على أمر إنهاء الجلسة يدوياً عرضة للنسيان والخطأ البشري. لحسن الحظ، يمكنك منع WSL Containers من التهام ذاكرة النظام بإنشاء ملف إعدادات عام في مجلد المستخدم الخاص بك على ويندوز.

افتح Notepad أو VS Code، وأنشئ ملفاً باسم .wslconfig داخل مجلد المستخدم الرئيسي على ويندوز (مثل C:\Users\<اسم_المستخدم>\.wslconfig)، وأضف كتلة الإعدادات التالية:

[wsl2]
# تحديد سقف لاستخدام الذاكرة حتى لا تلتهم آلات الجلسات المعزولة كامل ذاكرة الجهاز
memory=8GB

# إعادة استرداد الذاكرة المؤقتة غير المستخدَمة تلقائياً إلى ويندوز 11
autoMemoryReclaim=dropcache

# تحديد عدد أنوية المعالج المُخصَّصة للآلات الافتراضية في الخلفية
processors=4

# تحديد مساحة الترحيل (Swap)
swap=4GB

الإعداد الأهم هنا هو autoMemoryReclaim=dropcache، الذي يُجبر WSL2 على إعادة الذاكرة المخزّنة مؤقتاً وغير المستخدَمة إلى نظام ويندوز المضيف بشكل مستمر. بعد حفظ الملف، نفّذ wsl --shutdown مرة واحدة لتطبيق التغييرات عالمياً.

تسريع كرت الشاشة (GPU): الشيء الوحيد الذي عمل من أول مرة بلا مشاكل

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

صورة قياسية من CUDA 12.4 اكتشفت كرت RTX 5090 فوراً بمجرد علامة واحدة --gpus all — دون الحاجة لتثبيت أي تعريف يدوياً داخل الحاوية. بل عملت أيضاً مقابل تعريف مضيف أحدث من CUDA 13.3، وهو بالضبط نوع التعارض في الإصدارات الذي يُسبب الصداع عادةً. إذا أردت فهم الفروق الأساسية بين طبقات الحوسبة بالكرت الرسومي والمعالجات المخصّصة، راجع تحليلنا حول الفرق بين المعالجات CPU وGPU وAPU.

الصورة 3: اكتشاف فوري لكرت CUDA GPU داخل حاوية wslc باستخدام علامة --gpus all فقط.

ضع في اعتبارك أن هذه فرضنة GPU (Paravirtualization)، وليست تمريراً حصرياً (Passthrough)، لذا فإن إجمالي VRAM الذي تراه مُشترَك مع أي شيء آخر يعمل على سطح مكتب ويندوز في نفس الوقت. احسب حساباتك إذا كنت تُشغّل أي عمل آخر مكثّف على GPU بالتوازي.

النقطة الأقل تألقاً في قصة GPU هي مجموعة العلامات المحيطة بها. حتى نسخة المعاينة هذه، تفتقر wslc إلى --privileged، --device، و --restart. لا شيء تُشغّله ينجو من انتهاء الجلسة — وهذا مقبول لاختبار تدريب أو استنتاج سريع، لكنه عائق حقيقي إذا أردت الإبقاء على خدمة مدعومة بـ GPU تعمل على المدى الطويل.

إعداد الشبكة الافتراضي الذي سيُربكك

إليك تغييراً كلّفني عشرين دقيقة من استكشاف الأخطاء قبل أن أجد سببه. Docker Desktop يربط المنافذ المنشورة بعنوان 0.0.0.0 افتراضياً، ما يعني أن الخدمة قابلة للوصول من أي مكان على الجهاز. أما WSL Containers فيربطها بعنوان 127.0.0.1 بدلاً من ذلك — أي Loopback فقط. إذا كنت معتاداً على سلوك Docker، فستبدو حاوية الاختبار لديك وكأنها ترفض الاتصالات بصمت، رغم أنها تعمل بشكل طبيعي تماماً.

الحل هو نشر المنفذ بشكل صريح:

wslc run -p 0.0.0.0:8080:80 nginx

دمج WSL Containers مع VS Code وامتداد Dev Containers

بالنسبة لبيئات العمل البرمجية الحديثة، فإن دعم الحاويات لا يُساوي شيئاً بدون تكامل جيد مع بيئة التطوير. معظم المطورين على ويندوز يعتمدون بشكل كبير على Visual Studio Code إلى جانب امتداد Dev Containers الرسمي (المعروف سابقاً باسم Remote - Containers).

انقطاع الاتصال: Docker Daemon مقابل أداة wslc

افتراضياً، يتوقّع امتداد VS Code Dev Containers وجود مقبس Unix قياسي (/var/run/docker.sock أو الأنبوب المُسمّى //./pipe/docker_engine) تُديره Daemon يعمل بشكل دائم في الخلفية. وبما أن WSL Containers يعمل بنموذج بلا Daemon، حيث تُنشئ كل جلسة آلة افتراضية خاصة معزولة، فإن VS Code سيفشل في اكتشاف wslc تلقائياً من الصندوق.

الصورة 4: ضبط إعدادات VS Code Dev Containers لتُشير إلى مسار ملف wslc التنفيذي.

كيفية إعداد VS Code للعمل مع wslc

يمكنك تجسير هذه الفجوة بتخصيص إعدادات المستخدم في VS Code لتستهدف مسار ملف wslc.exe التنفيذي:

1. افتح إعدادات VS Code (Ctrl + ,).
2. ابحث عن dev.containers.dockerPath.
3. حدّد مسار الملف التنفيذي صراحة إلى: wslc.exe أو container.exe.
4. في ملف .devcontainer/devcontainer.json الخاص بمشروعك، تأكّد من ضبط "overrideCommand": true للسماح لـ wslc بالتحكّم بتنفيذ الـ shell.

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

لا دعم أصلي لـ Compose بعد — لكن المجتمع سدّ الفجوة

هذا هو السبب الأكبر وراء عودة كثيرين إلى Docker Desktop بعد تجربة wslc. حتى الإصدار 2.9.3، لا يوجد أمر wslc compose، ولا حتى نسخة جزئية منه — تنسيق حاويات متعددة عبر ملف YAML واحد ببساطة لم يُبنَ بعد. إنها حالياً الميزة الأكثر طلباً على مستودع microsoft/WSL الرسمي على GitHub، دون أي جدول زمني مُعلَن حتى منتصف 2026.

ما فاجأني هو أن البنية التحتية الأساسية — دورات حياة الشبكات والأحجام (Volumes) — موجودة بالفعل. مايكروسوفت ببساطة لم تُطلق بعد أمر Compose الرئيسي الذي يُحرّكها. مشروع مجتمعي باسم wslc-compose يستفيد من هذه الفجوة عبر أداة وسيطة خفيفة بلغة Python تُترجم ملفات Compose إلى أوامر wslc الفردية اللازمة لتشغيلها.

ثبّتُّها عبر pipx ووجّهتها إلى حزمة اختبار من خدمتين — nginx وPostgres، مع إدخال depends_on خصيصاً لمعرفة ما إذا كان سيُخلّ بترتيب التشغيل. لم يفعل. انتهيت بشبكة مخصّصة للمشروع، وقاعدة البيانات تبدأ قبل حاوية الويب، وطبقة Alpine أساسية مشتركة ومُزال تكرارها بين الحاويتين. تنفيذ down -v أنهى الحزمة بالكامل بشكل نظيف، بما في ذلك الشبكات. إنه ليس حلاً رسمياً، ولن يحصل على نفس ضمانات الدعم طويل الأمد، لكنه فعّال بما يكفي للاستخدام اليوم إذا كان Compose عائقاً حقيقياً بالنسبة لك.

نظرة معمّقة: WSL Containers مقابل Podman Desktop للشركات

بالنسبة للمطورين الراغبين في تجاوز نموذج ترخيص Docker Desktop للشركات (الذي يفرض اشتراكات مدفوعة على الشركات التي يزيد عدد موظفيها عن 250 أو إيراداتها عن 10 ملايين دولار)، يُقدّم كل من WSL Containers وPodman Desktop من Red Hat خيارين مجانيين جذابين. لكن بنيتيهما الأمنية وسلوكياتهما وقت التشغيل تختلفان جوهرياً. يمكنك مراجعة توثيق Podman Desktop الرسمي لاستكشاف أدواته الموجّهة للشركات.

البنية: Podman بلا صلاحيات جذر مقابل آلات wslc الافتراضية المعزولة

• Podman Desktop: يستخدم نموذج حاويات بلا Daemon وبلا صلاحيات جذر داخل آلة WSL مشتركة واحدة. تعمل الحاويات ضمن مساحات أسماء مستخدم غير مُمتازة (Unprivileged)، ما يُلغي المخاطر الأمنية الناتجة عن Daemon جذر مُخترَق على جهازك.
• WSL Containers (wslc): يعزل جلسات الحاويات على مستوى المُفرِضن (Hypervisor) بوضع كل جلسة داخل آلة Hyper-V دقيقة (Micro-VM) خاصة بها. رغم أنك تعمل بصلاحيات جذر داخل الآلة الافتراضية، فإن حدود المُفرِضن تُبقي ذاكرة ويندوز المضيف معزولة.

أي بديل مجاني تختار؟

5 أخطاء يقع فيها من يجرّب WSL Containers لأول مرة

1. عدم تنفيذ أمر الإنهاء أو ضبط .wslconfig إطلاقاً. الآلات الافتراضية المعزولة اليتيمة هي المصدر الأكبر لشكاوى "لماذا امتلأت ذاكرتي" مع wslc حالياً. إما اضبط autoMemoryReclaim أو اجعل wslc system session terminate عادة روتينية.
2. افتراض أن المنافذ تتصرّف مثل Docker. النشر دون ربط صريح بـ 0.0.0.0 يترك خدمتك قابلة للوصول فقط من داخل نفس الجهاز، وهو ما يبدو تماماً وكأنه حاوية معطوبة من الخارج.
3. توقّع أن ملفات Compose ستعمل من الصندوق مباشرة. لن تعمل بعد. إما ثبّت الأداة المجتمعية الوسيطة أو أعد هيكلة سير عملك حول أوامر wslc run الفردية.
4. معاملة الخدمات الدائمة وكأنها ستنجو من إعادة التشغيل. بدون علامة --restart، أي شيء تُشغّله يختفي بمجرد انتهاء الجلسة. هذه ليست الأداة المناسبة بعد لخدمة استضافة ذاتية تريدها تعمل على مدار الساعة — لهذه الحالة، ابقَ على Docker Desktop أو Podman أو حل فرضنة كامل مثل ما ورد في دليلنا حول أفضل تطبيقات الاستضافة الذاتية على Proxmox أو Docker.
5. الذعر عند رسالة جدار الحماية COM Surrogate. إنها سلوك متوقّع مرتبط بطبقة شبكات wslc، وليست برمجية خبيثة — رغم أنني أتفهّم لماذا تبدو مقلقة في أول مرة تراها.

إذن، هل تستبدل Docker Desktop به؟

بالنسبة للعمل البرمجي اليومي — حاويات التطوير، الاختبارات السريعة، تجارب GPU — إجابتي نعم، إنه جاهز فعلاً. سريع بما يكفي بحيث لا يهم الفرق مع Docker Desktop عملياً، وأخفّ على أجزاء النظام التي لا تتعلّق بالآلات الافتراضية اليتيمة، ودعم GPU عمل بشكل أفضل مما توقّعت من برنامج معاينة.

أما بالنسبة لأي شيء تريده يعمل دون مراقبة — خدمة في home-lab، تطبيق صغير مُستضاف ذاتياً، أي شيء يجب أن ينجو من إعادة تشغيل — فهو ليس هناك بعد. غياب سياسات إعادة التشغيل وغياب دعم Compose الأصلي عائقان حقيقيان لهذه الحالة، وعلة تسريب الذاكرة تجعله خياراً ضعيفاً لجهاز لا تُراقبه بنشاط. إذا كانت أعباء عملك تميل نحو خدمات تعمل لفترات طويلة أكثر من التطوير النشط، فإن مقارنتنا بين VMware وProxmox نقطة انطلاق أفضل من أي أداة حاويات أصلية على ويندوز حالياً.

الفجوة الحقيقية الأخرى هي وضوح الرؤية. Docker Desktop يضع كل حاوية أمامك في واجهة رسومية سواء بحثت عنها أم لا. أما WSL Containers فيُبقي كل شيء خلف سطر الأوامر، لذا عليك تنفيذ wslc ps -a بنشاط لمعرفة ما يستهلك مواردك. هذه على الأرجح فجوة برنامج معاينة أكثر من كونها خياراً تصميمياً دائماً، ولن تُفاجئني واجهة إدارة رسومية لاحقاً — لكن حتى ذلك الحين، اعتد على سطر الأوامر.

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

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