لینکس kernel کی تاریخ: اہم فیصلے اور آج کا اثر

لینکس kernel کی تاریخ کا مختصر جائزہ

لینکس kernel کی تاریخ September 1991 میں version 0.01 سے شروع ہوتی ہے اور آج servers پر boot ہونے والی 7.x series تک پہنچتی ہے۔ صرف releases کی فہرست اس تاریخ کا کم اہم حصہ ہے۔ چند فیصلوں نے اس kernel کی ساخت متعین کی، اور ان میں سے ہر فیصلے کا اثر آج بھی اس machine پر موجود ہے جسے آپ اسی دوپہر rent کرتے ہیں۔

یہاں دی گئی dates اور version numbers kernel.org اور اس کی شائع کردہ release history سے لیے گئے ہیں۔ August 2026 تک موجودہ صورت حال یہ ہے: 7.0، 12 April 2026 کو جاری ہوا؛ 7.1، 14 June 2026 کو جاری ہوا؛ اور 7.2 release candidates کے مرحلے میں ہے۔

1992 میں GPL کا انتخاب آج بھی کیوں اہم ہے

Version 0.01 کو 17 September 1991 کو Torvalds کی اپنی تحریر کردہ licence کے تحت جاری کیا گیا تھا۔ اس licence میں source کی تقسیم لازم تھی، اور اس میں ایک زیادہ اہم سطر بھی شامل تھی: "آپ اسے کسی فیس کے عوض تقسیم نہیں کر سکتے، حتیٰ کہ 'handling' costs کے لیے بھی نہیں۔" 1991 میں software floppy disks پر جاری ہوتا تھا، اور floppy disks کی copying اور posting پر لاگت آتی تھی۔ اس شق نے commercial Linux distribution کو ناممکن بنا دیا۔

انہوں نے اسے تبدیل کیا۔ GNU General Public License (GPL) کی طرف منتقلی کا اعلان January 1992 میں 0.12 release notes میں کیا گیا، اور یہ 1 February 1992 کو نافذ ہوئی۔ March 1992 میں جاری ہونے والا Version 0.95 اس licence کے تحت شائع ہونے والی پہلی release تھی۔ بعد میں Linux پر قائم ہونے والا ہر کاروبار اسی تبدیلی پر منحصر ہے۔

Kernel صرف GPL version 2 کے تحت ہے، اور یہ کبھی version 3 پر منتقل نہیں ہوا۔ Torvalds نے 2007 میں اس سے انکار کیا، جس کی بنیادی وجہ GPLv3 میں شامل anti-tivoisation rule تھا۔ اس rule کے مطابق جو device GPL code کے ساتھ ship ہو، اسے اسی code کی modified copy بھی قبول کرنی ہوتی ہے۔ ان کے نزدیک locked hardware manufacturer کا اپنا کاروباری معاملہ تھا۔ 2017 میں kernel developers نے Kernel Enforcement Statement شائع کیا۔ اس میں GPLv3 کے ایک حصے کو بہرحال اپنایا گیا ہے: جس شخص کو violation کے بارے میں مطلع کیے جانے کے بعد وہ اسے درست کر دے، اس کا licence برقرار رہتا ہے، بجائے اس کے کہ پہلی breach پر وہ مستقل طور پر ختم ہو جائے۔

Server پر اس کے دو نتائج نکلتے ہیں۔ جس kernel binary کو آپ boot کرتے ہیں، اس کے ساتھ matching source حاصل کرنے کا حق بھی شامل ہوتا ہے۔ اس لیے کوئی آپ کو ایسا Linux kernel نہیں دے سکتا جس کا آپ معائنہ یا rebuild نہ کر سکیں۔ دوسرا، kernel پر موجود copyright notice واضح کرتا ہے کہ licence ان user programs پر لاگو نہیں ہوتی جو عام system calls کے ذریعے kernel services استعمال کرتے ہیں۔ اسی لیے proprietary databases اور monitoring agents Linux کے لیے ship ہو سکتے ہیں اور کسی licence کی خلاف ورزی نہیں ہوتی۔ Permissive licence اس کے برعکس دباؤ پیدا کرتی ہے، اور platform منتخب کرنے سے پہلے اس فرق کو سمجھنا مفید ہے: Linux اور FreeBSD بطور server platforms۔

عملی طور پر monolithic kernel کیوں غالب رہا

