Linux kernel का इतिहास और महत्वपूर्ण तकनीकी निर्णय

Linux kernel के इतिहास का संक्षिप्त विवरण

Linux kernel का इतिहास September 1991 के version 0.01 से शुरू होकर आज servers पर boot होने वाली 7.x series तक पहुँचता है। Release list इसका सबसे कम महत्वपूर्ण हिस्सा है। कुछ ही निर्णयों ने इसकी संरचना तय की, और आज दोपहर किराए पर लिए गए machine पर भी प्रत्येक निर्णय का प्रभाव दिखाई देता है। 1991 में नए kernel की आवश्यकता ही क्यों पड़ी, यह Unix, AT&T licensing और BSD को रोक देने वाले मुकदमे की विस्तृत कहानी का हिस्सा है।

यहाँ दी गई तारीखें और version numbers kernel.org और उसके द्वारा प्रकाशित release history से लिए गए हैं। अगस्त 2026 तक की वर्तमान स्थिति यह है: 7.0 version 12 April 2026 को आया, 7.1 version 14 June 2026 को आया, और 7.2 version अभी release candidates के चरण में है।

1992 में GPL चुनने का महत्व आज भी क्यों है

Version 0.01 को 17 September 1991 को Torvalds द्वारा स्वयं लिखे गए एक लाइसेंस के तहत प्रकाशित किया गया था। इसमें यह अनिवार्य था कि source code वितरित किया जाए, और इसमें एक ऐसी पंक्ति जोड़ी गई जो अधिक महत्वपूर्ण थी: "आप इसे शुल्क लेकर वितरित नहीं कर सकते, यहाँ तक कि 'हैंडलिंग' लागत के लिए भी नहीं।" 1991 में software floppy disks पर ship होता था, और floppy disks को copy करने और भेजने में खर्च आता था। उस clause ने Linux का commercial distribution असंभव बना दिया था।

उन्होंने इसे बदल दिया। GNU General Public License (GPL) पर जाने की घोषणा January 1992 में 0.12 release notes में की गई थी और यह 1 February 1992 से प्रभावी हुआ। March 1992 में Version 0.95, इसके तहत प्रकाशित होने वाला पहला release था। बाद में Linux पर बना हर व्यवसाय उसी बदलाव पर टिका है।

Kernel केवल GPL version 2 है, और यह कभी version 3 पर नहीं गया। Torvalds ने 2007 में इसे मना कर दिया था, जिसका मुख्य कारण GPLv3 में anti-tivoisation नियम था। यह नियम अनिवार्य करता है कि GPL code के साथ ship होने वाला device उस code की modified copy को भी स्वीकार करे। उन्होंने locked hardware को निर्माता का निजी मामला माना। 2017 में kernel developers ने Kernel Enforcement Statement प्रकाशित किया, जो वैसे भी GPLv3 का एक हिस्सा उधार लेता है: यदि कोई व्यक्ति उल्लंघन के बारे में बताए जाने के बाद उसे ठीक कर देता है, तो उसका लाइसेंस बना रहता है, बजाय इसके कि पहली बार उल्लंघन करने पर ही वह स्थायी रूप से समाप्त हो जाए।

सर्वर पर इसके दो परिणाम होते हैं। जिस kernel binary को आप boot करते हैं, उसके साथ matching source का अधिकार जुड़ा होता है, इसलिए कोई भी आपको ऐसा Linux kernel नहीं दे सकता जिसे आप inspect या rebuild न कर सकें। और kernel पर मौजूद copyright notice यह कहता है कि लाइसेंस उन user programs को कवर नहीं करता जो सामान्य system calls द्वारा kernel services का उपयोग करते हैं। यही कारण है कि proprietary databases और monitoring agents बिना किसी नियम को तोड़े Linux के लिए ship होते हैं। एक permissive license इसके विपरीत दबाव बनाता है, और किसी platform को चुनने से पहले उस अंतर को समझना आवश्यक है: देखें Linux और FreeBSD सर्वर प्लेटफॉर्म के रूप में।

व्यावहारिक रूप से मोनोलिथिक कर्नल क्यों सफल रहा

