SSD Nodes Learn 🎉 VPS از $5.50/ماه
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-08-13

مقایسه Rocky Linux و AlmaLinux برای سرور مجازی

انتخاب بین Rocky Linux و AlmaLinux برای VPS به نیاز سخت‌افزاری شما بستگی دارد. AlmaLinux 10 از پردازنده‌های قدیمی پشتیبانی می‌کند اما Rocky Linux 10 این قابلیت را حذف کرده است.

مقایسه Rocky Linux و AlmaLinux: پاسخ کوتاه

برای تقریباً هر سروری، انتخاب بین Rocky Linux و AlmaLinux انتخابی است که پاسخ اشتباه ندارد. هر دو پروژه، سورس‌کد Red Hat Enterprise Linux (RHEL) را بازسازی می‌کنند، بنابراین هر دو پکیج‌های یکسانی را با چرخه پشتیبانی 10 ساله ارائه می‌دهند. تفاوت‌ها واقعی هستند، اما در نحوه مدیریت (governance) و تعداد کمی از موارد خاص (edge cases) وجود دارند، نه در کارهای روزمره مدیریت سرور.

وقتی انتخاب بین این دو تصادفی نیست، دو عامل تعیین‌کننده وجود دارد. AlmaLinux 10 همچنان نسخه‌ای برای پردازنده‌های قدیمی‌تر از Intel Haswell ارائه می‌دهد، در حالی که Rocky Linux 10 این کار را نمی‌کند؛ این موضوع در سخت‌افزارهای ارزان‌تر یا قدیمی‌تر VPS (سرور مجازی) اهمیت دارد. همچنین AlmaLinux به‌جای رفتار کاملاً یکسان، وعده سازگاری ABI را می‌دهد که اگر از محصول یک فروشنده با ماتریس پشتیبانی سخت‌گیرانه استفاده می‌کنید، اهمیت پیدا می‌کند.

خاستگاه هر دو توزیع

در تاریخ 8 دسامبر 2020، پروژه CentOS اعلام کرد که عمر CentOS Linux 8، که بازسازی‌شده‌ای از RHEL 8 بود، در پایان سال 2021 به پایان می‌رسد. این توزیع در ابتدا با تاریخ پایان پشتیبانی در سال 2029 منتشر شده بود. آینده این پروژه، CentOS Stream معرفی شد که در همان اطلاعیه، به عنوان توزیعی که دقیقاً پیش از نسخه فعلی RHEL حرکت می‌کند و نقش شاخه توسعه بالادستی (upstream) برای RHEL را دارد، توصیف شد. CentOS Linux 7 طبق برنامه زمانی اصلی خود باقی ماند و در تاریخ 30 ژوئن 2024 به پایان عمر خود رسید.

مشکل اصلی، خودِ CentOS Stream نبود. مشکل این بود که چرخه حیاتی که قرار بود در سال 2029 به پایان برسد، با حدود یک سال اطلاع‌رسانی، هشت سال جلو کشیده شد؛ آن هم برای ماشین‌هایی که از قبل نصب و راه‌اندازی شده بودند. Rocky Linux و AlmaLinux هر دو به همین دلیل به وجود آمدند. هر دو در سال 2021 ظاهر شدند و هدف هر دو یکسان بود: ارائه یک بازسازی رایگان از RHEL که مدیر سیستم بتواند آن را نصب کند و سپس برای یک دهه آن را به حال خود رها کند.

اشتراکات Rocky Linux و AlmaLinux

از اینجا شروع کنید، زیرا بخش مشترک، بخش عمده تصویر است. هر دو توزیع از منابع بالادستی یکسان RHEL بازسازی می‌شوند، بنابراین هر دو نسخه‌های بسته یکسان، مدیر بسته dnf یکسان، خط‌مشی SELinux (لینوکس با امنیت ارتقایافته) یکسان، رابط کاربری firewalld یکسان و ساختار unit در systemd یکسان را به شما ارائه می‌دهند. فایل‌های پیکربندی در مسیرهای مشابه قرار دارند. راهنمایی که برای یکی نوشته شده باشد، با تغییر نام برای دیگری نیز کار می‌کند.

