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

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

تاریخچهٔ هستهٔ Linux از نسخهٔ 0.01 در سپتامبر 1991 آغاز می‌شود و تا سری 7.x که امروز روی سرورها راه‌اندازی می‌شود ادامه دارد. فهرست releaseها کم‌اهمیت‌ترین بخش این تاریخچه است. تعداد اندکی تصمیم، ساختار این پروژه را شکل دادند و هرکدام هنوز بر ماشینی که همین بعدازظهر اجاره می‌کنید اثر دارند. این‌که چرا در سال 1991 اصلاً به هستهٔ جدیدی نیاز بود، به داستان مفصل‌تر Unix، مجوزدهی AT&T و دعوایی که توسعهٔ BSD را متوقف کرد مربوط است.

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

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

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

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

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

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

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

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

ادعای قابلیت انتقال با پورت کردن پاسخ داده شد. نسخه 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 فایلی که ماژول از آن آمده و پارامترهایی که می‌پذیرد را چاپ می‌کند. در یک سرور مجازی، بخش بزرگی از مسیر دیسک و شبکه از ماژول‌ها تشکیل شده است، به همین دلیل است که یک ایمیج هسته روی سخت‌افزاری که هرگز آن را ندیده است، بوت می‌شود. هسته فقط سخت‌افزار جدید را اعلام می‌کند و یک دیمون در فضای کاربری (user space) تصمیم می‌گیرد که کدام ماژول بارگذاری شود و نام دستگاه چه باشد؛ این همان دلیلی است که مدیریت دستگاه در سیستم init قرار گرفت و بخشی از دلیلی است که systemd به سختی قابل اجتناب شد.

ماژول‌ها این انعطاف‌پذیری را بدون هزینه‌ای که طراحی ریزهسته به همراه داشت، فراهم کردند. ایزوله کردن یک درایور در پردازش اختصاصی خود به معنای پرداخت هزینه برای 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 موضوعی عادی محسوب می‌شود. این موضوع همچنین نشان‌دهنده محدودیتی است که باید از آن آگاه باشید. در یک سرور مجازی اشتراکی، هسته شما رشته‌های (threads) شما را زمان‌بندی می‌کند و هایپروایزر (hypervisor) هسته شما را زمان‌بندی می‌کند. دستور top را اجرا کنید و فیلد %st را بخوانید. زمان Steal در واقع زمانی از CPU است که هسته شما آماده استفاده از آن بوده، اما میزبان آن را به مهمان دیگری اختصاص داده است؛ بنابراین هیچ تنظیماتی در داخل هسته شما نمی‌تواند این زمان از دست رفته را بازیابی کند.

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

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

این تفکیک پس از نسخه 2.6 کنار گذاشته شد. شاخه اصلی (Mainline) اکنون یک پنجره ادغام (merge window) حدوداً دو هفته‌ای باز می‌کند، کارهای جدید را می‌پذیرد، سپس تا زمان آرام شدن وضعیت، نامزدهای انتشار (release candidates) را اجرا می‌کند و هر 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 در آوریل 2005 منجر به تولید git شد

از فوریه 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 نگهداری می‌شد. اولین ادغام چندین شاخه (branch) در 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، یعنی بیش از شش سال پس از ظهورش، پشتیبانی شد. Red Hat حتی فراتر رفت و هسته مبتنی بر 2.6.32 خود را با backportهای اختصاصی تا زمان پایان عمر RHEL 6 در سال 2020 حفظ کرد. بازتولید این یک دهه پشتیبانی به‌صورت رایگان، دلیل اصلی وجود CentOS و جایگزینی آن توسط Rocky Linux و AlmaLinux است.

این وعده بیش از یک بار تغییر کرده است. ابتدا دو سال بود و سپس برای برخی شاخه‌ها به شش سال رسید. در سال 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) برای هسته‌های توزیع‌ها صادر می‌کنند.

هسته سیستم‌عامل در حال حاضر بر سر چه موضوعاتی بحث می‌کند

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

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

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

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

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

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

FAQ

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

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

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

یکپارچه، با قابلیت بارگذاری ماژول‌ها. درایورها و سیستم‌های فایل در فضای آدرس هسته اجرا می‌شوند و lsmod مواردی را که در حال حاضر بارگذاری شده‌اند نشان می‌دهد. نتیجه این ساختار، سرعت از یک سو و شعاع انفجار (blast radius) از سوی دیگر است: یک ماژول معیوب می‌تواند کل سیستم را دچار 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 جدیدتر بسازید و پیش از نهایی کردن آن، تاریخ پایان پشتیبانی شاخه‌ای که به آن مهاجرت می‌کنید را بررسی کنید.