29 जनवरी 1992 को, Andrew Tanenbaum ने comp.os.minix न्यूज़ग्रुप पर "LINUX is obsolete" शीर्षक से एक संदेश पोस्ट किया। उन्होंने दो दावे किए। मोनोलिथिक कर्नल, जहाँ ड्राइवर और फाइलसिस्टम एक विशेषाधिकार प्राप्त एड्रेस स्पेस के भीतर चलते हैं, 1970 के दशक का डिज़ाइन था, जबकि माइक्रोकर्नेल, जहाँ वे हिस्से सामान्य प्रक्रियाओं के रूप में चलते हैं, भविष्य थे। और Linux को Intel 386 के साथ जोड़ दिया गया था, इसलिए यह कभी भी पोर्टेबल नहीं होगा।

पोर्टेबिलिटी के दावे का उत्तर पोर्टिंग द्वारा दिया गया। मार्च 1995 में संस्करण 1.2 ने Alpha, SPARC और MIPS को जोड़ा। जून 1996 में संस्करण 2.0 ने 64-बिट Alpha पोर्ट जोड़ा।

डिज़ाइन के दावे का उत्तर एक समझौते द्वारा दिया गया। Linux कभी माइक्रोकर्नेल नहीं बना। इसमें लोड करने योग्य कर्नल मॉड्यूल (loadable kernel modules) शामिल किए गए: ये ऑब्जेक्ट फाइलें हैं जिन्हें आप चल रहे कर्नल में डालते हैं और फिर हटा देते हैं, इसलिए एक ड्राइवर कर्नल बाइनरी से अलग आता है।

lsmod | head
modinfo virtio_net | head -5

lsmod वर्तमान में लोड की गई चीजों की सूची देता है। modinfo उस फाइल को प्रिंट करता है जहाँ से मॉड्यूल आया था और उन पैरामीटर्स को जिन्हें वह स्वीकार करता है। एक वर्चुअल सर्वर पर डिस्क और नेटवर्क पाथ का अधिकांश हिस्सा मॉड्यूल होता है, यही कारण है कि एक कर्नल इमेज ऐसे हार्डवेयर पर बूट हो जाती है जिसे उसने पहले कभी नहीं देखा। कर्नल केवल नए हार्डवेयर की घोषणा करता है, और एक यूजर स्पेस डेमन यह तय करता है कि कौन सा मॉड्यूल लोड करना है और डिवाइस का नाम क्या रखना है, यही कारण है कि डिवाइस प्रबंधन init सिस्टम के भीतर आ गया और यही एक कारण है कि systemd से बचना कठिन हो गया।

मॉड्यूल ने माइक्रोकर्नेल डिज़ाइन की लागत के बिना वह लचीलापन प्राप्त किया। एक ड्राइवर को उसकी अपनी प्रक्रिया में अलग करने का मतलब है हर कॉल पर कॉन्टेक्स्ट स्विच और मैसेज की कीमत चुकाना, और 1992 में वह लागत बहुत अधिक थी।

Linux ने जिस लागत को बनाए रखा, वह वह है जिसके लिए योजना बनानी पड़ती है: एक मॉड्यूल पूर्ण कर्नल विशेषाधिकारों के साथ चलता है, इसलिए एक खराब मॉड्यूल एक प्रक्रिया के बजाय पूरी मशीन को डाउन कर देता है। आउट-ऑफ-ट्री मॉड्यूल वह जगह है जहाँ यह समस्या पैदा करता है। एक वेंडर ड्राइवर जो मेनलाइन में नहीं है, उसे हर नए कर्नल के विरुद्ध फिर से बनाया जाना चाहिए, जो कि अपग्रेड के दौरान DKMS करता है, और जब वह बिल्ड विफल हो जाता है तो रीबूट के बाद डिवाइस बस गायब हो जाता है।

SMP को पूरा होने में पंद्रह साल क्यों लगे

