تاریخچه هسته لینوکس: تصمیمات کلیدی از 0.01 تا 7.x

نسخه کوتاه تاریخچه هسته لینوکس

تاریخچه هسته لینوکس از نسخه 0.01 در سپتامبر 1991 تا سری 7.x که امروزه روی سرورها اجرا می‌شود، ادامه دارد. فهرست انتشارها کم‌اهمیت‌ترین بخش این تاریخچه است. تعداد کمی از تصمیمات، ساختار کلی آن را شکل دادند و هر کدام هنوز بر ماشینی که امروز اجاره می‌کنید، تأثیرگذار است.

تاریخ‌ها و شماره نسخه‌های ذکر شده در اینجا از kernel.org و تاریخچه انتشاری که این وب‌سایت منتشر می‌کند، استخراج شده‌اند. وضعیت فعلی تا اوت 2026 به این شرح است: نسخه 7.0 در 12 آوریل 2026، نسخه 7.1 در 14 ژوئن 2026 منتشر شدند و نسخه 7.2 در مرحله release candidate قرار دارد.

چرا انتخاب GPL در سال 1992 همچنان اهمیت دارد

نسخه 0.01 در تاریخ 17 سپتامبر 1991 تحت مجوزی منتشر شد که خود توروالدز نوشته بود. این مجوز مستلزم توزیع سورس‌کد بود و یک بند مهم‌تر نیز به آن اضافه شده بود: «شما اجازه ندارید این نرم‌افزار را در ازای دریافت هزینه توزیع کنید، حتی برای هزینه‌های جانبی.» در سال 1991، نرم‌افزارها روی فلاپی‌دیسک عرضه می‌شدند و کپی و پست کردن فلاپی‌دیسک هزینه داشت. آن بند، ایجاد یک توزیع تجاری لینوکس را غیرممکن می‌کرد.

او این وضعیت را تغییر داد. انتقال به مجوز عمومی همگانی گنو (GPL) در یادداشت‌های انتشار نسخه 0.12 در ژانویه 1992 اعلام شد و از 1 فوریه 1992 به اجرا درآمد. نسخه 0.95 در مارس 1992، اولین نسخه‌ای بود که تحت این مجوز منتشر شد. تمام کسب‌وکارهایی که بعدها بر پایه لینوکس بنا شدند، بر پایه همین تغییر استوار هستند.

کرنل فقط تحت نسخه 2 مجوز GPL است و هرگز به نسخه 3 منتقل نشد. توروالدز در سال 2007 با این کار مخالفت کرد که دلیل اصلی آن، قانون ضد-tivoisation در GPLv3 بود؛ قانونی که ایجاب می‌کند دستگاهی که کد GPL را عرضه می‌کند، باید نسخه اصلاح‌شده همان کد را نیز بپذیرد. او سخت‌افزارهای قفل‌شده را موضوعی مربوط به خودِ تولیدکننده می‌دانست. در سال 2017، توسعه‌دهندگان کرنل «بیانیه اجرای کرنل» (Kernel Enforcement Statement) را منتشر کردند که بخشی از GPLv3 را وام می‌گیرد: کسی که پس از اطلاع از نقض مجوز، آن را اصلاح کند، مجوز خود را حفظ می‌کند و برخلاف گذشته، در همان اولین تخلف، مجوزش را برای همیشه از دست نمی‌دهد.

این موضوع دو پیامد برای سرور دارد. باینری کرنلی که بوت می‌کنید، حق دسترسی به سورس‌کد منطبق با خود را به همراه دارد؛ بنابراین هیچ‌کس نمی‌تواند کرنل لینوکسی به شما بدهد که نتوانید آن را بررسی یا بازسازی کنید. همچنین، اعلامیه کپی‌رایت روی کرنل بیان می‌کند که این مجوز شامل برنامه‌های کاربری که از طریق system callهای استاندارد از سرویس‌های کرنل استفاده می‌کنند نمی‌شود؛ به همین دلیل است که دیتابیس‌های انحصاری و عوامل مانیتورینگ بدون ایجاد هیچ مشکلی برای لینوکس عرضه می‌شوند. یک مجوز آزاد (permissive) فشاری معکوس ایجاد می‌کند و درک این تفاوت پیش از انتخاب پلتفرم ضروری است: به لینوکس و FreeBSD به عنوان پلتفرم‌های سرور مراجعه کنید.

