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

مع الزمن ينشأ تلوّث الحالة (state pollution): أعطال بلا سبب واضح، لأن تغييرات المستخدم وتغييرات النظام والترقيات تمتزج في تثبيت واحد متغيِّر.

من هنا ولدت الأنظمة immutable (غير قابلة للتغيير)، وatomic (ذرية)، وtransactional (معاملاتية)، وdeclarative (تصريحية)، وimage-based (قائمة على صورة). كلها تحاول أن تعيد للقاعدة صلابتها دون أن تسحق بيانات المستخدم أو تذيبها في طين النظام.

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

المفاهيم الأساسية

Immutable (غير قابل للتغيير/ثابت): أجزاء كبيرة من القاعدة (مثل /usr أو الجذر) تكون للقراءة فقط، وتُدفع الحالة إلى أماكن قابلة للكتابة مثل /var و/etc.

Atomic (ذرّي): التحديث ينتقل بالنظام كوحدة كاملة قابلة للإقلاع؛ إمّا تُقلع الحالة الجديدة، أو تبقى على القديمة.

Transactional (معاملاتي): التحديث يُنفَّذ كمعاملة عبر لقطات (غالباً Btrfs): تُنشأ لقطة جديدة، يُحدَّث داخلها، ثم تُفعَّل عند الإقلاع.

Deployment (نَشر): نسخة كاملة من النظام محفوظة للإقلاع.

Generation (جيل): نسخة مبنية من النظام في NixOS/Guix يمكن الرجوع إليها.

A/B System (نظام أ/ب): وجود جذرين أو قسمين؛ أحدهما يعمل والآخر يُحدَّث.

Image-based (قائم على صورة): النظام يُسلَّم كصورة أو شجرة كاملة لنظام الملفات. لها شكلين:

• OSTree: أشجار نظام ملفات تُحدَّث ذرّياً .
• OCI / A-B: صور حاويات قابلة للإقلاع، أو قسمان يُحدَّث غير النشط ثم يُبدَّل.

Declarative (تصريحي): النظام يُعرَّف بوصف مكتوب يُبنى منه جيل جديد قابل للرجوع. NixOS وGuix هما المثالان الأوضح.

State pollution (تلوّث الحالة): اختلاط تغييرات المستخدم والنظام بمرور الزمن في تثبيت واحد.

Reproducible (قابل لإعادة الإنتاج): نفس المدخلات تؤدي إلى نفس النظام الناتج.

تداخل المصطلحات واستقلالها

هذه المصطلحات لا تتضمن بعضها تلقائياً، بل تصف أبعاداً مختلفة من تصميم النظام.

• Immutable يصف حالة القاعدة بعد البناء.
• Atomic يصف كيفية ظهور نتيجة التحديث (إما حالة كاملة جديدة أو تبقى القديمة).
• Transactional يصف آلية تنفيذ التحديث داخل بيئة معزولة قبل تفعيله.
• Declarative يصف طريقة تعريف النظام من خلال وصف مكتوب.

بعبارة مختصرة:

• Immutable يتعلق ببنية النظام
• Atomic يتعلق برؤية النتيجة
• Transactional يتعلق بآلية التنفيذ
• Declarative يتعلق بطريقة التعريف

لذلك لا يوجد لزوم منطقي بينها

يمكن لنظام أن يكون غير قابل للتغيير دون أن يكون تصريحياً (مثل Silverblue). ويمكن أن يكون تصريحياً دون أن يكون غير قابل للتغيير فعلياً (مثل NixOS حيث الجذر قابل للكتابة). ويمكن تحقيق سلوك ذرّي دون استخدام لقطات تقليدية، كما يمكن تنفيذ تحديثات معاملتية دون بنية A/B صريحة.

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

الطريق التصريحي: NixOS وGuix

في يناير 2006، قدّم إيلكو دولسترا أطروحة “The Purely Functional Software Deployment Model”: وصف مكتوب يبني نسخاً قابلة للعودة بدل تعديل متراكم. NixOS يفعل ذلك عملياً:

