في محادثة مجتمعية أُجريت في مايو 2024، ناقش تايغر، المدير التقني في IceWhale، والمطور المجتمعي أكسل سبب توجه منظومة تطبيقات CasaOS وZimaOS الناشئة نحو معايير الحاويات المشتركة بدلًا من الاعتماد على تنسيق حزم خاص بالمنصة.
كانت الفكرة الأساسية بسيطة: تنمو منظومة التطبيقات بسرعة أكبر عندما يستطيع المطورون إعادة استخدام ملفات Docker Compose المألوفة، وإضافة قدر صغير من البيانات الوصفية الخاصة بمتجر التطبيقات، وتوزيع التطبيقات دون التفاوض بشأن كل مساهمة مباشرةً مع الفريق الأساسي.
كان هذا توجهًا تقنيًا في عام 2024، وليس مواصفات إصدار حالي
أُجريت المحادثة بينما كان ZimaOS لا يزال يتطور انطلاقًا من الأسس المشتركة مع CasaOS. وكانت التصريحات المتعلقة بواجهات برمجة التطبيقات المستقبلية، وورش العمل، والإضافات التابعة لجهات خارجية، والتجزئة المعيارية باستخدام systemd-sysext تصف نوايا أو تجارب في مراحلها المبكرة آنذاك. ولا ينبغي تفسيرها على أنها وعود بتسليم كل مفهوم وفق الجدول الزمني المقترح.
لماذا تسبب تنسيق تطبيقات JSON المخصص المبكر في صعوبات؟
أوضح تايغر أن متجر تطبيقات CasaOS المبكر كان يستخدم تنسيق JSON مخصصًا. وكان الملف يصف البيانات الوصفية المرتبطة بصورة Docker، بما في ذلك عنوان التطبيق، والأيقونة، ولقطات الشاشة، وتفاصيل الإعداد.
لم تكن المشكلة أن JSON عاجز عن وصف تطبيق. بل كانت المشكلة في ضم المساهمين الجدد: إذ كان يتعين على أي شخص يريد نشر تطبيق أن يتعلم أولًا تنسيقًا خاصًا بـ CasaOS. حدّت خطوة الترجمة الإضافية هذه من سرعة تحويل مشاريع الحاويات الحالية إلى تطبيقات قابلة للتثبيت.
لماذا أصبح Docker Compose أساس حزم التطبيقات؟
وجد الفريق أن Docker Compose قابل للتوسعة بدرجة تكفي لحمل تعريف الحاوية، مع استيعاب البيانات الوصفية الإضافية التي يحتاج إليها متجر التطبيقات. ولذلك أمكن تكييف مشاريع Compose الحالية بدلًا من إعادة بنائها في نظام حزم منفصل.
غيّر ذلك نموذج المساهمة:
- كان بإمكان صور الحاويات وتعريفات الخدمات مواصلة استخدام اصطلاحات Docker المألوفة.
- أمكن إضافة حقول متجر التطبيقات، مثل العناوين، والأيقونات، ولقطات الشاشة، والمنافذ، ومعلومات وحدات التخزين، حول تعريف Compose.
- كان بإمكان المساهمين إعادة استخدام العمل upstream بدلًا من صيانة حزمة منفصلة خاصة بالمنصة.
- كان بإمكان ZimaOS وCasaOS الاستفادة من منظومة الاستضافة الذاتية الأوسع.
ما الذي غيّره Docker Compose في مساهمات المجتمع؟
استخدمت المقابلة مساهمة مجتمعية مبكرة مثالًا على ذلك. وتذكر تايغر أن مساهمًا يُعرف باسم Wisdom Sky حوّل نحو 150 صورة حاوية إلى تطبيقات CasaOS خلال ليلة واحدة، بينما كان دعم متجر التطبيقات القائم على Compose في طور الظهور. وكان الفريق يتوقع سابقًا زيادة متواضعة فقط مقارنة بالمعدل القديم البالغ تطبيقًا أو تطبيقين جديدين شهريًا.
كانت هذه حكاية من محادثة عام 2024، وليست معيارًا لمدى سرعة حزم كل تطبيق. فما يزال كل تطبيق يحتاج إلى منافذ ووحدات تخزين صحيحة، ودعم للمعمارية، وأذونات، وسلوك تحديث مناسب، ومراجعة من المشرف.
كيف تنسجم متاجر التطبيقات التابعة لجهات خارجية مع المنظومة؟
وصف الفريق أيضًا دعم مصادر التطبيقات التابعة لجهات خارجية. فبدلًا من إلزام كل حزمة مجتمعية بالدخول إلى الكتالوج الرسمي، كان بإمكان المشرف استضافة مصدر مستقل يمكن للمستخدمين إضافته إلى CasaOS أو ZimaOS.
يوسّع هذا النموذج نطاق الاختيار ويخفف عنق زجاجة المراجعة لدى الفريق الرسمي، لكنه يفصل أيضًا بين الإتاحة والتأييد. فظهور تطبيق في مصدر تابع لجهة خارجية لا يعني تلقائيًا أن IceWhale تصون صورته، أو تدقق في شفرته، أو تضمن تحديثاته، أو تدعم طريقة تعامله مع البيانات. وينبغي للمستخدمين التحقق من ناشر الصورة، والمستودع، والامتيازات المطلوبة، ووحدات التخزين المرتبطة، وانكشاف الشبكة، وسجل التحديثات قبل التثبيت.
التوازن المقترح بين المكونات المفتوحة وشفرات المنتج المملوكة
قال تايغر إن ZimaOS كان يُبنى على مكونات CasaOS المفتوحة، بما في ذلك أجزاء من أساس البوابة وناقل الرسائل، في حين ستظل طبقات أخرى من المنتج مملوكة. وكان الفريق يرغب في مواصلة قبول مساهمات المصادر المفتوحة، ويدرس إتاحة مزيد من واجهات برمجة التطبيقات لمطوري الإضافات.
لم تدّعِ المقابلة أن جميع شفرات ZimaOS ستصبح مفتوحة المصدر. بل وصفت حدًا هجينًا: كشف الواجهات القابلة لإعادة الاستخدام والمكونات الموجهة إلى المجتمع، مع إبقاء تنفيذات محددة للمنتج خاصة.
ما الذي كان يُفترض أن تتيحه التجزئة المعيارية باستخدام systemd-sysext؟
ذكرت المحادثة آلية مبكرة جدًا قائمة على systemd-sysext. وكان الهدف تمكين الجهات الخارجية من إضافة امتدادات على مستوى النظام دون تعديل النواة غير القابلة للتغيير مباشرةً، على نحو يشبه من حيث المبدأ البناء اعتمادًا على واجهة منصة محددة.
وبما أن تايغر وصف هذا العمل صراحةً بأنه في مرحلة مبكرة، فينبغي قراءة هذا القسم باعتباره سياقًا معماريًا. فلم يقدم المنشور حزمة تطوير عامة للإضافات، أو عقدًا مستقرًا لواجهة برمجة التطبيقات، أو سياسة توافق، أو موعد إصدار مؤكد.
المبدأ الأوسع: إعادة استخدام المعايير بدلًا من إعادة اختراعها
كانت الخلاصة الأكثر استدامة هي تفضيل معايير المجتمع الحالية. فقد أدى إعادة استخدام Docker وCompose إلى تقليل العمل الخاص بالمنصة لكل من فريق IceWhale والمساهمين في التطبيقات، مع ربط متجر التطبيقات بمجموعة أكبر بكثير من برمجيات الاستضافة الذاتية.
يقدم الاستعراض الحالي لـ ZimaOS الآن متجر تطبيقات قائمًا على السيناريوهات، ودعمًا لـ Docker التابع لجهات خارجية، وكتالوجًا يضم أكثر من 800 تطبيق. ويوضح وصف المنتج الحالي كيفية تطور المنظومة، بينما تشرح مقابلة عام 2024 منطق التصميم الذي سبق ذلك.
شاهد محادثة منظومة متجر التطبيقات الأصلية
يحافظ الفيديو الكامل على نبرة النقاش بين أكسل وتايغر وسياقه التاريخي.
الأسئلة الشائعة حول منظومة متجر تطبيقات ZimaOS
لماذا ابتعدت CasaOS عن تنسيق التطبيقات المخصص القائم على JSON فقط؟
أضاف التنسيق المخصص خطوة تعلم للمساهمين. وأتاح Docker Compose للمشرفين إعادة استخدام تعريف خدمات واسع الانتشار وسهل الفهم، مع إضافة البيانات الوصفية التي يحتاج إليها متجر التطبيقات.
هل متاجر تطبيقات ZimaOS التابعة لجهات خارجية هي نفسها متجر التطبيقات الرسمي؟
لا. يمكن للمصادر التابعة لجهات خارجية توسيع نطاق توفر التطبيقات، لكن قد يتولى صيانة حزمها ومراجعتها أشخاص مختلفون. وينبغي للمستخدمين تقييم المصدر وإعدادات الحاوية قبل التثبيت.
هل أكدت المقابلة وجود واجهة برمجة تطبيقات عامة لإضافات ZimaOS؟
لا. قال الفريق إنه يدرس واجهات برمجة التطبيقات، وورش العمل، وتطوير الإضافات. ولم تنشر المحادثة واجهة برمجة تطبيقات مستقرة أو موعدًا للتسليم.
هل كان systemd-sysext ميزة مكتملة بالفعل في ZimaOS في مايو 2024؟
لا. وصف تايغر آلية التجزئة المعيارية بأنها في مرحلة مبكرة جدًا. وقد قُدمت باعتبارها مسارًا محتملًا للإضافات حول نواة غير قابلة للتغيير.
هل جميع شفرات ZimaOS مفتوحة المصدر؟
وصفت المقابلة توازنًا بين المكونات المفتوحة وشفرات المنتج المملوكة، ولم تصف نظام تشغيل مفتوح المصدر بالكامل.
