تخيّل بلدةً صغيرة كانت، لعقودٍ طويلة، كلُّ بيوتِها تُبنى بطريقة مختلفة. بيتٌ يستخدم الشموع، وآخر يستخدم مصابيح الزيت، وثالث يستخدم المصابيح الكهربائية الأولى. كلّها كانت تُنتج الضوء، وكان كلّ صاحب بيتٍ فخورًا بأن نظامه هو الذي يعمل على النحو الصحيح. وكان شعار البلدة: «اختر طريقتك بنفسك.»

ثم في يومٍ من عام 2010، دخل إلى البلدة مهندسٌ شابٌّ وطموح. كان اسمه لينارت بوترينغ (Lennart Poettering). وكان يعمل في ريد هات (Red Hat)، إحدى أكبر الشركات في عالم لينكس. نظر حوله إلى كل هذه البيوت المختلفة، ثم قال: “هذا فوضى. كلُّ بيتٍ يفعل الشيء نفسه، لكن بطريقة مختلفة تمامًا. ماذا لو صمّمتُ نظامًا واحدًا يتولّى الإضاءة، والسباكة، والتدفئة، والأمن. كلَّها معًا، وكلَّها بطريقة موحّدة؟” أُعجب بعض الناس بالفكرة. وأخيرًا، كما ظنّوا، يمكننا أن نتوقّف عن إعادة اختراع العجلة. وخلال بضع سنوات، تبنّت معظم البلدة نظامه.

لكن آخرين غضبوا بشدة. قالوا إنه يدمّر الشيءَ نفسه الذي جعل بلدتهم مميّزة، حرية الاختيار. وبعضهم جمع أمتعته وذهب ليبني أحياءه الخاصة على أطراف البلدة، رافضًا استخدام نظامه. كان اسم نظام ذلك المهندس سيستم دي (systemd). وتلك البلدة؟ هي عالم لينكس. أمّا الجدل الذي بدأ في ذلك اليوم، فهو لم ينتهِ حقًّا إلى الآن.

ما هو ‎systemd‎، حقًّا؟

عندما تُشغّل حاسوبًا يعمل بنظام لينكس، فلا بدّ من وجود شيءٍ ما يوقظ كل شيء. عليه أن يبدأ تشغيل الشبكة، والشاشة، والصوت، وشاشة تسجيل الدخول. وعشرات الخدمات الأخرى، بالترتيب الصحيح، وفي الوقت الصحيح. البرنامج المسؤول عن هذه المهمة يُسمّى نظام التهيئة (init system)، اختصارًا لكلمة “initialization” أي التهيئة. وهو حرفيًا العملية رقم 1 (process number 1). أول ما يُطلقه النواة (kernel)، وهو الأصل الذي تتفرّع منه كل العمليات الأخرى على جهازك.

قبل ‎systemd‎، كانت معظم توزيعات لينكس تستخدم نظام تهيئة اسمه سِس-في-إنيت (SysVinit)، ويُنطق “sys-five-init”. وُلد SysVinit في أوائل ثمانينيات القرن العشرين، موروثًا من يونكس سيستم 5 (UNIX System V) الذي طوّرته شركة إيه تي آند تي (AT&T). كانت فكرته بسيطة: يشغّل سلسلة من نصوص الصدفة (shell scripts) واحدًا بعد الآخر. النص رقم 1 يبدأ الشبكة. النص رقم 2 يبدأ التسجيل. النص رقم 3 يبدأ مدير العرض. وهكذا. لقد نجح، ولعقودٍ نجح.

لكن كانت لديه مشكلات: -

• كان بطيئًا. كانت النصوص تُشغَّل واحدًا بعد الآخر، بالتتابع. وعلى جهاز حديث فيه قرص حالة صلبة (SSD) وثماني أنوية للمعالج، كان هذا يشبه الانتظار في طابور دفعٍ واحد في متجرٍ كبير بينما توجد سبعة طوابير أخرى فارغة.
• كان هشًّا. كل توزيعة كانت تكتب نصوصها بطريقتها الخاصة. لم تكن هناك صيغة قياسية موحّدة. وإذا تعطل شيء، كان عليك أن تقرأ نصوص صدفةٍ فوضوية لتعرف السبب.
• كان محدود الذكاء. لم يكن SysVinit يراقب الخدمات بعد تشغيلها. فإذا تعطل خادم الويب لديك في الساعة الثالثة صباحًا، لم يكن SysVinit يعلم بذلك، ولم يكن يهتم. كان يؤدي عمله وقت الإقلاع، ثم ينام تقريبًا.

رأى لينارت بوترينغ كلَّ هذا. كما رأى أيضًا ما فعلته آبل مع لونشد (launchd) في نظام ماك أو إس (macOS). وهو نظام تهيئة حديث يمكنه تشغيل الخدمات بالتوازي ومراقبتها. واعتقد أن لينكس يستحق شيئًا جيدًا مثله، إن لم يكن أفضل. في مارس 2010، أعلن لينارت بوترينغ وكاي زيفرز (Kay Sievers)، وكلاهما يعمل في ريد هات (Red Hat)، عن سيستم دي (systemd). والاسم فيه تلاعب لفظي بعبارة شيطان النظام (System Daemon)؛ وكلمة daemon في يونكس تعني عملية تعمل في الخلفية، وفي الوقت نفسه تلتزم بعادة يونكس المتمثلة في إضافة الحرف “d” إلى أسماء العمليات الخدمية.