29 January 1992 کو Andrew Tanenbaum نے comp.os.minix newsgroup میں "LINUX is obsolete" کے عنوان سے ایک پیغام پوسٹ کیا۔ انہوں نے دو دعوے کیے۔ Monolithic kernels میں drivers اور filesystems ایک ہی privileged address space کے اندر چلتے ہیں، اور یہ 1970 کی دہائی کا design تھا۔ اس کے برعکس microkernels میں یہ حصے عام processes کے طور پر چلتے ہیں، اور یہی مستقبل تھے۔ دوسرا دعویٰ یہ تھا کہ Linux کو Intel 386 کے ساتھ اس قدر مخصوص طور پر جوڑا گیا تھا کہ یہ کبھی دوسرے hardware platforms پر منتقل نہیں ہو سکے گا۔

Portability کے دعوے کا جواب porting کے ذریعے دیا گیا۔ March 1995 میں Version 1.2 نے Alpha، SPARC اور MIPS شامل کیے۔ June 1996 میں Version 2.0 نے 64-bit Alpha port شامل کیا۔

Design کے دعوے کا جواب ایک درمیانی حل تھا۔ Linux کبھی microkernel نہیں بنا۔ اس میں loadable kernel modules شامل کیے گئے: یہ object files ہوتی ہیں جنہیں چلتے ہوئے kernel میں داخل کیا اور دوبارہ نکالا جا سکتا ہے۔ اس طرح driver کو kernel binary سے الگ release کیا جا سکتا ہے۔

lsmod | head
modinfo virtio_net | head -5

lsmod اس وقت load کیے گئے modules کی فہرست دکھاتا ہے۔ modinfo وہ file دکھاتا ہے جس سے module آیا ہے اور وہ parameters دکھاتا ہے جنہیں module قبول کرتا ہے۔ Virtual server پر disk اور network path کا زیادہ تر حصہ modules پر مشتمل ہوتا ہے۔ اسی لیے ایک kernel image ایسے hardware پر بھی boot ہو سکتی ہے جس سے اس کا پہلے کبھی سامنا نہیں ہوا۔

Modules نے microkernel design کی لاگت کے بغیر یہ flexibility فراہم کی۔ Driver کو اپنے الگ process میں isolate کرنے کے لیے ہر call پر context switch اور message کی لاگت برداشت کرنا پڑتی ہے، اور 1992 میں یہ لاگت زیادہ تھی۔

Linux نے جو لاگت برقرار رکھی، planning میں اسی کو مدنظر رکھنا چاہیے: module مکمل kernel privileges کے ساتھ چلتا ہے۔ اس لیے خراب module صرف ایک process کے بجائے پوری machine کو بند کر سکتا ہے۔ یہ مسئلہ out-of-tree modules میں نمایاں ہوتا ہے۔ ایسا vendor driver جو mainline میں شامل نہ ہو، ہر نئے kernel کے لیے دوبارہ build کرنا پڑتا ہے۔ Upgrade کے دوران یہی کام DKMS کرتا ہے۔ اگر build ناکام ہو جائے تو reboot کے بعد device موجود نہیں ہوتا۔

SMP کو مکمل ہونے میں پندرہ سال کیوں لگے

جون 1996 میں Linux 2.0 پہلا kernel تھا جس نے symmetric multiprocessing (SMP) کو support کیا۔ اس کا مطلب ہے کہ ایک سے زیادہ CPU ایک ہی kernel چلا سکتے ہیں۔ پہلی implementation میں ایک ہی lock استعمال ہوتا تھا، جسے big kernel lock (BKL) کہا جاتا تھا۔ اس لیے ایک وقت میں صرف ایک processor kernel code کے اندر ہو سکتا تھا۔ چنانچہ دوسرا CPU ایسے workload میں مدد دیتا تھا جو user space میں compute کرتا ہو، لیکن system calls والے workload میں بہت کم مدد دیتا تھا، کیونکہ وہ بھی اسی lock کے پیچھے queue ہو جاتے تھے۔

اس lock کو مکمل طور پر ہٹانے میں پندرہ سال لگے۔ باقی استعمالات کو fine-grained locking میں تبدیل کیا گیا، جس میں Arnd Bergmann کا بڑا کردار تھا۔ BKL کو 2.6.39 میں حذف کیا گیا، جو 18 May 2011 کو release ہوا۔ Scheduler بھی اسی سست رفتار سے آگے بڑھا: 2.6.0 میں O(1) scheduler، 2007 میں 2.6.23 سے Completely Fair Scheduler (CFS)، اور EEVDF، جس نے October 2023 میں 6.6 میں CFS کی جگہ لی۔

