توزیع لینوکس چیست؟ Ubuntu، Debian، Fedora، RHEL و Alpine

هستهٔ لینوکس به‌تنهایی سیستم‌عامل آمادهٔ تولید نیست. توزیع (Linux distribution) همان بسته‌ای است که هسته، فضای کاربری، نصب‌کننده، مخازن نرم‌افزار، سیاست امنیتی و چرخهٔ پشتیبانی را به یک محصول قابل‌نصب تبدیل می‌کند. وقتی می‌گویید «اوبونتو ۲۲٫۰۴» یا «دبیان ۱۲»، در واقع یک قرارداد کامل دربارهٔ نسخهٔ بسته، نام سرویس‌ها و نحوهٔ به‌روزرسانی را انتخاب کرده‌اید — نه فقط یک والپیپر.

اشتباه رایج تازه‌واردها این است که همهٔ توزیع‌ها را «تقریباً یکی» بدانند. فرمان‌های پایه شبیه هم است، اما مسیر فایل تنظیمات، نام بسته، طول پشتیبانی، و رفتار پیش‌فرض فایروال یا SELinux/AppArmor می‌تواند شب عیب‌یابی را کاملاً عوض کند. این مقاله نقشهٔ خانواده‌ها، معیار انتخاب، و تله‌های مهاجرت را می‌دهد.

اگر هنوز مدل هسته در برابر سیستم‌عامل را نخوانده‌اید، مقالهٔ ۱۴۲ را اول ببینید؛ اینجا فرض می‌کنیم می‌دانید توزیع روی هسته سوار است.

پاسخ کوتاه

توزیع لینوکس ترکیب پشتیبانی‌شدهٔ هسته + ابزارها + مخازن + سیاست انتشار است. برای بیشتر سرورهای وب و یادگیری Ops، Ubuntu LTS یا Debian پایدار انتخاب‌های کم‌ریسک‌اند. Fedora تازگی بسته می‌خواهد؛ RHEL (و کلون‌های سازگار) پایداری و پشتیبانی تجاری سازمانی؛ Alpine تصویر کانتینر مینیمال با musl. «بهترین توزیع» بدون معیار بار کاری، شعار است.

توزیع را مثل قرارداد تیم انتخاب کنید: هزینهٔ یادگیری، طول پشتیبانی، و سازگاری با Imageهایتان مهم‌تر از علاقهٔ شخصی به دسکتاپ است.

توزیع دقیقاً چه چیزی تحویل می‌دهد؟

• هستهٔ بسته‌بندی‌شده با درایورها و تنظیمات پیش‌فرض معقول.
• مدیر بسته (apt، dnf، apk، pacman، zypper) و مخازن امضاشده.
• نصب‌کننده یا Image ابری/کانتینری آماده.
• سیاست به‌روزرسانی: پایدار، غلتان (rolling)، یا ترکیبی.
• لایهٔ امنیتی پیش‌فرض: AppArmor، SELinux، یا مینیمال.
• مستندات و جامعه یا پشتیبانی تجاری.

دو سرور با «لینوکس» می‌توانند یکی با apt و فایل‌های /etc/nginx و دیگری با dnf و واحدهای متفاوت systemd باشند. اتوماسیون باید توزیع را صریح اعلام کند.

خانواده‌های اصلی

خانوادهٔ Debian: Debian و Ubuntu

Debian روی پایداری و نرم‌افزار آزاد سخت‌گیر است؛ انتشارهای پایدار برای سرور کلاسیک محبوب‌اند. Ubuntu بر پایهٔ Debian ساخته شده، چرخهٔ انتشار منظم و نسخه‌های LTS با پشتیبانی طولانی دارد و در ابر و مستندات آموزشی بسیار دیده می‌شود. برای بسیاری تیم‌های کوچک، Ubuntu Server LTS پیش‌فرض عملی است چون Image ابری، آموزش، و بستهٔ رایج فراوان است.

تفاوت عملی: نام برخی بسته‌ها، نسخهٔ پیش‌فرض زبان‌ها، و افزوده‌های Ubuntu (مثل snap در برخی editionها) با Debian خالص یکی نیست. اگر اسکریپت نصب «برای اوبونتو» نوشته شده، روی دبیان بدون آزمایش کپی نکنید.

خانوادهٔ Red Hat: Fedora، RHEL، CentOS Stream

Fedora لبهٔ تازگی را برای اکوسیستم Red Hat نگه می‌دارد؛ چرخهٔ عمر نسبتاً کوتاه‌تر و بستهٔ جدیدتر. RHEL محصول تجاری با پشتیبانی طولانی، گواهی، و کانال‌های پایدار است. CentOS Stream نزدیک به جریان توسعهٔ RHEL قرار دارد و جایگزین «CentOS کلاسیک کلون پایدار» قدیمی نیست — انتظار رفتار کلون بیت‌به‌بیت را نداشته باشید مگر مستند همان محصول را خوانده باشید.