لم يكن ‎systemd‎ مجرد بديلٍ عن SysVinit، بل كان إعادة تصوّر كاملة لما يمكن أن يكون عليه نظام التهيئة. وهذا ما جاء به:

• الإقلاع المتوازي (Parallel startup). بدلًا من تشغيل النصوص واحدًا بعد الآخر، كان ‎systemd‎ قادرًا على تشغيل كثيرٍ من الخدمات في الوقت نفسه، ما خفّض أزمنة الإقلاع بشكلٍ واضح.
• إدارة الاعتماديات (Dependency management). يمكنك أن تقول لـ ‎systemd‎: “لا تبدأ خادم الويب حتى تصبح الشبكة جاهزة.” وهو يتولّى حساب الترتيب الصحيح تلقائيًا.
• الإشراف على الخدمات (Service supervision). إذا تعطلت خدمة، يستطيع ‎systemd‎ اكتشاف ذلك وإعادة تشغيلها تلقائيًا.
• تهيئة موحّدة (Unified configuration). بدلًا من نصوص الصدفة shell الفوضوية، كانت الخدمات تُعرَّف في ملفات الوحدات (unit files). وهي ملفات نصية بسيطة، وتصريحية تبدو بالطريقة نفسها في كل التوزيعات.
• جورنالد (journald). نظام تسجيل مدمج يستبدل ملفات السجل القديمة المتفرقة بسجل واحد منظّم وقابل للبحث. وأكثر من ذلك بكثير.

مع مرور الوقت، توسّع ‎systemd‎ ليشمل إدارة اسم المضيف، ومزامنة الوقت، وتهيئة الشبكة، وتتبع جلسات تسجيل الدخول، وإدارة الحاويات، وعشرات الميزات الأخرى. وهذه النقطة الأخيرة، و العديد سواها. هي بالضبط حيث تبدأ المشكلة.

كيف غزا ‎systemd‎ عالم لينكس.

السرعة التي اعتُمِد بها ‎systemd‎ هي واحدة من أكثر الأحداث لفتًا للنظر في تاريخ لينكس. ففي نحو أربع سنوات تقريبًا، انتقل من مشروعٍ جديد تمامًا إلى نظام التهيئة الافتراضي في كل توزيعة لينكس كبرى تقريبًا. وهذا هو الخط الزمني:

لماذا حدث هذا بهذه السرعة؟

كانت هناك عدة قوى دفعت هذا التبنّي السريع:

1. نفوذ ريد هات

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

وقد كانت فيدورا (Fedora)، وهي توزيعة المجتمع التابعة لريد هات، بمثابة أرض الاختبار. وما إن أثبت systemd استقراره هناك، حتى اعتمدته آر إتش إي إل (RHEL)، وبما أن سنت أو إس (CentOS)، ولاحقًا ألما لينكس (AlmaLinux) وروكي لينكس (Rocky Linux)، تعكس RHEL، فقد تبعتها تلقائيًا.

2. فوائد تقنية حقيقية

أحببته أم كرهته، فقد حلّ systemd مشكلات حقيقية:

• انخفضت أزمنة الإقلاع بشكل ملحوظ.
• أصبح بإمكان مديري الأنظمة إدارة الخدمات بمجموعة أوامر موحّدة (systemctl start، systemctl stop، systemctl status) بدلًا من حفظ مسارات نصوص مختلفة على توزيعات مختلفة.
• كانت صيغة ملفات الوحدات أبسط فعلًا من نصوص SysVinit.
• استطاع مطوّرو البرمجيات كتابة ملف وحدة واحد، وهم يعلمون أنه سيعمل على فيدورا، وديبيان، وآرتش، وسوزي من دون تعديل.

وكان هذا أمرًا بالغ الأهمية للمنظومة.

3. اعتماديات البرمجيات

مع توسّع systemd، بدأت مزيدٌ من البرمجيات تعتمد عليه. أو بتعبير أدق، تعتمد على مكتباته وواجهاته (libraries and interfaces).

وأبرز مثال على ذلك هو لوغيند (logind)، وهو مدير تسجيل الدخول في systemd. فقد بدأت بيئات سطح المكتب مثل جنوم (GNOME) تطلب logind من أجل:

• تتبّع الجلسات
• إدارة الأجهزة المتعدّدة (seat management)
• التحكم في الطاقة (مثل تعليق الحاسوب المحمول عند إغلاق الغطاء)

وإذا لم تكن التوزيعة لديك تحتوي على logind، فلن يعمل GNOME كما ينبغي. وقد سبّب هذا ضغطًا هائلًا على التوزيعات كي تتبنّى systemd، حتى لو كانت لدى القائمين عليها تحفظات.

وبعض الناس سمّوا هذا «الاحتجاز الناعم (soft lock-in)»، وكانوا غير راضين عنه بشدة.

4. تصويت ديبيان

كانت اللحظة الأكثر درامية في فبراير 2014، عندما صوّتت اللجنة التقنية في ديبيان (Debian Technical Committee) على نظام التهيئة الافتراضي الذي ستستخدمه ديبيان.

وتُعد ديبيان، على الأرجح، التوزيعة الأكثر تأثيرًا في عالم لينكس. ليس فقط بسبب مستخدميها، بل لأن مئات التوزيعات الأخرى، ومنها أوبونتو ولينكس منت وغيرها، مبنية عليها.

كان التصويت متقاربًا ومثيرًا للانقسام. ناقش أعضاء اللجنة الأمر لأشهر. وفي النهاية، فاز systemd.