जून 1996 में Linux 2.0 पहला ऐसा kernel था जिसने symmetric multiprocessing (SMP) का समर्थन किया, जिसका अर्थ है कि एक से अधिक CPU एक ही kernel को चला सकते हैं। पहले implementation में एक single lock, यानी big kernel lock (BKL) का उपयोग किया गया था, इसलिए एक समय में केवल एक ही processor kernel code के अंदर रह सकता था। परिणामस्वरूप, दूसरा CPU केवल user space में गणना करने वाले workload में मदद करता था, लेकिन system calls वाले workload में बहुत कम मदद कर पाता था, क्योंकि वे सभी एक ही lock के पीछे कतार में लगे होते थे।

उस lock को हटाने में पंद्रह साल लग गए। बचे हुए users को fine-grained locking में परिवर्तित किया गया, जिसका मुख्य श्रेय Arnd Bergmann को जाता है, और BKL को 18 मई 2011 को release हुए 2.6.39 में हटा दिया गया। Scheduler भी इसी धीमी गति से आगे बढ़ा: 2.6.0 में O(1) scheduler, 2007 में 2.6.23 से Completely Fair Scheduler (CFS), और अक्टूबर 2023 में 6.6 में EEVDF, जिसने CFS की जगह ली।

यही कारण है कि आज 4 vCPU वाला plan सामान्य बात है। यह एक ऐसी सीमा को भी दर्शाता है जिसे जानना आवश्यक है। एक shared virtual server पर आपका kernel आपके threads को schedule करता है, और hypervisor आपके kernel को schedule करता है। top चलाएं और %st field को पढ़ें। Steal time वह CPU समय है जिसे आपका kernel उपयोग करने के लिए तैयार था लेकिन host ने उसे किसी अन्य guest को दे दिया, इसलिए आपके kernel के भीतर की गई कोई भी ट्यूनिंग इसे वापस नहीं ला सकती।

2.6 सीरीज ने kernel build करने के तरीके को क्यों बदला

2.6 से पहले, version numbers जोड़ों में आते थे। दूसरा अंक सम (even) होने का मतलब एक stable series (2.4) था, और विषम (odd) का मतलब development (2.5) था। 2.4 को 4 January 2001 को और 2.6 को 17 December 2003 को release किया गया था, इसलिए users को अगली stable series के लिए लगभग तीन साल तक इंतजार करना पड़ा। Distributions इतना इंतजार नहीं कर सकती थीं, इसलिए उन्होंने backporting की। "2.4" ship करने वाले दो vendors के kernels के बीच हजारों patches का अंतर हो गया।

2.6 के बाद इस विभाजन को समाप्त कर दिया गया। Mainline अब लगभग दो सप्ताह की एक merge window खोलता है, नया काम स्वीकार करता है, फिर release candidates चलाता है जब तक कि काम शांत न हो जाए, और हर 9 से 10 सप्ताह में ship करता है; यही वह cadence है जिसे kernel.org आज भी document करता है। इस मॉडल का दूसरा हिस्सा 4 March 2005 को stable tree के पहले release के साथ आया, जो 2.6.11 का केवल fix-only update था, जिसे Greg Kroah-Hartman और Chris Wright द्वारा maintain किया गया था। Stable tree केवल fixes लेता है और features को अस्वीकार करता है।

एक दुष्प्रभाव: version number अब एक वादा नहीं रहा। 3.0, 4.0, 5.0 और 7.0 पूरी तरह से नए सिरे से लिखे गए (rewrites) नहीं हैं। Torvalds पहले अंक को तब बढ़ाते हैं जब दूसरा अंक इतना बड़ा हो जाता है कि उन्हें परेशान करने लगे, यही कारण है कि April 2026 में 6.19 के बाद 7.0 आया। एक server के लिए जो मायने रखता है वह यह है कि आपका distribution किस branch को track करता है, और क्या उस branch को अभी भी fixes मिल रहे हैं।

अप्रैल 2005 में BitKeeper के टूटने से git का जन्म कैसे हुआ

