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

لمحة موجزة عن تاريخ Linux kernel

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

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

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

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

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

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

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

لماذا انتصرت النواة أحادية الكتلة عملياً

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

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

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

lsmod | head
modinfo virtio_net | head -5

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

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

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

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

كان Linux 2.0، الذي صدر في يونيو 1996، أول kernel يدعم المعالجة المتعددة المتماثلة (SMP)، أي تشغيل أكثر من CPU واحد باستخدام kernel واحد. استخدم التنفيذ الأول قفلاً واحداً هو big kernel lock (BKL)، لذلك لم يكن يمكن إلا لمعالج واحد دخول شيفرة kernel في كل مرة. لذلك كان CPU الثاني يساعد عبء العمل الذي ينفّذ الحسابات في مساحة المستخدم، لكنه كان يساعد بدرجة محدودة جداً عبء العمل الذي يعتمد على استدعاءات النظام، لأن هذه الاستدعاءات كانت تنتظر خلف القفل نفسه.

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

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

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

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

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

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

كيف أدّى تعطل BitKeeper إلى ظهور git في أبريل 2005

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

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

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

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

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

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

كان الإصدار 2.6.32، الذي صدر في December 2009، أول ما أثبت نجاح هذا النموذج. فقد أطلقت RHEL 6 وDebian 6 وSUSE Linux Enterprise 11 SP1 وUbuntu 10.04 LTS إصدارات مبنية عليه، واستمرّت صيانة الفرع حتى February 2016، أي لأكثر من ست سنوات بعد صدوره. وذهبت Red Hat إلى أبعد من ذلك، إذ واصلت صيانة kernel المبني على 2.6.32 عبر backports الخاصة بها حتى انتهاء RHEL 6 في 2020. وكان توفير عقد كامل من الدعم مجاناً هو السبب الأساسي لوجود CentOS واستبداله بـ Rocky Linux وAlmaLinux.

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

[
  {
    "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 حتى August 2026. وسيكون أقدمها، 5.10، قد حمل الإصلاحات لمدة 6.0 سنوات عند انتهائه في Dec 2026. أما أحدثها، 6.18، فمن المتوقع أن يستمر حتى Dec 2028، أي 3.1 سنوات من الإصلاحات.

اعتبر هذه التواريخ حداً أدنى لا عقداً ملزماً. فقد امتدت توقّعات 6.6 و6.12 مرة أخرى في February 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 الخاصة بالتوزيعة، ولذلك يوضح الرقم نقطة بداية الفرع، ولا يوضح الإصلاحات الموجودة فيه. ولهذا السبب تحديداً تطلق أدوات الفحص إنذارات كاذبة عند التعامل مع kernels الخاصة بالتوزيعات إذا حكمت عليها من خلال سلسلة إصدارها.

ما الذي يختلف عليه kernel حالياً

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

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

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

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

ما الذي يعنيه هذا التاريخ بالنسبة إلى الخادم الذي تستأجره

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

FAQ

لماذا لا تزال نواة Linux تستخدم GPLv2 بدلاً من GPLv3؟

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

هل نواة Linux نواة أحادية البنية أم نواة مصغّرة؟

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

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

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

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

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

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

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