هر دو توزیع، نسخه‌های فرعی RHEL را به‌دقت دنبال می‌کنند. AlmaLinux 10.2 در تاریخ 26 May 2026 و Rocky Linux 10.2 در تاریخ 28 May 2026 منتشر شدند. سری 9 نیز در همان هفته جابه‌جا شد: AlmaLinux 9.8 در 26 May 2026 و Rocky Linux 9.8 در 27 May 2026. در گذشته این فاصله بیشتر بود. AlmaLinux 10.0 در 27 May 2025 و Rocky Linux 10.0 در 11 June 2025 عرضه شدند.

این فاصله مربوط به رسانه‌های انتشار نسخه‌های فرعی است، نه امنیت. هر دو پروژه به‌طور مداوم بین نسخه‌های فرعی، اصلاحیه‌ها (errata) را از طریق سرویس اصلاحیه اختصاصی خود منتشر می‌کنند. اختلاف دو هفته‌ای در زمان انتشار یک ایمیج .2 به معنای دو هفته بدون وصله امنیتی نیست.

هر دو توزیع همچنین از مدل چرخه حیات ده ساله که از RHEL به ارث برده‌اند پیروی می‌کنند: تقریباً پنج سال پشتیبانی فعال و سپس پنج سال نگهداری فقط برای موارد امنیتی. سری 10 در هر دو توزیع تا سال 2035 ادامه دارد.

چه نهادی پشت هر پروژه قرار دارد؟

Rocky Linux متعلق به Rocky Enterprise Software Foundation (RESF) است؛ یک شرکت انتفاعی عمومی در دلاور که توسط Gregory Kurtzer، از هم‌بنیان‌گذاران CentOS، ایجاد شد. در نوامبر 2022، RESF اساسنامه و منشوری را تصویب کرد که کنترل پروژه را از دست بنیان‌گذار آن خارج کرده و به آن ساختار مکتوب منتقل نمود. شرکت CIQ که آن هم توسط Kurtzer تأسیس شده، حامی اصلی این پروژه است و پشتیبانی تجاری برای Rocky Linux ارائه می‌دهد.

AlmaLinux متعلق به AlmaLinux OS Foundation است؛ یک سازمان غیرانتفاعی 501(c)(6) که در مارس 2021 در دلاور ثبت شد. هیئت‌مدیره این بنیاد توسط اعضای آن و در دوره‌های چهارساله متناوب انتخاب می‌شوند، صورت‌جلسات ظرف چهارده روز منتشر می‌گردد و طبق اساسنامه، هیچ کارفرمای واحدی نمی‌تواند بیش از یک کرسی حق رأی در هیئت‌مدیره داشته باشد، صرف‌نظر از اینکه چقدر حامی مالی پروژه است. شرکت CloudLinux این پروژه را آغاز کرد و در اکتبر 2024 حمایت مالی پلاتینیوم خود را به ارزش یک میلیون دلار در سال تمدید نمود. بخش TuxCare از همین شرکت، پشتیبانی تجاری آن را ارائه می‌دهد.

هر دو ساختار به گونه‌ای طراحی شده‌اند که هیچ شرکت واحدی نتواند اتفاقی که برای CentOS Linux 8 افتاد را تکرار کند و هیچ‌کدام به‌طور آشکار امن‌تر از دیگری نیست. آنچه در هر دو مورد می‌توانید بررسی کنید یکسان است: می‌توانید اساسنامه‌ها را بخوانید و نام سازمانی که هزینه‌ها را تأمین می‌کند، شناسایی کنید.

در سال 2023 چه تغییری رخ داد و آیا هنوز اهمیت دارد؟