اسی کام کی وجہ سے آج 4 vCPU plan غیر معمولی نہیں ہے۔ اس سے ایک اہم حد بھی واضح ہوتی ہے جسے سمجھنا ضروری ہے۔ مشترکہ virtual server پر آپ کا kernel آپ کے threads کو schedule کرتا ہے، جبکہ hypervisor آپ کے kernel کو schedule کرتا ہے۔ top چلائیں اور %st field پڑھیں۔ Steal time وہ CPU وقت ہے جسے استعمال کرنے کے لیے آپ کا kernel تیار تھا، لیکن host نے وہ وقت کسی دوسرے guest کو دے دیا۔ اس لیے آپ کے kernel کے اندر کوئی tuning اسے واپس حاصل نہیں کر سکتی۔

2.6 سیریز نے kernel کی build کا طریقہ کیوں بدلا

2.6 سے پہلے version numbers جوڑوں کی صورت میں آتے تھے۔ دوسرا number even ہو تو stable series (2.4) ہوتی تھی، اور odd ہو تو development series (2.5)۔ 2.4، 4 January 2001 کو release ہوا اور 2.6، 17 December 2003 کو، اس لیے users نے اگلی stable series کے لیے تقریباً تین سال انتظار کیا۔ Distributions اتنا انتظار نہیں کر سکتی تھیں، اس لیے انہوں نے patches کو backport کیا۔ بظاہر "2.4" ship کرنے والے دو vendors کے kernels میں ہزاروں patches کا فرق ہوتا تھا۔

2.6 کے بعد یہ تقسیم ختم کر دی گئی۔ اب mainline تقریباً دو ہفتوں کی merge window کھولتا ہے، نیا کام شامل کرتا ہے، پھر release candidates چلاتا ہے تاوقتیکہ تبدیلیاں رک نہ جائیں، اور ہر 9 سے 10 ہفتوں میں release کرتا ہے؛ kernel.org اب بھی یہی cadence دستاویز کرتا ہے۔ اس model کا دوسرا حصہ 4 March 2005 کو stable tree کی پہلی release کے ساتھ آیا۔ یہ 2.6.11 کے لیے صرف fixes پر مشتمل update تھی، جسے Greg Kroah-Hartman اور Chris Wright maintain کرتے تھے۔ stable tree fixes قبول کرتا ہے اور features قبول نہیں کرتا۔

اس کا ایک نتیجہ یہ نکلا کہ version number نے وعدہ ہونا چھوڑ دیا۔ 3.0، 4.0، 5.0 اور 7.0 ازسرنو تحریریں نہیں ہیں۔ Torvalds پہلا number اس وقت بڑھاتے ہیں جب دوسرا number ان کے لیے کافی بڑا ہو جاتا ہے، اسی لیے April 2026 میں 7.0، 6.19 کے بعد آیا۔ Server کے لیے اہم بات یہ ہے کہ آپ کی distribution کس branch کو track کرتی ہے، اور آیا اس branch کو اب بھی fixes مل رہے ہیں۔

اپریل 2005 میں BitKeeper کے تنازعے سے git کیسے وجود میں آیا

فروری 2002 سے kernel کی development BitKeeper میں ہو رہی تھی۔ BitKeeper، Larry McVoy کی کمپنی BitMover کا proprietary distributed version control system تھا، اور اس کا استعمال 2.5 series سے شروع ہوا۔ BitMover نے kernel developers کو کچھ شرائط کے ساتھ free licence دیا تھا: آپ کسی competing version control tool پر کام نہیں کر سکتے تھے، اور BitKeeper کو reverse engineer نہیں کر سکتے تھے۔ بہت سے developers کو یہ بات پسند نہیں تھی کہ وہ ایسے tool کے ساتھ free kernel تیار کریں جس کا source code انہیں پڑھنے کی اجازت نہیں تھی۔

یہ سلسلہ اپریل 2005 میں اس وقت ٹوٹ گیا جب Andrew Tridgell نے ایسا program دکھایا جو BitKeeper repositories کے ساتھ بات کر سکتا تھا۔ BitMover نے اسے reverse engineering قرار دیا اور free licence واپس لے لیا۔ Kernel نے development cycle کے دوران اپنا version control system کھو دیا۔

