ملاحظة من Zima
شكرًا لك، بوب، على تحويل تجربتك مع ZimaCube إلى شيء أكثر فائدة بكثير من مراجعة تقليدية. تتابع يومياتك المستمرة الجهاز وهو يغيّر أدواره — من الانطباعات الأولى وتفكيك الجهاز إلى ZimaOS وWindows Server وProxmox والنسخ الاحتياطية والمراقبة ووكلاء الذكاء الاصطناعي وحتى موجّه افتراضي — مع إبقاء الجوانب التي أعجبتك وتلك التي سببت لك الإحباط في السجل نفسه. يساعدنا هذا النوع من التجارب الصادقة طويلة الأمد على فهم ليس فقط ما يستطيع ZimaCube فعله، بل أيضًا ما يحدث بعد أن يصبح جزءًا من مختبر منزلي حقيقي.
— Zima
تعرّف إلى Bob Loves Tech
Bob Loves Tech هو مستخدم لمختبر منزلي وصانع محتوى تقني، تمتد أعماله إلى Windows وLinux والافتراضية والشبكات والاستضافة الذاتية، إضافة إلى الأجهزة التي تقوم عليها هذه التقنيات.
تعود علاقة بوب بأجهزة Zima إلى ما قبل هذا المشروع. فقد كان قد أمضى وقتًا مع منتجات Zima السابقة، بما فيها ZimaBoard وZimaBlade، قبل انضمامه إلى برنامج Zima Pioneer. وعندما وصل ZimaCube، قرر ألا ينتج مراجعة واحدة مصقولة ثم ينتقل إلى غيره. بدلًا من ذلك، أنشأ مدونة تجربة ZimaCube، وهي مستودع عام يواصل النمو مع تغير الجهاز إلى جانب مختبره المنزلي.
يصف بوب المشروع بأنه يوميات مستمرة، لا مراجعة رسمية. وهذا التمييز يشرح طبيعة المشروع جيدًا. فهو يتضمن رد الفعل الأول تجاه الجهاز، والأمور التي اكتشفها بعد فتحه، وأنظمة التشغيل التي جرّبها، والبنية التحتية التي أنشأها حوله، والاستنتاجات التي تغيرت بعد أسابيع من الاستخدام.
توثيق ZimaCube بما يتجاوز الانطباع الأول
تبدأ أقدم تدوينات مشروع بوب من النقطة التي تبدأ منها معظم قصص الأجهزة: إخراج الجهاز من عبوته، وفحص جودة التصنيع، والتحقق من المنافذ وحوامل الأقراص، وتحديد ما يبدو مختلفًا بعد وضع الجهاز فعليًا على المكتب.
لكن المدونة لا تتوقف عند هذا الحد. يعود بوب إلى الجهاز بعد أن يتعايش معه. ويتضمن مستودعه نظرة عامة مخصصة على الجهاز، وتفكيكًا كاملًا، ومتابعة بعد ستة أسابيع، ونظرة أقرب على سبب تحول الذاكرة، لا أنوية المعالج، إلى عنق الزجاجة العملي، بالإضافة إلى تدوينة منفصلة تطرح السؤال الذي يهم كل مراجع في نهاية المطاف: هل سينفق ماله الخاص عليه فعلًا؟
هذا التدرج هو ما يجعل المشروع قيّمًا. فالانطباع الأول يخبرك بكيفية وصول المنتج إليك، بينما تخبرك يوميات الاستخدام بما يصمد بعد زوال حداثة التجربة.
فتح الجهاز ومتابعة التفاصيل
يحمل أحد فصول العتاد اسمًا بسيطًا هو تفكيكه، وهذا يكشف الكثير عن نهج بوب.
بدلًا من التعامل مع ZimaCube كجهاز NAS مغلق، فتح الهيكل ووثّق المكونات الداخلية، بما في ذلك نظام التبريد والتفاصيل الصغيرة في العتاد التي لا تظهر إلا عندما يقرر شخص ما أن الجهاز ينبغي أن يكون قابلًا للصيانة والتعديل.
يقود ذلك التفكيك لاحقًا إلى جزء آخر من المذكرات: ما الذي تغيّر بعد ستة أسابيع وما الذي لم يتغيّر. تصبح بعض الملاحظات أقل أهمية بمرور الوقت، بينما تزداد أهمية ملاحظات أخرى، منها التبريد وسلوك المروحة وسعة الذاكرة وإمكانية الترقية ومدى ملاءمة العتاد لبيئة تعمل دائمًا.
للقراء الذين يرغبون في التعمق أكثر في أسئلة العتاد نفسها، يوسّع دليل تفكيك ZimaCube الحديث عن التصميم الداخلي ومسارات الترقية، بينما يتناول 7 تفاصيل ذكية في تصميم ZimaCube بمزيد من التفصيل الجوانب التي تظهر عند فتح النظام بدلًا من الاكتفاء بمشاهدته عبر جدول المواصفات.
اكتشاف أن ذاكرة RAM أهم من زيادة أنوية وحدة المعالجة المركزية
تصل إحدى الإدخالات اللاحقة المتعلقة بالعتاد إلى استنتاج أكثر فائدة بكثير من مخطط أداء آخر: لم يكن ZimaCube بحاجة إلى مزيد من أنوية وحدة المعالجة المركزية لأعباء عمل بوب، بل كان بحاجة إلى مزيد من الذاكرة.
تصف مذكراته نظامًا يعمل عليه عشرة أجهزة ضيفة، بينما ظل استخدام وحدة المعالجة المركزية عند نحو أربعة بالمئة، في حين ارتفع استهلاك الذاكرة إلى قرابة 27GB. وهذا يغيّر طريقة تقييم العتاد. فلم يكن المعالج هو الحد العملي الأول، بل كانت تهيئة الذاكرة المرفقة هي العامل المحدِّد.
بالنسبة إلى جهاز يتحول تدريجيًا إلى مضيف للمحاكاة الافتراضية، وخادم نسخ احتياطي، وعقدة للمراقبة، ومضيف للأجهزة الافتراضية الخاصة بالموجّه، وبيئة تجارب للذكاء الاصطناعي، تصبح سعة الذاكرة جزءًا من البنية التحتية بدلًا من كونها مجرد مواصفة.
هذا تحديدًا هو نوع الاستنتاج الذي يمكن أن تكشفه قصة مستخدم ممتدة. فهو لا يأتي من السؤال عما يمكن لوحدة المعالجة المركزية فعله نظريًا، بل من مراقبة النظام بعد تراكم المزيد والمزيد من أعباء العمل الفعلية.
محو ZimaOS وتثبيت Windows Server 2025
بدأت التجربة الأبرز في مستودع بوب عندما أزال ZimaOS وثبّت Windows Server 2025 مباشرةً على ZimaCube.
يصف بوب هذا المزيج بأنه غير متجانس، وهذا تحديدًا هو سبب تجربته له. أصبح المشروع وسيلة لاختبار العتاد من دون الاعتماد على بيئة البرامج التي شُحن بها: سلوك التثبيت، والبحث عن برامج التشغيل، والشبكات، والتخزين، وما إذا كانت منصة NAS مدمجة لا تزال منطقية عند التعامل معها كخادم Windows متعدد الأغراض.
توضح التجربة أيضًا جانبًا مهمًا من فلسفة أجهزة Zima. فإزالة ZimaOS لا تنهي العمر المفيد للجهاز، إذ تظل الأجهزة القائمة على x86 منصةً يمكن إعادة بنائها حول نظام تشغيل مختلف.
حوّلنا تلك التجربة إلى دليل إعداد Windows Server 2025 على ZimaCube أكثر تنظيمًا، يغطي مسار التثبيت، والعمل على برنامج تشغيل شبكة Intel، وإعداد التخزين للمستخدمين الذين يرغبون في استكشاف الاتجاه نفسه.
منح ZimaOS اختبارًا منصفًا قبل الانتقال إلى خيار آخر
لا يمثّل Windows Server سوى جزء من قصة نظام التشغيل. فقد كتب Bob أيضًا مراجعة مخصصة لـ ZimaOS في مذكّرات المختبر المنزلي.
استنتاجه أكثر دقةً من مجرد وصف النظام بأنه «جيد» أو «سيئ». يصف المستودع ZimaOS بأنه مناسب جدًا للأجهزة الأصغر، مع التشكيك في مدى توافق التجربة المبسطة مع ما يريده من ZimaCube يجري دفعه بعمق أكبر نحو المحاكاة الافتراضية والبنية التحتية للمختبر المنزلي.
هذا الانتقاد مفيد لأن Bob لا يقيّم ZimaOS بصفته شخصًا يجرّب الاستضافة الذاتية للمرة الأولى، بل يقيّمه من منظور شخص يدير بالفعل مختبرًا منزليًا متعدد الأنظمة، ولديه خبرة في إدارة الطبقات الأساسية بنفسه.
بالنسبة إلى مستخدم آخر، قد تكون البساطة سببًا للاستمرار. أما بالنسبة إلى Bob، فقد أصبح تعقّد البنية التحتية المتزايد سببًا للانتقال إلى خيار آخر.
نستكشف المفاضلة نفسها في مقارنتنا بين ZimaOS وProxmox وWindows Server، التي نشأت من المجموعة الأوسع نفسها من التجارب.
جعل Proxmox محور المختبر المنزلي
بعد تجربة توجهات أخرى، توصّل Bob في النهاية إلى استنتاج أقوى بكثير بشأن نظام التشغيل الذي يريده على ZimaCube: كان Proxmox البيئة الأكثر ملاءمة لمختبره المنزلي.
تصف المدوّنة جهاز ZimaCube وهو يعمل إلى جانب وحدة تخزين NFS من Synology، ليصبح جزءًا من مجموعة مكوّنة من ثلاثة مضيفين. عند هذه النقطة، لم يعد الجهاز يخضع للتقييم أساسًا بوصفه جهاز NAS، بل أصبح بنيةً تحتية.
يفتح هذا التغيير الباب أمام عدة إدخالات لاحقة في اليوميات، لأن Proxmox يوفر الأساس للتجارب التالية: البنية التحتية للنسخ الاحتياطي، والمراقبة، وخدمات الذكاء الاصطناعي، والمحاكاة الافتراضية للشبكات.
للمستخدمين المهتمين ببناء الأساس نفسه، يوضح دليل إعداد ZimaCube وProxmox الخاص بنا المسار بدءًا من تجهيز BIOS وصولًا إلى الأجهزة الافتراضية وحاويات LXC والتخزين والشبكات والتمرير المباشر.
بناء النسخ الاحتياطية حول البنية التحتية
بمجرد أن تصبح الآلة جزءًا من البنية التحتية، لا يعود السؤال التالي هو ما إذا كان بإمكانها تشغيل مزيد من الخدمات، بل ما الذي يحدث عند اختفاء إحدى تلك الخدمات.
تتابع يوميات بوب النسخ الاحتياطية هذا الانتقال. يدخل Proxmox Backup Server في الصورة، إلى جانب السؤال الدائري المحرج حول نسخ البنية التحتية احتياطيًا باستخدام بنية تحتية هي نفسها جزء من النظام المحمي.
والنتيجة لا تتعلق بالعثور على وجهة نسخ احتياطي مثالية واحدة بقدر ما تتعلق بإنشاء طبقات تجعل الاسترداد متوقعًا بما يكفي حتى لا يعود النسخ الاحتياطي أمرًا يتعين على بوب التفكير فيه باستمرار.
أصبحت تلك التجربة أساس دليل Proxmox Backup Server الخاص بنا، الذي يوسّع الفكرة لتشمل نسخًا احتياطية تزايدية للأجهزة الافتراضية والحاويات، والاحتفاظ بالنسخ، والتحقق منها، وطبقات حماية إضافية.
مراقبة المجموعة بدلًا من التحقق منها باستمرار
سؤال بوب التالي مألوف لكل من نما مختبره المنزلي إلى ما يتجاوز بضع خدمات: ما مقدار المراقبة الذي يحتاج إليه شخص واحد فعلًا؟
يتناول إدخاله مراقبة المجموعة أدوات من بينها Pulse وProxmox Data Center Manager، لكن الهدف الأكثر أهمية هو تقليل مقدار الاهتمام اليدوي الذي تتطلبه البنية التحتية.
ينبغي ألا ينشئ نظام المراقبة المفيد لوحة معلومات أخرى تحتاج إلى المراقبة طوال اليوم. بل يجب أن يجعل التشغيل العادي هادئًا، وأن يجعل الأعطال واضحة عندما تكون هناك حاجة فعلية إلى التدخل.
طوّرنا هذا الجزء من تجربة بوب بشكل أكبر في دليل مراقبة الخادم المنزلي، الذي يتناول Pulse وUptime Kuma وProxmox Data Center Manager، والمرحلة التي ينبغي فيها أن تقلل المراقبة من أعمال الصيانة بدلًا من أن تزيدها.
منح وكيل ذكاء اصطناعي منزلًا دائمًا
ينتقل السجل في النهاية إلى طبقة أخرى من الاستضافة الذاتية: تشغيل وكيل ذكاء اصطناعي دائم على ZimaCube.
في مقال لماذا ينتمي Hermes Agent إلى ZimaCube الخاص بك، ينظر بوب إلى الجهاز ليس باعتباره بنية للتخزين أو الافتراضية فحسب، بل باعتباره مكانًا دائم التشغيل يعيش فيه وكيل مستضاف ذاتيًا.
يبدو هذا الاقتران منطقيًا في سياق كل ما سبقه. فبمجرد أن يصبح ZimaCube متصلًا بالإنترنت على مدار الساعة، ومرتبطًا بالمختبر المنزلي، وتُجرى له نسخ احتياطية وتتم مراقبته، يمكن أن يصبح الوكيل خدمة مستمرة أخرى بدلًا من أن يكون مرتبطًا بجلسة حاسوب محمول.
إذا أردت استكشاف سير العمل هذا مباشرةً على ZimaOS، فسيغطي دليل إعداد Hermes Agent على ZimaOS التثبيت، وتهيئة النموذج، ودمج المراسلة، والوصول إلى لوحة معلومات Hermes.
تحويل ZimaCube إلى موجّه OPNsense
تدفع إحدى أكثر التجارب اللاحقة إثارة الجهاز إلى دور مختلف تمامًا مرة أخرى: بنية تحتية للشبكة.
ينظر سجل OPNsense الذي كتبه بوب في واجهتي 2.5GbE المزدوجتين في ZimaCube مع Proxmox، ويتساءل عما إذا كانت آلة الموجّه الافتراضية قد تكون حتى الآن أحد أكثر استخدامات هذه الأجهزة إقناعًا.
هنا يبدأ قرار نظام التشغيل السابق في تحقيق فوائده. يتيح Proxmox للجهاز الفعلي نفسه استضافة أعباء عمل كانت تتطلب تقليديًا أجهزة منفصلة، بينما تتيح واجهتا Ethernet مسارًا طبيعيًا لفصل WAN عن LAN داخل إعداد جدار حماية افتراضي.
يستكشف دليل Proxmox لدينا أيضًا تشغيل OPNsense على هيئة آلة افتراضية لموجّه برمجي على ZimaCube، بما في ذلك فكرة تمرير واجهتي 2.5GbE منفصلتين إلى جهاز الشبكة.
القيمة تكمن في السجل، لا في حكم نهائي
عند النظر إلى المشروع ككل، يصبح مشروع بوب أكثر إثارة بكثير من مراجعة ذات خلاصة ثابتة.
يظهر ZimaCube نفسه في عدة أشكال مختلفة على مدار عمر المستودع.
يبدأ الأمر كقطعة أجهزة جديدة. يخرجها بوب من علبتها، ويفحص تصميمها، ويفتح الهيكل، ويتساءل عن التبريد، ويبدأ في التفكير في الترقيات.
يتحول الأمر إلى تجربة مع Windows Server. يختبر بوب ما إذا كانت الأجهزة الأساسية تظل مفيدة من دون البرنامج الذي شُحنت به، وذلك بإزالة ZimaOS.
يعود الأمر إلى سؤال نظام التشغيل. يقيّم بوب ZimaOS بنفسه قبل أن يقرر أن بيئته المتزايدة التعقيد تحتاج إلى شيء مختلف.
ويصبح مضيفًا لـProxmox. ومن هناك، ينضم الجهاز إلى أسطول أوسع ويبدأ في تحمّل مسؤوليات البنية التحتية.
ويصبح جزءًا من نظام النسخ الاحتياطي والمراقبة. يغيّر Proxmox Backup Server وPulse وإدارة الأسطول الهدف من «مواصلة إضافة الخدمات» إلى «جعل الخدمات موثوقة بما يكفي للتوقف عن التفكير فيها».
ثم يتحول إلى مضيف للذكاء الاصطناعي وجهاز للشبكة. لا يُعد Hermes Agent وOPNsense تجربتين منفصلتين؛ بل أصبحا ممكنين لأن طبقات البنية التحتية السابقة موجودة بالفعل.
والنتيجة هي بالضبط ما وعد به Bob في البداية: ليست مراجعة رسمية، بل ملاحظات وتجارب وآراء تتغير مع الخبرة، ومشروع مختبر منزلي يزداد طموحًا.
تحولت قصة مستخدم واحد إلى مكتبة من أدلة ZimaCube
يوضح مشروع Bob أيضًا سبب أهمية الاختبار المجتمعي طويل الأمد بما يتجاوز مختبر المنزل الخاص بشخص واحد.
تطورت عدة تجارب موثقة في مدونة تجربة ZimaCube منذ ذلك الحين إلى موارد أعمق من Zima: تثبيت Windows Server، ونشر Proxmox، واختيار نظام التشغيل، وبنية النسخ الاحتياطي، ومراقبة مختبر المنزل.
وهذا ينشئ حلقة مفيدة بين تجربة المجتمع والتوثيق. يجرّب Bob شيئًا بدافع الفضول. ويسجّل السجل ما حدث. ثم تصبح الأجزاء المفيدة أسهل لإعادة تنفيذها من قِبل الشخص التالي.
لا تزال القصة قيد الكتابة
لا تزال قصة Bob Loves Tech وZima قيد الكتابة. لقد انتقلت مدونة تجربة ZimaCube الخاصة به بالفعل من فتح الصندوق وتفكيك الأجهزة إلى ZimaOS وWindows Server وProxmox والنسخ الاحتياطية ومراقبة الأسطول وHermes Agent وOPNsense — والفكرة الأساسية من السجل المستمر هي أنه لا حاجة إلى وجود إعداد نهائي.
مع تغيّر مختبر المنزل، يمكن أن يتغيّر دور ZimaCube معه. إذا أردت معرفة ما الذي سيجرّبه Bob لاحقًا، فتابع مدونة تجربة ZimaCube المستمرة على GitHub من Bob Loves Tech.