در 21 ژوئن 2023، Red Hat اعلام کرد که CentOS Stream به تنها مخزن برای انتشار کدهای منبع عمومی مرتبط با RHEL تبدیل خواهد شد. پیش از آن، کدهای منبع بسته‌های RHEL در git.centos.org قرار می‌گرفتند که همان جایی بود که پروژه‌های بازسازی (rebuild) کدهای خود را از آن دریافت می‌کردند. حذف این منبع، مانع از فعالیت پروژه‌های بازسازی نشد. اما این اقدام، هر پروژه را مجبور کرد تا به‌صورت عمومی پاسخ دهد که چگونه منابع خود را تأمین خواهد کرد.

پروژه Rocky در 29 ژوئن 2023 پاسخ داد. این پروژه منابع RHEL را از طریق imageهای کانتینر Universal Base Image (UBI) و نمونه‌های ابری عمومی با پرداخت به ازای استفاده (pay per use) دریافت می‌کند، با این استدلال که «هیچ‌کس نمی‌تواند مانع بازنشر نرم‌افزارهای تحت مجوز GPL شود». در اوت 2023، شرکت‌های CIQ، Oracle و SUSE «انجمن لینوکس سازمانی باز» (OpenELA) را تشکیل دادند که منابع مورد نیاز برای یک بازسازی لینوکس سازمانی با سازگاری کامل (bug for bug compatible) را منتشر می‌کند. AlmaLinux عضو این انجمن نیست.

پروژه AlmaLinux در 13 ژوئیه 2023 پاسخ داد و پاسخ آن تغییری در اهداف پروژه بود. این پروژه سازگاری 1:1 (bug for bug) را کنار گذاشت و سازگاری ABI را جایگزین آن کرد. به گفته خودشان: «ما دیگر خود را ملزم به رعایت سازگاری bug-for-bug با Red Hat نمی‌دانیم و این بدان معناست که اکنون می‌توانیم اصلاحات باگ‌ها را خارج از چرخه انتشار Red Hat بپذیریم». همان پست به کاربران اطمینان داد که در استفاده روزمره «تغییر بسیار کمی» را تجربه خواهند کرد.

پس از گذشت سه سال، مسئله تأمین منابع در عمل حل شده است. هر دو پروژه از آن زمان تاکنون تمامی نسخه‌های فرعی RHEL را در زمان‌بندی‌های مشابه منتشر کرده‌اند. آنچه از این بحث باقی مانده، تفاوت در وعده‌هایی است که هر یک از این دو پروژه به کاربران خود می‌دهند.

سازگاری Bug for bug یا ABI: تفاوت در چیست؟

صفحه اصلی Rocky Linux همچنان این توزیع را به گونه‌ای توصیف می‌کند که برای سازگاری 100 درصدی Bug for bug با RHEL طراحی شده است. عبارت Bug for bug به این معناست که بازسازی (rebuild)، رفتار RHEL را دقیقاً با همان نقص‌هایش بازتولید می‌کند. اگر بسته‌ای در RHEL دارای باگ باشد، همان بسته در Rocky Linux نیز آن باگ را دارد؛ بنابراین راهکارهای ارائه‌شده در مقالات پایگاه دانش Red Hat بدون نیاز به تغییر، در اینجا نیز قابل استفاده هستند.

سازگاری ABI محدودتر و دقیق‌تر است. ABI یا Application Binary Interface، قرارداد باینری است که یک برنامه کامپایل‌شده به آن وابسته است: نام نمادها (symbol names)، چیدمان ساختارها، قراردادهای فراخوانی و نسخه‌های کتابخانه‌ها. اگر این قرارداد ثابت بماند، فایلی که برای RHEL ساخته شده است، بارگذاری و اجرا می‌شود. این وعده هیچ حرفی درباره مطابقت با باگ‌های RHEL نمی‌زند.