git پر کام 3 اپریل 2005 کو شروع ہوا۔ Torvalds نے 6 اپریل کو اس کا اعلان کیا۔ 7 اپریل کو git self-hosting کر رہا تھا، یعنی git کی اپنی history پہلے ہی git میں محفوظ ہو رہی تھی۔ کئی branches کا پہلا merge 18 اپریل کو ہوا۔ جون 2005 میں git نے 2.6.12 کی release manage کی۔ اس کے کچھ ہی عرصے بعد Torvalds نے maintenance Junio Hamano کے حوالے کی اور kernel پر واپس چلے گئے۔

اس design کی بنیاد براہ راست اسی مسئلے سے نکلی: ہزاروں contributors، اور ایسے maintainers جو ایک ایسے network پر ایک دوسرے سے changes pull کرتے ہیں جس پر کوئی اعتماد نہیں کرتا۔ ہر object کا نام اس کے content کے hash سے بنتا ہے، اس لیے پرانی history کے ایک byte کو بدلنے سے اس کے بعد آنے والے ہر commit کا نام بدل جاتا ہے۔ اسی لیے clone محض دعویٰ نہیں بلکہ evidence ہوتا ہے۔ ہر deploy pipeline، ہر configuration repository، وہ code host جہاں زیادہ تر teams push کرتی ہیں اور وہ git server جسے آپ خود چلا سکتے ہیں، kernel کے بارے میں licensing کے ایک تنازعے سے وجود میں آئے۔

LTS ماڈل کیا وعدہ کرتا ہے، اور کیا نہیں کرتا

Mainline وہ ورژن نہیں ہے جسے آپ چلاتے ہیں۔ Mainline release کے 9 سے 10 ہفتے بعد اس کی جگہ نیا release لے لیتا ہے۔ Stable tree ہر release کے بعد چند ہفتوں تک fixes فراہم کرتا ہے۔ Longterm branches، جنہیں عموماً LTS لکھا جاتا ہے، یہ fixes برسوں تک فراہم کرتی ہیں، اور distributions اپنی builds کے لیے انہی branches کو بنیاد بناتی ہیں۔

2.6.32، جو December 2009 میں release ہوا، وہ مرحلہ تھا جہاں یہ ماڈل کامیاب ثابت ہوا۔ RHEL 6، Debian 6، SUSE Linux Enterprise 11 SP1 اور Ubuntu 10.04 LTS سب نے اسے ship کیا، اور یہ branch February 2016 تک maintain کی گئی، یعنی اس کے release ہونے کے 6 سال سے زیادہ عرصے بعد تک۔

یہ وعدہ ایک سے زیادہ مرتبہ تبدیل ہوا ہے۔ ابتدا میں مدت 2 سال تھی، پھر کچھ branches کے لیے 6 سال کر دی گئی۔ 2023 میں stable maintainers نے default مدت دوبارہ 2 سال کر دی، کیونکہ پرانی trees میں backporting کے لیے maintainer کا وقت درکار ہوتا ہے اور پرانی branches کی حقیقی testing کم ہو جاتی ہے۔ 25 February 2026 کو Greg Kroah-Hartman نے ان کمپنیوں سے مشاورت کے بعد، جو ان branches پر انحصار کرتی ہیں، طویل مدت کے projections دوبارہ شائع کیے۔ موجودہ framework 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
  }
]

August 2026 تک kernel.org پر 6 longterm branches درج ہیں۔ سب سے پرانی branch، 5.10، جب Dec 2026 میں ختم ہوگی تو اس میں 6.0 سال تک fixes فراہم کی جا چکی ہوں گی۔ سب سے نئی branch، 6.18، کے Dec 2028 تک چلنے کا projection ہے، جو fixes کی 3.1 سالہ مدت بنتی ہے۔

ان تاریخوں کو معاہدے کے بجائے کم از کم مدت سمجھیں۔ 6.6 اور 6.12 دونوں کے projections February 2026 میں آگے بڑھائے گئے، لیکن جس branch کو کوئی استعمال نہ کرتا ہو اسے اس سے پہلے بھی ختم کیا جا سکتا ہے۔ عموماً آپ کی distribution یہ انتخاب خود کرتی ہے: Debian 13، 6.12 ship کرتا ہے، اور Ubuntu 26.04 LTS، 7.0 ship کرتا ہے۔ یہی فرق سرور پر LTS اور interim release کے سوال کا عملی مفہوم ہے، اور Ubuntu 24.04 کو 26.04 پر upgrade کرنے کے بعد بنیادی طور پر یہی چیز آپ کے سسٹم میں تبدیل ہوتی ہے۔

