تاريخ نواة Linux: قرارات غيّرت الخوادم

ملخص موجز لتاريخ نواة Linux

يمتد تاريخ نواة Linux من الإصدار 0.01 في سبتمبر 1991 إلى سلسلة الإصدارات 7.x التي تعمل على الخوادم اليوم. قائمة الإصدارات هي الجزء الأقل أهمية. فقد حدّد عدد قليل من القرارات بنية النواة، ولا يزال لكل قرار منها أثر على خادم تستأجره هذا بعد الظهر.

تأتي التواريخ وأرقام الإصدارات المذكورة هنا من kernel.org ومن سجل الإصدارات الذي ينشره. أما الحالة الحالية، حتى أغسطس 2026، فهي كالتالي: صدر الإصدار 7.0 في 12 أبريل 2026، والإصدار 7.1 في 14 يونيو 2026، والإصدار 7.2 متاح حالياً كإصدارات مرشحة.

لماذا لا يزال اختيار GPL في عام 1992 مهماً

نُشرت النسخة 0.01 في 17 سبتمبر 1991 بموجب ترخيص كتبه Torvalds بنفسه. اشترط الترخيص توزيع الشيفرة المصدرية، وأضاف سطراً أكثر أهمية: "لا يجوز لك توزيع هذا البرنامج مقابل رسوم، ولا حتى مقابل تكاليف «المعالجة»." في عام 1991، كانت البرمجيات تُوزَّع على الأقراص المرنة، وكان نسخ الأقراص المرنة وإرسالها بالبريد يكلّف مالاً. جعل هذا الشرط توزيع Linux تجارياً مستحيلاً.

غيّر Torvalds ذلك. أُعلن الانتقال إلى GNU General Public License (GPL) في ملاحظات إصدار 0.12 في يناير 1992، ودخل حيّز التنفيذ في 1 فبراير 1992. وكانت النسخة 0.95، في مارس 1992، أول إصدار يُنشر بموجبها. وكل نشاط تجاري بُني لاحقاً على Linux يعتمد على ذلك التغيير.

النواة مرخّصة بموجب GPL version 2 فقط، ولم تنتقل قط إلى version 3. رفض Torvalds ذلك في عام 2007، وكان السبب الرئيسي هو قاعدة مكافحة تقييد الأجهزة في GPLv3، التي تشترط أن يقبل الجهاز الذي يشغّل شيفرة GPL نسخة معدّلة من تلك الشيفرة أيضاً. اعتبر أن الأجهزة المقفلة شأن تجاري خاص بالشركة المصنّعة. في عام 2017، نشر مطوّرو النواة بيان إنفاذ النواة (Kernel Enforcement Statement)، واستعاروا منه مع ذلك جزءاً واحداً من GPLv3: من يصلح مخالفة بعد إبلاغه بها يحتفظ بترخيصه، بدلاً من فقدانه نهائياً عند أول خرق.

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

سبب انتشار النواة الأحادية عملياً

في 29 January 1992، نشر Andrew Tanenbaum رسالة بعنوان "LINUX is obsolete" في مجموعة الأخبار comp.os.minix. طرح ادعاءين. كانت النوى الأحادية، حيث تعمل التعريفات وأنظمة الملفات داخل مساحة عناوين واحدة ذات امتيازات كاملة، من تصاميم سبعينيات القرن الماضي، بينما كانت النوى المصغّرة، حيث تعمل هذه المكونات كعمليات عادية، هي المستقبل. كما أن Linux كان مرتبطاً بمعالج Intel 386، ولذلك لن ينتقل إلى منصات أخرى.

جاء الرد على ادعاء قابلية النقل عبر نقل النظام إلى منصات أخرى. أضاف الإصدار 1.2 في March 1995 دعم Alpha وSPARC وMIPS. وأضاف الإصدار 2.0 في June 1996 دعماً لمعمارية Alpha ذات 64-bit.

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

lsmod | head
modinfo virtio_net | head -5

يعرض lsmod ما هو محمّل حالياً. ويطبع modinfo الملف الذي جاءت منه الوحدة والمعلمات التي تقبلها. في الخادم الافتراضي، يعتمد معظم مسار القرص والشبكة على الوحدات، ولذلك تقلع صورة نواة واحدة على عتاد لم تتعامل معه من قبل.

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

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