چرا هسته یکپارچه (Monolithic) در عمل پیروز شد

در تاریخ 29 ژانویه 1992، Andrew Tanenbaum پیامی با عنوان "LINUX is obsolete" در گروه خبری comp.os.minix منتشر کرد. او دو ادعا مطرح کرد. نخست اینکه هسته‌های یکپارچه، که در آن‌ها درایورها و سیستم‌های فایل در یک فضای آدرس دارای امتیاز (privileged) اجرا می‌شوند، طراحی مربوط به دهه 1970 هستند، در حالی که ریزهسته‌ها (microkernels) که این بخش‌ها را به عنوان پردازش‌های معمولی اجرا می‌کنند، آینده را می‌سازند. دوم اینکه لینوکس به معماری Intel 386 وابسته است و هرگز قابلیت انتقال (portability) نخواهد داشت.

پاسخ به ادعای قابلیت انتقال، با انجام همان پورت‌ها داده شد. نسخه 1.2 در مارس 1995 پشتیبانی از Alpha، SPARC و MIPS را اضافه کرد. نسخه 2.0 در ژوئن 1996 یک پورت 64 بیتی برای Alpha اضافه کرد.

پاسخ به ادعای طراحی، با یک مصالحه داده شد. لینوکس هرگز به یک ریزهسته تبدیل نشد. در عوض، ماژول‌های هسته قابل بارگذاری (loadable kernel modules) را دریافت کرد: فایل‌های شیء (object files) که می‌توانید به یک هسته در حال اجرا تزریق کرده و دوباره حذف کنید، بنابراین یک درایور به‌صورت جدا از باینری هسته عرضه (ship) می‌شود.

lsmod | head
modinfo virtio_net | head -5

lsmod فهرستی از آنچه در حال حاضر بارگذاری شده است را نمایش می‌دهد. modinfo فایلی که ماژول از آن آمده و پارامترهایی که می‌پذیرد را چاپ می‌کند. در یک سرور مجازی، بخش بزرگی از مسیر دیسک و شبکه از ماژول‌ها تشکیل شده است، به همین دلیل است که یک ایمیج هسته روی سخت‌افزاری که هرگز آن را ندیده است، بوت می‌شود.

ماژول‌ها این انعطاف‌پذیری را بدون هزینه‌ای که طراحی ریزهسته به همراه داشت، فراهم کردند. ایزوله کردن یک درایور در پردازش اختصاصی خود به معنای پرداخت هزینه برای context switch و ارسال پیام در هر فراخوانی است، و در سال 1992 این هزینه بسیار زیاد بود.

هزینه‌ای که لینوکس حفظ کرد، همان چیزی است که باید برای آن برنامه‌ریزی کرد: یک ماژول با امتیازات کامل هسته اجرا می‌شود، بنابراین یک ماژول معیوب به جای از کار انداختن یک پردازش، کل ماشین را از دسترس خارج می‌کند. ماژول‌های خارج از درخت اصلی (out-of-tree) جایی هستند که این مشکل بروز می‌کند. درایور یک فروشنده که در خط اصلی (mainline) نیست، باید با هر هسته جدید دوباره ساخته شود؛ این همان کاری است که DKMS در طول ارتقا انجام می‌دهد، و زمانی که این فرآیند ساخت با شکست مواجه شود، دستگاه پس از reboot به سادگی در دسترس نخواهد بود.

چرا تکمیل SMP پانزده سال طول کشید

هسته Linux 2.0 در ژوئن 1996 اولین نسخه‌ای بود که از پردازش متقارن (SMP) پشتیبانی می‌کرد؛ به این معنی که بیش از یک CPU می‌توانست یک هسته را اجرا کند. پیاده‌سازی اولیه از یک قفل واحد به نام big kernel lock (BKL) استفاده می‌کرد، بنابراین در هر لحظه تنها یک پردازنده می‌توانست در کد هسته حضور داشته باشد. در نتیجه، CPU دوم تنها به بارهایی که در فضای کاربر (user space) محاسبه می‌شدند کمک می‌کرد و برای بارهای کاری مبتنی بر system call تأثیر بسیار کمی داشت، زیرا این درخواست‌ها پشت همان قفل واحد در صف می‌ماندند.