sudo nixos-rebuild switch

sudo nixos-rebuild switch --rollback

النسخ تظهر في GRUB، ويمكنك الاحتفاظ بعدد غير محدود منها (على عكس اثنين فقط في rpm-ostree).

لكن يجب أن نكون دقيقين: نظام الملفات الجذر في NixOS قابل للكتابة فعلاً. يمكنك تعديل ملفات يدوياً إن أردت. ما يمنحك إياه NixOS ليس قفل الملفات بل ضمان أنك إذا صرّحت بحالة النظام عبر وصف مكتوب، تستطيع إعادة بنائه في أي مكان وزمان بشكل متطابق.

ولذلك ظهرت ممارسات تجعل الحالة غير المصرَّح بها مؤقتة: يمكن ضبط النظام بحيث تُحفظ فقط المجلدات المحددة صراحة، بينما يُعاد بناء بقية البيئة عند كل إقلاع انطلاقاً من الوصف التصريحي.

كما يمكن إدارة بيئة المستخدم،من الحزم إلى ملفات الإعداد. بنفس الأسلوب التصريحي، بحيث تصبح بيئة العمل قابلة لإعادة البناء تماماً كالنظام نفسه.

GNU Guix (نوفمبر 2012): نفس المنطق التصريحي لكن بـ Guile Scheme بدل لغة Nix، والتزام صارم ببرمجيات حرّة فقط في القنوات الافتراضية. guix system reconfigure ينشئ جيلاً جديداً، والأجيال القديمة تظهر في قائمة الإقلاع.

الطريق الذرّي القائم على الشجرة: من CoreOS الأصلي إلى Flatcar وFedora CoreOS وSilverblue

التاريخ الحقيقي: CoreOS → Flatcar (الوريث الفعلي) وFedora CoreOS (الوريث بالاسم)

هنا تصحيح تاريخي مهم يُغفل كثيراً: CoreOS (لاحقاً Container Linux) تأسست عام 2013، وكانت أول توزيعة لينكس واعية بفكرة الثبات في عالم الخوادم. استخدمت آلية تحديث اسمها Omaha. وهي نفس الآلية التي بدأت في Chromebooks ثم تبنّتها Android. تعمل على مستوى الكتل (blocks) لا الملفات.

Red Hat اشترت CoreOS في يناير 2018 مقابل 250 مليون دولار، لكن ما حدث بعدها يُساء فهمه. Red Hat لم تُكمل مشروع Container Linux. بل أعادت تسمية مشروعها الخاص Project Atomic إلى Fedora CoreOS. ولا يوجد تقريباً أي تشابه تقني بين المشروعين سوى الاسم التجاري.

الوريث الحقيقي لـ Container Linux هو Flatcar Linux: فُرِّع من Container Linux عند الاستحواذ، ثم اشترته Microsoft ضمن صفقة Kinvolk، وتبرّعت به لاحقاً لـ CNCF.

ما يجعل Flatcar مختلفاً حقاً ان معظم التوزيعات تصف نفسها بـ A/B partitions كاستعارة. Flatcar هي الوحيدة التي لديها أقسام A/B حقيقية على القرص: USR-A وUSR-B كأقسام فعلية، يكتب النظام أجزاءه غير المتغيرة فيهما ويتبادل الإقلاع بينهما. كل التوزيعات الأخرى لديها “أشجار ملفات A/B” أو “صور A/B” على نفس القسم. وهذا فرق تقني حقيقي، ليس مجرد لغة.

OSTree و Fedora CoreOS وSilverblue: من الخوادم إلى سطح المكتب

OSTree الذي بدأ مع Project Atomic يطرح سؤالاً بسيطاً في جوهره: ماذا لو تتبّعنا كل ملف في نظام الملفات وربطنا الإصدارات ببعضها؟

كما لو كان نظام التشغيل أمر commit في مستودع git، وكان بوسعنا التبديل بين الإصدارات. هذا يُتيح أكثر من مجرد A/B. يمكنك الاحتفاظ بعدة commits والإقلاع إلى أي منها.

