تاریخچه و ریشه‌های توزیع‌های لینوکس

توزیع لینوکس واقعاً چیست

تاریخچه توزیع‌های لینوکس با یک خلأ آغاز می‌شود: هسته لینوکس به‌تنهایی هیچ کاربری مفیدی برای انسان ندارد. هسته بوت می‌شود و سخت‌افزار را شناسایی می‌کند، سپس متوقف می‌شود. کسی باید یک فضای کاربری (userland) به آن اضافه کند، نحوه نصب و به‌روزرسانی نرم‌افزارها را تعیین نماید و متعهد شود که سال‌ها آن را پشتیبانی و اصلاح کند. یک توزیع، مجموعه‌ای از همین انتخاب‌ها به همراه گروهی از افراد است که پس از آن در کنار پروژه باقی می‌مانند.

این توزیع از 5 بخش تشکیل شده است. با تغییر هر یک از این بخش‌ها، شما توزیع متفاوتی خواهید داشت، حتی اگر اکثر فایل‌های باینری مشابه باشند:

• یک هسته (kernel)، با نسخه‌ای که پروژه انتخاب کرده و با وصله‌ها و درایورهایی که به آن افزوده است.
• یک فضای کاربری (userland): کتابخانه C، شل (shell)، سیستم init و دستورات استاندارد.
• یک فرمت بسته (package format) و ابزاری که آن را نصب می‌کند.
• یک سیاست انتشار (release policy): چه چیزی ممکن است تغییر کند، با چه تناوبی، و هر نسخه تا چه زمانی پشتیبانی می‌شود.
• افراد: نگهدارندگان بسته‌ها، تیم امنیتی و کسی که در صورت خرابی یک بسته، پاسخگو باشد.

هسته بخش مشترک است، بنابراین دو توزیع لینوکس بسیار به یکدیگر نزدیک‌ترند تا هر کدام از آن‌ها به یک سیستم‌عامل یونیکس دیگر. این نکته هنگام مقایسه لینوکس و FreeBSD به عنوان پلتفرم‌های سرور حائز اهمیت است؛ جایی که هسته و فضای کاربری پایه توسط یک پروژه ساخته و با هم منتشر می‌شوند. در لینوکس، این قطعات از منابع بالادستی (upstream) جداگانه می‌آیند و توزیع همان چیزی است که باعث می‌شود این قطعات با هم هماهنگ شوند.

تاریخچه توزیع‌های لینوکس در سه خانواده

سه پروژه که در سال‌های 1993 و 1994 آغاز شدند، به خانواده‌های اصلی تبدیل شدند: Slackware، Debian و Red Hat. امروزه تقریباً هر ایمیجی که در پنل کنترل VPS مشاهده می‌کنید، یکی از این موارد یا مشتقات آن‌هاست. هر توزیع مشتق‌شده، فرمت بسته‌ها، ساختار فایل‌ها و معمولاً عادت‌های انتشار نسخه را از والد خود به ارث می‌برد؛ به همین دلیل است که یک توزیع مبتنی بر Debian، حتی پس از حذف نام و نشان تجاری، همچنان حس و حال Debian را دارد.

توزیع‌های مستقل جایگاه ویژه‌ای دارند، زیرا از هیچ توزیع دیگری منشعب نشده‌اند. Arch، Gentoo، Alpine، NixOS و Void هر کدام مدیر بسته و قوانین خاص خود را ایجاد کرده‌اند. دو مورد از آن‌ها، یعنی Arch و Alpine، به دلایلی که هیچ ارتباطی با محیط دسکتاپ نداشت، در نهایت به لیست ایمیج‌های ارائه‌دهنده خدمات شما راه یافتند.

1992: توزیع‌های پیش از خانواده‌ها