اس سے ایک مسئلہ پیدا ہوتا ہے۔ uname -r Ubuntu 24.04 پر کچھ اس طرح ظاہر کرتا ہے: 6.8.0-51-generic۔ یہ upstream base کے ساتھ distribution کے اپنے backports کا مجموعہ ہوتا ہے۔ اس لیے یہ number صرف بتاتا ہے کہ branch کہاں سے شروع ہوئی تھی، یہ نہیں بتاتا کہ اس میں کون سی fixes شامل ہیں۔ اسی وجہ سے وہ scanners جو kernel کو اس کے version string کی بنیاد پر جانچتے ہیں، distribution kernels کے بارے میں false alarms پیدا کرتے ہیں۔

اس وقت kernel کس معاملے پر اختلاف کر رہا ہے

دو اختلافات جاری ہیں، اور دونوں کا تعلق اس بات سے ہے کہ کام کون کرے گا۔

Rust دسمبر 2022 میں 6.1 کے ساتھ infrastructure کے طور پر شامل ہوا۔ 7.0 میں experimental کا لیبل ہٹا دیا گیا، اس لیے kernel کی بنیادی زبانیں C، assembly اور Rust ہیں، اور build کے لیے اب nightly compiler درکار نہیں۔ اختلاف maintenance کے بارے میں ہے۔ C maintainer جب کوئی interface تبدیل کرتا ہے تو وہ Rust bindings توڑ سکتا ہے جنہیں وہ خود نہیں پڑھتا، اور بحث اس بات پر ہے کہ انہیں درست کرنا کس کی ذمہ داری ہے۔

دوسرا اختلاف AI contribution کے بارے میں ہے۔ Sasha Levin نے جولائی 2025 میں ایک policy تجویز کی، جب machine-assisted patches کی بڑھتی ہوئی تعداد mailing lists تک پہنچنے لگی۔ یہ document 23 دسمبر 2025 کو commit کیا گیا اور اب kernel کی اپنی process documentation میں موجود ہے: docs.kernel.org/process/coding-assistants.html۔ AI agent کو Signed-off-by tag شامل نہیں کرنا چاہیے، کیونکہ یہ سطر Developer Certificate of Origin (DCO) کی تصدیق کرتی ہے اور صرف کوئی انسان ہی اس کی تصدیق کر سکتا ہے۔ Assistance کا اعلان Assisted-by: tag کے ذریعے کیا جاتا ہے، جسے review کے دوران Co-developed-by: سے تبدیل کیا گیا، کیونکہ tool author نہیں ہوتا۔ Generated code کو GPL-2.0-only کے ساتھ compatible ہونا چاہیے۔ جو انسان patch بھیجتا ہے وہ اس کا review کرتا ہے اور اس کی ذمہ داری قبول کرتا ہے۔

اس policy کے پیچھے بنیادی دباؤ review کا وقت ہے۔ Patch generate کرنے میں چند seconds لگتے ہیں، جبکہ ایک patch کا review maintainer کی پوری afternoon لے سکتا ہے۔ کوئی tag اس عدم توازن کو ختم نہیں کرتا۔ البتہ یہ provenance محفوظ رکھتا ہے: history میں یہ درج رہتا ہے کہ ہر change کی ذمہ داری کے لیے کس نے sign کیا تھا۔ DCO کو 2004 میں اسی property کے تحفظ کے لیے متعارف کرایا گیا تھا۔

اس تاریخ کا آپ کے کرائے کے server کے لیے مطلب