نتیجه‌گیری بسیار ساده است. AlmaLinux می‌تواند باگی را پیش از Red Hat برطرف کند و می‌تواند درایوری را که Red Hat حذف کرده است، نگه دارد. هر دوی این موارد، رفتار سیستم را به‌طور عمدی از RHEL متمایز می‌کند. Rocky Linux طبق طراحی خود هیچ‌کدام از این کارها را انجام نمی‌دهد، بنابراین دقیقاً به همان شکلی که برای گواهی‌نامه‌ها (certification) اهمیت دارد، قابل پیش‌بینی باقی می‌ماند.

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

آیا بسته‌های ارائه‌شده توسط فروشنده که برای RHEL ساخته شده‌اند، روی هر دو نصب می‌شوند؟

بله. یک فایل RPM که برای RHEL 9 یا RHEL 10 ساخته شده است، روی هر دو نصب و اجرا می‌شود؛ زیرا ABI مطابقت دارد و هر دو توزیع خود را به ابزارهای سیستمی به شکلی معرفی می‌کنند که سیستم‌های خانواده Red Hat معرفی می‌کنند. فایلی که این معرفی را انجام می‌دهد /etc/os-release است.

NAME="AlmaLinux"
ID="almalinux"
ID_LIKE="rhel centos fedora"

نسخه موجود در Rocky Linux ساختار مشابهی با NAME="Rocky Linux" و ID="rocky" دارد و همچنین rhel را در ID_LIKE فهرست می‌کند. اسکریپت نصبی که ID_LIKE را می‌خواند، rhel را پیدا می‌کند و مسیر Red Hat را در پیش می‌گیرد، روی هر دو کار می‌کند. اسکریپتی که فقط ID را با یک لیست سخت‌کد شده از rhel، centos و fedora مقایسه می‌کند، روی هر دو شکست می‌خورد و این شکست در هر دو یکسان است و با پیام توزیع پشتیبانی‌نشده مواجه می‌شود. این یک باگ در اسکریپت است، نه تفاوتی بین این دو سیستم.

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

کدام توزیع همچنان روی پردازنده‌های قدیمی‌تر اجرا می‌شود؟

توزیع RHEL 10 سطح پایه معماری x86-64 را به x86-64-v3 ارتقا داده است. این سطح با نسل Haswell اینتل و Excavator ای‌ام‌دی مطابقت دارد و نیازمند افزونه‌های مجموعه دستورالعمل‌هایی مانند AVX2 است. Rocky Linux 10 نیز در این مورد از RHEL پیروی می‌کند. مستندات آن بیان می‌کند که x86-64-v3 سطح پایه است و سطوح v2 و قدیمی‌تر دیگر پشتیبانی نمی‌شوند.

توزیع AlmaLinux 10 نسخه v3 را به عنوان پیش‌فرض ارائه می‌دهد و یک نسخه مجزای x86-64-v2 نیز اضافه کرده است تا به گفته خودشان، کاربران دارای سخت‌افزارهای قدیمی‌تر بتوانند برای ده سال دیگر به‌روزرسانی‌های امنیتی دریافت کنند. AlmaLinux همچنین بسته‌های EPEL را برای آن معماری بازسازی می‌کند، زیرا بسته‌های شخص‌ثالث RHEL 10 برای v3 هدف‌گذاری شده‌اند. این نکته‌ای است که پیش از تکیه بر آن باید بدانید: نسخه v2 برای مجموعه بسته‌های پیش‌فرض و EPEL مخصوص v2 خودِ AlmaLinux مناسب است و هر چیز دیگری باید توسط شما برای v2 بازسازی شود.

