تاريخ توزيعات Linux: من Slackware وDebian وRed Hat

ما هي توزيعة Linux فعلياً

يبدأ تاريخ توزيعات Linux بفجوة: نواة Linux وحدها لا تنفّذ أي شيء يمكن للإنسان استخدامه. تقلع وتتعرف على العتاد. ثم تتوقف. يجب أن يضيف أحدهم userland، ويحدد طريقة تثبيت البرامج وتحديثها، ويتعهد بمواصلة إصلاحها لسنوات. التوزيعة هي مجموعة هذه الخيارات، إضافةً إلى مجموعة الأشخاص الذين يواصلون العمل عليها بعد ذلك.

تتكون التوزيعة من خمسة أجزاء. إذا غيّرت أي جزء منها، تحصل على توزيعة مختلفة، حتى عندما تتطابق معظم الملفات التنفيذية:

• نواة بالإصدار الذي اختاره المشروع، مع التصحيحات وبرامج التشغيل التي أضافها.
• userland: مكتبة C، وshell، ونظام init، والأوامر القياسية.
• تنسيق للحزم، والأداة التي تثبّتها.
• سياسة للإصدارات: ما الذي يمكن تغييره، وعدد مرات التغيير، والمدة التي يستمر فيها إصلاح كل إصدار.
• الأشخاص: مشرفو الحزم، وفريق الأمان، وشخص يجيب عند تعطل إحدى الحزم.

النواة هي الجزء المشترك، لذلك تكون توزيعتا Linux أقرب بكثير إلى بعضهما من قرب أي منهما إلى Unix آخر. يجدر تذكّر ذلك عند مقارنة Linux وFreeBSD كمنصتين للخوادم، حيث يبني مشروع واحد النواة وuserland الأساسي ويصدرهما معاً. أما في Linux، فتأتي هذه الأجزاء من مشاريع upstream منفصلة، والتوزيعة هي التي تجعلها متوافقة.

تاريخ توزيعات Linux ضمن ثلاث عائلات

بدأت ثلاثة مشاريع في عامي 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)، الذي أصدره Peter MacDonald في 1992، إلى أبعد من ذلك وأضاف X ‏(نظام X Window) وشبكات TCP/IP. كان SLS السبب في أن كلمة distribution تحمل معناها الحالي. لكنه كان كثير الأخطاء وبطيئاً في الصيانة، وفي 1993 قرر شخصان، كلٌّ على حدة، إصلاح ذلك. أعاد أحدهما بناءه. وبدأ الآخر من جديد وفق قواعد مكتوبة.

Slackware، 1993: أقدم عائلة لا تزال تصدر إصدارات

أصدر Patrick Volkerding الإصدار Slackware 1.00 في 16 July 1993، وقد بُني من SLS بعد إزالة الأخطاء منه. ولا يزال المشروع يحظى بالصيانة، ولذلك يُعد أقدم توزيعة Linux ما زالت قائمة.

حزمة Slackware هي أرشيف tar مضغوط يحتوي على نص تثبيت بداخله. ولا توجد آلية لحل التبعيات؛ إذ لا يتحقق النظام من وجود المكتبة التي تحتاج إليها حزمتك الجديدة على القرص. شكّل هذا القرار الواحد كل ما جاء بعده. فإذا كانت الأداة لا تحل التبعيات، فيجب أن تكون مجموعة الحزم المصدرة متوافقة بطبيعتها، ولذلك تبقى الإصدارات نادرة ومحافظة. صدر Slackware 15.0 في February 2022، بعد ست سنوات من 14.2.

العائلة صغيرة. بُنيت الإصدارات الأولى من SUSE في منتصف عقد 1990 على Slackware، قبل أن يسلك المشروع مساره الخاص باستخدام YaST ثم، لاحقاً، تنسيق الحزم RPM. وهذه النقطة الأخيرة تربك بعض الناس. تستخدم SUSE وopenSUSE حزم RPM، وهما ليستا توزيعتين مشتقتين من Red Hat. انتقل التنسيق، لكن سلالة التطوير لم تنتقل.

دبيان، 1993: عقد اجتماعي ومسار من ثلاث مجموعات إصدارات