حذف آن قفل پانزده سال زمان برد. کاربران باقی‌مانده به استفاده از قفل‌های با دانه‌بندی ریز (fine-grained locking) روی آوردند که بخش عمده این کار توسط Arnd Bergmann انجام شد و در نهایت BKL در نسخه 2.6.39 که در 18 مه 2011 منتشر شد، حذف گردید. زمان‌بند (scheduler) نیز با همین سرعتِ پایین تکامل یافت: زمان‌بند O(1) در نسخه 2.6.0، زمان‌بند Completely Fair Scheduler (CFS) از نسخه 2.6.23 در سال 2007، و در نهایت EEVDF که در نسخه 6.6 در اکتبر 2023 جایگزین CFS شد.

این تلاش‌ها دلیلی است که امروزه داشتن یک پلن با 4 vCPU موضوعی عادی محسوب می‌شود. این موضوع همچنین نشان‌دهنده محدودیتی است که باید از آن آگاه باشید. در یک سرور مجازی اشتراکی، هسته شما تردها را زمان‌بندی می‌کند و هایپروایزر (hypervisor) هسته شما را زمان‌بندی می‌کند. دستور top را اجرا کنید و فیلد %st را بخوانید. Steal time به معنای زمانی از CPU است که هسته شما آماده استفاده از آن بوده، اما میزبان آن را به مهمان دیگری اختصاص داده است؛ بنابراین هیچ تنظیماتی در داخل هسته شما نمی‌تواند آن را بازیابی کند.

چرا سری 2.6 نحوه ساخت هسته را تغییر داد

پیش از نسخه 2.6، شماره نسخه‌ها به‌صورت جفت ارائه می‌شدند. عدد دوم زوج به معنای سری پایدار (2.4) و عدد فرد به معنای نسخه توسعه (2.5) بود. نسخه 2.4 در 4 ژانویه 2001 و نسخه 2.6 در 17 دسامبر 2003 منتشر شد، بنابراین کاربران نزدیک به سه سال برای سری پایدار بعدی منتظر ماندند. توزیع‌ها نمی‌توانستند صبر کنند، بنابراین اقدام به backport کردن کردند. دو توزیع‌کننده که هر دو نسخه "2.4" را ارائه می‌دادند، هسته‌هایی با هزاران وصله (patch) متفاوت داشتند.

این تفکیک پس از نسخه 2.6 کنار گذاشته شد. خط اصلی توسعه (Mainline) اکنون یک پنجره ادغام (merge window) حدوداً دو هفته‌ای باز می‌کند، کارهای جدید را می‌پذیرد، سپس تا زمان آرام شدن روند، نامزدهای انتشار (release candidate) ارائه می‌دهد و هر 9 تا 10 هفته یک نسخه منتشر می‌کند؛ زمان‌بندی‌ای که kernel.org همچنان آن را مستند می‌کند. نیمه دیگر این مدل در 4 مارس 2005 با اولین انتشار شاخه پایدار (stable tree) محقق شد؛ یک به‌روزرسانی صرفاً برای رفع اشکال در نسخه 2.6.11 که توسط Greg Kroah-Hartman و Chris Wright نگهداری می‌شد. شاخه پایدار فقط اصلاحات را می‌پذیرد و از پذیرش قابلیت‌های جدید خودداری می‌کند.

یک اثر جانبی این بود که شماره نسخه دیگر یک وعده محسوب نمی‌شد. نسخه‌های 3.0، 4.0، 5.0 و 7.0 بازنویسی کامل نیستند. Torvalds زمانی که عدد دوم به اندازه کافی بزرگ شود که او را آزار دهد، عدد اول را افزایش می‌دهد؛ به همین دلیل است که نسخه 7.0 در آوریل 2026 پس از نسخه 6.19 منتشر شد. آنچه برای یک سرور اهمیت دارد این است که توزیع شما کدام شاخه را دنبال می‌کند و آیا آن شاخه همچنان اصلاحات را دریافت می‌کند یا خیر.

چگونه وقفه در BitKeeper منجر به ایجاد git در آوریل 2005 شد