फरवरी 2002 से kernel का विकास BitKeeper में किया गया था, जो Larry McVoy की कंपनी BitMover का एक proprietary distributed version control system था। इसकी शुरुआत 2.5 series के साथ हुई थी। BitMover ने kernel developers को कुछ शर्तों के साथ एक मुफ्त licence दिया था: आप किसी प्रतिस्पर्धी version control tool पर काम नहीं कर सकते थे, और आप BitKeeper को reverse engineer नहीं कर सकते थे। कई developers को एक ऐसे tool के साथ मुफ्त kernel बनाना पसंद नहीं था जिसे पढ़ने की उन्हें अनुमति नहीं थी।

यह अप्रैल 2005 में टूट गया, जब Andrew Tridgell ने एक ऐसा program प्रदर्शित किया जो BitKeeper repositories के साथ संवाद करता था। BitMover ने इसे reverse engineering कहा और मुफ्त licence वापस ले लिया। विकास चक्र के बीच में ही kernel ने अपना version control system खो दिया।

git पर काम 3 अप्रैल 2005 को शुरू हुआ। Torvalds ने 6 अप्रैल को इसकी घोषणा की। 7 अप्रैल तक git self-hosting हो गया था, जिसका अर्थ है कि git का अपना इतिहास पहले से ही git में रखा जा रहा था। कई branches का पहला merge 18 अप्रैल को चला। जून 2005 में, git ने 2.6.12 के release का प्रबंधन किया। Torvalds ने जल्द ही रखरखाव Junio Hamano को सौंप दिया और वापस kernel पर लौट गए।

इसका design सीधे समस्या से निकला: हजारों contributors, और ऐसे maintainers जो एक ऐसे network पर एक-दूसरे से code pull करते हैं जिस पर कोई भरोसा नहीं करता। प्रत्येक object का नाम उसकी सामग्री के hash द्वारा रखा जाता है, इसलिए पुराने इतिहास के एक byte को बदलने से उसके बाद के हर commit का नाम बदल जाता है। इसीलिए एक clone केवल एक दावा नहीं बल्कि सबूत होता है। हर deploy pipeline, हर configuration repository, वह code host जहाँ अधिकांश टीमें push करती हैं और वह git server जिसे आप स्वयं चला सकते हैं, ये सभी एक kernel के बारे में हुए licence विवाद से उपजे हैं।

LTS मॉडल क्या वादा करता है और क्या नहीं

Mainline वह नहीं है जिसे आप run करते हैं। एक mainline release 9 से 10 सप्ताह बाद ही बदल दिया जाता है। Stable tree में प्रत्येक release के कुछ सप्ताह बाद तक fixes आते हैं। Longterm branches, जिन्हें आमतौर पर LTS लिखा जाता है, उनमें वर्षों तक fixes मिलते हैं और distributions इन्हीं पर आधारित होते हैं।

2.6.32, जिसे दिसंबर 2009 में release किया गया था, वह version है जहाँ यह मॉडल सफल साबित हुआ। RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 और Ubuntu 10.04 LTS सभी ने इसे ship किया था, और इस branch को फरवरी 2016 तक maintain किया गया, जो इसके आने के छह साल से अधिक समय बाद तक था। Red Hat ने इसे और आगे बढ़ाया और अपने 2.6.32-आधारित kernel को अपने स्वयं के backports पर तब तक रखा जब तक RHEL 6 का 2020 में अंत नहीं हुआ। समर्थन के उस दशक को मुफ्त में दोहराना ही वह मुख्य कारण है कि CentOS का अस्तित्व था और Rocky Linux तथा AlmaLinux ने उसकी जगह ली।

यह वादा एक से अधिक बार बदला है। पहले यह दो साल था, फिर कुछ branches के लिए छह साल। 2023 में stable maintainers ने डिफ़ॉल्ट अवधि को घटाकर दो साल कर दिया, क्योंकि पुराने trees में backporting करने में maintainer का समय खर्च होता है और पुरानी branches की वास्तविक testing बहुत कम हो पाती है। 25 फरवरी 2026 को Greg Kroah-Hartman ने उन कंपनियों के साथ चर्चा के बाद फिर से लंबी projections प्रकाशित कीं जो उन branches पर निर्भर हैं, और वर्तमान framework तीन से छह साल तक चलता है।