این موضوع در VPS اهمیت بیشتری نسبت به سخت‌افزاری که مالک آن هستید دارد، زیرا شما پردازنده میزبان را انتخاب نمی‌کنید. در میزبان‌های قدیمی‌تر یا ارزان‌تر، یا جایی که هایپروایزر یک مدل CPU محافظه‌کارانه را به مهمان ارائه می‌دهد، ماشین مجازی ممکن است AVX2 را در دسترس قرار ندهد، حتی اگر تراشه فیزیکی آن را داشته باشد. در این صورت، بسته‌های ساخته‌شده برای v3 به دنبال دستورالعمل‌هایی می‌گردند که پردازنده فاقد آن‌هاست و در نتیجه با شکست مواجه می‌شوند. پیش از آنکه مجموعه‌ای از سرورها را به سری 10 منتقل کنید، بررسی کنید که نمونه (instance) شما واقعاً چه قابلیت‌هایی را ارائه می‌دهد. سری 9 هر دو توزیع همچنان در سطح v2 اجرا می‌شوند. در نمونه‌های ARM به جای نمونه‌های x86 این پرسش هرگز مطرح نمی‌شود، زیرا سطوح ریزمعماری مفهومی مختص x86-64 هستند.

همین آزادی عمل در بخش‌های دیگر AlmaLinux 10 نیز دیده می‌شود. این پروژه پشتیبانی از بیش از 150 دستگاهی که در نسخه بالادستی (upstream) حذف شده بودند، از جمله شناسه‌های PCI برای کنترلرهای قدیمی RAID و iSCSI را دوباره فعال کرده و SPICE را هم برای استفاده سرور و هم کلاینت بازگردانده است. اشاره‌گرهای فریم (frame pointers) به‌صورت پیش‌فرض فعال هستند که باعث می‌شود پروفایل‌گیری در سطح کل سیستم به‌درستی کار کند. تعهد به «خطا به ازای خطا» (bug for bug) مانع از هر یک از این تغییرات می‌شد، بنابراین تصمیم سال 2023 همان چیزی بود که فضای لازم برای انجام این تغییرات را فراهم کرد.

چگونه یک سرور CentOS یا RHEL موجود را مهاجرت دهیم؟

Rocky Linux اسکریپت‌های تبدیل را در مخزن rocky-tools خود منتشر می‌کند. migrate2rocky.sh یک سیستم Enterprise Linux 8 را به Rocky Linux 8 تبدیل می‌کند و migrate2rocky9.sh همین کار را برای سری 9 انجام می‌دهد. هر کدام در محدوده یک نسخه اصلی (major version) کار می‌کنند. از اوت 2026، این مخزن هیچ اسکریپت مشابهی برای Enterprise Linux 10 ندارد، بنابراین انتقال به Rocky Linux 10 به معنای نصب مجدد است.

AlmaLinux ابزار almalinux-deploy.sh را منتشر می‌کند که Enterprise Linux 8، 9 و 10 را پوشش می‌دهد و تبدیل از CentOS Stream، Oracle Linux، RHEL، Rocky Linux، MiracleLinux و Virtuozzo Linux را در معماری‌های x86_64، aarch64، ppc64le و s390x انجام می‌دهد. پیش از شروع، مطالعه محدودیت‌های مستندشده آن ضروری است. تنها boot loader از نوع GRUB2 در سیستم‌هایی که به آن نیاز دارند پشتیبانی می‌شود و هسته‌های سفارشی مانند UEK (Unbreakable Enterprise Kernel) متعلق به Oracle به‌طور خودکار حذف نمی‌شوند، که این امر باعث می‌شود دستگاه تحت Secure Boot قادر به بالا آمدن نباشد.

برای پرش بین نسخه‌های اصلی، AlmaLinux پروژه ELevate را نگهداری می‌کند که بر پایه فریم‌ورک leapp شرکت Red Hat ساخته شده است. مسیرهای مستندشده عبارتند از CentOS 7 به EL8، AlmaLinux 8 یا CentOS Stream 8 به EL9، و AlmaLinux 9 یا CentOS Stream 9 به EL10. مستندات، مقصد را به جای نام بردن از یک توزیع خاص، به صورت EL8، EL9 یا EL10 ذکر می‌کنند، زیرا شما انتخاب می‌کنید که در نهایت از کدام توزیع Enterprise Linux استفاده کنید.