أعلن Ian Murdock عن Debian في 16 أغسطس 1993، بعد ثلاثة أسابيع من Slackware وللسبب نفسه. يجمع الاسم بين اسم شريكته Debra واسمه. صدر بيان Debian في يناير 1994، وحدد الشروط: ستتولى إدارة هذا التوزيع مجموعة من المتطوعين بشفافية، وليس شركة.

ثم وثّقت Debian هذه الشروط. اعتُمد العقد الاجتماعي لـDebian وإرشادات Debian للبرمجيات الحرة (DFSG) في يوليو 1997، وأصبحت DFSG أساس تعريف المصدر المفتوح في 1998. كانت الوثيقة تهدف إلى تحديد ما يندرج ضمن توزيع واحد، لكنها انتهت إلى تعريف فئة تراخيص لصناعة البرمجيات بأكملها. وهذا يفسر أيضاً سبب احتواء sources.list على مكونات: يضم main البرامج التي تستوفي الإرشادات، بينما يضم contrib وnon-free ما لا يستوفيها، وأضاف Debian 12 المكوّن non-free-firmware حتى يتمكن حاسوب محمول مزود ببطاقة لاسلكية من التثبيت دون البحث يدوياً عن الحزم والبرامج المطلوبة.

أما الإرث الآخر فهو أدوات إدارة الحزم. يثبّت dpkg حزمة واحدة، ويرفض المتابعة عند غياب تبعية، ويطبع dpkg: dependency problems prevent configuration of. أما APT (أداة الحزم المتقدمة)، التي أصبحت الافتراضية مع Debian 2.1 في 1999، فهي الطبقة التي تحدد ما يجب جلبه أيضاً وبأي ترتيب. وكل أمر apt في كل توزيعة مشتقة من Debian يعود إلى هذا العمل.

تتكون آلية الإصدارات من ثلاث مجموعات إصدارات وقاعدة واحدة. يرفع المشرف الحزمة إلى unstable، التي تحمل الاسم الرمزي الدائم sid. وتنقل حزمة نصية الحزمة إلى testing بعد نحو 5 إلى 10 أيام، إذا بُنيت على معماريات الإصدار ولم تسجل أي علة جديدة حرجة للإصدار. ثم تتجمد testing، ويعالج فريق الإصدار ما تبقى، ويصدر stable عندما تصبح قائمة العلل قصيرة بما يكفي. لا يرتبط ذلك بتاريخ محدد. ولهذا يبدو Debian stable قديماً ويعمل باستقرار: تتوقف أرقام الإصدارات عند بدء التجميد، بينما تستمر إصلاحات الأمان في نقلها إلى هذه الإصدارات.

كما أن الحوكمة موثقة، مع قائد مشروع منتخب وقرارات عامة ملزمة. في 2014 اختارت هذه الآلية systemd كنظام init الافتراضي، وتفرّع الأشخاص الذين عارضوا ذلك إلى Devuan، الذي أصدر نسخته الأولى في 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، وبنى الاثنان أول نشاط تجاري في Linux يبيع الدعم بدلاً من البرامج. أُدرجت Red Hat في البورصة في 11 August 1999. أتمّت IBM الاستحواذ على الشركة في July 2019 مقابل نحو 34 billion dollars، ولذلك أصبح التوزيع الذي تعتمد عليه معظم برمجيات المؤسسات في الاعتماد ملكاً لـ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 في November 2003 بوصفه الإصدار المجتمعي السريع، وRHEL ‏(Red Hat Enterprise Linux)، الذي بدأ باسم Advanced Server 2.1 في عام 2002، بوصفه الإصدار المدفوع البطيء. السبب واضح. لا يمكن لمنتج واحد أن يكون في الوقت نفسه المكان الذي تُجرَّب فيه الإصدارات الجديدة والمنصة التي يشغّلها بنك من دون تغيير طوال عشر سنوات. يرتبط القسمان أحدهما بالآخر: يتفرع الإصدار الرئيسي من RHEL من إصدار Fedora، ثم يُثبَّت ويُجمَّد. تحركت أداة الحزم وفق الجدول نفسه، من yum في 2000s إلى dnf بوصفها الإعداد الافتراضي في Fedora عام 2015، مع rpm تحتهما معاً.