از فوریه 2002، هسته لینوکس با استفاده از BitKeeper توسعه می‌یافت؛ یک سیستم کنترل نسخه توزیع‌شده و انحصاری از شرکت BitMover متعلق به Larry McVoy که از سری 2.5 آغاز شد. شرکت BitMover به توسعه‌دهندگان هسته یک مجوز رایگان با شرایط خاص اعطا کرد: شما اجازه نداشتید روی ابزار کنترل نسخه رقیب کار کنید و اجازه مهندسی معکوس BitKeeper را نداشتید. بسیاری از توسعه‌دهندگان از ساخت یک هسته آزاد با ابزاری که اجازه بررسی کدهای آن را نداشتند، ناراضی بودند.

این همکاری در آوریل 2005 از هم پاشید، پس از آنکه Andrew Tridgell برنامه‌ای را نمایش داد که با مخازن BitKeeper ارتباط برقرار می‌کرد. BitMover این کار را مهندسی معکوس نامید و مجوز رایگان را لغو کرد. هسته لینوکس در میانه چرخه توسعه، سیستم کنترل نسخه خود را از دست داد.

کار روی git در 3 آوریل 2005 آغاز شد. Torvalds در 6 آوریل آن را معرفی کرد. در 7 آوریل، git به مرحله self-hosting رسید، به این معنی که تاریخچه خودِ git در حال حاضر در خودِ git نگهداری می‌شد. اولین ادغام (merge) چندین شاخه در 18 آوریل انجام شد. در ژوئن 2005، git مدیریت انتشار نسخه 2.6.12 را بر عهده گرفت. Torvalds مدت کوتاهی پس از آن، نگهداری پروژه را به Junio Hamano سپرد و به کار روی هسته بازگشت.

طراحی git مستقیماً از دل همین مشکل بیرون آمد: هزاران مشارکت‌کننده و نگهداری که از طریق شبکه‌ای که هیچ‌کس به آن اعتماد نداشت، تغییرات یکدیگر را دریافت (pull) می‌کردند. هر شیء با هش محتوای خود نام‌گذاری می‌شود، بنابراین تغییر حتی یک بایت از تاریخچه قدیمی، نام تمام commitهای پس از آن را تغییر می‌دهد. به همین دلیل است که یک clone از مخزن، یک مدرک است نه صرفاً یک ادعا. هر خط لوله استقرار (deploy pipeline)، هر مخزن پیکربندی، میزبانی کدی که اکثر تیم‌ها کدهای خود را به آن push می‌کنند و سرور git که می‌توانید خودتان اجرا کنید، همگی از دل یک بحث حقوقی بر سر مجوز یک هسته متولد شدند.

وعده‌های مدل LTS و آنچه شامل آن نمی‌شود

نسخه Mainline برای اجرا در محیط عملیاتی مناسب نیست. هر نسخه Mainline پس از 9 تا 10 هفته با نسخه جدیدتر جایگزین می‌شود. شاخه Stable تنها برای چند هفته پس از هر انتشار، اصلاحات را دریافت می‌کند. شاخه‌های Longterm که معمولاً با نام LTS شناخته می‌شوند، این اصلاحات را برای سال‌ها دریافت می‌کنند و توزیع‌های لینوکسی بر پایه همین شاخه‌ها ساخته می‌شوند.

نسخه 2.6.32 که در دسامبر 2009 منتشر شد، نقطه‌ای بود که این مدل کارایی خود را اثبات کرد. توزیع‌های RHEL 6، Debian 6، SUSE Linux Enterprise 11 SP1 و Ubuntu 10.04 LTS همگی از این نسخه استفاده کردند و این شاخه تا فوریه 2016، یعنی بیش از شش سال پس از انتشار اولیه، پشتیبانی شد.

این وعده بیش از یک بار تغییر کرده است. ابتدا دو سال بود و سپس برای برخی شاخه‌ها به شش سال رسید. در سال 2023، نگهدارندگان نسخه Stable بازه پیش‌فرض را به دو سال کاهش دادند، زیرا backport کردن اصلاحات به شاخه‌های قدیمی وقت‌گیر است و شاخه‌های قدیمی عملاً تست کمی دریافت می‌کنند. در 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 تا اوت 2026، تعداد 6 شاخه Longterm را فهرست کرده است. قدیمی‌ترین آن‌ها یعنی 5.10، تا زمان پایان پشتیبانی در Dec 2026، به مدت 6.0 سال اصلاحات دریافت کرده است. جدیدترین آن‌ها یعنی 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 به همراه backportهای اختصاصی توزیع است؛ بنابراین این شماره فقط نشان می‌دهد که شاخه از کجا شروع شده است و مشخص نمی‌کند دقیقاً چه اصلاحاتی در آن اعمال شده است. ابزارهای اسکن که کرنل را صرفاً بر اساس رشته نسخه قضاوت می‌کنند، دقیقاً به همین دلیل هشدارهای اشتباه (false alarm) برای کرنل‌های توزیع‌ها صادر می‌کنند.