هر یک از این ابزارها بسته‌های release را بازنویسی کرده و بخش بزرگی از سیستم را دوباره نصب می‌کنند. ابتدا یک snapshot از ارائه‌دهنده سرویس خود تهیه کنید. همان‌طور که مستندات خود AlmaLinux توصیه می‌کند، عملیات تبدیل را داخل screen یا tmux اجرا کنید، زیرا قطع شدن اتصال SSH در میانه راه، دستگاه را در وضعیتی قرار می‌دهد که نمی‌خواهید آن را از طریق rescue console عیب‌یابی کنید.

پس کدام‌یک را انتخاب کنید؟

برای یک workload معمولی روی VPS، هر دو مناسب هستند. آن‌ها بسته‌های یکسانی را نصب می‌کنند و در یک سال به پایان پشتیبانی می‌رسند. یکی را انتخاب کنید، آن را روی تمام سرورهایی که مدیریت می‌کنید به کار ببرید و دیگر به آن فکر نکنید. ثبات، ارزشمندتر از تفاوت بین آن‌هاست، زیرا ناوگان ترکیبی از توزیع‌ها، تعداد imageها و فیدهای errata که باید دنبال کنید را دوبرابر می‌کند. این هزینه به‌محض اینکه شروع به مدیریت همزمان چندین سرور لینوکسی کنید، به‌سرعت افزایش می‌یابد.

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

  • پردازنده میزبان شما قدیمی‌تر از Haswell است یا hypervisor قابلیت AVX2 را از guest مخفی می‌کند. AlmaLinux 10 دارای build نسخه x86-64-v2 است، اما Rocky Linux 10 چنین نیست.
  • فروشنده‌ای که به او هزینه پرداخت می‌کنید، توزیع خاصی را در ماتریس پشتیبانی خود ذکر کرده است. از همان استفاده کنید.
  • برای گواهی‌نامه یا حسابرسی، به رفتاری دقیقاً مشابه RHEL نیاز دارید. هدف اعلام‌شده Rocky Linux سازگاری «باگ برای باگ» است، در حالی که هدف AlmaLinux صراحتاً چنین نیست.
  • قصد دارید یک سرور در حال اجرا را تبدیل کنید، نه اینکه یک سرور جدید بسازید. ابزارهای AlmaLinux در حال حاضر توزیع‌های منبع و نسخه‌های اصلی بیشتری، از جمله Enterprise Linux 10 را پوشش می‌دهند.

اگر پرسش اصلی انتخاب بین Enterprise Linux و چیزی دیگر است، در واقع دارید مدل چرخه حیات را انتخاب می‌کنید. یک توزیع Enterprise Linux به شما ده سال زمان با یک مجموعه بسته ثابت می‌دهد، بدون اینکه نیاز باشد برای جهش‌های نسخه‌ای برنامه‌ریزی کنید. نسخه‌های long term support در Ubuntu، پنج سال پشتیبانی استاندارد با یک مسیر ارتقای پشتیبانی‌شده در هر دو سال به شما می‌دهند که معامله متفاوتی است و در مقایسه Ubuntu LTS و نسخه‌های interim به آن پرداخته شده است. هر کدام را که نصب کنید، ساعت اول کار با ماشین یکسان به نظر می‌رسد؛ بنابراین پیش از نصب هر چیزی، ده دقیقه اول روی یک VPS جدید را انجام دهید.

FAQ

آیا Rocky Linux یا AlmaLinux به Red Hat Enterprise Linux نزدیک‌تر است؟