مدیر بستهٔ رایج این خانواده dnf است؛ سیاست SELinux معمولاً پررنگ‌تر از Ubuntu پیش‌فرض است. برای سازمان‌هایی که قرارداد پشتیبانی می‌خواهند، RHEL (یا جایگزین‌های سازگار مستند) معیار است نه سلیقهٔ دسکتاپ.

Alpine و تصاویر مینیمال

Alpine با musl و BusyBox، Imageهای کوچک کانتینر می‌سازد. عالی برای کاهش سطح حمله و حجم لایه — با هزینهٔ سازگاری: بعضی باینری‌های glibc روی musl مستقیم اجرا نمی‌شوند. اگر فقط «کوچک‌تر بهتر است» بگویید بدون تست، در CI با خطاهای عجیب روبه‌رو می‌شوید.

Arch و غلتان‌ها

Arch و مشتقات rolling برای دسکتاپ و یادگیری عمیق محبوب‌اند؛ مدل «همیشه تازه» برای سرور Production بدون انضباط سخت، ریسک تغییر ناگهانی دارد. Arch Wiki از بهترین منابع مفهومی لینوکس است حتی اگر سرورتان Debian باشد.

جدول مقایسهٔ عملی

معیار انتخاب برای سرور وب/API

1. طول پشتیبانی امنیتی را با افق پروژه هم‌تراز کنید (LTS در برابر انتشار کوتاه).
2. ببینید Image رسمی زبان/فریم‌ورکتان روی کدام پایه است (node، python، postgres).
3. مهارت تیم را بشمارید: یک توزیع آشنا بهتر از «بهینهٔ تئوری» ناشناخته است.
4. نیاز به پشتیبانی تجاری یا انطباق (compliance) را صریح کنید.
5. اندازه و سطح حملهٔ Image کانتینر را جدا از OS میزبان ارزیابی کنید.

برای VPS تازه‌کار که می‌خواهد Nginx و یک اپ Python/Node بالا بیاورد، Ubuntu LTS یا Debian Stable معمولاً اصطکاک کمتری دارد. برای کلاستر سازمانی با قرارداد، مسیر RHEL‌مانند را با چشم‌باز بررسی کنید.

چرخهٔ انتشار، LTS و به‌روزرسانی

LTS یعنی پنجرهٔ پشتیبانی طولانی‌تر برای وصلهٔ امنیتی — نه اینکه هرگز چیزی عوض نشود. بین انتشارهای بزرگ باید برنامهٔ ارتقا داشته باشید. به‌روزرسانی بی‌برنامه روی Production بدون staging، یکی از رایج‌ترین علت‌های downtime خودساخته است.

unattended-upgrades یا معادل dnf-automatic را بشناسید: وصلهٔ خودکار امنیتی مفید است، اما ریبوت هسته و شکست سرویس را باید مانیتور کنید. «توزیع پایدار» جایگزین بکاپ و پنجرهٔ نگهداری نیست.

مهاجرت بین توزیع‌ها

جابه‌جایی Debian→Ubuntu گاهی ساده‌تر از Debian→RHEL است چون خانوادهٔ بسته فرق دارد. هرگز «آپگرید درجا» بین خانواده‌های ناسازگار را با عوض کردن فقط repository امتحان نکنید. مسیر امن: سرور جدید، استقرار مجدد با IaC، قطع ترافیک کنترل‌شده، سپس خاموشی قدیم.

کانتینر این درد را کم می‌کند ولی حذف نمی‌کند: میزبان و ابزارهای بوت/دیسک/شبکه هنوز توزیع‌محورند.

توزیع برای دسکتاپ در برابر سرور

دسکتاپ به درایور GPU، محیط گرافیکی و تجربهٔ لپ‌تاپ حساس است؛ سرور به SSH، پایداری سرویس و حداقل سطح حمله. می‌توانید روی دسکتاپ Fedora و روی سرور Debian باشید — اشکالی ندارد اگر مفاهیم مشترک (فایل‌سیستم، مجوز، systemd) را جدا یاد بگیرید. یکی‌کردن اجباری دسکتاپ و سرور فقط وقتی ارزشمند است که تیم کوچک و هزینهٔ زمینه مهم باشد.

اشتباه‌های رایج

• انتخاب توزیع فقط بر اساس زیبایی صفحهٔ نصب.
• اجرای دستورات yum روی سیستم apt بدون فکر (و برعکس).
• فرض اینکه CentOS Stream همان CentOS 7 قدیمی است.
• ساخت Image Alpine بدون تست وابستگی‌های native.
• نادیده گرفتن تاریخ پایان پشتیبانی LTS.
• مخلوط کردن مخازن شخص ثالث بدون امضا و پین نسخه.