وكان القرار مثيرًا للخلاف، إلى حدّ أنه أدّى إلى:

• إنشاء قرار عام (General Resolution) بشأن تنوّع أنظمة التهيئة.

• إلهام مشروع ديفوان (Devuan) مباشرةً، الذي سنعود إليه لاحقًا.

• استقالة أحد مطوّري ديبيان، وهو جوي هِس (Joey Hess)، وهو اسم محترم للغاية وخبير قضى 15 سنة في المشروع، واصفًا عملية النقاش بأنها سامة.

  التمرّد

  لماذا يكره كثيرون ‎.systemd‎ المعارضة لـ ‎systemd‎ ليست حركة هامشية. فهي تضمّ بعض أكثر الأصوات خبرةً واحترامًا في عالم لينكس ويونكس. وحججهم جادّة، وتقنية، وفلسفية. وهذه أهمها:

1. «إنه ينتهك فلسفة يونكس» فلسفة يونكس، التي صاغها على نحوٍ مشهور دوغ ماكلروي (Doug McIlroy)، وجرى تلخيصها ونشرها في صياغة بيتر سالوس (Peter Salus)، تقول: «اكتب برامج تقوم بشيء واحد، وتقوم به جيدًا. واكتب برامج تعمل معًا.» يرى المنتقدون أن ‎systemd‎ ينتهك هذا المبدأ من جذوره. فبدلًا من أن يكون نظام تهيئة صغيرًا، نما ليصبح مجموعة ضخمة تضم أكثر من 80 ملفًا تنفيذيًا (binaries) تدير التسجيل (journald)، والشبكات (networkd)، وحلّ أسماء النطاقات (DNS resolution) عبر (resolved)، ومزامنة الوقت (timesyncd)، والحاويات (machinectl)، والأدلة المنزلية (homed)، ومحمّل الإقلاع (systemd-boot)، وغير ذلك. ومن وجهة نظرهم، لم يعد هذا نظام تهيئة، بل أصبح طبقة من نظام التشغيل (operating system layer) تبتلع كل ما حولها. أما لينوس تورفالدس (Linus Torvalds)، مبتكر لينكس نفسه، فلم يكن معارضًا لـ ‎systemd‎ صراحةً، لكنه عبّر في عام 2014 عن استيائه من أسلوب مطوّري ‎systemd‎، وبخاصة من كاي زيفرز، وقال إنه لن يقبل بعض الرقع البرمجية بعد الآن، واعتبر طريقة فريق ‎systemd‎ في تتبّع الأخطاء إشكالية.

2. «إنه معقّد أكثر مما ينبغي» كان SysVinit بسيطًا. كان يمكنك قراءة نص صدفة وفهم ما الذي يفعله. أمّا ‎systemd‎ فلديه قاعدة شيفرة ضخمة، ووثائق كثيرة، و يتطلّب خبرة كبيرة. وعندما يحدث خطأ عميق داخل ‎systemd‎، فقد يكون تتبّعه صعبًا للغاية. ويرى المنتقدون أن التعقيد عدوّ الاعتمادية، وأن نظام التهيئة، وهو أساس نظام التشغيل، يجب أن يكون أبسط المكوّنات وأكثرها قابليةً للتدقيق، لا أكثرها تعقيدًا.

3. «إنه أحادي البنية ومترابط بإحكام» مع أن مشروع ‎systemd‎ مكوّن تقنيًا من عدة ملفات تنفيذية منفصلة، فإن المنتقدين يرون أن هذه المكوّنات، عمليًا، منسوجة معًا بإحكام. فلا يمكنك بسهولة استخدام journald من دون systemd، أو logind من دون systemd. وهذا الترابط المحكم يعني أن التوزيعات تواجه خيارًا من اثنين: إمّا اعتماد ‎systemd‎ بالكامل، وإمّا بذل جهدٍ كبير لاستبداله.

4. «إمّا طريقة لينارت، وإمّا لا طريق» يعترض بعض المنتقدين على ثقافة التطوير المحيطة بـ ‎systemd‎. فقد كانت تقارير الأخطاء تُرفض أحيانًا. ولم تكن الحلول البديلة مُرحّبًا بها. وأصبح لينارت بوترينغ نفسه مثاراَ للجدل. حتى إنه تلقّى قدرًا من العداء شمل تهديداتٍ بالقتل. وفي أكتوبر 2014، كتب تدوينة بعنوان «أكبر الخرافات (The Biggest Myths)» يدافع فيها عن ‎systemd‎ ويشير فيها إلى الإساءة التي تعرّض لها. وكانت كلفة هذا الجدل حقيقية وقبيحة على الجانبين.

5. «السجلات الثنائية فكرة سيئة» كان تسجيل يونكس التقليدي يستخدم ملفات نصية عادية. كنت تستطيع قراءتها بواسطة cat، والبحث فيها بواسطة grep، ومعالجتها بواسطة awk. أمّا جورنالد (journald) فيخزّن السجلات بصيغة ثنائية (binary format). وإذا تلف ملف السجل، فقد تخسر كل شيء. ويرى المنتقدون في ذلك تراجعًا إلى الوراء. أمّا مؤيّدو ‎systemd‎ فيردّون بأن السجل منظّم، ومفهرس، وقابل للبحث بواسطة journalctl، وأنه يمكنك مع ذلك إعادة توجيه السجلات إلى سيسلوغ (syslog) التقليدي القائم على النصوص إذا أردت.