لماذا توقّف CentOS عن كونه إعادة بناء مجانية لـRHEL

بدأ CentOS في 2004 بمهمة بسيطة: أخذ حزم المصدر التي تنشرها Red Hat، وإزالة العلامات التجارية منها، وإعادة بنائها، ثم إتاحة النتيجة مجاناً. أصبح التوزيعة المجانية الافتراضية للخوادم لمدة عقد، واستحوذت Red Hat على المشروع وأدخلته ضمن الشركة في 2014.

في 8 December 2020 أعلنت Red Hat أن CentOS Linux 8 سينتهي في 31 December 2021، أي قبل الموعد المنشور بثماني سنوات، وأن الاسم سيستمر مع CentOS Stream. لا يُعد Stream إعادة بناء. بل هو الفرع الذي تُشتق منه الإصدارات الثانوية لـRHEL، ولذلك فهو يتقدم على RHEL بدلاً من أن يتأخر عنه. إذا كنت تنوي إبقاء جهاز لسنوات، فالتقدم ليس الاتجاه الصحيح، لأنك ستتلقى التغييرات قبل عملاء Red Hat الذين يدفعون.

ظهرت إعادتَا بناء في 2021. بدأ Gregory Kurtzer مشروع Rocky Linux، وهو أحد المؤسسين المشاركين لـCentOS. موّلت CloudLinux مشروع AlmaLinux. في June 2023 توقفت Red Hat عن نشر مصادر RHEL في أي مكان باستثناء CentOS Stream وبوابة العملاء التابعة لها. واصل Rocky استهداف إعادات بناء مطابقة. غيّر AlmaLinux هدفه إلى التوافق مع ABI (واجهة التطبيق الثنائية)، وهذا يعني أن البرامج المبنية لـRHEL تعمل، من دون وعد بأن قائمة الأخطاء مطابقة سطراً بسطر. أنشأت Oracle وSUSE وCIQ منظمة OpenELA في وقت لاحق من العام نفسه لنشر مصادر مشتركة.

إذا كانت قائمة صور مزود الخدمة لا تزال تعرض CentOS، فتحقق من المقصود قبل أن تبني عليه.

cat /etc/os-release

NAME="CentOS Stream" هو فرع تطوير متتابع يقود إلى RHEL. أما NAME="AlmaLinux" أو NAME="Rocky Linux" فهو إعادة بناء تتبعه، مع فترة دعم تمتد لعشر سنوات.

Ubuntu، 2004: لقطة من Debian unstable وفق جدول زمني

صدر Ubuntu 4.10 في 20 October 2004 بتمويل من Mark Shuttleworth. علاقته بـDebian عملية وليست عاطفية. تبدأ كل دورة باستيراد الحزم من Debian unstable إلى إصدار Ubuntu الجديد. تستمر عمليات الاستيراد حتى Debian Import Freeze في منتصف الدورة، وبعد ذلك يحتفظ Ubuntu بتغييراته الخاصة. كثير من حزم Ubuntu هي حزمة Debian مضافاً إليها فرق تغييرات، ويبيّن changelog ماهية هذا الفرق.

النصف الآخر هو الجدول الزمني. تصدر Debian عندما تصبح جاهزة. يصدر Ubuntu في April وOctober، ورقم الإصدار هو التاريخ: صدر 24.04 في April 2024. كل إصدار يصدر في April بعد إصدارين هو LTS (دعم طويل الأمد)، وهذا ما يقصده مزود الخدمة عندما يدرج Ubuntu من دون مؤهل. يوضّح موضوع الاختيار بين إصدارات Ubuntu LTS والإصدارات المرحلية أي الإصدارين يناسب الخادم، كما أن الانتقال من إصدار LTS إلى الإصدار التالي له إجراء خاص، موضح في الترقية من 24.04 إلى 26.04.

تلفت إحدى التفاصيل انتباه مسؤولي الخوادم كل عام. ينقسم مستودع Ubuntu إلى مكوّنات. main تتولى Canonical صيانته طوال فترة الدعم الكاملة. universe تتم صيانته من المجتمع، وتغطية الأمان فيه تمثل التزاماً مختلفاً. apt install لا يعرض شيئاً عن هذا الفرق. يعرضه أمر واحد:

apt-cache policy nginx

يعني سطر المستودع المنتهي بـ/main أن فريق الأمان في Canonical مسؤول عن تلك الحزمة. أما السطر المنتهي بـ/universe فيعني أن المجتمع مسؤول عنها. افحص ذلك لكل ما يتصل بالإنترنت.

Arch، 2002: الإصدارات المتتابعة وتكلفة الترقية الجزئية

أصدر Judd Vinet الإصدار Arch 0.1 في 11 March 2002، مع مدير حزم كتبه بنفسه، pacman، ووصفات بناء هي في الأساس shell scripts عادية. لا يحتوي Arch على إصدارات مرقّمة إطلاقاً. وسائط التثبيت هي لقطات مؤرخة من المستودعات المتتابعة نفسها، لذلك يعمل جهاز ثُبّت في 2019 وتلقى تحديثات أسبوعية بنسخة Arch نفسها التي يعمل بها جهاز ثُبّت اليوم. يحتوي مستودع مستخدمي 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 للأجهزة المضمنة، لا لأجهزة سطح المكتب. وهي تستبدل معظم مكونات userland المعتادة: تستخدم musl بدلاً من GNU C library، وBusyBox بدلاً من GNU core utilities، وOpenRC بدلاً من systemd، وapk بصفته مدير الحزم. وكان إصدار Alpine 3.0 في عام 2014 هو الإصدار الذي انتقل إلى musl.

جعلتها الحاويات شائعة. فطبقة Alpine الأساسية أصغر بكثير من طبقة Debian أو Ubuntu الأساسية. لذلك أصبحت منذ عام 2016 صورة أساسية شائعة، وأصبح عدد كبير من الأشخاص الذين لم يثبّتوا Alpine قط يستخدمونها يومياً.

لكن musl ليست glibc، ويظهر الفرق على شكل أخطاء تبدو غير مرتبطة بالسبب. يفشل ملف ثنائي مرتبط بـglibc على Alpine برسالة تدفع المستخدمين إلى البحث عن ملف موجود بالفعل:

sh: ./myapp: not found

البرنامج موجود. لكن مفسّر ELF الخاص به غير موجود، لأن محمّل glibc غائب. وتشكّل Python المفاجأة الشائعة الأخرى: لن تُثبَّت العجلات المبنية مسبقاً لـmanylinux على musl، لذلك تعود pip إلى التجميع من المصدر وتتوقف عند عدم تثبيت أي مترجم. عالج معيار عجلات musllinux الصادر في 2021 هذه المشكلة للمشاريع التي تنشر تلك العجلات، ولا يعالجها لأي مشاريع أخرى.

كنظام تشغيل مضيف على VPS، تُثبَّت Alpine بسرعة وبحجم صغير، لكنها تدفعك إلى مسار يختلف عما تفترضه معظم الوثائق. كل دليل يطلب منك تشغيل systemctl enable يحتاج إلى ترجمة مقابلة إلى rc-update add.

الجيل غير القابل للتغيير: التحديثات الذرّية والخوادم المعتمدة على الصور

يغيّر أحدث فرع نموذج التحديث بدلاً من قائمة الحزم. يحتفظ النظام المعتمد على ostree بـ /usr للقراءة فقط. التحديث هو شجرة نظام ملفات جديدة كاملة تُنزَّل وتُجهَّز، ثم يجري التبديل إليها عند إعادة التشغيل التالية. تبقى الشجرة السابقة كخيار إقلاع، لذلك يمكن التراجع عن تحديث معيب بإعادة التشغيل والإقلاع إلى الشجرة القديمة.