مثال تصمیم‌گیری کوتاه

تیم چهار نفره، یک VPS برای API و Postgres، بودجهٔ پشتیبانی تجاری صفر، تجربهٔ قبلی با apt: Ubuntu 24.04 LTS یا Debian 12. استارتاپ با نیاز SOC2 و پشتیبانی فروشنده: ارزیابی RHEL یا Ubuntu Pro. میکروسرویس با صدها Image کوچک: Alpine یا distroless برای اپ، با میزبان پایدار جدا. این‌ها الگو هستند نه حکم؛ معیارهای بالا را روی کاغذ بنویسید.

سوالات متداول

برای یادگیری از کدام شروع کنم؟

Ubuntu Server LTS یا Debian Stable روی یک VM. بعد از راحتی با apt و systemd، یک دور Fedora یا Alpine امتحان کنید تا تفاوت خانواده را حس کنید.

آیا باید همهٔ مشتقات را یاد بگیرم؟

خیر. یک خانواده را عمیق کنید؛ مفاهیم را منتقل کنید؛ man و مستند همان توزیع را منبع حقیقت بدانید.

Mint، Pop!_OS و دیگران چطور؟

بسیاری مشتق Ubuntu/Debian برای دسکتاپ‌اند. برای سرور Production معمولاً به بالادست (Ubuntu/Debian رسمی) نزدیک بمانید مگر دلیل محصولی داشته باشید.

آیا توزیع روی عملکرد اپ من معجزه می‌کند؟

اختلاف روزمره بیشتر از تنظیمات اپ، نسخهٔ کتابخانه و منابع VM می‌آید تا «نام توزیع». اول گلوگاه را بسنجید.

rolling برای سرور خوب است؟

فقط با انضباط تست، پین، و پنجرهٔ نگهداری. برای بیشتر تیم‌های کوچک، LTS کم‌استرس‌تر است.

مدیر بسته و تفاوت روزمرهٔ فرمان‌ها

روی خانوادهٔ Debian با apt و dpkg کار می‌کنید؛ روی Fedora/RHEL با dnf و rpm؛ روی Alpine با apk. مفهوم یکی است — نصب، حذف، جستجو، قفل نسخه — اما نام بسته و مسیر تنظیمات فرق دارد. جدول ذهنی کوچک بسازید: قبل از کپی از Stack Overflow، توزیع و نسخه را در سوال و در سرور یکی کنید.

bash

# Debian/Ubuntu sudo apt update && sudo apt install nginx # Fedora sudo dnf install nginx # Alpine sudo apk add nginx

همین سه خط نشان می‌دهد چرا «یک اسکریپت برای همهٔ لینوکس‌ها» بدون تشخیص توزیع شکننده است. در اتوماسیون، fact توزیع (مثلاً ansible_os_family) را جدی بگیرید.

امنیت پیش‌فرض: AppArmor در برابر SELinux

بسیاری از سیستم‌های Ubuntu/Debian با AppArmor می‌آیند؛ خانوادهٔ RHEL معمولاً SELinux را پررنگ‌تر پیش‌فرض می‌کند. هر دو مدل MAC هستند ولی ابزار عیب‌یابی و زبان سیاست فرق دارد. اگر سرویس بعد از نصب «Permission denied» عجیب می‌دهد، قبل از chmod ۷۷۷، وضعیت MAC را چک کنید. خاموش کردن SELinux برای «راه‌افتادن سریع» بدهی امنیتی می‌سازد که در audit بعدی دردسر است.

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

تصاویر ابری و cloud-init

در AWS، Azure، GCP و بیشتر VPSها، Image رسمی Ubuntu، Debian، RHEL یا Alma/Rocky از قبل با cloud-init آماده‌اند. انتخاب Image یعنی انتخاب همان قرارداد توزیع. اگر تیم شما Playbook اوبونتو دارد و Image فدورا می‌گیرید، نصف زمان را صرف ترجمهٔ مسیرها می‌کنید. Image را در Terraform/آزادِ ساخت سرور قفل کنید و ارتقا را آگاهانه انجام دهید.

برای کانتینر، پایهٔ Image (Dockerfile FROM) را از میزبان جدا فکر کنید: می‌توانید میزبان Ubuntu و کانتینر Alpine داشته باشید؛ فقط وابستگی‌های build و مسیر لاگ را مستند کنید.

چه زمانی توزیع را عوض نکنید؟