6. «إنه يضعف تنوّع التوزيعات» عندما تستخدم كل التوزيعات نظام التهيئة نفسه، ونظام التسجيل نفسه، ومدير الشبكة نفسه. يقول بعضهم إن لينكس يفقد التنوّع الذي جعله قويًا. وإذا وُجد خلل حرج في ‎systemd‎، فإنه سيؤثر في كل التوزيعات تقريبًا، و في الوقت ذاته. والثقافات الأحادية، سواء في البرمجيات أو غيرها، هشّة بطبيعتها.

   التوزيعات التي قالت «لا»

رفضت عدة توزيعات لينكس، وبعضها مستوحًى من يونكس BSD . اعتماد ‎systemd‎. واتخذت كلٌّ منها طريقة مختلفة، ودفعت ثمنًا مختلفًا.

7. ديفوان (Devuan) تاريخ الميلاد: 2014، بوصفها تفريعة مباشرة من ديبيان. المؤسسون: مجموعة تُسمّي نفسها مديري يونكس المخضرمين (Veteran Unix Admins - VUA) . ديفوان هي ديبيان من دون ‎systemd‎. تستخدم سِس-في-إنيت (sysvinit) افتراضيًا، لكنها تدعم أيضًا أوبن آر سي (OpenRC) ورَن إت (runit). وتتبع ديفوان حزم ديبيان وتُجري عليها ترقيعات لإزالة اعتماديات ‎systemd‎. الكلفة: إن صيانة تفريعة من واحدة من أكبر التوزيعات في العالم هو عمل هائل. ففي كل مرة تُصدر فيها ديبيان حزمة تعتمد على ‎systemd‎، يتعيّن على فريق ديفوان ترقيعها أو إيجاد بديل لها. كما أنهم يشغّلون بنيتهم التحتية الخاصة للحزم. إنهم فريق صغير يقوم بعمل كبير. ومع ذلك، فقد استمرّوا، ولديهم مجتمع مخلص.
8. فويد لينكس (Void Linux) تاريخ الميلاد: 2008، أي قبل جدل ‎systemd‎. المنشئ: خوان روميرو باردينِس (Juan Romero Pardines)، وهو مطوّر سابق في نت بي إس دي (NetBSD) : لم تُبنَ Void أصلًا حول ‎systemd‎. فهي تستخدم رَن إت (runit)، وهو نظام تهيئة صغير وسريع وخفيف. أنشأه غيريت بابِه (Gerrit Pape). كما تستخدم Void مدير الحزم الخاص بها إكس بي بي إس (XBPS)، وتبني كل شيء من الصفر بدلًا من أن تكون مبنية على توزيعة أخرى. الكلفة: لأن Void مستقلة بالكامل، فعليها أن تحافظ على مستودع الحزم الخاص بها كاملًا. ولديها تشكيلة حزم أصغر من ديبيان أو آرتش. لكن الفائدة أنها لم تحتجّ يومًا إلى نزع ‎systemd‎ من نظامها. فقد بُنيت ببساطة بطريقة مختلفة منذ البداية.
9. آرتِكس لينكس (Artix Linux) تاريخ الميلاد: 2017، بوصفها تفريعة من آرتش لينكس : تأخذ Artix آرتش لينكس وتستبدل ‎systemd‎ بخيار من OpenRC أو runit أو s6 أو dinit. وكما تفعل ديفوان مع ديبيان، تتبع Artix حزم آرتش وتُجري عليها ترقيعات. الكلفة: مشابهة لما في ديفوان، ترقيعٌ وصيانةٌ مستمران. لكن Artix تستفيد من نموذج الإصدارات المستمرة في آرتش، ومن مستودع مستخدمي آرتش (Arch User Repository - AUR)، مما يجعلها جذابةً للمستخدمين الذين يحبون آرتش لكنهم لا يحبون ‎systemd.
10. جِنتو لينكس (Gentoo Linux) لطالما كان Gentoo متعلقًا بفكرة الاختيار. فهو يدعم ‎systemd‎ بوصفه خيارًا، لكنه يعتمد افتراضيًا على أوبن آر سي (OpenRC)، الذي وُلد أصلًا من نصوص التهيئة الخاصة بجنتو، وكتب معظمه روي ماربلز (Roy Marples) ابتداءً من نحو عام 2007. ويقوم مستخدمو Gentoo ببناء كل شيء من المصدر، ويمكنهم اختيار ما يريدون بدقة. الكلفة: بما أن Gentoo قائم على المصدر، فإن الكلفة يتحمّلها المستخدم نفسه على شكل وقت بناء وجهدٍ في التهيئة. لكنه يثبت أن توزيعة كبيرة وقديمة يمكن أن توفّر ‎systemd‎ بوصفه خيارًا من دون أن تفرضه.
11. ألباين لينكس (Alpine Linux) تستخدم Alpine أوبن آر سي (OpenRC)، وهي مبنية حول مكتبة سي القياسية ماسِل (musl libc) وبِزي بوكس (BusyBox) بدلًا من غليبك (glibc) وأدوات GNU الأساسية (GNU coreutils) الأكثر شيوعًا. وقد صُمّمت لتكون صغيرة وآمنة وبسيطة. وأصبحت شائعة جدًا بوصفها صورة أساس لحاويات دوكر (Docker container base image) بسبب حجمها الصغير جدًا. إذ إن صورة Alpine الأساسية تقارب 5 ميغابايت، مقارنةً بأكثر من 70 ميغابايت لأوبونتو. الكلفة: إن استخدام Alpine لمكتبة C مختلفة، وهي musl، يعني أن بعض البرمجيات لا تُجمع أو لا تعمل كما ينبغي من دون تعديل. لكن بالنسبة إلى الحاويات والأنظمة المضمّنة، أثبتت Alpine أن طريقةً غير معتمدة على ‎systemd‎، وغير متقيّدة بالمعيار GNU الشائع، يمكنها ليس فقط أن تبقى، بل أن تزدهر في المجال المناسب.
12. سلاكوير (Slackware) المؤسس: باتريك فولكردينغ (Patrick Volkerding)، منذ عام 1993. وهي أقدم توزيعة لينكس ما زالت باقية : لم تعتمد ‎systemd‎ قط. فهي تستخدم نصوص تهيئة بأسلوب (BSD-style init scripts) التقليدي. وكان باتريك فولكردينغ متحفّظًا بهدوء تجاه ‎systemd‎، مفضّلًا البساطة والتقاليد. الكلفة: تقلّصت قاعدة مستخدمي Slackware على مرّ العقود، وإن كان هذا يعود، على الأرجح، إلى عوامل كثيرة تتجاوز سؤال ‎systemd‎ وحده. ومع ذلك، ما زالت توزيعةً محبوبةً لدى أصحاب النزعة النقية.