موضوعات مورد بحث فعلی در هسته (Kernel)

دو بحث در جریان است و هر دو درباره این است که چه کسی باید کار را انجام دهد.

زبان Rust در دسامبر 2022 به عنوان زیرساخت در نسخه 6.1 وارد شد. در نسخه 7.0 برچسب آزمایشی از روی آن برداشته شد، بنابراین زبان‌های اصلی هسته اکنون C، اسمبلی و Rust هستند و فرآیند ساخت دیگر نیازی به کامپایلر nightly ندارد. اختلاف فعلی بر سر نگهداری است. یک نگهدارنده (maintainer) زبان C که یک رابط (interface) را تغییر می‌دهد، ممکن است باعث خرابی بایندینگ‌های Rust شود که آن‌ها را مطالعه نمی‌کند؛ بحث بر سر این است که وظیفه اصلاح آن‌ها بر عهده کیست.

بحث دوم مربوط به مشارکت هوش مصنوعی است. Sasha Levin در ژوئیه 2025 و پس از افزایش حجم وصله‌های (patch) تولیدشده با کمک ماشین در لیست‌های پستی، سیاستی را پیشنهاد کرد. این سند در 23 دسامبر 2025 ثبت شد و اکنون در مستندات فرآیند خودِ هسته در docs.kernel.org/process/coding-assistants.html قرار دارد. یک عامل هوش مصنوعی نباید تگ Signed-off-by را اضافه کند، زیرا آن خط گواهی‌نامه مبدأ توسعه‌دهنده (DCO) را تأیید می‌کند و فقط یک انسان می‌تواند آن را تأیید نماید. استفاده از کمک هوش مصنوعی با تگ Assisted-by: اعلام می‌شود که در طول بازبینی از Co-developed-by: به این شکل تغییر یافت، زیرا یک ابزار، نویسنده محسوب نمی‌شود. کد تولیدشده باید با GPL-2.0-only سازگار باشد. انسانی که وصله را ارسال می‌کند، آن را بازبینی کرده و مسئولیت آن را بر عهده می‌گیرد.

فشار پشت این سیاست، زمان بازبینی است. تولید یک وصله چند ثانیه طول می‌کشد، اما بازبینی آن یک بعدازظهر از وقت یک نگهدارنده را می‌گیرد. یک تگ این عدم تعادل را برطرف نمی‌کند. آنچه این سیاست حفظ می‌کند، اصالت (provenance) است: تاریخچه همچنان ثبت می‌کند که چه کسی هر تغییر را امضا کرده است؛ این همان ویژگی‌ای است که DCO در سال 2004 برای محافظت از آن معرفی شد.

این تاریخچه برای سروری که اجاره می‌کنید چه معنایی دارد

• مجوز (licence) دلیلی است که به شما اجازه می‌دهد هسته‌ای (kernel) را که ارائه‌دهنده بوت می‌کند بخوانید و بازسازی کنید، و همچنین دلیل اجرای نرم‌افزارهای انحصاری روی آن است.
• طراحی یکپارچه (monolithic) دلیلی است که یک باگ در درایور باعث ریبوت شدن کل ماشین می‌شود و چرا یک ماژول خارج از درخت (out-of-tree) باید در هر ارتقای هسته بازسازی شود.
• مدل انتشار (release model) دلیلی است که شماره نسخه اطلاعات کمی به شما می‌دهد، در حالی که شاخه (branch) و تاریخ پایان پشتیبانی (end-of-life) آن تقریباً همه چیز را مشخص می‌کند.
• نوع مجازی‌سازی تعیین می‌کند که اصلاً چه کارهایی می‌توانید انجام دهید: در KVM شما هسته خود را بوت می‌کنید و ماژول‌ها را بارگذاری می‌کنید، در حالی که در مجازی‌سازی کانتینری که هسته میزبان را به اشتراک می‌گذارد، uname -r نسخه میزبان را نشان می‌دهد، modprobe با خطا مواجه می‌شود و چندین sysctl فقط‌خواندنی هستند.