نسخه MCC Interim Linux در فوریه 1992 توسط Owen Le Blanc در Manchester Computing Centre گردآوری و عرضه شد. این توزیع، هسته سیستم‌عامل و ابزارهای GNU (مخفف GNU's not Unix) را روی یک جفت دیسکت فلاپی به همراه یک نصب‌کننده منومحور قرار داد. دلیل وجود این توزیع این بود که انجام دستی این مراحل، یک روز کاری زمان می‌برد.

توزیع SLS (مخفف Softlanding Linux System) که در سال 1992 توسط Peter MacDonald منتشر شد، گامی فراتر نهاد و X (سیستم پنجره‌ای X) و شبکه TCP/IP را به آن افزود. SLS دلیلی است که واژه توزیع (distribution) امروزه معنای فعلی خود را دارد. این توزیع همچنین دارای باگ‌های فراوان بود و به‌کندی پشتیبانی می‌شد؛ به همین دلیل در سال 1993، دو نفر به‌طور جداگانه تصمیم گرفتند این مشکلات را برطرف کنند. یکی از آن‌ها سیستم را بازسازی کرد و دیگری کار را با تدوین قوانین مکتوب از نو آغاز نمود.

Slackware، سال 1993: قدیمی‌ترین خانواده‌ای که همچنان عرضه می‌شود

Patrick Volkerding در تاریخ 16 ژوئیه 1993 نسخه 1.00 از Slackware را منتشر کرد که بر پایه SLS و با رفع باگ‌های آن ساخته شده بود. این توزیع همچنان پشتیبانی می‌شود و به همین دلیل، قدیمی‌ترین توزیع لینوکس است که تا به امروز باقی مانده است.

یک پکیج Slackware، یک آرشیو tar فشرده است که یک اسکریپت نصب در داخل خود دارد. در این سیستم، قابلیت حل وابستگی‌ها (dependency resolution) وجود ندارد: هیچ ابزاری بررسی نمی‌کند که آیا کتابخانه‌ای که پکیج جدید شما به آن نیاز دارد، از قبل روی دیسک موجود است یا خیر. همین تصمیم واحد، مسیر تمام بخش‌های دیگر را شکل داد. از آنجا که ابزارها وابستگی‌ها را حل نمی‌کنند، مجموعه نرم‌افزارهای ارائه‌شده باید از همان ابتدا با هم سازگار باشند؛ به همین دلیل، انتشار نسخه‌های جدید بسیار نادر و محافظه‌کارانه است. نسخه 15.0 از Slackware در فوریه 2022، یعنی شش سال پس از نسخه 14.2، عرضه شد.

این خانواده کوچک است. اولین نسخه‌های SUSE در اواسط دهه 1990 بر پایه Slackware ساخته شدند، پیش از آنکه این پروژه با ابزار YaST و بعدها با فرمت پکیج RPM، مسیر مستقل خود را در پیش بگیرد. این بخش آخر باعث سردرگمی کاربران می‌شود. SUSE و openSUSE از پکیج‌های RPM استفاده می‌کنند، اما آن‌ها مشتقاتی از Red Hat نیستند. فرمت پکیج‌ها جابه‌جا شد، اما تبار و ریشه آن‌ها یکی نشد.

دبیان، 1993: یک قرارداد اجتماعی و خط لوله سه مرحله‌ای

Ian Murdock در 16 اوت 1993، سه هفته پس از Slackware و به همان دلیل، دبیان را معرفی کرد. نام این پروژه ترکیبی از نام شریک زندگی او، Debra، و نام خودش است. مانیفست دبیان در ژانویه 1994 منتشر شد و شرایط را تعیین کرد: این توزیع باید به‌صورت متن‌باز و توسط داوطلبان نگهداری شود، نه توسط یک شرکت.

سپس دبیان این شرایط را مکتوب کرد. قرارداد اجتماعی دبیان و DFSG (دستورالعمل‌های نرم‌افزار آزاد دبیان) در ژوئیه 1997 تصویب شدند و DFSG در سال 1998 به پایه و اساس تعریف متن‌باز (Open Source Definition) تبدیل شد. سندی که برای تعیین محتوای یک توزیع نوشته شده بود، در نهایت یک دسته‌بندی مجوز برای کل صنعت تعریف کرد. به همین دلیل است که sources.list شما دارای بخش‌های مختلف است: main نرم‌افزارهایی را در خود جای می‌دهد که با دستورالعمل‌ها مطابقت دارند، contrib و non-free شامل مواردی هستند که این‌گونه نیستند، و دبیان 12 بخش non-free-firmware را اضافه کرد تا لپ‌تاپی با کارت شبکه بی‌سیم بتواند بدون نیاز به جستجوی دستی درایورها، نصب شود.

ابزارها میراث دیگر این پروژه هستند. dpkg یک بسته را نصب می‌کند و اگر چیزی کم باشد، با چاپ dpkg: dependency problems prevent configuration of از انجام آن خودداری می‌کند. APT (ابزار پیشرفته بسته‌ها) که از سال 1999 با دبیان 2.1 به ابزار پیش‌فرض تبدیل شد، لایه‌ای است که مشخص می‌کند چه چیزهای دیگری باید دریافت شوند و با چه ترتیبی. هر دستور apt در تمام مشتقات دبیان، از آن کار نشأت می‌گیرد.

ماشین انتشار دارای سه مجموعه (suite) و یک قانون است. یک نگهدارنده (maintainer)، بسته را در شاخه unstable که نام مستعار دائمی آن sid است، آپلود می‌کند. یک اسکریپت، بسته را پس از حدود 5 تا 10 روز به testing منتقل می‌کند، مشروط بر اینکه بسته روی معماری‌های هدف ساخته شده باشد و هیچ باگ بحرانی جدیدی در آن گزارش نشده باشد. سپس شاخه testing وارد وضعیت freeze می‌شود، تیم انتشار باگ‌های باقی‌مانده را پاکسازی می‌کند و زمانی که لیست باگ‌ها به اندازه کافی کوتاه شد، نسخه stable منتشر می‌شود. این اتفاق بر اساس تاریخ نیست. به همین دلیل است که دبیان stable قدیمی به نظر می‌رسد و عملکرد پایداری دارد: شماره نسخه‌ها در زمان freeze متوقف می‌شوند، در حالی که اصلاحات امنیتی همچنان به این نسخه‌ها backport می‌شوند.

حاکمیت نیز مکتوب است و شامل یک رهبر پروژه منتخب و قطعنامه‌های عمومی الزام‌آور است. در سال 2014، این سازوکار، systemd را به عنوان سیستم init پیش‌فرض انتخاب کرد و افرادی که با این تصمیم مخالف بودند، پروژه Devuan را fork کردند که اولین نسخه خود را در سال 2017 منتشر کرد. از جمله مشتقات بزرگ‌تر دبیان می‌توان به Ubuntu، Raspberry Pi OS، Proxmox VE، Kali و Linux Mint اشاره کرد.

Red Hat، سال 1994: RPM و سپس تقسیم به Fedora و RHEL

Marc Ewing اولین نسخه Red Hat Linux را حوالی هالووین 1994 منتشر کرد. شرکت Bob Young در سال 1995 آن را خریداری کرد و این دو نفر اولین کسب‌وکار لینوکسی را بنا نهادند که به‌جای فروش نرم‌افزار، پشتیبانی می‌فروخت. Red Hat در 11 آگوست 1999 سهامی عام شد. IBM در جولای 2019 خرید این شرکت را با مبلغی حدود 34 میلیارد دلار نهایی کرد؛ بنابراین توزیعی که اکثر نرم‌افزارهای سازمانی برای آن گواهی می‌شوند، از آن زمان تحت مالکیت IBM است.

مهم‌ترین دستاورد فنی این شرکت RPM (مدیریت بسته Red Hat) است که توسط Erik Troan و Marc Ewing برای Red Hat Linux 2.0 در سال 1995 نوشته شد. یک فایل RPM وابستگی‌های خود را اعلام می‌کند و از یک فایل spec تولید می‌شود؛ فایلی که در واقع دستورالعمل ساخت است و هر کسی می‌تواند آن را اجرا کند. همین ویژگی دوم بود که بعدها امکان بازسازی مستقل محصول سازمانی Red Hat را فراهم کرد.

نسخه Red Hat Linux 9 در سال 2003 آخرین نسخه از خط تولید اصلی بود. این شرکت آن را به دو بخش تقسیم کرد: Fedora Core 1 در نوامبر 2003 به‌عنوان نسخه سریع جامعه کاربری، و RHEL (Red Hat Enterprise Linux) که در سال 2002 با نام Advanced Server 2.1 آغاز شده بود، به‌عنوان نسخه کند و پولی. دلیل این کار روشن است. یک محصول نمی‌تواند هم‌زمان هم محلی برای آزمایش نسخه‌های جدید باشد و هم پلتفرمی که یک بانک ده سال بدون تغییر از آن استفاده می‌کند. این دو نیمه به هم متصل هستند: یک نسخه اصلی RHEL از یک انتشار Fedora منشعب می‌شود، به ثبات می‌رسد و سپس در وضعیت ثابت (frozen) قرار می‌گیرد. ابزار مدیریت بسته نیز با همین زمان‌بندی پیش رفت؛ از yum در دهه 2000 به dnf به‌عنوان پیش‌فرض Fedora در سال 2015، در حالی که rpm زیربنای هر دو بود.

چرا CentOS دیگر یک بازسازی رایگان از RHEL نیست

پروژه CentOS در سال 2004 با هدفی ساده آغاز شد: دریافت بسته‌های سورس منتشر شده توسط Red Hat، حذف علائم تجاری، بازسازی آن‌ها و ارائه رایگان نتیجه نهایی. این پروژه برای یک دهه به توزیع پیش‌فرض سرورهای رایگان تبدیل شد و Red Hat در سال 2014 مدیریت این پروژه را به عهده گرفت.

در تاریخ 8 دسامبر 2020، شرکت Red Hat اعلام کرد که عمر CentOS Linux 8 در 31 دسامبر 2021 به پایان می‌رسد؛ یعنی هشت سال زودتر از تاریخی که پیش‌تر اعلام شده بود. همچنین اعلام شد که نام CentOS به عنوان CentOS Stream ادامه خواهد یافت. نسخه Stream یک بازسازی (rebuild) نیست. این نسخه شاخه‌ای است که نسخه‌های فرعی RHEL از آن استخراج می‌شوند؛ بنابراین، این نسخه به جای آنکه از RHEL عقب‌تر باشد، جلوتر از آن حرکت می‌کند. برای ماشینی که قصد دارید سال‌ها از آن استفاده کنید، حرکت به سمت جلو اشتباه است، زیرا تغییرات را پیش از مشتریان پولی Red Hat دریافت می‌کنید.

در سال 2021 دو پروژه بازسازی ظهور کردند. Rocky Linux توسط Gregory Kurtzer، یکی از هم‌بنیان‌گذاران CentOS، راه‌اندازی شد. AlmaLinux توسط CloudLinux تأمین مالی شد. در ژوئن 2023، Red Hat انتشار سورس‌های RHEL را در هر جایی به جز CentOS Stream و پورتال مشتریان خود متوقف کرد. Rocky همچنان بر هدف بازسازی دقیق (identical rebuild) متمرکز ماند. AlmaLinux هدف خود را به سازگاری ABI (رابط باینری برنامه) تغییر داد؛ این یعنی نرم‌افزارهای ساخته‌شده برای RHEL روی آن اجرا می‌شوند، بدون اینکه تضمینی وجود داشته باشد که لیست باگ‌ها دقیقاً مشابه باشد. Oracle، SUSE و CIQ در اواخر همان سال OpenELA را برای انتشار سورس‌های مشترک تأسیس کردند.

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

cat /etc/os-release

NAME="CentOS Stream" یک شاخه توسعه غلتان (rolling) است که پیش از RHEL حرکت می‌کند. NAME="AlmaLinux" یا NAME="Rocky Linux" یک بازسازی هستند که از RHEL پیروی می‌کنند و دارای چرخه عمر ده ساله می‌باشند.

اوبونتو 20.04: تصویری از Debian unstable بر اساس تقویم

اوبونتو 4.10 در تاریخ 20 اکتبر 2004 و با سرمایه‌گذاری Mark Shuttleworth منتشر شد. رابطهٔ آن با Debian بیشتر جنبهٔ فنی دارد تا احساسی. هر چرخهٔ توسعه با وارد کردن بسته‌ها از Debian unstable به نسخهٔ جدید اوبونتو آغاز می‌شود. این واردات تا زمان Debian Import Freeze در میانهٔ چرخه ادامه می‌یابد و پس از آن، اوبونتو تغییرات اختصاصی خود را اعمال می‌کند. بسیاری از بسته‌های اوبونتو، همان بسته‌های Debian به همراه یک تفاوت (delta) هستند که در changelog ذکر می‌شود.

نیمهٔ دیگر این ماجرا، تقویم است. Debian زمانی منتشر می‌شود که آماده باشد، اما اوبونتو در ماه‌های آوریل و اکتبر منتشر می‌شود و شمارهٔ نسخه، همان تاریخ انتشار است: نسخهٔ 24.04 در آوریل 2024 عرضه شد. هر نسخهٔ آوریل که در سال‌های زوج منتشر می‌شود، یک نسخهٔ LTS (پشتیبانی بلندمدت) است؛ این همان چیزی است که ارائه‌دهندگان خدمات هنگام لیست کردن اوبونتو بدون هیچ پسوندی به آن اشاره دارند. انتخاب بین این دو برای سرور، موضوع اصلی انتخاب بین اوبونتو LTS و نسخه‌های میان‌دوره‌ای است و انتقال از یک نسخهٔ LTS به نسخهٔ بعدی، رویهٔ خاص خود را دارد که در ارتقا از 24.04 به 26.04 پوشش داده شده است.

یک نکته هر ساله مدیران سرور را غافلگیر می‌کند. آرشیو اوبونتو به بخش‌های مختلفی تقسیم شده است. main توسط Canonical برای کل دورهٔ پشتیبانی نگهداری می‌شود. universe توسط جامعهٔ کاربری نگهداری می‌شود و تعهد امنیتی آن متفاوت است. apt install هیچ اطلاعاتی دربارهٔ این تفاوت ارائه نمی‌دهد. یک دستور این تفاوت را نشان می‌دهد:

apt-cache policy nginx

خطی از مخزن که به /main ختم می‌شود، به این معناست که تیم امنیتی Canonical مسئولیت آن بسته را بر عهده دارد. خطی که به /universe ختم می‌شود، یعنی جامعهٔ کاربری مسئول آن است. این مورد را برای هر سرویسی که در معرض اینترنت قرار دارد، بررسی کنید.

Arch، 2002: انتشار غلتان و هزینه ارتقای ناقص

Judd Vinet در 11 مارس 2002 نسخه Arch 0.1 را با یک مدیر بسته که خودش نوشته بود، یعنی pacman، و دستورالعمل‌های ساخت که اسکریپت‌های ساده shell هستند، منتشر کرد. Arch هیچ نسخه شماره‌گذاری‌شده‌ای ندارد. رسانه‌های نصب، اسنپ‌شات‌های تاریخ‌دار از همان مخازن غلتان (rolling) هستند؛ بنابراین سیستمی که در سال 2019 نصب شده و هر هفته به‌روزرسانی می‌شود، همان Arch را اجرا می‌کند که سیستم نصب‌شده در امروز اجرا می‌کند. AUR (مخزن کاربران Arch) شامل دستورالعمل‌های ساختی است که توسط کاربران ارائه شده‌اند. این‌ها دستورالعمل هستند، نه بسته‌های بازبینی‌شده؛ بنابراین خواندن PKGBUILD پیش از اجرای آن، بخشی از وظیفه کاربر است.

مدل غلتان یک حالت شکست دارد که همیشه ناشی از خطای کاربر است. نصب یک بسته تکی با pacman -Sy foo، پایگاه داده بسته‌ها را به‌روز می‌کند و سپس یک باینری جدید نصب می‌کند که به کتابخانه‌هایی جدیدتر از آنچه روی دیسک موجود است، لینک شده است. در این حالت، برنامه‌ها به این شکل دچار خطا می‌شوند:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

عملیات پشتیبانی‌شده، pacman -Syu است که همه چیز را با هم به‌روز می‌کند. این پروژه همچنین اطلاعیه‌هایی منتشر می‌کند که در آن‌ها ذکر شده پیش از برخی ارتقاهای خاص، مداخله دستی لازم است؛ اجرای ارتقا بدون خواندن این اطلاعیه‌ها می‌تواند منجر به سیستمی شود که دیگر بوت نمی‌شود.

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

Alpine: توزیعی کوچک که کانتینرها آن را به شهرت رساندند

Alpine حدود سال 2005 به عنوان انشعابی از LEAF (Linux embedded appliance framework) آغاز شد که خود از پروژه Linux Router Project نشأت گرفته بود. Natanael Copa آن را برای تجهیزات سخت‌افزاری (appliances) و نه برای دسکتاپ ساخت. این توزیع اکثر ابزارهای معمول فضای کاربری (userland) را جایگزین کرده است: musl به‌جای کتابخانه GNU C، BusyBox به‌جای ابزارهای اصلی GNU، OpenRC به‌جای systemd و apk به‌عنوان مدیر بسته. نسخه Alpine 3.0 در سال 2014 همان نسخه‌ای بود که به استفاده از musl روی آورد.

کانتینرها باعث محبوبیت آن شدند. لایه پایه Alpine بخش کوچکی از حجم یک پایه Debian یا Ubuntu را دارد؛ بنابراین از سال 2016 به بعد، به یک image پایه رایج تبدیل شد و بسیاری از افرادی که هرگز Alpine را نصب نکرده بودند، هر روز آن را اجرا می‌کردند.

هزینه این کار این است که musl همان glibc نیست و این شکاف به‌صورت باگ‌هایی ظاهر می‌شود که نامرتبط به نظر می‌رسند. یک فایل باینری که با glibc لینک شده باشد، روی Alpine با پیامی شکست می‌خورد که کاربران را به دنبال فایلی می‌فرستد که در واقع وجود دارد:

sh: ./myapp: not found

برنامه وجود دارد. مفسر ELF آن وجود ندارد، زیرا loader مربوط به glibc غایب است. Python دیگر غافلگیری معمول است: چرخ‌های (wheels) پیش‌ساخته برای manylinux روی musl نصب نمی‌شوند، بنابراین pip به کامپایل از سورس روی می‌آورد و زمانی که هیچ کامپایلری نصب نباشد، متوقف می‌شود. استاندارد musllinux wheel که در سال 2021 معرفی شد، این مشکل را برای پروژه‌هایی که آن چرخ‌ها را منتشر می‌کنند حل کرد، اما برای بقیه پروژه‌ها تغییری ایجاد نشد.

به‌عنوان یک سیستم‌عامل میزبان روی یک VPS، Alpine کوچک نصب می‌شود و سریع به‌روزرسانی می‌شود، اما شما را از مسیری که اکثر مستندات فرض می‌کنند، خارج می‌کند. هر راهنمایی که به شما می‌گوید systemctl enable را اجرا کنید، نیاز به ترجمه به rc-update add دارد.

نسل تغییرناپذیر: به‌روزرسانی‌های اتمی و سرورهای مبتنی بر ایمیج

شاخه جدیدتر، مدل به‌روزرسانی را به جای لیست بسته‌ها تغییر می‌دهد. یک سیستم مبتنی بر ostree، بخش /usr را به صورت read-only نگه می‌دارد. به‌روزرسانی شامل یک درخت فایل‌سیستم کامل و جدید است که دانلود و آماده‌سازی شده و در reboot بعدی جایگزین می‌شود. درخت قبلی به عنوان یک ورودی بوت باقی می‌ماند، بنابراین یک به‌روزرسانی ناموفق با reboot کردن به نسخه قدیمی، خنثی می‌شود.

Fedora Silverblue این قابلیت را در سال 2018 به دسکتاپ آورد و Fedora CoreOS پس از خرید CoreOS توسط Red Hat در سال 2018، آن را در سال 2019 به سرورها منتقل کرد. Flatcar Container Linux پس از بازنشستگی Container Linux اصلی در سال 2020، مسیر آن را ادامه داد. openSUSE MicroOS از طریق btrfs snapshots و transactional-update به همین نقطه می‌رسد. در سال 2024، Red Hat یک حالت مبتنی بر ایمیج را به RHEL اضافه کرد که بر پایه bootc ساخته شده است؛ در این حالت، سیستم‌عامل به شکل یک container image عرضه می‌شود و به‌روزرسانی ماشین با اشاره به یک tag جدید انجام می‌گیرد. Talos Linux فراتر رفته و shell و SSH را به‌طور کامل حذف کرده است: ماشین از طریق یک API پیکربندی می‌شود، بنابراین هیچ محیطی برای ورود (login) وجود ندارد. NixOS که اولین بار در سال 2007 منتشر شد، از مسیر متفاوتی به این نقطه می‌رسد. کل سیستم از یک پیکربندی اعلانی (declarative) ساخته می‌شود و نسل‌های قبلی همچنان قابل بوت هستند.

ارائه‌دهنده شما احتمالاً هیچ‌کدام از این موارد را به عنوان یک ایمیج با قابلیت نصب تک‌کلیک ارائه نمی‌دهد، زیرا انتظار دارند سیستم در اولین بوت توسط Ignition یا cloud-init پیکربندی شود، نه توسط مدیر سیستم که فایل‌ها را از طریق SSH ویرایش می‌کند. این سیستم‌ها در مقیاس تعداد زیادی ماشین مشابه بازدهی دارند؛ وضعیتی که وقتی در حال مدیریت چندین سرور لینوکس به‌طور همزمان هستید و نیاز دارید هر کدام از آن‌ها به‌طور اثبات‌پذیری با بقیه یکسان باشد، با آن مواجه خواهید شد.

مدت زمان پشتیبانی از هر نسخه چقدر است؟

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

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine هر شاخه 3.x را به مدت 2 سال پشتیبانی می‌کند؛ به همین دلیل برای ایمیج‌های کانتینری که مرتباً بازسازی می‌کنید، مناسب‌تر از میزبان‌هایی است که آن‌ها را به حال خود رها می‌کنید. تیم امنیتی Debian یک نسخه پایدار (stable) را برای حدود 3 سال پوشش می‌دهد و سپس تیم LTS، معماری‌های رایج را در مجموع تا حدود 5 سال پشتیبانی می‌کند. نسخه Ubuntu LTS به شما 5 سال پشتیبانی برای بسته‌های موجود در main ارائه می‌دهد و اشتراک Ubuntu Pro این مدت را به 10 سال افزایش می‌دهد که برای استفاده شخصی روی تعداد کمی از ماشین‌ها رایگان است. RHEL 10 مدت 10 سال را اعلام کرده است که با افزودنی پولی پشتیبانی از چرخه عمر طولانی (extended life cycle support)، به 13 سال می‌رسد. AlmaLinux 10 با بازه 10 ساله RHEL مطابقت دارد، بدون اینکه نیازی به هیچ‌گونه اشتراکی باشد؛ این دقیقاً همان دلیلی است که توزیع‌های بازسازی‌شده (rebuilds) وجود دارند.

Arch در این لیست جایگاهی ندارد، زیرا یک توزیع غلتان (rolling distribution) نسخه‌ای برای پشتیبانی ندارد. عددی که برای Arch اهمیت دارد، مدت زمانی است که می‌توانید یک ماشین را بدون تغییر رها کنید و این مدت با واحد هفته اندازه‌گیری می‌شود.

چرا لیست ایمیج‌های VPS شما به این شکل است

یک ارائه‌دهنده، ایمیج‌هایی را که مشتریان بر اساس نام درخواست می‌کنند و به‌صورت خودکار روی هایپروایزر نصب می‌شوند، ارائه می‌دهد. به همین دلیل است که تقریباً هر لیستی با Ubuntu LTS و Debian stable شروع می‌شود، AlmaLinux یا Rocky را برای کسانی که نرم‌افزارشان برای RHEL گواهی شده است اضافه می‌کند و Alpine، Arch و Fedora را در رتبه‌های پایین‌تر لیست قرار می‌دهد. هنگامی که بدانید VPS چیست و ایمیج چگونه به دیسک می‌رسد، الگو به‌وضوح قابل درک است: ارائه‌دهنده سیستم‌عامل‌هایی را انتخاب می‌کند که در نصب خودکار بدون مشکل عمل کنند و مدت‌زمانی طولانی‌تر از میانگینِ زمان نگهداری سرور توسط مشتری، پشتیبانی شوند.

این انتخاب شما را به چیزی فراتر از یک مدیر بسته (package manager) متعهد می‌کند. این انتخاب، نوع ارتقایی را که سه سال دیگر انجام خواهید داد تعیین می‌کند و این روش‌ها در خانواده‌های مختلف کاملاً متفاوت هستند. Debian و Ubuntu از ارتقای نسخه اصلی در محل (in-place) پشتیبانی می‌کنند. خانواده Red Hat این کار را از طریق leapp انجام می‌دهند. Arch هیچ ارتقایی ندارد چون اصلاً نسخه (version) ندارد. روش Alpine ویرایش /etc/apk/repositories و اجرای apk upgrade --available است. این انتخاب همچنین تعیین می‌کند که چه نرم‌افزاری را می‌توانید بدون افزودن مخازن شخص ثالث نصب کنید، چه کسی هنگام انتشار یک CVE (آسیب‌پذیری‌ها و مواجهه‌های رایج) برای نرم‌افزار شما وصله ارائه می‌دهد، و سیستم init و کتابخانه C که نرم‌افزارهای آینده شما فرض می‌کنند وجود دارد، کدام است.

یک اثر دیگر نیز وجود دارد که دست‌کم گرفتن آن آسان است. اکثر پاسخ‌های نوشته‌شده در اینترنت فرض را بر مسیر خانواده Debian یا خانواده Red Hat می‌گذارند؛ بنابراین انتخاب خارج از این دو خانواده به معنای ترجمه دستورالعمل‌ها در تمام طول عمر دستگاه است. خانواده‌ای را انتخاب کنید که سیاست انتشار آن با میزان تمایل شما به دسترسی به سرور مطابقت دارد و سپس همان را حفظ کنید. تغییر بسته‌های نرم‌افزاری روی سیستم آسان است، اما تغییر توزیع زیربنایی به معنای بازسازی کامل سرور است.

FAQ

توزیع لینوکس سرور من در کدام خانواده قرار دارد؟

دستور cat /etc/os-release را اجرا کنید. فیلد ID نام توزیع و ID_LIKE نام خانواده آن را مشخص می‌کند؛ بنابراین یک ماشین Ubuntu مقدار ID_LIKE=debian و یک ماشین AlmaLinux مقدار ID_LIKE="rhel centos fedora" را گزارش می‌دهند. مدیر بسته (package manager) نیز نشانه دیگری است. apt و dpkg به خانواده Debian، dnf و rpm به خانواده Red Hat، apk به Alpine و pacman به Arch اشاره دارند.

آیا CentOS هنوز نسخه رایگان RHEL است؟

خیر. CentOS Linux 8، آخرین نسخه بازسازی‌شده با این نام، در تاریخ 31 دسامبر 2021 به پایان رسید و عمر CentOS Linux 7 نیز در 30 ژوئن 2024 به پایان رسید. پروژه باقی‌مانده، یعنی CentOS Stream، شاخه‌ای است که نسخه‌های فرعی RHEL از آن ساخته می‌شوند؛ بنابراین تغییرات را پیش از RHEL دریافت می‌کند، نه پس از آن. جایگزین‌های رایگانی که نقش قدیمی آن را بر عهده گرفته‌اند، AlmaLinux و Rocky Linux هستند که هر دو دارای پشتیبانی ده ساله می‌باشند.

چرا نسخه پایدار Debian از شماره نسخه‌های قدیمی استفاده می‌کند؟

زیرا شماره نسخه ثابت می‌ماند در حالی که اصلاحات همچنان ارائه می‌شوند. Debian وصله‌های امنیتی را به نسخه‌ای که منتشر کرده است backport می‌کند، به جای اینکه نسخه جدیدتر upstream را وارد کند؛ بنابراین بسته‌ای که نسخه 2.4.57-2+deb13u1 را نشان می‌دهد، ممکن است شامل اصلاحی باشد که هفته گذشته منتشر شده است. پسوند بعد از نسخه upstream، بازبینی (revision) خودِ Debian است و apt changelog <package> جزئیات تغییرات اعمال شده در آن را فهرست می‌کند. قضاوت درباره امنیت یک سرور Debian بر اساس شماره نسخه‌ها، همیشه نتیجه اشتباه به دست می‌دهد.

آیا باید توزیع‌های rolling release مانند Arch را روی VPS اجرا کنم؟

فقط در صورتی که قصد دارید طبق برنامه به‌روزرسانی کنید. یک توزیع rolling فرض می‌کند که هر ماشین به مجموعه بسته‌های فعلی همگرا می‌شود؛ بنابراین به‌روزرسانی تنها یک بسته با pacman -Sy foo منجر به عدم تطابق کتابخانه‌ها و خطاهایی مانند cannot open shared object file می‌شود. دستور pacman -Syu را به‌طور منظم اجرا کنید، پیش از هر بار اجرا صفحه اخبار پروژه را بخوانید تا سیستم پایدار بماند. اگر آن را برای یک سال رها کنید، اولین ارتقا به عملیاتی پرخطر تبدیل خواهد شد.

توزیع‌های immutable یا atomic دقیقاً چه چیزی را تغییر می‌دهند؟

این توزیع‌ها زمان اعمال به‌روزرسانی‌ها و نحوه بازگشت (undo) آن‌ها را تغییر می‌دهند. مسیر /usr به‌صورت read-only مونت می‌شود، به‌روزرسانی به‌عنوان یک درخت کامل جدید آماده‌سازی شده و تغییر در زمان reboot اعمال می‌شود؛ در حالی که درخت قبلی به‌عنوان یک ورودی بوت برای بازگشت (rollback) حفظ می‌گردد. شما ماشینی خواهید داشت که یا کاملاً به‌روز است یا اصلاً به‌روز نیست و حالتی بینابین وجود ندارد. در این مدل، امکان نصب نرم‌افزار از طریق ویرایش مستقیم فایل‌ها را از دست می‌دهید، بنابراین برنامه‌ها به داخل کانتینرها یا بسته‌های لایه‌بندی‌شده منتقل می‌شوند.