طبق هدف اعلام‌شده، Rocky Linux. صفحه اصلی این توزیع، آن را به گونه‌ای توصیف می‌کند که 100 درصد با RHEL سازگار باشد (bug for bug compatible)؛ به این معنی که قصد دارد رفتار RHEL، از جمله نقص‌های آن را بازتولید کند. AlmaLinux در 13 ژوئیه 2023 اعلام کرد که در عوض، سازگاری ABI (رابط باینری برنامه) را هدف قرار می‌دهد؛ بنابراین نرم‌افزارهایی که برای RHEL ساخته شده‌اند روی آن اجرا می‌شوند، در حالی که کد زیرین ممکن است شامل اصلاحاتی باشد که RHEL هنوز عرضه نکرده است. برای اجرای نرم‌افزارهای معمول سرور، این دو معادل هستند. برای دریافت گواهینامه‌ای که به رفتار RHEL وابسته است، این تفاوت نکته اصلی است.

آیا می‌توانم بدون نصب مجدد، از Rocky Linux به AlmaLinux مهاجرت کنم؟

بله، در این جهت امکان‌پذیر است. almalinux-deploy.sh مربوط به AlmaLinux، توزیع‌های Rocky Linux 8، 9 و 10 را در کنار CentOS Stream، Oracle Linux، RHEL و MiracleLinux در لیست منابع پشتیبانی‌شده خود دارد. حرکت در جهت عکس محدودتر است: مخزن rocky-tools مربوط به Rocky، اسکریپت‌های تبدیل را فقط برای Enterprise Linux 8 و 9 ارائه می‌دهد؛ بنابراین تا اوت 2026 مسیر مستقیمی برای ارتقا به Rocky Linux 10 وجود ندارد. پیش از هرگونه تبدیل، یک snapshot تهیه کنید و عملیات را از نشست (session) امنی اجرا کنید که با قطع اتصال از بین نرود، زیرا این فرآیند بسته‌های release را جایگزین کرده و بخش بزرگی از سیستم را مجدداً نصب می‌کند.

آیا بسته‌های ساخته‌شده برای RHEL روی هر دو کار می‌کنند؟

بله، برای بسته‌های معمولی RPM و مخازن شخص ثالث. هر دو توزیع، رابط باینری برنامه (ABI) مربوط به RHEL را حفظ می‌کنند و هر دو خود را با ID_LIKE="rhel centos fedora" در /etc/os-release شناسایی می‌کنند؛ بنابراین یک بسته یا اسکریپت نصب که خانواده سیستم Red Hat را بررسی می‌کند، مسیر درست را انتخاب خواهد کرد. استثنا در اینجا تجاری است، نه فنی: ممکن است یک فروشنده فقط توزیع‌هایی را پشتیبانی کند که در ماتریس پشتیبانی‌اش نام برده شده‌اند، حتی اگر بسته آن روی هر دو نصب و اجرا شود. اگر برای آن پشتیبانی هزینه پرداخت می‌کنید، اجازه دهید ماتریس تصمیم‌گیرنده باشد.

برای یک VPS ارزان با CPU قدیمی از کدام استفاده کنم؟

اگر به سری 10 نیاز دارید، AlmaLinux. نسخه RHEL 10 حداقل سطح مورد نیاز x86-64 را به معماری v3 ارتقا داده است که به پردازنده‌ای در سطح Intel Haswell یا AMD Excavator نیاز دارد و Rocky Linux 10 نیز از همین استاندارد پیروی می‌کند. AlmaLinux 10 یک نسخه اضافی x86-64-v2 برای سخت‌افزارهای قدیمی‌تر ارائه می‌دهد که ده سال به‌روزرسانی امنیتی برای آن در نظر گرفته شده است. پیش از نهایی کردن انتخاب، بررسی کنید که instance شما چه چیزی را نمایش می‌دهد، زیرا یک ماشین مجازی مدل CPUای را می‌بیند که hypervisor به آن اختصاص داده است و نه لزوماً تمام مجموعه دستورالعمل‌های میزبان را. سری 9 هر دو توزیع همچنان روی سخت‌افزارهای v2 اجرا می‌شوند.