كيف تطوَّرت البدائل بفضل systemd نفسه

هناك جانب من القصَّة نادرًا ما يُذكر، وهو ربَّما الأكثر إثارةً للاهتمام. أنظمة التمهيد البديلة اليوم ليست هي أنظمة التمهيد القديمة التي جاء systemd ليحلَّ محلَّها. لنعد إلى بداية القصَّة.

عندما ظهر systemd في عام 2010، كان يحلُّ مشاكل حقيقيَّة في SysVinit: البطء، والفوضى، وغياب المراقبة. وكان محقًّا في ذلك. لا أحد يستطيع إنكار أنَّ SysVinit القديم كان بحاجة إلى بديل. لكنَّ ما حدث بعد ذلك هو ما يحدث دائمًا في عالم البرمجيَّات الحرَّة عندما يظهر مُنافس قويٌّ، تطوَّرت البدائل. المنافسة أجبرت المعسكر الآخر على الارتقاء بمستواه. لم يقف المعارضون مكتوفي الأيدي يشتكون فحسب. بل بنوا حلولًا أفضل ممَّا كان موجودًا قبل systemd.

البطء؟ انقلبت المعادلة أحد أقوى حجج systemd عند ظهوره كانت سرعة الإقلاع. الإقلاع المتوازي (Parallel Startup) كان ثوريًّا مقارنةً بسكربتات SysVinit المتسلسلة البطيئة. لكنَّ المستخدم الذي يُثبِّت اليوم توزيعة مثل فويد لينكس (Void Linux) بنظام runit، أو آرتكس (Artix) بنظام dinit أو s6، سيُفاجأ بشيء لم يتوقَّعه. هذه الأنظمة سريعة، سريعة جدًّا. في كثير من الحالات، أسرع من systemd نفسه.

كيف؟ لأنَّ هذه الأنظمة البديلة اتَّبعت فلسفة مختلفة تمامًا. بدلًا من بناء نظام ضخم يفعل كلَّ شيء، بنت أنظمة صغيرة جدًّا وخفيفة جدًّا لا تفعل إلَّا ما هو ضروريٌّ، وتفعله بسرعة مذهلة. خذ runit مثلًا. الشيفرة المصدريَّة الكاملة لـ runit أصغر بمراتب من systemd. ليس لديه عشرات المكوِّنات الفرعيَّة التي تحتاج إلى التحميل والتهيئة. يُقلع، يُشغِّل الخدمات، ويتنحَّى جانبًا.

النتيجة؟ على العتاد نفسه، يمكن لنظام فويد لينكس بـ runit أن يصل إلى سطح المكتب في ثوانٍ قليلة. أحيانًا أقلَّ ممَّا يستغرقه systemd حتَّى في قراءة ملفَّات الوحدات الخاصَّة به.

أمَّا s6، الذي صمَّمه لوران بيركو (Laurent Bercot)، فقد ذهب إلى أبعد من ذلك. بنى نظامًا يجمع بين سرعة الإقلاع المتوازي والإشراف الدقيق على الخدمات، لكن بشيفرة خفيفة وصغيرة تلتزم بفلسفة يونكس حرفيًّا. وأضاف فوقه طبقة تُسمَّى s6-rc لإدارة الاعتماديَّات بين الخدمات. وهي الميزة ذاتها التي تفاخر بها systemd.

ونظام dinit، الذي طوَّره ديفين أوستن (Davin McCall)، صُمِّم من البداية كنظام إشراف على الخدمات مع دعم كامل للاعتماديَّات والإقلاع المتوازي. يجمع مزايا systemd التقنيَّة في حزمة أخفَّ بكثير. بعبارة أخرى: المشكلة التي جاء systemd لحلِّها، وهي بطء الإقلاع، لم تعد حجَّة لصالحه بالضرورة. البدائل الحديثة حلَّتها أيضًا، وأحيانًا بشكل أفضل.

إدارة الخدمات؟ الكبرى الثانية من حجج systemd كانت إدارة الخدمات الموحَّدة. قبله، كان عليك أن تعرف أين يوجد سكربت كلِّ خدمة، وكيف تُشغِّلها، وكيف تُوقفها، وكلُّ توزيعة تفعل ذلك بطريقة مختلفة. جاء systemd بأوامر موحَّدة:

systemctl start nginx systemctl stop nginx systemctl status nginx systemctl enable nginx

كان هذا تحسُّنًا حقيقيًّا وملموسًا. لا أحد يُنكر ذلك. لكن انظر الآن كيف يتعامل runit في فويد لينكس مع الخدمات:

لتشغيل خدمة:

ln -s /etc/sv/nginx /var/service/

مجرَّد إنشاء رابط رمزيٍّ (Symbolic Link). هذا كلُّ شيء. runit يكتشف الرابط تلقائيًّا ويُشغِّل الخدمة.

لإيقاف خدمة:

sv stop nginx

لمعرفة حالة خدمة:

sv status nginx

لإزالة خدمة من الإقلاع التلقائيِّ:

rm /var/service/nginx

مجرَّد حذف الرابط الرمزيِّ. ولكتابة خدمة جديدة؟ في systemd تكتب ملفَّ وحدة (Unit File) بتنسيق خاصٍّ في runit، كلُّ ما تحتاجه هو ملفٌّ واحد اسمه run سكربت شِل بسيط من بضعة أسطر. هذا سكربت شِل عاديٌّ:

bash #!/bin/sh exec nginx -g 'daemon off;'

لا تحتاج إلى تعلُّم تنسيق جديد. لا تحتاج إلى قراءة عشرات الصفحات من التوثيق. أيُّ شخص يفهم أساسيَّات الشِّل يفهم هذا الملفَّ فورًا. والميزة التي لا يعرفها كثيرون، إن runit يُراقب الخدمات أيضًا. إذا توقَّفت خدمة، يُعيد runit تشغيلها تلقائيًّا. تمامًا كما يفعل systemd. تلك الميزة التي قيل لنا إنَّها غائبة عن عالم ما قبل systemd؟ هي موجودة في runit منذ البداية، لأنَّ runit لم يكن SysVinit. كان جيلًا مختلفًا تمامًا.

الإشراف على الخدمات لم يخترعه systemd هذه نقطة مهمَّة . systemd لم يخترع مفهوم الإشراف على الخدمات (Service Supervision). هذا المفهوم أقدم بكثير: - daemontools، الذي كتبه دانييل بيرنشتاين (Daniel J. Bernstein) في أواخر التسعينيَّات، كان من أوائل أنظمة الإشراف على الخدمات في يونكس. أثَّر بعمق في كلِّ ما جاء بعده. - runit (2004) بناه غيريت بابي (Gerrit Pape) متأثِّرًا بـ daemontools، لكنَّه جعله أبسط وأنظف. - s6 بناه لوران بيركو متأثِّرًا بكليهما، لكنَّه أضاف تصميمًا أكثر صرامة وأمانًا.

ما فعله systemd هو أنَّه جمع هذه الأفكار وجعلها افتراضيَّة على كلِّ التوزيعات الكبرى. هذا إنجاز حقيقيٌّ من ناحية الانتشار. لكنَّ الأفكار نفسها كانت موجودة، وكانت تعمل، وقد تطوَّرت منذ ذلك الحين بشكل مستقلٍّ.

التنافس رفع المستوى، هذه هي المفارقة الكبرى في قصَّة systemd:

بوجوده، أصبحت البدائل أفضل ممَّا كانت ستكون لولاه. قبل systemd، لم يكن هناك ضغط حقيقيٌّ لتطوير أنظمة تمهيد بديلة. SysVinit كان “جيِّدًا بما يكفي” ولم يهتمَّ أحد بالابتكار في هذا المجال. عندما ظهر systemd وفرض نفسه، اضطرَّ كلُّ من رفضه إلى أن يُثبت أنَّ البديل ليس مجرَّد تمسُّك بالماضي — بل إنَّه يمكن أن يكون مستقبلًا مختلفًا وأفضل. - OpenRC أضاف دعمًا أفضل للتوازي وتحسينات في الأداء على مرِّ السنين. - runit أثبت أنَّ البساطة المتناهية يمكن أن تكون ميزة لا عيبًا. - s6 وs6-rc أثبتا أنَّه يمكن بناء نظام يُنافس systemd في الميزات مع الالتزام الصارم بفلسفة يونكس. - dinit ظهر كنظام حديث يأخذ أفضل ما في systemd (الاعتماديَّات، التوازي، الإشراف) ويُقدِّمه بحجم أصغر بكثير. المنافسة تُنتج تطوُّرًا. هذا صحيح في الاقتصاد، وصحيح في البرمجيَّات. وsystemd — شاء مؤيِّدوه أم أبوا — كان المحفِّز الأكبر لهذا التطوُّر.

ماذا يعني هذا للمستخدم العاديِّ؟ يعني أنَّك إذا سمعتَ أحدًا يقول: “التوزيعات بدون systemd بطيئة وبدائيَّة”، فاعلم أنَّ هذا كلام قديم. ربَّما كان صحيحًا في عام 2012. لكنَّه ليس صحيحًا في 2024 أو 2025. المستخدم الذي يُثبِّت فويد لينكس اليوم سيجد: إقلاعًا سريعًا غالبًا أسرع ممَّا اعتاد عليه على أوبونتو أو فيدورا. إدارة خدمات بسيطة وأنيقة, بأوامر قصيرة وملفَّات واضحة. إشرافًا تلقائيًّا على الخدمات إذا تعطَّلت خدمة، تُعاد تلقائيًّا. نظامًا خفيفًا يستهلك ذاكرة أقلَّ وموارد أقلَّ. شفافيَّة كاملة كلُّ شيء مكتوب بسكربتات شِل بسيطة يمكنك قراءتها وفهمها وتعديلها. هل هناك أشياء يفتقدها؟ بالتأكيد لكنَّ جودة تجربة الاستخدام الأساسيَّة لم تعد نقطة ضعف. إنَّها نقطة قوَّة. القصَّة التي بدأت بمهندس واحد يريد توحيد كلِّ شيء، أنتجت دون قصد عالمًا من البدائل أفضل ممَّا كان موجودًا قبله. وهذه ربَّما هي أجمل نتيجة في هذا الجدل كلِّه.