ولأن OSTree لا يملك مرونة التعامل مع الحزم الفردية، أُنشئ rpm-ostree للسماح بتراكب حزم RPM فوق القاعدة. لكن هنا تظهر مفارقة تستحق التوقف. لأن OSTree لا يتيح المرونة الكافية لإدارة حزم منفردة، جاء rpm-ostree لتراكب حزم RPM فوق القاعدة. لكن هذا يُقوّض جوهر الفكرة . فأمر مثل:

rpm-ostree install -A $PACKAGE

يُثبّت الحزمة على نظام حيّ يعمل. أحياناً تُفسد هذه التراكبات النظام، ولهذا تُشجّع Red Hat الانتقال إلى bootc الذي لا يدعم تراكبات RPM.

Fedora CoreOS وSilverblue

Fedora CoreOS (FCOS) هو تنفيذ الخوادم، وSilverblue هو تنفيذ سطح المكتب. كلاهما مبني على OSTree. أما توزيعات مثل Bazzite وBluefin فهي نسخ مبنية فوق Silverblue، لكنها تضيف مجموعة اختيارات جاهزة مسبقاً (حزم، إعدادات، أدوات) موجَّهة لسيناريو معين مثل الألعاب أو التطوير، بدلاً من ترك كل شيء افتراضياً ومحايداً.

أما التسمية فلها تاريخ: وثيقة تغيير Fedora Atomic Desktops تذكر صراحة أن مصطلح غير قابل للتغيير immutable مربك. والهدف تجميع نسخ سطح المكتب المبنية على rpm-ostree تحت اسم موحد. تم تأسيس فريق العمل الطوعي في فبراير 2018، وإصدار Fedora 29 في أكتوبر 2018 كأول إصدار Silverblue.

ما يلمسه المستخدم: / و/usr للقراءة فقط، الحالة في /var، و/home رابط إلى /var/home. والتحديث والرجوع في مكانهما الطبيعي:

sudo rpm-ostree upgrade
reboot

وإن لم تعجبك النتيجة:

sudo rpm-ostree rollback
reboot

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

Universal Blue: حين تصبح الذرّية طريقة توزيع لا مجرد آلية تحديث

الفكرة التي يضيفها مشروع Universal Blue عملياً، هي أن الثبات immutability والذرّية atomicity لا تبقيان مجرد آلية تحديث مع إمكانية الرجوع، بل تتحولان أيضاً إلى طريقة توزيع كاملة للنظام.

فبدلاً من الاعتماد حصراً على مستودعات OSTree، تُبنى الأنظمة وتُوزَّع على شكل صور OCI قابلة للإقلاع، ويجري تحديثها باستخدام bootc. هكذا يصبح النظام نفسه صورة حاوية يمكن بناؤها، توقيعها، نشرها، وتحديثها بذات منطق الحاويات الحديثة. مع اهتمام واضح بسلسلة التوريد Supply Chain عبر توقيع الصور والتحقق منها كجزء افتراضي من عملية البناء.

لكن هذه الهندسة لا تظهر للمستخدم كتعقيد تقني، بل كقيمة عملية مباشرة على سطح المكتب.

القيمة العملية لمستخدم سطح المكتب

Universal Blue ليس توزيعة مستقلة، بل مشروع بناء صور فوق Fedora Atomic Desktops (مثل Silverblue وKinoite). بدلاً من أن تبدأ بصورة أساسية وتُخصّصها يدوياً، تختار صورة مُعدّة مسبقاً لسيناريو واضح:

• Bazzite → تجربة ألعاب متكاملة (Steam، Lutris، Heroic، تعريفات وضبط GPU، HDR/VRR)
• Bluefin → بيئة تطوير جاهزة (Dev Containers، Distrobox، أدوات سحابية)
• Aurora → KDE Plasma مُحسّن وموجّه للمستخدم المكتبي.

