Outline على ARM: أي بناء، ومن يصونه؟

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

المدير أم العميل: اختر الأداة الصحيحة أولًا

يوفّر Outline مديرًا لإدارة الخوادم وعميلًا لتوصيل الأجهزة، وهما تطبيقان منفصلان. يميّز المستودع الأصلي بين الدورين ويضع روابط لقنوات التثبيت الخاصة بكل منهما. تثبيت مدير على Raspberry Pi لا يمنحك عميلًا لذلك الجهاز. كما تتحدّث القناتان وفق جداول مختلفة. الدوران موجودان، لذا السؤال هو أي دور يُفترض أن يؤديه الجهاز.

افحص قناة العميل الحالية لنظام التشغيل الذي تشغّله. مدخل Linux عام ليس مصفوفة معماريات، وليس وعدًا بكل لوحة. اقرأ صفحة التنزيل كقائمة بما هو موجود لا كقائمة بما ينبغي أن يكون موجودًا.

مسألة تاريخية تطلب دعم ARM لا تقول شيئًا عمّا يُنشر اليوم. تعامل معها كسجل لفجوة سابقة لا كبيان عن الحاضر. القناة التي يمكنك التنزيل منها هي الدليل الوحيد المعتبر.

أي معمارية يشغّلها النظام المثبّت فعلًا؟

سجّل الإصدار والأداة قيد المراجعة، لا اسم اللوحة فقط. طابق الملف التنفيذي ومكوّناته الأصلية مع الهدف، لأن نواة 64 بت يمكنها تشغيل مساحة مستخدم 32 بت ولن يخبرك الملصق على الصندوق أيّهما.

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

uname -m ومعمارية حزمة النظام المثبّت هما الحقيقتان المهمتان هنا. اقرأهما على الجهاز، لا على الآلة التي تبني منها. أي تعارض في تلك الخطوة يبطل كل مقارنة لاحقة.

البناء المجتمعي يضيف مالكًا للإصدار

إذا لم تكن لدى القناة الرسمية أداة مدعومة لهدفك، يصبح البناء المجتمعي قرار نشر لا عملية تثبيت. حدّد الناشر، ومراجعة المصدر، والتغييرات عن الأصل، وتعليمات البناء.

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

مستودع يبدو حديثًا لا يقول شيئًا عن المراجعة التي أنتجت ملفًا ثنائيًا تملكه بالفعل. قارن تعليمات البناء بما تعلنه الأداة عن نفسها. إذا اختلف الاثنان، فالأداة هي التي يجب عدم الوثوق بها.

ما يثبته المجموع الاختباري وما لا يثبته

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

لقطة شاشة لإطلاق ناجح هي دليل على آلة واحدة. إنها ليست مراجعة للملف الثنائي ولا لقناة تحديثه. لا أي من الأثرين يغني عن قراءة المصدر.

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

قرّر ما إذا كان هذا تجربة أم جهازًا

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

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