نقل Fedora Silverblue هذا النموذج إلى أجهزة سطح المكتب في 2018، ثم نقله Fedora CoreOS إلى الخوادم في 2019، بعد أن اشترت Red Hat مشروع CoreOS في 2018. واصل Flatcar Container Linux المشروع الأصلي Container Linux بعد إيقافه في 2020. ويصل openSUSE MicroOS إلى النتيجة نفسها من خلال لقطات btrfs وtransactional-update. في 2024 أضافت Red Hat وضعاً يعتمد على الصور إلى RHEL، مبنياً على bootc، حيث يُطرح نظام التشغيل في صورة حاوية، ويُحدَّث الجهاز بتوجيهه إلى tag جديد. يذهب Talos Linux إلى أبعد من ذلك، إذ يزيل shell وSSH بالكامل؛ ويُضبط الجهاز عبر API، لذلك لا يوجد شيء يمكن تسجيل الدخول إليه. أما NixOS، الذي صدر أول مرة في 2007، فيتبع اتجاهاً مختلفاً. يُبنى النظام بأكمله من إعداد تصريحي واحد، وتبقى الأجيال السابقة قابلة للإقلاع.

من المحتمل أن مزود الخدمة لديك لا يوفّر أياً من هذه الأنظمة كصورة جاهزة بنقرة واحدة، لأنه يتوقع إعدادها عند الإقلاع الأول بواسطة Ignition أو cloud-init، بدلاً من أن يحرر المسؤول الملفات عبر SSH. تظهر فوائدها عند تشغيل العديد من الأجهزة المتطابقة، وهي الحالة التي تصل إليها عندما تصبح تدير عدة خوادم Linux في الوقت نفسه وتحتاج إلى إثبات أن كل خادم مطابق للخوادم الأخرى.

ما مدة دعم الإصدار الواحد؟

سياسة الإصدارات هي جانب التوزيعة الذي ستتعامل معه لأطول مدة، وتُنشر عادةً بعدد من السنوات. فيما يلي مدد الدعم للإصدارات الحالية من الخوادم وعددها 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 دعماً لمدة 5 سنوات للحزم في main، وتمدد اشتراك Ubuntu Pro ذلك إلى 10 سنوات، مجاناً للاستخدام الشخصي على عدد صغير من الأجهزة. يعلن RHEL 10 عن 10 سنوات من الدعم، ويمدّدها ملحق دعم دورة الحياة الموسعة المدفوع إلى 13. يطابق AlmaLinux 10 مدة دعم RHEL البالغة 10 سنوات دون أي اشتراك، وهذا هو السبب الأساسي لوجود عمليات إعادة البناء هذه.

لا يضم الجدول Arch، لأن التوزيعة ذات الإصدارات المتتابعة لا تملك إصداراً محدداً يحتاج إلى دعم. الرقم المهم في Arch هو المدة التي يمكنك خلالها ترك الجهاز دون تحديث، وتُقاس هذه المدة بالأسابيع.

لماذا تبدو قائمة صور VPS لديك بهذا الشكل

يوفّر مزود الخدمة الصور التي يطلبها العملاء بالاسم، والتي تُثبَّت تلقائياً على برنامج الإشراف الخاص به. لذلك تبدأ كل قائمة تقريباً بإصدار Ubuntu LTS وDebian stable، وتضيف AlmaLinux أو Rocky لمن تكون برمجياتهم معتمدة على RHEL، وتضع Alpine وArch وFedora في مواضع أبعد أسفل الصفحة. بعد أن تعرف ما هو VPS وكيف تصل الصورة إلى القرص، يصبح النمط واضحاً: يختار مزود الخدمة أنظمة تشغيل تنجح في التثبيت التلقائي وتبقى مدعومة مدة أطول من الفترة التي يُبقي فيها العميل العادي الخادم.

هذا الاختيار يفرض عليك أكثر من مجرد مدير حزم. فهو يحدد الترقية التي ستجريها بعد ثلاث سنوات، وتختلف هذه الترقية اختلافاً كاملاً بين العائلات. يتيح Debian وUbuntu إجراء ترقيات رئيسية في مكانها. وتجري عائلة Red Hat هذه الترقيات عبر leapp. لا يملك Arch ترقية لأنه لا يملك إصدارات. أما Alpine، فتتم ترقيته بتحرير /etc/apk/repositories وتشغيل apk upgrade --available. ويحدد الاختيار أيضاً البرامج التي يمكنك تثبيتها من دون إضافة مستودع تابع لجهة خارجية، والجهة التي توفّر التصحيح عند ظهور إدخال CVE (الثغرات والتعرضات الشائعة) في أحد المكونات التي تشغّلها، ونظام init ومكتبة C التي ستفترض برمجياتك المستقبلية وجودهما.

