ملاحظة من Zima
شكرًا لك، sbinske، على إظهار أن الخادم المنزلي المفيد لا يحتاج إلى أن يبدأ بأجهزة خوادم مخصصة أو خبرة مهنية في إدارة الأنظمة. فقد حوّل إعدادك لحفلة LAN الكلاسيكية قطع حاسوب فائضة إلى نظام ZimaOS يشغّل خدمات Docker وأجهزة افتراضية متعددة وDNS وTeamSpeak والأدوات المساندة اللازمة لإنجاح فعالية شبكة محلية تقليدية.
نقدّر بشكل خاص أنك وثّقت خطوات استكشاف الأخطاء وإصلاحها بوضوح مماثل لتوثيق النجاح. فتجمّد GT710، وعدم استقرار بطاقة الشبكة، والقيود التي اكتشفتها في آلية عمل متجر التطبيقات، وطلبك لمزيد من المرونة في تركيبات التخزين، كلها أمثلة على الملاحظات التي تساعد في إظهار المواضع التي يبدو فيها النظام الخفيف سهل الاستخدام، والمواضع التي لا يزال يطلب فيها الكثير من الهاوي.
— Zima
تعرّفوا على sbinske
يصف sbinske نفسه بأنه مستخدم غير محترف للتقنية وهاوٍ للأعمال اليدوية. وهذا التمييز مهم لهذه القصة. فلم يتعامل مع ZimaOS بصفته مسؤول أنظمة يبحث عن منصة أخرى لإجراء المقارنات المعيارية، بل بصفته شخصًا يستمتع ببناء الأشياء وإعادة استخدام الأجهزة والوصول إلى نتيجة عملية من دون تحويل كل مشروع إلى بنية تحتية مؤسسية.
قبل أن يستقر على ZimaOS، أمضى وقتًا طويلًا في البحث عن بديل لـ Unraid. وما جذبه لم يكن التكافؤ في الميزات واحدةً بواحدة. بل إن أحد الأمور التي أعجبته هو أن ZimaOS بدا أخف وزنًا ولم يحاول أن يكون شاملًا مثل Unraid.
أصبح مشروعه في فبراير 2026 اختبارًا محددًا جدًا لهذه الفكرة: هل يستطيع نظام تشغيل خفيف نسبيًا للخوادم المنزلية تشغيل مزيج الحاويات والأجهزة الافتراضية والشبكات والتخزين اللازم لحفلة LAN كلاسيكية؟
أصبحت حفلة LAN كلاسيكية حالة الاختبار
كان الخادم يُجهَّز لحفلة LAN تقليدية، حيث كان يتعين أن تعمل البنية التحتية محليًا وأن تدعم الفعالية من دون الاعتماد على مجموعة من الخدمات الخارجية.
بحلول الوقت الذي وثّق فيه عملية الإعداد، كان ZimaOS يشغّل بالفعل حاويتَي Docker: خادم TeamSpeak وخادم DNS. وإلى جانبهما كانت هناك ثلاثة أجهزة افتراضية: ETI-SyncServer وLanPage VM وجهاز افتراضي آخر مخصّص لتنظيم الخدمات المتبقية الخاصة بالفعالية.
كان عبء العمل هذا هو ما جعل المشروع أكثر إثارة للاهتمام من مجرد اختبار NAS. لم يكن التخزين سوى جزء واحد منه؛ إذ كان على النظام أيضًا استضافة خدمات الشبكة وعدة أجهزة افتراضية معزولة في الوقت نفسه.
لماذا نجح ZimaOS كبديل خفيف لـ Unraid
كانت مقارنة sbinske مع Unraid عملية عن قصد. لم يكن يتوقع من ZimaOS أن يكرر كل إمكانات Unraid. كان يريد نظامًا أصغر يغطي الوظائف التي يحتاج إليها فعلًا، ويظل مفهومًا بما يكفي ليتمكن هاوٍ من التعامل معه.
بعد السيطرة على مشكلات العتاد، كانت تجربته العامة إيجابية. واستقر النظام في حالة مستقرة وتعامل مع أعباء شبكة LAN للحفلات التي بناها حوله.
لا تزال وثائق ZimaOS الحالية تصف الأجهزة الافتراضية بأنها جزء قيد التطوير من المنصة، بينما يجمع النظام الأوسع بين التخزين وتطبيقات Docker والافتراضية في واجهة واحدة. وهذا يجعل مشروع sbinske مثالًا جيدًا على استخدام هذه المكوّنات معًا بدلًا من التعامل مع كل ميزة باعتبارها عرضًا تجريبيًا منفصلًا.
بدت المشكلة الرئيسية الأولى كأنها تجمّد في ZimaOS
لم يبدأ إعداد الجهاز بسلاسة. أفاد sbinske بأن ZimaOS كان يتجمّد تمامًا بعد نحو 20 دقيقة من التشغيل.
بعد فحص السجلات واختبار المكوّنات، عزا السبب الأول للمشكلات إلى بطاقة NVIDIA GeForce GT 710 قديمة. حاول تثبيت برامج التشغيل يدويًا عبر الطرفية، لكن ذلك لم يحل المشكلة. كما جرّب تغييرات مرتبطة بمحركات الأقراص الافتراضية دون نجاح.
في النهاية أزال بطاقة الرسومات، وأعاد ضبط النظام، وأعاد تثبيت ZimaOS من دونها. وعمل التثبيت النظيف بصورة صحيحة مجددًا.
ينبغي التعامل مع هذه المشكلة بوصفها مشكلة توافق أبلغ عنها منشئ المحتوى في جهازه المحدد، لا باعتبارها ادعاءً عامًا بأن كل بطاقة GT 710 غير متوافقة مع كل إصدار من ZimaOS. توثّق المصادر ما حدث في هذا الإعداد، لكنها لا تثبت وجود قاعدة عامة لبرامج التشغيل.
كشفت إعادة تركيب وحدة معالجة الرسومات عن مشكلة عتادية أكثر تعقيدًا
عندما أعاد sbinske بطاقة الرسومات، تغيّر السلوك. فبدلًا من ظهور ما بدا أنه مشكلة في برنامج تشغيل الرسومات فقط، بدأ الجهاز يفصل محركات الأقراص الصلبة وبطاقات الشبكة ويعيد اكتشافها بشكل متكرر.
أظهرت السجلات أخطاءً، لكنه لم يتمكن من عزوها بثقة إلى محول شبكة محدد أو إلى بطاقة الرسومات وحدها. لذلك غيّر أسلوب استكشاف الأخطاء وإصلاحها: إزالة مكوّن عتادي واحد في كل مرة، ومراقبة النقطة التي يتوقف فيها النظام عن إظهار المشكلات.
أدت تلك العملية إلى أوضح نتيجة في جلسة تصحيح الأخطاء بأكملها. كان النظام غير مستقر عند استخدام ثلاث بطاقات شبكة إضافية، بالإضافة إلى واجهة الشبكة المدمجة في اللوحة الأم. أما مع بطاقتي شبكة إضافيتين فقط، فقد عمل الجهاز جيدًا.
اشتبه في تخصيص مسارات PCIe — لكنه لم يثبت ذلك
لم يكن المضيف عتاد خادم مصممًا لهذا الغرض. فقد استخدم AMD Ryzen 5 2600، ولوحة أم MSI B450 Plus، وذاكرة وصول عشوائي بسعة 64 جيجابايت — أي عتادًا احتياطيًا متاحًا للمشروع أساسًا.
اشتبه sbinske في أن تركيبة اللوحة الأم ووحدة المعالجة المركزية وبطاقة الرسومات وعدة محولات شبكة ربما واجهت مشكلة في مسارات PCIe أو في تخصيص الموارد. لكنه لم يواصل التحقيق بما يكفي لإثبات هذه النظرية، لأن الجهاز كان يلبي احتياجاته بالفعل باستخدام بطاقتي شبكة إضافيتين.
هذا الحد مهم. فنتيجة استكشاف الأخطاء وإصلاحها الناجحة معروفة: تقليل تركيبة بطاقات التوسعة جعل النظام مستقرًا. أما السبب الجذري الكهربائي أو المتعلق بالبرامج الثابتة أو بتخصيص المسارات، فلا يزال فرضية من صاحب التجميعة، وليس عيبًا مؤكدًا في ZimaOS.
بعد استقرار الأجهزة، ظل الخادم مستقرًا
بعد تقليل عدد بطاقات الشبكة وإزالة تركيبة الأجهزة المسببة للمشكلة، أفاد sbinske بأن النظام عمل بثبات.
غيّر ذلك نظرته إلى المشروع. فقد جعلت حالات التجمّد الأولية عملية التثبيت تبدو غير موثوقة، لكن السلوك اللاحق أشار إلى تفاعل أكثر تعقيدًا بين نظام التشغيل ومجموعة غير معتادة من مكونات حاسوب مكتبي مُعاد استخدامها.
في تجميعة تُبنى ذاتيًا، كان هذا الفرق أهم من تحديد سبب جذري مثالي. فقد وصل إلى إعداد قادر على إبقاء خدمات حفلات الشبكة المحلية قيد التشغيل، وكانت بطاقتا الشبكة كافيتين بالفعل للدور الذي خطط له.
كان متجر التطبيقات هو الموضع الذي بدا فيه ZimaOS أقل سهولة من Unraid
كان أقوى انتقاد لقابلية الاستخدام في استبيان sbinske يتعلق بتجربة متجر التطبيقات الخاصة بحاويات Docker التابعة لجهات خارجية.
كان مرجعه هو Unraid: ثبّت متجر التطبيقات، وابحث عن الحاوية، واتبع وصفًا واضحًا ونموذج إعداد، ثم ثبّتها. ورأى أن ZimaOS يمكنه الوصول إلى النتيجة نفسها، لكن إضافة حاوية غير مألوفة أو تابعة لجهة خارجية كانت تتطلب معرفة كبيرة من غير المتخصصين والهواة.
سُجّلت تلك الملاحظات في فبراير 2026. وتذكر وثائق ZimaOS الحالية الآن أن المستخدمين يمكنهم استيراد ملفات YAML عشوائية لـ Docker Compose، وتعديل الإعدادات مباشرة، وتشغيل مجموعات متعددة الحاويات، واستخدام متاجر خارجية تديرها جهات من المجتمع. كما تصف وثائق المطورين سير عمل حزم متجر التطبيقات الحالي بمزيد من التفصيل.
هذه الإمكانات الأحدث لا تمحو تجربته الأصلية. بل توفر سياقًا مفيدًا: فسير العمل الذي وجده معقدًا للغاية كان تحديدًا من المجالات التي واصل ZimaOS توسيعها لاحقًا في عام 2026.
كانت مرونة التخزين هي العنصر المفقود الآخر
كان sbinske يريد أيضًا حرية أكبر في تقسيم عدة أقراص إلى مجموعات تخزين مختلفة لأحمال عمل مختلفة.
كان مثاله عمليًا: إذ يمكن استخدام زوج من الأقراص كـ RAID 0 عندما تكون السعة والسرعة أهم من التكرار، بينما يمكن أن يكون زوج آخر بتكوين RAID 1 للبيانات التي تستحق النسخ المتطابق. أما حمل عمل SyncServer لديه، فكان يحتاج إلى مساحة تتجاوز 4 تيرابايت، لكنه لم يتطلب المستوى نفسه من حماية البيانات الذي يحتاجه التخزين الأهم.
من وجهة نظره، يمكن أن يؤدي الجمع بين الأقراص الموجودة الأرخص في مصفوفات مخصصة لأحمال عمل معينة إلى خفض تكلفة الأجهزة وتحقيق استفادة أفضل من محركات الأقراص المتاحة لديه بالفعل.
تغطي وثائق ZimaOS الحالية الآن RAID 0 وRAID 1 وRAID 5 وRAID 6 وJBOD وZFS. ومع ذلك، لا تؤكد الوثائق العامة التي تمت مراجعتها لهذه القصة صراحةً سير العمل الدقيق للمصفوفات المتعددة الذي طلبه sbinske — مثل إنشاء RAID 0 مستقل من قرصين وRAID 1 منفصل من قرصين على المضيف نفسه عبر واجهة المستخدم العادية. ولهذا السبب، تحتفظ هذه الصفحة بطلبه بدلًا من الادعاء بأنه حُل بالكامل.
تعريف مستخدم غير محترف للنجاح
ما يجعل هذا المشروع مفيدًا هو أن sbinske لم يقيّم النظام بناءً على عدد الميزات المتقدمة التي يوفرها. بل قيّمه بناءً على قدرته على دعم الخدمات التي أراد تشغيلها فعليًا.
بعد استكشاف أخطاء الأجهزة وإصلاحها، كانت الإجابة إلى حد كبير نعم. كان ZimaOS أخف من Unraid، لكن ذلك كان مقبولًا لأن خادم حفلة LAN الخاص به لم يكن يحتاج إلى كل ميزات Unraid. فقد كان حاويتا Docker وثلاث آلات افتراضية وDNS محلي واتصالات صوتية ومزامنة وخدمات إدارة الفعاليات كافية لجعل الخادم مفيدًا.
جاءت انتقاداته من المنظور العملي نفسه. فسهولة تثبيت Docker من جهات خارجية ستقلل منحنى التعلم. كما أن تجميع الأقراص بمرونة أكبر قد يخفض تكلفة الأجهزة. وستجعل التوافق الأفضل مع توليفات غير معتادة من بطاقات التوسعة المكتبية مشاريع الأجهزة المتوفرة أقل عرضة للمفاجآت.
لا تزال القصة قيد الكتابة
لا تزال قصة sbinske وZima قيد الكتابة. بدأ مشروعه الحالي كبديل خفيف لـ Unraid من أجل حفلة LAN بألعاب قديمة، ثم تحول إلى اختبار واقعي لكيفية عمل ZimaOS على أجهزة مكتبية معاد استخدامها تحت عبء عمل مختلط من Docker والآلات الافتراضية.
لم تكن النتيجة النهائية عملية تثبيت أولى نظيفة تمامًا. بل كانت نظامًا DIY عاملًا تم الوصول إليه من خلال استكشاف الأخطاء وإصلاحها على مستوى المكونات: إزالة GT 710، وتقليل توليفة بطاقات التوسعة، والإبقاء على بطاقتي الشبكة المطلوبتين فعليًا، ثم المتابعة بعد استقرار الجهاز.
بالنسبة إلى شخص يصف نفسه صراحةً بأنه هاوٍ وليس محترفًا، قد تكون هذه النتيجة الأكثر فائدة للمشروع. لم يُخفِ النظام عنه كل التفاصيل التقنية، لكن بعد تبسيط توليفة الأجهزة، وفّر بيئة خادم منزلي أخف كان يبحث عنها.
للاطلاع على سياق المنصة الحالي، راجع نظرة عامة على ميزات ZimaOS والمرجع الحالي لإعدادات RAID.