المنطقة الرمادية

استخدام مكتبات ‎systemd‎ من دون استخدام ‎systemd‎، هنا تتعقّدة الأمور ! . تذكّر أننا قلنا إن GNOME يعتمد على لوغيند (logind)؟ وإن logind جزء من ‎systemd‎؟ لقد خلق هذا كابوسًا للتوزيعات غير المعتمدة على ‎systemd‎ التي ما زالت تريد تشغيل GNOME. وجاء الحل في صورة إي-لوغيند (elogind). وهي نسخة مستقلة من logind استُخرجت من الشيفرة المصدرية لـ ‎systemd‎ وجُعلت تعمل بصورة مستقلة. ويُصان elogind أساسًا بواسطة مجتمع جنتو (Gentoo)، ويُستخدم في ديفوان وآرتكس وفويد وغيرها من التوزيعات غير المعتمدة على ‎systemd‎. وهنا تكمن المفارقة: حتى التوزيعات التي ترفض ‎systemd‎ تنتهي كثيرًا إلى استخدام شيفرة وُلدت داخل مشروع ‎systemd‎ نفسه.

فهي تستخدم مكتباته ومكوّناته، بينما ترفض استخدام ‎systemd‎ بوصفه نظام التهيئة الأساسي.

ومن الأمثلة الأخرى:

• ليب-يوديف (libudev)، أو إيوديف (eudev)، وهو تفريعة مستقلة: تحتاج كثير من البرامج إلى libudev لاكتشاف العتاد. وتحافظ التوزيعات غير المعتمدة على ‎systemd‎ على تفريعتها الخاصة منه، مع أن eudev، في السنوات الأخيرة، أُعيد دمجه في udev الخاص بـ ‎systemd‎، مما خلق تحديات صيانة مستمرة.
• إس دي-بَس (sd-bus): وهي مكتبة دي-بَس (D-Bus) التابعة لـ ‎systemd‎.

وقد بدأت بعض البرمجيات تربط نفسها بها. هذه المنطقة الرمادية تُحبط الناس على الجانبين. يقول منتقدو ‎systemd‎ إنها تثبت أن المشروع يصنع اعتماديات غير ضرورية ويبتلع بنيةً تحتيةً كان ينبغي أن تبقى مستقلة. أمّا مؤيدو ‎systemd‎ فيقولون إنها تثبت أن المشروع ينتج مكوّنات مفيدة وعالية الجودة، حتى إن خصومه لا يستطيعون تجنب استخدامها.

هل ينبغي أن يهمّك الأمر؟

إذا كنت مستخدم لينكس عاديًا. تتصفح الويب، وتكتب المستندات، وتلعب الألعاب، وربما تقوم ببعض البرمجة. فإنك غالبًا لن تتعامل مع نظام التهيئة مباشرةً أبدًا. فعندما تضغط زر التشغيل، تظهر لك بيئة سطح المكتب. وعندما تضغط «إيقاف التشغيل»، ينطفئ الحاسوب. وسواء كان ‎systemd‎ أو OpenRC أو runit هو الذي يدير ذلك في الخلفية، فقد لا تلاحظ أي فرق في استخدامك اليومي. إذًا، متى قد يفكر المستخدم العادي في توزيعة غير معتمدة على ‎systemd‎؟ إليك بعض الأسباب المشروعة:

1. أنت تتعلّم لينكس بعمق. إذا كنت تريد أن تفهم حقًّا كيف يعمل لينكس على المستوى الأساسي، فإن استخدام توزيعة غير معتمدة على ‎systemd‎ مثل Void أو Gentoo يُجبرك على تعلّم ما الذي يفعله نظام التهيئة فعلًا، وكيف تُدار الخدمات، وكيف تتآلف أجزاء نظام التشغيل معًا. فـ ‎systemd‎ يُخفي كثيرًا من هذه التفاصيل.
2. أنت تقدّر البساطة والحدّ الأدنى. إذا كنت تريد نظامًا خفيفًا ورشيقًا. ربما على حاسوب قديم، أو راسبيري باي (Raspberry Pi)، أو خادم تريد فيه أقصى قدر من التحكم وأدنى قدر من الحمل الزائد. فإن توزيعات غير معتمدة على ‎systemd‎ مثل Alpine أو Void تستطيع أن تقدّم نظامًا أصغر وأبسط.
3. أنت تهتم بالمبادئ الفلسفية. إذا كانت فلسفة يونكس مهمة بالنسبة إليك، وإذا كنت تؤمن بالأدوات الصغيرة القابلة للتركيب، وإذا أردت دعم تنوّع البرمجيات داخل منظومة لينكس، فإن اختيار توزيعة غير معتمدة على ‎systemd‎ هو طريقة لتحويل مبادئك إلى ممارسة.
4. أنت تشغّل أنظمة متخصصة. فالأنظمة المضمّنة، والحاويات، وبعض بيئات الخوادم تستفيد كثيرًا من أنظمة التهيئة الأبسط. وهيمنة Alpine في عالم دوكر دليل واضح على ذلك.

