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

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

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

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

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

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

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

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

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

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

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

سیستم SLS (مخفف Softlanding Linux System) که توسط Peter MacDonald در سال 1992 منتشر شد، فراتر رفت و 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 نیستند. فرمت بسته‌ها مهاجرت کرد، اما تبار و ریشه آن‌ها خیر.

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

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

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

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

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

ساختار حاکمیتی نیز مکتوب است و شامل یک رهبر پروژه منتخب و قطعنامه‌های عمومی الزام‌آور می‌باشد. در سال 2014، این ساختار systemd را به عنوان سیستم init پیش‌فرض انتخاب کرد و کسانی که با این تصمیم مخالف بودند، توزیع Devuan را انشعاب (fork) دادند که اولین نسخه خود را در سال 2017 منتشر کرد. Debian نه اولین توزیعی بود که این تغییر را انجام داد و نه آخرین آن‌ها؛ دلایل تکرار این اتفاق و اعتراضاتی که در نهایت درست از آب درآمدند، در گزارش جایگزینی SysV init توسط systemd بررسی شده است. از جمله بزرگ‌ترین نوادگان این توزیع می‌توان به 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 package manager) است که توسط 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) که کار خود را به‌عنوان Advanced Server 2.1 در سال 2002 آغاز کرده بود، به‌عنوان نسخه کند و پولی. دلیل این کار روشن است. یک محصول نمی‌تواند هم‌زمان هم محلی برای آزمایش نسخه‌های جدید باشد و هم پلتفرمی که یک بانک ده سال بدون تغییر از آن استفاده می‌کند. این دو بخش به هم متصل هستند: یک نسخه اصلی RHEL از یک نسخه Fedora منشعب می‌شود، به ثبات می‌رسد و سپس تثبیت (freeze) می‌شود. ابزار مدیریت بسته نیز بر اساس همین زمان‌بندی تغییر کرد؛ از yum در دهه 2000 به dnf به‌عنوان پیش‌فرض Fedora در سال 2015، در حالی که rpm در زیرساخت هر دو قرار داشت.

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

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

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

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

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

cat /etc/os-release

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

اوبونتو 2004: تصویری از 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 ختم می‌شود، به این معناست که جامعهٔ کاربری مسئول آن است. این مورد را برای هر سرویسی که در معرض اینترنت قرار دارد، بررسی کنید.

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

Judd Vinet در 11 مارس 2002 نسخه 0.1 از Arch را منتشر کرد. او این کار را با یک مدیر بسته که خودش نوشته بود، یعنی pacman، و دستورالعمل‌های ساخت که اسکریپت‌های ساده shell بودند، انجام داد. Arch هیچ نسخهٔ شماره‌گذاری‌شده‌ای ندارد. رسانه‌های نصب، اسنپ‌شات‌های تاریخ‌دار از همان مخازن غلتان (rolling) هستند؛ بنابراین سیستمی که در سال 2019 نصب شده و هر هفته به‌روزرسانی می‌شود، همان Arch را اجرا می‌کند که سیستم نصب‌شده در امروز اجرا می‌کند. مخزن AUR (مخزن کاربران آرچ) شامل دستورالعمل‌های ساختی است که توسط کاربران ارائه شده‌اند. این‌ها دستورالعمل هستند، نه بسته‌های بازبینی‌شده؛ بنابراین خواندن فایل 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 به بعد، این توزیع به یک ایمیج پایه رایج تبدیل شد و بسیاری از افرادی که هرگز Alpine را نصب نکرده بودند، هر روز از آن استفاده می‌کردند.

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

sh: ./myapp: not found

برنامه وجود دارد، اما مفسر ELF آن موجود نیست، زیرا لودر glibc در سیستم نیست. پایتون نیز یکی دیگر از غافلگیری‌های همیشگی است: ویل‌های (wheels) پیش‌ساخته‌ای که برای manylinux آماده شده‌اند، روی musl نصب نمی‌شوند؛ بنابراین pip به کامپایل از سورس روی می‌آورد و در صورتی که هیچ کامپایلری نصب نباشد، متوقف می‌شود. استاندارد ویل musllinux که در سال 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 از طریق snapshotهای btrfs و 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 یک نسخه پایدار را حدود 3 سال پوشش می‌دهد و سپس تیم LTS معماری‌های رایج را در مجموع تا حدود 5 سال پشتیبانی می‌کند. Ubuntu LTS برای بسته‌های موجود در main به شما 5 سال زمان می‌دهد و اشتراک 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 شروع می‌شود، برای کسانی که نرم‌افزارشان با RHEL گواهی شده است AlmaLinux یا Rocky را اضافه می‌کند و 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 stable از شماره نسخه‌های قدیمی استفاده می‌کند؟

زیرا شماره نسخه ثابت می‌ماند در حالی که اصلاحات همچنان اعمال می‌شوند. 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 انجام می‌شود؛ در حالی که درخت قبلی به‌عنوان یک boot entry برای بازگشت (rollback) حفظ می‌گردد. شما ماشینی خواهید داشت که یا کاملاً به‌روز است یا اصلاً به‌روز نیست و حالتی بینابین وجود ندارد. در این مدل، شما امکان نصب نرم‌افزار از طریق ویرایش مستقیم فایل‌ها را از دست می‌دهید، بنابراین برنامه‌ها به داخل کانتینرها یا بسته‌های لایه‌بندی‌شده منتقل می‌شوند.