لماذا استغرق دعم SMP خمسة عشر عاماً

كان Linux 2.0، الذي صدر في يونيو 1996، أول نواة تدعم المعالجة المتعددة المتماثلة (SMP)، أي تشغيل أكثر من CPU واحد باستخدام نواة واحدة. استخدم التنفيذ الأول قفلاً واحداً، وهو القفل الكبير للنواة (BKL)، لذلك لم يكن يمكن إلا لمعالج واحد دخول شيفرة النواة في كل مرة. لذلك كان CPU إضافي مفيداً لحِمل العمل الذي يجري حساباته في مساحة المستخدم، لكنه كان قليل الفائدة جداً لحِمل عمل يعتمد على system calls، لأن هذه الطلبات كانت تصطف خلف القفل نفسه.

استغرق إزالة ذلك القفل خمسة عشر عاماً. حُوِّل ما تبقى من المستخدمين إلى استخدام أقفال دقيقة النطاق، ويرجع الفضل في ذلك بدرجة كبيرة إلى Arnd Bergmann، ثم حُذف BKL في الإصدار 2.6.39، الذي صدر في 18 مايو 2011. وتطور scheduler على الوتيرة البطيئة نفسها: scheduler ‏O(1) في 2.6.0، ثم Completely Fair Scheduler ‏(CFS) بدءاً من 2.6.23 في 2007، ثم EEVDF، الذي حل محل CFS في 6.6 في أكتوبر 2023.

لهذا أصبح اختيار خطة تحتوي على 4 vCPU أمراً عادياً الآن. لكنه يوضح أيضاً حداً ينبغي معرفته. في الخادم الافتراضي المشترك، تعمل نواتك على جدولة مؤشرات التنفيذ، بينما يعمل hypervisor على جدولة نواتك. شغّل top واقرأ الحقل %st. وقت السرقة هو وقت CPU كانت نواتك مستعدة لاستخدامه، لكن المضيف منحه لضيف آخر؛ لذلك لا يمكن لأي ضبط داخل نواتك استعادته.

كيف غيّرت السلسلة 2.6 طريقة بناء النواة

قبل 2.6، كانت أرقام الإصدارات تأتي في أزواج. كان الرقم الثاني الزوجي يعني سلسلة مستقرة، مثل 2.4، بينما كان الرقم الفردي يعني سلسلة تطوير، مثل 2.5. صدر 2.4 في 4 January 2001، وصدر 2.6 في 17 December 2003، لذلك انتظر المستخدمون نحو ثلاث سنوات للسلسلة المستقرة التالية. لم تستطع التوزيعات الانتظار، لذلك أجرت backport للتغييرات. وكان بائعان يوزعان الإصدار "2.4" يشحنان نواتين تفصل بينهما آلاف الرقع.

أُسقط هذا الفصل بعد 2.6. تفتح السلسلة الرئيسية الآن نافذة دمج تستمر نحو أسبوعين، وتستقبل الأعمال الجديدة، ثم تشغّل إصدارات مرشحة حتى تستقر التغييرات، وتصدر إصداراً كل 9 إلى 10 أسابيع، وفق الوتيرة التي لا يزال kernel.org يوثقها. وصل النصف الآخر من النموذج في 4 March 2005 مع أول إصدار من الشجرة المستقرة، وكان تحديثاً يقتصر على الإصلاحات للإصدار 2.6.11، ويتولى صيانته Greg Kroah-Hartman وChris Wright. تقبل الشجرة المستقرة الإصلاحات وترفض الميزات الجديدة.

وكان من آثار ذلك أن رقم الإصدار لم يعد وعداً. فالإصدارات 3.0 و4.0 و5.0 و7.0 ليست عمليات إعادة كتابة. يرفع Torvalds الرقم الأول عندما يكبر الرقم الثاني بما يكفي لإزعاجه، ولهذا جاء 7.0 بعد 6.19 في April 2026. ما يهم الخادم هو الفرع الذي تتبعه توزيعتك، وما إذا كان هذا الفرع لا يزال يتلقى الإصلاحات.

كيف أدّت أزمة BitKeeper إلى ظهور git في April 2005