وماذا تخسر إذا اخترت توزيعة غير معتمدة على ‎systemd‎؟

1. مجتمع أصغر ووثائق أقل. إذا كنت تستخدم أوبونتو ثم بحثت عن مشكلة، فستجد ألف مشاركة في المنتديات وألف درس. أمّا إذا كنت تستخدم Void Linux، فستجد القليل، وستعتمد أكثر على الوثائق الرسمية. وهي، في حالة Void وGentoo، ممتازة فعلًا .
2. احتمال وجود مشكلات توافق برمجي. بعض البرمجيات باتت تفترض أكثر فأكثر أن ‎systemd‎ موجود. ومع أن التوزيعات غير المعتمدة عليه تقوم بعمل ممتاز في الالتفاف على ذلك بالترقيعات والبدائل، فقد تصادف أحيانًا حزمة لا تعمل على نحوٍ كامل، أو تحتاج إلى تهيئة إضافية لا يحتاجها مستخدم ‎systemd‎.
3. قيود على Flatpak. نظام فلاتباك Flatpak لتوزيع التطبيقات يعتمد على بعض مكونات systemd، وخاصةً systemd-binfmt والبوابات portals التي تتكامل مع systemd. في التوزيعات غير المعتمدة على systemd، قد لا يعمل Flatpak إطلاقًا، أو يعمل بشكل جزئي مع قيود ملحوظة. وهذا يعني أنك قد تفقد الوصول السهل إلى آلاف التطبيقات المتوفرة على فلاتهَب Flathub.
4. إعداد أصعب لبيئات سطح المكتب. إن GNOME، على وجه الخصوص، مندمج بإحكام مع مكونات ‎systemd‎. يمكنك تشغيله على توزيعات غير معتمدة على ‎systemd‎ بفضل elogind. لكن ذلك قد يتطلب إعدادًا إضافيًا، وقد لا تعمل بعض الحالات الطرفية بالضبط على النحو نفسه. أمّا بيئات سطح المكتب مثل إكس إف سي إي (XFCE) وإل إكس كيو تي (LXQt) وماتيه (MATE)، فعادةً ما تعمل بلا مشاكل تُذكر من دون systemd‎. .
5. مزايا أقل «من الصندوق». يوفّر ‎systemd‎ وسائل راحة كثيرة : إدارة تلقائية للخدمات، ووحدات مؤقّتة (timer units) بديلة لـ كرون (cron)، وتفعيلًا بالمقابس (socket activation)، والوصول إلى السجل. وكل ذلك بمجموعة أدوات واحدة. أمّا في توزيعة غير معتمدة على ‎systemd‎، فإنك تتعامل مع هذه الأشياء بأدوات منفصلة. مرونة أكبر، نعم، لكن عملًا أكثر أيضًا.
6. توقعات المهنة وبيئة العمل. إذا كنت تعمل في إدارة الأنظمة أو ديف أوبس (DevOps)، فإن الصناعة قد توحّدت إلى حدٍّ كبير على ‎systemd‎. ومعرفة ‎systemd‎ أصبحت مطلبًا مهنيًا. وخوادم الإنتاج لديك تعمل به في الغالب الأكيد. وهذا لا يعني ألا تتعلّم البدائل، بل يعني أنك ينبغي أن تعرف ‎systemd‎ على أي حال.

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

العالم غير المعتمد على ‎systemd‎ يقاتل للحفاظ على هذه الرؤية، وغالبًا بكلفة كبيرة في الصيانة والتوافق. والحقيقة هي أن لدى كلا الجانبين ما يقوله. فـ ‎systemd‎ ليس برمجية خبيثة. وليس مؤامرة. إنه قطعة برمجية مصمّمة جيدًا، حلّت مشكلاتٍ حقيقية، واعتمدها الناس لأن تلك الحلول كانت مطلوبة فعلًا. وفي المقابل، فإن المنتقدين ليسوا أعداءً للتقدّم. ولا هم خائفون من التغيير. كثيرٌ منهم مهندسون أصحاب خبرة عميقة، يرون مخاطر حقيقية في الثقافة الأحادية، وفي التعقيد، وفي الترابط المحكم . وهي مخاطر أثبت التاريخ أنها مخاوف صحيحة في هندسة البرمجيات.

لست مضطرًا إلى اختيار جانب. لديك رفاهية استثنائية: أن تستطيع تجربة الجانبين معًا. ثبّت أوبونتو أو فيدورا، وعاين صقل ‎systemd‎. ثم ثبّت Void أو Artix، وتذوّق بساطة runit أو OpenRC. كوّن رأيك بنفسك. إن هذه القدرة على الاختيار ، هي ما كان لينكس يدور حوله دائمًا. الجدل حول ‎systemd‎ ليس عيبًا في مجتمع لينكس. بل هو ميزة. إنه يعني أن الناس يهتمون بعمق بالبرمجيات التي يستخدمونها، وبالمبادئ التي تقف خلفها. وما دام الناس يهتمون، فسيظل لينكس يتطوّر. وسواء انتهى بك المطاف إلى جانب ‎systemd‎، أو إلى الجانب الآخر، أو سعيدًا في الوسط، فأنت الآن جزء من واحدٍ من أكثر النقاشات حماسةً في تاريخ البرمجيات مفتوحة المصدر. أهلًا بك في لينكس.