هناك تأثير آخر يسهل التقليل من أهميته. تفترض معظم الإجابات المنشورة على الإنترنت مساراً من عائلة Debian أو مساراً من عائلة Red Hat، ولذلك يعني اختيار عائلة أخرى ترجمة التعليمات طوال فترة تشغيل الجهاز. اختر العائلة التي تتوافق سياسة إصداراتها مع عدد المرات التي تقبل فيها تعديل الخادم، ثم التزم بها. تغيير الحزم المثبتة فوقها سهل. أما تغيير التوزيعة الأساسية فيعني إعادة بناء الخادم.

FAQ

ما عائلة توزيعة Linux التي يعمل بها خادمي؟

شغّل cat /etc/os-release. يذكر الحقل ID اسم التوزيعة، ويذكر ID_LIKE عائلتها؛ لذلك يعرض جهاز Ubuntu القيمة ID_LIKE=debian، بينما يعرض جهاز AlmaLinux القيمة ID_LIKE="rhel centos fedora". ومدير الحزم مؤشر آخر. تعني apt وdpkg عائلة Debian، وتعني dnf وrpm عائلة Red Hat، وتعني apk توزيعة Alpine، وتعني pacman توزيعة Arch.

هل ما يزال CentOS إصداراً مجانياً من RHEL؟

لا. انتهى CentOS Linux 8، وهو آخر إصدار أُعيد بناؤه بهذا الاسم، في 31 December 2021، ووصل CentOS Linux 7 إلى نهاية دعمه في 30 June 2024. أما المشروع المستمر، CentOS Stream، فهو الفرع الذي تُبنى منه الإصدارات الثانوية من RHEL، لذلك تصله التغييرات قبل RHEL لا بعده. والإصدارات المجانية التي تولت الدور القديم هي AlmaLinux وRocky Linux، وكلاهما يوفر فترة دعم مدتها ten years.

لماذا تحتوي إصدارات Debian stable على أرقام إصدارات قديمة؟

لأن رقم الإصدار يتجمد بينما تستمر الإصلاحات في الوصول. تنقل Debian تصحيحات الأمان إلى الإصدار الذي أصدرته بدلاً من استيراد إصدار أحدث من upstream، لذلك قد تحتوي حزمة يظهر فيها 2.4.57-2+deb13u1 على إصلاح نُشر الأسبوع الماضي. واللاحقة التي تأتي بعد إصدار upstream هي مراجعة Debian، ويسرد apt changelog <package> ما أُدرج فيها. إن تقييم أمان خادم Debian اعتماداً على أرقام إصداراته يؤدي دائماً إلى نتيجة خاطئة.

هل ينبغي أن أشغّل توزيعة rolling مثل Arch على VPS؟

فقط إذا كنت ستحدّثها وفق جدول منتظم. تفترض التوزيعة rolling أن تتقارب كل الأجهزة نحو مجموعة الحزم الحالية، لذلك يؤدي تحديث حزمة واحدة باستخدام pacman -Sy foo إلى ترك مكتبات غير متطابقة وأخطاء مثل cannot open shared object file. شغّل pacman -Syu بانتظام، واقرأ صفحة أخبار المشروع قبل كل تشغيل، وسيظل النظام مستقراً. إذا تركته لمدة عام، فستصبح أول ترقية هي العملية المحفوفة بالمخاطر.

ما الذي يتغير فعلياً عند استخدام توزيعة immutable أو atomic؟

يتغير وقت تطبيق التحديثات وطريقة التراجع عنها. يتم تركيب /usr للقراءة فقط، ويُجهَّز التحديث كشجرة جديدة كاملة، ثم يحدث التبديل عند إعادة التشغيل، مع الاحتفاظ بالشجرة السابقة كإدخال إقلاع لاستخدامها في التراجع. تحصل على جهاز يكون محدثاً بالكامل أو غير محدث بالكامل، من دون حالة مطبقة جزئياً. لكنك تتخلى عن تثبيت البرامج عبر تعديل الملفات في مكانها، لذلك تنتقل التطبيقات إلى الحاويات أو إلى حزم ذات طبقات.