من February 2002، طُوِّرت النواة باستخدام BitKeeper، وهو نظام احتكاري موزّع للتحكم في الإصدارات من شركة BitMover التابعة لـ Larry McVoy، بدءاً من السلسلة 2.5. منحت BitMover مطوّري النواة ترخيصاً مجانياً بشروط: لا يجوز لك العمل على أداة منافسة للتحكم في الإصدارات، ولا يجوز لك إجراء هندسة عكسية لـ BitKeeper. لم يعجب كثيراً من المطوّرين بناء نواة حرة باستخدام أداة لم يُسمح لهم بقراءة شيفرتها.

انهار ذلك في April 2005، بعدما عرض Andrew Tridgell برنامجاً يتخاطب مع مستودعات BitKeeper. اعتبرت BitMover ذلك هندسة عكسية، وسحبت الترخيص المجاني. فقدت النواة نظام التحكم في إصداراتها في منتصف دورة تطوير.

بدأ العمل على git في 3 April 2005. أعلن Torvalds عنه في 6 April. وفي 7 April أصبح git مستضيفاً لنفسه، أي إن سجل git نفسه أصبح محفوظاً في git. نُفّذت أول عملية دمج لعدة فروع في 18 April. في June 2005، تولّى git إدارة إصدار 2.6.12. سلّم Torvalds الصيانة إلى Junio Hamano بعد ذلك بوقت قصير، وعاد إلى النواة.

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

ما الذي يَعِد به نموذج LTS وما الذي لا يَعِد به

الإصدار Mainline ليس الإصدار الذي تشغّله. يُستبدل إصدار Mainline بإصدار أحدث بعد 9 إلى 10 أسابيع. وتحتفظ شجرة stable بالإصلاحات لبضعة أسابيع بعد كل إصدار. أما الفروع طويلة الأمد، التي يُشار إليها عادةً باسم LTS، فتحتفظ بها لسنوات، وهي الفروع التي تبني عليها التوزيعات إصداراتها.

كان الإصدار 2.6.32، الذي صدر في ديسمبر 2009، أول اختبار ناجح لهذا النموذج. فقد أطلقته RHEL 6 وDebian 6 وSUSE Linux Enterprise 11 SP1 وUbuntu 10.04 LTS، واستمرت صيانة الفرع حتى فبراير 2016، أي لأكثر من ست سنوات بعد صدوره.

تغيّرت مدة الدعم الموعودة أكثر من مرة. كانت سنتين، ثم أصبحت ست سنوات لبعض الفروع. وفي 2023 أعاد مشرفو stable المدة الافتراضية إلى سنتين، لأن نقل الإصلاحات إلى الأشجار القديمة يستهلك وقت المشرفين، ولأن الفروع القديمة تخضع لاختبارات فعلية أقل. وفي 25 فبراير 2026 نشر Greg Kroah-Hartman توقعات بمدد أطول مرة أخرى، بعد مناقشات مع الشركات التي تعتمد على هذه الفروع، وأصبح الإطار الحالي يتراوح بين ثلاث وست سنوات.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

يسرد kernel.org عدد 6 من فروع longterm حتى أغسطس 2026. أقدمها، 5.10، سيكون قد احتفظ بالإصلاحات لمدة 6.0 سنوات عند انتهاء دعمه في Dec 2026. أما أحدثها، 6.18، فمن المتوقع أن تستمر صيانته حتى Dec 2028، أي 3.1 سنوات من الإصلاحات.

تعامل مع هذه التواريخ باعتبارها حداً أدنى لا عقداً ملزماً. فقد امتدت التوقعات الخاصة بالإصدارين 6.6 و6.12 في فبراير 2026، لكن يمكن إسقاط فرع لا يستخدمه أحد بدلاً من ذلك. تختار التوزيعة عادةً الإصدار نيابةً عنك: يأتي Debian 13 مع الإصدار 6.12، ويأتي Ubuntu 26.04 LTS مع الإصدار 7.0. يتضح المحتوى العملي لهذا الفرق في مسألة استخدام LTS بدلاً من الإصدار المرحلي على الخادم، وهو ما يتغير فعلياً في النظام عند ترقية Ubuntu 24.04 إلى 26.04.

ينتج عن ذلك فخ واحد. يطبع uname -r على Ubuntu 24.04 قيمة مثل 6.8.0-51-generic. هذه القيمة تمثل قاعدة upstream مضافاً إليها backports الخاصة بالتوزيعة، لذلك يوضح الرقم نقطة بدء الفرع، ولا يوضح الإصلاحات الموجودة فيه. ترفع أدوات الفحص التي تقيّم kernel وفق سلسلة إصداره تنبيهات كاذبة بشأن kernels الخاصة بالتوزيعات لهذا السبب تحديداً.