FAQ

چرا هسته لینوکس همچنان تحت مجوز GPLv2 است و نه GPLv3؟

لینوس توروالدز در سال 2007 با GPLv3 مخالفت کرد؛ دلیل اصلی این تصمیم، شرط ضد-tivoization در آن بود که دستگاه‌های حاوی کد GPL را مجبور می‌کند نسخه‌های تغییریافتهٔ آن کد را نیز بپذیرند. او سخت‌افزارهای قفل‌شده را موضوعی مربوط به تولیدکننده می‌داند. از نظر عملی نیز تغییر مجوز تقریباً غیرممکن است، زیرا حق تکثیر هسته در اختیار هزاران مشارکت‌کننده است و هیچ توافق‌نامهٔ واگذاری حق کپی‌رایتی وجود ندارد که بتوان به آن استناد کرد. هسته فقط تحت مجوز GPL-2.0 است، بنابراین کدی که صرفاً تحت GPLv3 ارائه شود، قابل ادغام نیست.

آیا هسته لینوکس یک هسته یکپارچه (Monolithic) است یا ریزهسته (Microkernel)؟

یکپارچه است، با قابلیت بارگذاری ماژول‌ها. درایورها و سیستم‌های فایل در فضای آدرس هسته اجرا می‌شوند و lsmod مواردی را که در حال حاضر بارگذاری شده‌اند نشان می‌دهد. نتیجهٔ این ساختار، سرعت بالا از یک سو و دامنهٔ خرابی گسترده از سوی دیگر است: یک ماژول معیوب می‌تواند کل سیستم را دچار kernel panic کند، در حالی که در یک ریزهسته، تنها یک پردازش از دست می‌رفت. این وضعیت از سال 1992 با معرفی سیستم‌های فایل FUSE در فضای کاربری و برنامه‌های eBPF که هسته پیش از اجرا آن‌ها را تأیید می‌کند، تا حدی تعدیل شده است.

تفاوت بین هسته‌های mainline، stable و longterm چیست؟

Mainline همان شاخهٔ اصلی توروالدز است که هر 9 تا 10 هفته منتشر می‌شود و ویژگی‌های جدید ابتدا در آن قرار می‌گیرند. نسخهٔ Stable آخرین انتشار mainline را می‌گیرد و برای چند هفته اصلاحات باگ دریافت می‌کند. شاخه‌های Longterm برای سال‌ها اصلاحات دریافت می‌کنند و توزیع‌های لینوکس هسته‌های خود را بر پایهٔ آن‌ها می‌سازند. سایت kernel.org شاخه‌های longterm فعلی را به همراه تاریخ پایان پشتیبانی (end-of-life) برای هر کدام فهرست می‌کند.

آیا هسته لینوکس کدهای نوشته‌شده توسط هوش مصنوعی را می‌پذیرد؟

بله، طبق سیاستی که در دسامبر 2025 تصویب شد. ابزار مورد استفاده باید در تگ Assisted-by: ذکر شود، یک عامل هوش مصنوعی نباید خط Signed-off-by را اضافه کند و کد تولیدشده باید با GPL-2.0 سازگار باشد. ارسال‌کنندهٔ انسانی باید پچ را امضا (sign-off) کند؛ این به معنای آن است که او پچ را بررسی کرده و طبق Developer Certificate of Origin مسئولیت آن را می‌پذیرد.

روی سرور باید از کدام نسخهٔ هسته استفاده کنم؟

در تقریباً تمام موارد، نسخه‌ای که توزیع شما نگهداری می‌کند. هستهٔ توزیع، ترکیبی از یک شاخهٔ longterm، اصلاحات backport شده و تست‌های انجام‌شده توسط فروشنده است؛ این همان نسخه‌ای است که ایمیج‌های ارائه‌دهندهٔ شما و توافق‌نامه‌های پشتیبانی بر پایهٔ آن فرض شده‌اند. زمانی که به درایور یا ویژگی خاصی نیاز دارید، یک هستهٔ جدیدتر mainline بسازید و پیش از نهایی کردن تصمیم، تاریخ پایان پشتیبانی شاخه‌ای که به آن مهاجرت می‌کنید را بررسی کنید.