Outline روی ARM: کدام ساخت و چه کسی آن را نگه می‌دارد؟

برچسب ARM64 یک پرسش سازگاری را حل می‌کند و سه پرسش دشوارتر را باز می‌گذارد. نمی‌گوید چه کسی فایل اجرایی را ساخته، از کدام بازنگری منبع آمده یا چه کسی اصلاح امنیتی بعدی را می‌رساند. وقتی پاسخ قدیمی یک انجمن به ساخت جامعه اشاره می‌کند، همان پرسش‌ها تعیین می‌کنند که آیا نصب قابل دفاع است. پیش از دانلود هر چیزی آن‌ها را جدا کنید.

مدیر یا کلاینت: نخست ابزار درست را انتخاب کنید

Outline یک مدیر برای اداره سرورها و یک کلاینت برای اتصال دستگاه‌ها ارائه می‌کند و این‌ها دو برنامه جداگانه‌اند. مخزن بالادست دو نقش را از هم جدا می‌کند و به کانال‌های نصب خودشان پیوند می‌دهد. نصب یک مدیر روی Raspberry Pi کلاینتی برای همان Pi به شما نمی‌دهد. دو کانال با زمان‌بندی‌های متفاوت به‌روزرسانی می‌شوند. هر دو نقش وجود دارند، پس پرسش این است که دستگاه قرار است کدام نقش را بازی کند.

کانال فعلی کلاینت را برای سیستم‌عاملی که اجرا می‌کنید بررسی کنید. یک مدخل عمومی Linux ماتریس معماری نیست و وعده‌ای درباره هر برد نیست. صفحه دانلود را فهرستی از آنچه وجود دارد بخوانید، نه فهرستی از آنچه باید وجود داشته باشد.

یک گزارش تاریخی که پشتیبانی ARM را می‌خواهد چیزی درباره آنچه امروز منتشر می‌شود نمی‌گوید. آن را سندی از یک کمبود گذشته بدانید، نه بیانیه‌ای درباره حال. کانالی که می‌توانید از آن دانلود کنید تنها شواهدی است که به حساب می‌آید.

سیستم نصب‌شده واقعاً کدام معماری را اجرا می‌کند؟

نسخه و ابزار در حال بررسی را ثبت کنید، نه فقط نام برد را. فایل اجرایی و اجزای بومی آن را با هدف تطبیق دهید، زیرا هسته 64 بیتی می‌تواند فضای کاربری 32 بیتی را اجرا کند و برچسب روی جعبه به شما نمی‌گوید کدام.

کد منبع کلاینت شامل کد رابط مشترک و اجزای مخصوص پلتفرم است. بازسازی تنها رابط، پورت پلتفرم نیست، هر‌قدر هم که تمیز کامپایل شود. قطعات بومی جایی هستند که معماری واقعاً خود را نشان می‌دهد. بازسازی‌ای که فقط رابط را لمس کند اجرا می‌شود و باز هم در سمت بومی شکست می‌خورد.

uname -m و معماری بسته سیستم نصب‌شده دو واقعیتی هستند که اینجا مهم‌اند. آن‌ها را روی دستگاه بخوانید، نه روی ماشینی که از آن می‌سازید. ناسازگاری در آن گام هر مقایسه بعدی را بی‌اعتبار می‌کند.

ساخت جامعه یک مالک انتشار اضافه می‌کند

اگر کانال رسمی برای هدف شما ابزار پشتیبانی‌شده‌ای ندارد، ساخت جامعه به تصمیمی برای استقرار تبدیل می‌شود نه نصب. ناشر، بازنگری منبع، تغییرات نسبت به بالادست و دستورالعمل‌های ساخت را مشخص کنید.

سپس بپرسید اصلاحات آینده چگونه به نصب می‌رسند. به‌روزرسانی‌ها ممکن است از بالادست، از انشعاب یا از بازسازی دستی‌ای بیایند که کسی باید به یاد داشته باشد اجرا کند. گزینه سوم همان است که بی‌صدا متوقف می‌شود.

مخزنی که به‌روز به نظر می‌رسد چیزی درباره اینکه کدام بازنگری فایل دودویی‌ای را که دارید ساخته نمی‌گوید. دستورالعمل‌های ساخت را با آنچه ابزار درباره خودش گزارش می‌دهد مقایسه کنید. اگر آن دو ناسازگار باشند، ابزار همان چیزی است که نباید به آن اعتماد کرد.

مجموع بازبینی چه چیزی را اثبات می‌کند و چه چیزی را نه

مجموع بازبینی بایت‌های مشخصی را شناسایی می‌کند. مجموع بازبینی‌ای که همان سازنده غیررسمی منتشر می‌کند آن سازنده را پروژه بالادست نمی‌کند و به شما نمی‌گوید آن بایت‌ها چه دارند. پاسخ می‌دهد که آیا دانلود سالم رسیده است، که پرسشی سودمند اما باریک است. این ویژگی فایل است، نه شخصی که آن را منتشر کرده.

تصویر صفحه از یک راه‌اندازی موفق شواهدی درباره یک ماشین است. بررسی فایل دودویی یا کانال به‌روزرسانی آن نیست. هیچ‌کدام از این دو ابزار جای خواندن منبع را نمی‌گیرد.

یک ساخت ناآشنا را تا زمانی که منشأ و اختیارات لازم بررسی نشده‌اند از اسرار تولید دور نگه دارید. نخست آن را در محیطی یک‌بارمصرف با حساب خودش اجرا کنید. این ارزان است و یک نظر را به آزمون تبدیل می‌کند.

تصمیم بگیرید این یک آزمایش است یا یک دستگاه

مدیر ممکن است آگاهانه منبع بررسی‌شده‌ای را برای هدفی پشتیبانی‌شده بسازد و مسئولیت وابستگی‌ها، بسته‌بندی و به‌روزرسانی‌ها را بپذیرد. این مدل پشتیبانی متفاوتی از نصب ابزار بالادست نگه‌داری‌شده است. برای دستگاه بی‌ناظر، مدلی را انتخاب کنید که مالک مسئول بتواند حفظ کند.

هویت ابزار، پلتفرم، نتیجه بررسی و مالک به‌روزرسانی را کنار استقرار ثبت کنید. تصمیم زمانی کامل است که این‌ها همخوانی داشته باشند، نه زمانی که یک فایل دودویی ARM یک بار شروع به کار کند.