وإذا كنت بالفعل على Fedora Atomic Desktop، يمكنك إعادة التأسيس rebase إلى إحدى هذه الصور دون إعادة تثبيت النظام. للانتقال من Silverblue إلى Bazzite:

rpm-ostree rebase ostree-image-signed:ghcr.io/ublue-os/bazzite:stable

reboot

ثلاث طبقات للقيمة المضافة

1) صور موجهة لسيناريوهات جاهزة

بدلاً من ساعات إعداد التعريفات والأدوات، تحصل على نظام مُهيأ لغرض محدد منذ الإقلاع الأول.

2) قابلية بناء صورة شخصية قابلة للتكرار

يوفر المشروع قالبًا رسميًا image template يمكّنك من:

• تعديل Containerfile
• بناء صورتك الخاصة
• نشرها إلى GHCR عبر GitHub Actions
• بل وحتى توليد ISO مخصص باستخدام bootc image builder

أي أنك لا تعدّل نظاماً قائماً فحسب، بل تبني نظامك كمنتج قابل لإعادة الإنتاج.

3) تقليل الاحتكاك اليومي

توفر صور Universal Blue أوامر مختصرة عبر ujust (وصفات justfile) تجعل المهام الشائعة أقرب إلى أوامر بشرية بسيطة، مثل:

ujust update
ujust install-gaming-tools

بدلاً من التنقل بين وثائق وأوامر متعددة.

ماذا يبقى ثابتاً؟

رغم كل التخصيصات، تبقى مزايا Fedora Atomic كما هي:

• تحديث ذرّي كوحدة واحدة
• إمكانية الرجوع الفوري (rpm ostree rollback
• /usr للقراءة فقط
• التطبيقات عبر Flatpak
• بيئات التطوير المعزولة عبر Distrobox

أي أن Universal Blue لا يكسر النموذج الذرّي، بل يستثمره ويوسّعه. وإذا كان Silverblue يمثل النظام الذرّي النقي، فإن Universal Blue هو الذرّية حين تلبس شخصية عملية:

Fedora Atomic كنظام مُنتَج جاهز، لا مجرد قاعدة تقنية.

الطريق المعاملاتي: openSUSE MicroOS ولقطات Btrfs

في openSUSE الفكرة تُبنى على خصائص نظام ملفات Btrfs وسلوك اللقطات. مدونة MicroOS تشرح منطق transactional-update ببساطة: لا تُحدّث النظام الجاري، بل أنشئ لقطة جديدة فارغة، نفّذ التحديث داخلها، ثم اجعلها الافتراضية وتُفعَّل بعد إعادة التشغيل. ويمكن رميها إن لم تُعجبك.

MicroOS هي الأقرب إلى توزيعة لينكس تقليدية في هذه القائمة: لا تزال تعمل وتتصرف كـ SUSE، لكنها تستخدم لقطات Btrfs لحل مشكلة الرجوع عن التحديثات.

sudo transactional-update up
sudo reboot

home/ لا يدخل في اللقطات افتراضياً حتى لا تفقد ملفاتك إذا رجعت، كما أن اللقطات تُفعَّل على الجذر فقط إذا كان أكبر من 16GB كإجراء احترازي للمساحة.

في مايو 2023 صار MicroOS Desktop GNOME اسمه openSUSE Aeon، وMicroOS Desktop Plasma اسمه Kalpa.

نموذج A/B وصور OCI: ABRoot و ShanOS

ABRoot (المستخدم في Vanilla OS) يعرّف نفسه بوضوح: يحقق لا قابلية تغيير وذرية معا. عبر التبديل بين نظامي جذر (A↔B)، وأن التحديثات تُجرى باستخدام صور OCI. معنى الرجوع هنا مختلف: لا تعود إلى لقطة Btrfs ولا إلى Deployment OSTree، بل إلى الجذر الكامل الذي كان يعمل من قبل.

(Vanilla OS):

sudo abroot status
sudo abroot rollback

ShanOS

يسير على المسار ذاته لكن بنكهة Arch: نظام A/B مع رجوع تلقائي عبر systemd-boot:

sudo shani-deploy --rollback

نموذج A/B يختصر الرجوع إلى فعل واحد: بدّل بين جذرين، وترك القاعدة دائماً في حالة قابلة للإقلاع.

خارج سطح المكتب: أنظمة متخصصة تكشف اتساع المشهد

IncusOS: نظام غير قابل للتغيير مكرّس لتشغيل Incus (مدير حاويات وآلات افتراضية حديث). Debian 13، mkosi: A/B مع أقسام موقّعة تشفيرياً، Secure Boot/TPM 2.0.

Talos Linux: يحمل منظوراً مختلفاً تماماً: الـimmutability هنا ليست الهدف بذاتها، بل نتيجة جانبية لتصميم قائم على إدارة عبر API.

Talos لا يُكمل تسلسل الإقلاع العادي لـLinux. التسلسل المعتاد:

UEFI → bootloader → kernel + initramfs → pivot to real filesystem → PID 1

أما Talos فيُشغّل نظام التشغيل بالكامل داخل initramfs عبر Unified Kernel Image (UKI). لا يوجد جذر على القرص للانتقال إليه.

Talos يُحزَّم ويُوزَّع كصورة حاوية، وله مفهوم system extensions (أيضاً كحاويات) تُركَّب فوق جذر النظام لإضافة حزم وتعريفات وخدمات. ملفات قابلة للتغيير موجودة على القرص كصور الحاويات وقسم الحالة. لكن نظام التشغيل الفعلي يعمل بشكل ثابت في الذاكرة. التغييرات لا تبقى عبر عمليات الإعادة، وعند الإقلاع يقرأ Talos الحالة التصريحية من قسم STATE ويُطبّقها.

الفرق الحقيقي على المدى البعيد: استخدام API بدلاً من SSH للترقيات والإدارة. كل التوزيعات الأخرى تعتمد systemd للخدمات، مما يُفرض قيوداً على كيفية تشغيلها ومتى. Talos يُشغّل كل شيء كحاويات، حتى خدمات النظام. مما يُتيح التبديل في الوقت الفعلي.

Talos يُثبت أن الثبات ليس دائماً فلسفة تخزين، قد يكون أسلوب إدارة.

Kairos: فكرتها مختلفة، بدلاً من بناء توزيعة من الصفر، هي تأخذ توزيعة موجودة وتُضيف إليها طبقة ثبات. Kairos تُحزّم نظام الملفات كملف img وتوزّعه كحاوية. هذا يعني أنك تبني التوزيعة في Dockerfile، لكن على القرص لديها overlay mounts مشابهة لـFlatcar. بدلاً من قسمين كاملين، تُقلع Kairos من صورة واحدة مركّبة كـloopback، والتحديثات تكتب فوق الـ img وتُحدّث Grub.

Bottlerocket (AWS): توزيعة AWS لتشغيل الحاويات. لا SSH.

postmarketOS Duranium: حين يصل الثبات إلى الهاتف

الفكرة ليست حكراً على الحواسيب. postmarketOS Duranium يطبّق المنطق ذاته على الهواتف: نواة read-only، صور كاملة قابلة للاستبدال، ورجوع تلقائي إذا فشل التحديث. etc/ يُدار عبر symlinks من usr/ بنمط copy-on-write، وإعادة الضبط تمسح القسم المشفر .

حدود النموذج

(أ) المساحة: ثمن الرجوع يُدفع من القرص

مستخدم على جهاز بـSSD سعة 128GB يشغّل Fedora Atomic Desktop: بعض Flatpak، وحاويات في Toolbx، وطبقات RPM مضافة. في كل تحديث يُنشأ Deployment جديد. الافتراضي نشران كحد أعلى، لكن مع تراكم var/، إذا امتلأ القرص فالتحديث الجديد سيتعثر. الحل:

sudo rpm-ostree cleanup --rollback
sudo rpm-ostree cleanup --pending

(ب) الأمن: الثبات لا يمنح حصانة

CVE-2024-2905 في rpm-ostree مثال موثّق على أن الثبات لا يعني الحصانة. أدّت المشكلة إلى ضبط أذونات الملفات etc/shadow/ و etc/gshadow/ بشكل خاطئ، بحيث أصبحت قابلة للقراءة من جميع المستخدمين. تصف قاعدة بيانات الثغرات الوطنية (NVD) الخلل بأنه تمكين لبتّ القراءة للجميع (world-readable bit) على /etc/shadow، وهو ملف يحتوي على بيانات حساسة لكلمات المرور.

نشرت فيدورا إعلاناً أمنياً يتضمن إصلاحاً فورياً، مع إعادة ضبط الأذونات عبر الأمر:

chmod --verbose 0000 /etc/shadow /etc/gshadow /etc/shadow- /etc/gshadow-

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

(ج) إعادة التشغيل كعادة يومية

في نماذج Deployment واللقطات، التحديث لا يكتمل إلا مع reboot. هذا ثمن الاتساق، لكنه يُغيّر عادة المستخدم الذي اعتاد تثبيت أدوات متعاقبة أثناء جلسة واحدة.

9bootc (2025–2026): اتجاه مؤسسي لا صفّارة نهاية

بعد rpm-ostree وDeployments، بدأ يظهر انتقال في اللغة والأدوات: bootc ونمط الصورة image mode. وتشير وثائق Red Hat الرسمية (RHEL 10) إلى عبارة حاسمة مفادها أن هذه المقاربة مقصود بها أن تحل محل rpm-ostree مستقبلاً.

الفكرة ببساطة: تكتب Containerfile عادياً، فيُبنى منه نظام كامل على شكل صورة قابلة للإقلاع والتحديث، كما لو كان حاوية.

لكن هناك مقايضة تقنية مهمة لا ينبغي تجاهلها: تحديثات OSTree كانت قائمة على الملفات، تُحمّل فقط الملفات التي تغيرت. هذا مشابه لآلية block-level diffs في Flatcar، لكن ربما أكثر كفاءة لأنك تُحمّل محتوى الملف لا الكتلة كاملة.

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

هذا لا يعني أن bootc خطأ. لكنه تبادل: تبسيط في الأدوات والبنية مقابل كفاءة أقل في حجم التحديثات.

Fedora CoreOS في Fedora 42 تنتقل إلى تحديثات OCI، لكن تقول بوضوح: “سنستمر في استخدام rpm-ostree، وليس bootc بعد.” . Fedora Magazine نشرت في 31 ديسمبر 2025 مقالاً عن إضافة أمر kickstart جديد في Anaconda لتثبيت صور bootc مباشرة.

bootc ليس موضة بل اتجاه مؤسسي واضح. لكنه انتقال مرحلي مع مقايضات تقنية حقيقية.

جدول مقارنة

الاختيار:

• إن كنت تريد سطح مكتب مألوفاً مع رجوع سريع وأدواتك متوفرة على Flathub:
  ابدأ من Fedora Silverblue أو Universal Blue (Bazzite للألعاب، Bluefin للتطوير). تذكّر أن تثبيت RPM على القاعدة يتطلب إعادة تشغيل.

• إن كانت علاقتك بـBtrfs جيدة وتحب الشفافية: جرّب MicroOS/Aeon.

• إن كان همّك إعادة الإنتاج، أن تقول “هذا النظام يمكن بناؤه من جديد”: NixOS مع Home Manager.

• إن أردت الروح التصريحية مع قواعد جنو GNU جرب Guix .

• إن تدير خوادم: Flatcar أو IncusOS (لـIncus تحديداً).

• bootc: رياح قادمة، لكن الانتقال تدريجي.

قال هِرقليطس: “لا شيء دائم سوى التغيير.” والسؤال لم يكن يوماً كيف نمنع التغيير، بل كيف نجعله آمناً وقابلاً للرجوع.

لا شيء من هذه الأنظمة غير قابل للتغيير بالمعنى المطلق. لكنها جميعاً تطرح إجابات مختلفة على سؤال واحد: كيف نجعل القاعدة قابلة للتوقع، ونُبقي للمستخدم حريةً لا تتحول إلى تلوث دائم؟

Flatcar تُجيب: أقسام حقيقية وdiffs على مستوى الكتل. OSTree تُجيب: شجرة ملفات كاملة تُنشر كـcommit. اما MicroOS فتُجيب: لقطة جديدة لكل تحديث. NixOS تُجيب: كل شيء من وصف، والتاريخ لا يُمحى. Talos تُجيب: لا قرص للنظام أصلاً، فقط API.

والسنوات القليلة القادمة ستطرح السؤال بشكل أكثر عملية: هل نحدّث نظام التشغيل كحاوية؟

bootc وimage mode يلمّحان إلى هذا. لكن مع ثمن: فقدان كفاءة التحديثات القائمة على الملفات. وهذا سؤال مفتوح لا إجابة نهائية مكتوبة بعد.

ملحق المصطلحات التقنية

OSTree نظام لإدارة شجرة ملفات كنُسخ مترابطة قابلة للرجوع.

rpm-ostree أداة تمزج RPM و OSTree لبناء نشرات ذرّية.

bootc أداة لتشغيل وتحديث أنظمة مبنية كصور حاويات قابلة للإقلاع.

Snapshot (لقطة) حفظ لحالة نظام الملفات في لحظة معينة.

Btrfs نظام ملفات يدعم اللقطات ونسخ عند الكتابة.

Copy-on-write لا تُنسخ البيانات إلا عند تعديلها.

Layer (طبقة) جزء متراكب من صورة حاوية.

Layering (تراكب الحزم) إضافة حزم فوق القاعدة دون إعادة بناء كاملة.

Rebase (إعادة التأسيس) الانتقال من صورة/شجرة نظام إلى أخرى.

OCI Image (صورة OCI) صيغة معيارية لصورة الحاوية.

Containerfile ملف يصف خطوات بناء صورة.

Flatpak صيغة حزم معزولة لتطبيقات سطح المكتب.

Flathub مستودع تطبيقات Flatpak.

Toolbx / Distrobox بيئات حاوية لتشغيل أدوات أو توزيعات أخرى داخل النظام.

Initramfs بيئة أولية تُحمّل قبل النظام الكامل أثناء الإقلاع.

UKI (Unified Kernel Image) صورة موحّدة تجمع النواة ومكونات الإقلاع.

PID 1 أول عملية في النظام (مدير الخدمات).

systemd-boot محمّل إقلاع بسيط.

Overlay mounts تركيب طبقة قابلة للكتابة فوق طبقة قراءة فقط.

Symlink (رابط رمزي) ملف يشير إلى مسار آخر.

Secure Boot التحقق من توقيع مكونات الإقلاع.

TPM 2.0 شريحة عتادية لتخزين الأسرار وقياس سلامة النظام.

CVE معرّف قياسي لثغرة أمنية.

NVD قاعدة بيانات الثغرات الوطنية.

اختلاف المصطلح لا يعني اختلاف الفكرة

تستخدم الأنظمة المختلفة كلمات مختلفة لوصف “حالة نظام محفوظة يمكن الرجوع إليها”:

• Deployment في OSTree / rpm-ostree
• Generation في NixOS وGuix
• Snapshot في Btrfs وopenSUSE

المفهوم العام واحد: حفظ حالة كاملة للنظام يمكن الإقلاع إليها لاحقاً.

لكن الاختلاف في الآلية:

Deployment → مبني على شجرة ملفات مُعنونة (commit)

Generation → ناتج عن إعادة بناء تصريحية

Snapshot → لقطة نظام ملفات على مستوى التخزين

الاختلاف هنا تاريخي وتقني في التنفيذ، لا مفاهيمي في الهدف.