ما الذي يناقشه kernel حالياً

هناك نقاشان جاريان، وكلاهما يتعلق بمن ينفّذ العمل.

أصبح Rust جزءاً من البنية التحتية في الإصدار 6.1 في ديسمبر 2022. وفي الإصدار 7.0 أزيلت عنه صفة التجريبية، لذلك أصبحت اللغات الأساسية في kernel هي C وassembly وRust، ولم يعد البناء يحتاج إلى nightly compiler. يدور الخلاف حول الصيانة. يمكن لمشرف على C يغيّر واجهة أن يكسر روابط Rust التي لا يراجعها، والخلاف هو حول الجهة المسؤولة عن إصلاحها.

يتعلق النقاش الثاني بمساهمات الذكاء الاصطناعي. اقترح Sasha Levin سياسة في يوليو 2025، بعد أن بدأت أعداد متزايدة من الرقع المُنشأة بمساعدة الآلات بالوصول إلى القوائم البريدية. أُدرجت الوثيقة في 23 ديسمبر 2025، وأصبحت الآن ضمن وثائق إجراءات kernel في docs.kernel.org/process/coding-assistants.html. يجب ألا يضيف وكيل ذكاء اصطناعي وسم Signed-off-by، لأن هذا السطر يشهد على شهادة منشأ المطوّر (DCO)، ولا يمكن إلا لشخص أن يشهد عليها. يُعلن عن استخدام المساعدة بوسم Assisted-by:، بعد تغييره من Co-developed-by: أثناء المراجعة لأن الأداة ليست مؤلفاً. يجب أن تكون الشفرة المُنشأة متوافقة مع GPL-2.0-only. يراجع الشخص الذي يرسل الرقعة هذه الرقعة ويتحمل مسؤوليتها.

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

ما الذي يعنيه هذا التاريخ للخادم الذي تستأجره

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

FAQ

لماذا لا يزال Linux kernel خاضعاً لـ GPLv2 وليس GPLv3؟

رفض Torvalds اعتماد GPLv3 في 2007، وكان السبب الرئيسي هو شرطها المناهض لـtivoisation، الذي يُلزم الجهاز الذي يشحن برمجيات خاضعة لـGPL بقبول نسخة معدّلة من تلك البرمجيات أيضاً. وهو يعتبر العتاد المقفلاً جزءاً من نشاط الشركة المصنّعة. كما أن إعادة الترخيص شبه مستحيلة عملياً، لأن حقوق الطبع والنشر في kernel يملكها آلاف المساهمين، ولا يوجد اتفاق تنازل يمكن الرجوع إليه. يخضع kernel للترخيص GPL-2.0-only، لذلك لا يمكن دمج الشيفرة المتاحة بموجب GPLv3 فقط.

هل Linux kernel أحادي النواة أم microkernel؟

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

ما الفرق بين mainline وstable وlongterm kernels؟

يمثل mainline شجرة Torvalds، ويصدر كل 9 إلى 10 أسابيع، وتصل الميزات الجديدة إليه أولاً. يأخذ stable أحدث إصدار من mainline، ويتلقى إصلاحات الأخطاء لبضعة أسابيع. وتستمر فروع longterm في تلقي الإصلاحات لسنوات، وهي الفروع التي تبني التوزيعات kernels الخاصة بها عليها. يعرض kernel.org فروع longterm الحالية مع تاريخ متوقّع لنهاية الدعم لكل فرع.

هل يقبل Linux kernel شيفرة كتبها الذكاء الاصطناعي؟

نعم، بموجب سياسة اعتُمدت في December 2025. يجب ذكر الأداة في وسم Assisted-by:، ويُمنع وكيل الذكاء الاصطناعي من إضافة سطر Signed-off-by، كما يجب أن تكون الشيفرة المولّدة متوافقة مع GPL-2.0-only. يوقّع المرسل البشري على التغيير، ما يعني أنه راجع التصحيح ويتحمّل مسؤوليته بموجب Developer Certificate of Origin.

ما إصدار kernel الذي ينبغي أن أشغّله على خادم؟

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