اگر Production پایدار است، مانیتورینگ و بکاپ دارید، و فقط «شنیده‌اید فلان توزیع سریع‌تر است»، مهاجرت را عقب بیندازید. تعویض توزیع هزینهٔ پنهان دارد: بازنویسی اتوماسیون، آموزش، و کشف تفاوت‌های ظریف سرویس. وقتی ارزش دارد که پشتیبانی تمام شده، نیاز compliance دارید، یا خانوادهٔ بسته با استاندارد سازمان یکی نیست.

ارتقای نسخهٔ بزرگ داخل همان خانواده (مثلاً Ubuntu 22.04→24.04) معمولاً کم‌ریسک‌تر از پرش بین خانواده‌هاست — باز هم با staging و چک‌لیست سرویس.

چک‌لیست یک‌صفحه‌ای قبل از انتخاب

• افق پشتیبانی امنیتی ≥ عمر برنامه‌ریزی‌شدهٔ سرور + یک سال حاشیه.
• حداقل دو نفر در تیم با همان مدیر بسته راحت‌اند.
• Image رسمی اپ/دیتابیس روی همان پایه تست شده است.
• سیاست MAC (AppArmor/SELinux) صاحب دارد، نه «بعداً».
• مسیر ارتقا و تاریخ EOL در تقویم تیم ثبت شده است.
• مخازن شخص ثالث حداقل و امضاشده‌اند.

خلاصه

توزیع لینوکس قرارداد کامل بسته‌بندی و پشتیبانی است. خانوادهٔ Debian/Ubuntu برای بسیاری سرورهای عمومی نقطهٔ شروع امن است؛ Fedora/RHEL مسیر سازمانی و تازگی/پایداری تجاری؛ Alpine مسیر کانتینر مینیمال با مبادلهٔ سازگاری. با معیار طول پشتیبانی، مهارت تیم و سازگاری Image انتخاب کنید — نه با هیجان انجمن.

قدم بعد: ترمینال را جدی بگیرید (۱۴۴) و ساختار فایل‌سیستم همان توزیعی که نصب کردید را روی ۱۴۶ مرور کنید.

پکیج‌منیجر و نام‌های متفاوت بسته

حتی وقتی مفهوم یکی است، نام بسته فرق می‌کند: apache2 در برابر httpd، یا python3-venv در برابر نام‌های دیگر. اتوماسیون چندتوزیعی باید یا ماتریس بسته داشته باشد یا فقط یک Distro را پشتیبانی کند. کپی کور دستور از اینترنت بدون نگاه به خانواده، شایع‌ترین علت شکست نصب است.

bash

# Debian/Ubuntu # sudo apt install nginx # Fedora # sudo dnf install nginx # Alpine # sudo apk add nginx

بعد از نصب، مسیر کانفیگ را از مستند همان Distro بخوانید؛ فرض /etc/nginx/sites-enabled فقط روی بعضی خانواده‌ها درست است.

EOL و تقویم ارتقا

پایان پشتیبانی رسمی یعنی دیگر وصلهٔ امنیتی به‌موقع از همان کانال نمی‌آید. ادامه دادن از روی عادت، ریسک شناخته‌شده است. در تقویم تیم، تاریخ EOL هر Image پایه را کنار تاریخ تمدید دامنه بگذارید تا فراموش نشود.

ارتقای عمده را در Staging با همان دادهٔ شبیه Production بیازمایید. پرش دو نسخهٔ بزرگ بدون یادداشت مهاجرت، برای دیتابیس و کانفیگ دردناک است.

توزیع مینیمال برای کانتینر

Alpine و نسخه‌های slim دبیان/اوبونتو سطح حمله و حجم را کم می‌کنند، ولی musl یا کمبود بعضی بسته‌ها ممکن است باینری‌های glibc را بشکند. معیار انتخاب Image: سازگاری وابستگی، تعداد CVE قابل‌پیگیری، و راحتی بازتولید برای تیم — نه فقط مگابایت.

اگر روی میزبان Ubuntu هستید و Image هم Debian-based بماند، دانش عملیاتی‌تان قابل‌انتقال‌تر است تا اینکه هر سرویس Distroی جدا داشته باشد.

تصمیم پیشنهادی برای خوانندهٔ این سری

برای دنبال کردن مقالات لینوکس FutureForge سری ۳ روی یک VPS: Ubuntu LTS یا Debian Stable. همان را در CI برای smoke test نگه دارید. وقتی نیاز سازمانی به RHEL آمد، با آگاهی مهاجرت کنید نه با هیجان انجمن.

منابع و مراجع

• Debian Documentation — https://www.debian.org/doc/
• Ubuntu Server documentation — https://documentation.ubuntu.com/server/
• Fedora Documentation — https://docs.fedoraproject.org/en-US/docs/
• Red Hat Enterprise Linux Documentation — https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/
• Alpine Linux — Documentation — https://docs.alpinelinux.org/
• Filesystem Hierarchy Standard (context for all distros) — https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html