[
  {
    "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 branches की सूची देता है। सबसे पुराना, 5.10, Dec 2026 में समाप्त होने तक 6.0 वर्षों तक fixes प्राप्त करेगा। सबसे नया, 6.18, Dec 2028 तक चलने के लिए projected है, जो कि 3.1 वर्षों के fixes हैं।

इन तारीखों को एक अनुबंध के बजाय एक न्यूनतम सीमा के रूप में पढ़ें। 6.6 और 6.12 की projections दोनों फरवरी 2026 में आगे बढ़ गईं, और जिस branch का कोई उपयोग नहीं करता उसे बंद भी किया जा सकता है। आपका distribution आमतौर पर आपके लिए यह चुनाव करता है: Debian 13 में 6.12 होता है, और Ubuntu 26.04 LTS में 7.0 होता है। वह अंतर ही सर्वर पर LTS बनाम interim release के प्रश्न का व्यावहारिक सार है, और जब आप Ubuntu 24.04 को 26.04 में upgrade करते हैं तो वास्तव में यही आपके नीचे बदलता है।

इससे एक समस्या उत्पन्न होती है। Ubuntu 24.04 पर uname -r कुछ इस तरह प्रिंट करता है: 6.8.0-51-generic। यह एक upstream base और distribution के अपने backports का मिश्रण है, इसलिए यह संख्या आपको केवल यह बताती है कि branch कहाँ से शुरू हुई थी, न कि इसमें कौन से fixes शामिल हैं। जो scanners kernel को केवल उसके version string से आंकते हैं, वे ठीक इसी कारण से distribution kernels के खिलाफ गलत चेतावनियाँ (false alarms) देते हैं।

कर्नेल अभी किस विषय पर बहस कर रहा है

दो तर्क चल रहे हैं, और दोनों ही इस बारे में हैं कि काम किसे करना चाहिए।

दिसंबर 2022 में 6.1 में Rust को इंफ्रास्ट्रक्चर के रूप में शामिल किया गया था। 7.0 में experimental लेबल हटा दिया गया, इसलिए कर्नेल की मुख्य भाषाएं C, assembly और Rust हैं, और अब बिल्ड के लिए nightly compiler की आवश्यकता नहीं है। विवाद रखरखाव (maintenance) को लेकर है। एक C मेंटेनर जो किसी इंटरफेस को बदलता है, वह उन Rust बाइंडिंग्स को तोड़ सकता है जिन्हें वह पढ़ता नहीं है, और बहस इस बात पर है कि उन्हें ठीक करना किसका काम है।

दूसरा तर्क AI योगदान के बारे में है। Sasha Levin ने जुलाई 2025 में एक नीति प्रस्तावित की, जब मशीन-सहायता प्राप्त पैच की बढ़ती संख्या मेलिंग लिस्ट तक पहुंच गई। यह दस्तावेज़ 23 दिसंबर 2025 को कमिट किया गया था और अब यह कर्नेल की अपनी प्रक्रिया दस्तावेज़ीकरण में docs.kernel.org/process/coding-assistants.html पर उपलब्ध है। एक AI एजेंट को Signed-off-by टैग नहीं जोड़ना चाहिए, क्योंकि वह पंक्ति Developer Certificate of Origin (DCO) को प्रमाणित करती है और केवल एक व्यक्ति ही इसे प्रमाणित कर सकता है। सहायता की घोषणा Assisted-by: टैग के साथ की जाती है, जिसे समीक्षा के दौरान Co-developed-by: से बदल दिया गया था क्योंकि एक टूल लेखक नहीं होता है। उत्पन्न कोड GPL-2.0-only के साथ संगत होना चाहिए। पैच भेजने वाला व्यक्ति इसकी समीक्षा करता है और इसके लिए जिम्मेदारी उठाता है।

इस नीति के पीछे का दबाव समीक्षा का समय है। एक पैच बनाने में सेकंड लगते हैं, और एक की समीक्षा करने में मेंटेनर की पूरी दोपहर लग जाती है। एक टैग उस असंतुलन को ठीक नहीं करता है। जो यह सुरक्षित रखता है वह है प्रोवेनेंस (provenance): इतिहास यह रिकॉर्ड करना जारी रखता है कि प्रत्येक बदलाव के लिए किसने हस्ताक्षर किए, जो कि वह संपत्ति है जिसे 2004 में DCO के माध्यम से सुरक्षित करने के लिए पेश किया गया था।

आपके द्वारा किराए पर लिए गए सर्वर के लिए इस इतिहास का क्या अर्थ है

• लाइसेंस ही वह कारण है जिसके चलते आप उस kernel को पढ़ और फिर से बना (rebuild) सकते हैं जिसे आपका प्रदाता बूट करता है, और यही कारण है कि proprietary software उस पर चलता है।
• monolithic डिज़ाइन ही वह कारण है जिसके चलते एक driver bug पूरी मशीन को रीबूट कर देता है, और एक out-of-tree module को हर kernel upgrade पर फिर से बनाना पड़ता है।
• release model ही वह कारण है जिसके चलते version number आपको बहुत कम जानकारी देता है, जबकि branch और उसकी end-of-life तिथि आपको लगभग सब कुछ बता देती है।
• virtualisation का प्रकार यह तय करता है कि आप क्या कर सकते हैं: KVM पर आप अपना kernel बूट कर सकते हैं और modules लोड कर सकते हैं, जबकि container virtualisation पर जो host kernel साझा करता है, uname -r host का version दिखाता है, modprobe विफल हो जाता है, और कई sysctls केवल read-only होते हैं।

FAQ

Linux kernel अभी भी GPLv2 पर क्यों है, GPLv3 पर क्यों नहीं?

Torvalds ने 2007 में GPLv3 के खिलाफ निर्णय लिया था, जिसका मुख्य कारण इसकी anti-tivoisation आवश्यकता थी। यह आवश्यकता किसी भी ऐसे डिवाइस को, जिसमें GPL कोड हो, उस कोड के संशोधित संस्करण को स्वीकार करने के लिए बाध्य करती है। वे locked hardware को निर्माता का निजी मामला मानते हैं। व्यवहार में relicensing लगभग असंभव है, क्योंकि kernel का copyright हजारों contributors के पास है और इसके लिए कोई assignment agreement मौजूद नहीं है। kernel केवल GPL-2.0-only है, इसलिए केवल GPLv3 के तहत पेश किया गया कोड इसमें merge नहीं किया जा सकता।

क्या Linux kernel एक monolithic kernel है या microkernel?

यह loadable modules के साथ एक monolithic kernel है। Drivers और filesystems kernel के address space के भीतर चलते हैं, और lsmod अभी लोड किए गए modules को दिखाता है। इसका प्रभाव एक तरफ गति है तो दूसरी तरफ blast radius: एक दोषपूर्ण module पूरी मशीन को 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 का निर्माण करते हैं। kernel.org प्रत्येक के लिए अनुमानित end-of-life तिथि के साथ वर्तमान longterm branches की सूची देता है।

क्या Linux kernel AI द्वारा लिखा गया कोड स्वीकार करता है?

हाँ, दिसंबर 2025 में अपनाई गई एक नीति के तहत। tool का नाम Assisted-by: tag में होना चाहिए, AI agent को Signed-off-by line नहीं जोड़नी चाहिए, और generated कोड GPL-2.0-only के साथ संगत होना चाहिए। मानव submitter इसे sign off करता है, जिसका अर्थ है कि उन्होंने patch की समीक्षा की है और Developer Certificate of Origin के तहत इसकी जिम्मेदारी ली है।

मुझे सर्वर पर कौन सा kernel version चलाना चाहिए?

लगभग हर मामले में, वही जो आपका distribution maintain करता है। एक distribution kernel एक longterm branch होती है जिसमें backported fixes और vendor की testing शामिल होती है, और आपके provider की images और support व्यवस्था इसी पर आधारित होती है। जब आपको किसी विशिष्ट driver या feature की आवश्यकता हो, तभी नया mainline kernel build करें, और जिस branch पर आप जा रहे हैं, उसकी end-of-life तिथि की जाँच अवश्य करें।