• licence کی وجہ سے آپ اپنے provider کے boot کیے ہوئے kernel کو پڑھ اور دوبارہ build کر سکتے ہیں، اور اسی وجہ سے proprietary software بھی اس پر چلتا ہے۔
• monolithic design کی وجہ سے ایک driver bug پوری machine کو reboot کر دیتا ہے، اور اسی وجہ سے ہر kernel upgrade کے بعد out-of-tree module کو دوبارہ build کرنا پڑتا ہے۔
• release model کی وجہ سے version number آپ کو بہت کم معلومات دیتا ہے، جبکہ branch اور اس کی end-of-life date تقریباً تمام ضروری معلومات فراہم کرتے ہیں۔
• virtualisation type یہ طے کرتی ہے کہ آپ بالکل کیا کر سکتے ہیں: KVM پر آپ اپنا kernel boot اور modules load کرتے ہیں، جبکہ ایسی container virtualisation میں جو host kernel share کرتی ہے، uname -r host کا version دکھاتا ہے، modprobe ناکام ہوتا ہے، اور کئی sysctls read-only ہوتے ہیں۔

FAQ

Linux kernel اب بھی GPLv2 پر کیوں ہے، GPLv3 پر کیوں نہیں؟

Torvalds نے 2007 میں بنیادی طور پر GPLv3 کی مخالفت کی، کیونکہ اس میں anti-tivoisation کی شرط شامل ہے۔ یہ شرط اس device کو، جو GPL code ship کرتا ہے، اسی code کے modified version کو بھی قبول کرنے کا پابند بناتی ہے۔ ان کے نزدیک locked hardware manufacturer کا کاروباری معاملہ ہے۔ عملی طور پر relicensing بھی تقریباً ناممکن ہے، کیونکہ kernel کا copyright ہزاروں contributors کے پاس ہے اور کوئی assignment agreement موجود نہیں جس سے رجوع کیا جا سکے۔ kernel صرف GPL-2.0-only کے تحت ہے، اس لیے صرف GPLv3 کے تحت پیش کیا گیا code merge نہیں کیا جا سکتا۔

Linux kernel monolithic kernel ہے یا microkernel؟

یہ loadable modules کے ساتھ monolithic kernel ہے۔ Drivers اور filesystems kernel کے address space کے اندر چلتے ہیں، اور lsmod اس وقت loaded components دکھاتا ہے۔ اس کا ایک نتیجہ رفتار ہے، جبکہ دوسرا وسیع اثرات کا خطرہ ہے: faulty module پوری machine کو panic کر سکتا ہے، جبکہ microkernel میں ایک process متاثر ہوتا۔ 1992 کے بعد یہ فرق کچھ کم ہوا ہے، کیونکہ user space میں FUSE filesystems اور eBPF programs استعمال ہوتے ہیں جنہیں kernel چلانے سے پہلے verify کرتا ہے۔

mainline، stable اور longterm kernels میں کیا فرق ہے؟

Mainline، Torvalds کا tree ہے، جو ہر 9 سے 10 ہفتے بعد release ہوتا ہے، اور نئی features سب سے پہلے اسی میں شامل ہوتی ہیں۔ Stable، تازہ ترین mainline release سے بنتا ہے اور اسے چند ہفتوں تک bug fixes ملتی رہتی ہیں۔ Longterm branches کو کئی سال تک fixes ملتی رہتی ہیں، اور distributions اپنے kernels عموماً انہی branches کی بنیاد پر بناتی ہیں۔ kernel.org موجودہ longterm branches کے ساتھ ہر branch کی متوقع end-of-life date بھی درج کرتا ہے۔

کیا Linux kernel، AI کے ذریعے لکھا گیا code قبول کرتا ہے؟

ہاں، دسمبر 2025 میں منظور کی گئی policy کے تحت۔ Tool کا نام Assisted-by: tag میں درج ہونا چاہیے، AI agent کو Signed-off-by line شامل نہیں کرنی چاہیے، اور generated code کو GPL-2.0-only کے ساتھ compatible ہونا چاہیے۔ Human submitter sign off کرتا ہے، یعنی اس نے patch کا review کیا ہے اور Developer Certificate of Origin کے تحت اس کی ذمہ داری قبول کرتا ہے۔

Server پر کون سا kernel version چلانا چاہیے؟

تقریباً ہر صورت میں وہی kernel version چلائیں جسے آپ کی distribution maintain کرتی ہے۔ Distribution kernel، longterm branch، backported fixes اور vendor کی testing کا مجموعہ ہوتا ہے۔ آپ کے provider کی images اور support arrangements بھی اسی kernel کو فرض کرتے ہیں۔ جب آپ کو کسی مخصوص driver یا feature کی ضرورت ہو تو نیا mainline kernel build کریں۔ اس پر commit کرنے سے پہلے اس branch کی end-of-life date ضرور دیکھیں جس پر آپ منتقل ہو رہے ہیں۔