Linux kernel చరిత్ర: ఇప్పటికీ ప్రభావం చూపే నిర్ణయాలు

Linux kernel చరిత్ర: సంక్షిప్త పరిచయం

Linux kernel చరిత్ర September 1991లో విడుదలైన version 0.01 నుంచి, ప్రస్తుతం serversపై boot అవుతున్న 7.x series వరకు సాగుతుంది. Release జాబితా ఇందులో అత్యంత ఆసక్తికరమైన భాగం కాదు. కొన్ని ముఖ్యమైన నిర్ణయాలు దీని నిర్మాణాన్ని నిర్దేశించాయి. వాటిలో ప్రతి నిర్ణయం మీరు ఈ మధ్యాహ్నం rent చేసే machineపై ఇప్పటికీ ప్రభావం చూపుతుంది.

ఇక్కడి తేదీలు మరియు 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 కింద ప్రచురించారు. Source పంపిణీ చేయాలని అది నిర్దేశించింది. అంతకంటే ముఖ్యమైన మరో వాక్యాన్ని కూడా చేర్చింది: "You may not distribute this for a fee, not even 'handling' costs." 1991లో software ను floppy disks పై విడుదల చేసేవారు. Floppy disks ను copy చేసి పంపడానికి ఖర్చు ఉండేది. ఆ నిబంధన వల్ల commercial Linux distribution అసాధ్యమైంది.

ఆయన దాన్ని మార్చారు. GNU General Public License (GPL) కు మార్పును January 1992లో విడుదలైన 0.12 release notes లో ప్రకటించారు. అది 1 February 1992న అమల్లోకి వచ్చింది. March 1992లో విడుదలైన Version 0.95, దాని కింద ప్రచురించిన మొదటి release. తరువాత Linux ఆధారంగా ఏర్పడిన ప్రతి business ఈ మార్పుపైనే ఆధారపడి ఉంది.

Kernel కేవలం GPL version 2 కింద మాత్రమే ఉంది. అది ఎప్పుడూ version 3కు మారలేదు. 2007లో Torvalds దాన్ని తిరస్కరించారు. దీనికి ప్రధాన కారణం GPLv3లోని anti-tivoisation నియమం. GPL code తో విడుదలయ్యే device, ఆ code యొక్క modified copyని కూడా అమలు చేయగలగాలని ఈ నియమం కోరుతుంది. Locked hardware తయారీదారు స్వయంగా తీసుకునే వ్యాపార నిర్ణయమని ఆయన భావించారు. 2017లో kernel developers Kernel Enforcement Statement ను ప్రచురించారు. అందులో GPLv3లోని ఒక అంశాన్ని అయినా స్వీకరించారు: ఉల్లంఘన గురించి తెలియజేసిన తరువాత దాన్ని సరిచేసిన వ్యక్తి తన licence ను కొనసాగించగలడు. మొదటి breach జరిగిన వెంటనే licence ను శాశ్వతంగా కోల్పోడు.

దీని వల్ల server పై రెండు ప్రభావాలు ఉంటాయి. మీరు boot చేసే kernel binary కు సరిపోలే source ను పొందే హక్కు మీకు ఉంటుంది. అందువల్ల మీరు inspect లేదా rebuild చేయలేని Linux kernel ను ఎవరూ మీకు అందించలేరు. అలాగే kernel పై ఉన్న copyright notice ప్రకారం, సాధారణ system calls ద్వారా kernel services ను ఉపయోగించే user programs కు ఆ licence వర్తించదు. అందుకే proprietary databases మరియు monitoring agents Linux కోసం విడుదలైనప్పుడు ఎటువంటి సమస్య ఏర్పడదు. Permissive licence దీనికి విరుద్ధమైన ఒత్తిడిని సృష్టిస్తుంది. Platform ను ఎంచుకునే ముందు ఈ తేడాను అర్థం చేసుకోవడం ఉపయోగకరం: server platforms గా Linux మరియు FreeBSD.

ఆచరణలో monolithic kernel ఎందుకు గెలిచింది

29 January 1992న Andrew Tanenbaum, comp.os.minix newsgroupలో "LINUX is obsolete" అనే శీర్షికతో ఒక సందేశాన్ని పోస్ట్ చేశారు. ఆయన రెండు వాదనలు చేశారు. Drivers మరియు filesystems ఒకే privileged address spaceలో నడిచే monolithic kernels 1970ల నాటి design అని, అవి సాధారణ processesగా నడిచే microkernels భవిష్యత్తు అని అన్నారు. అలాగే Linux Intel 386కు గట్టిగా అనుసంధానించబడి ఉందని, కాబట్టి అది ఎప్పటికీ ఇతర platformsకు port కాలేదని పేర్కొన్నారు.

Porting ద్వారా portability వాదనకు సమాధానం లభించింది. March 1995లో వచ్చిన Version 1.2లో Alpha, SPARC మరియు MIPS చేర్చబడ్డాయి. June 1996లో వచ్చిన Version 2.0లో 64-bit Alpha port చేర్చబడింది.

ఒక compromise ద్వారా design వాదనకు సమాధానం లభించింది. Linux ఎప్పుడూ microkernelగా మారలేదు. బదులుగా దీనిలో loadable kernel modules వచ్చాయి: నడుస్తున్న kernelలో insert చేసి, తరువాత remove చేయగల object files. అందువల్ల ఒక driverను kernel binary నుంచి విడిగా విడుదల చేయవచ్చు.

lsmod | head
modinfo virtio_net | head -5

ప్రస్తుతం ఏవి loadedగా ఉన్నాయో lsmod చూపిస్తుంది. Module ఏ file నుంచి వచ్చిందో, అది స్వీకరించే parameters ఏమిటో modinfo ముద్రిస్తుంది. Virtual serverలో disk మరియు network pathలో ఎక్కువ భాగం modulesగా ఉంటుంది. అందుకే తాను ఇంతకుముందు చూడని hardwareపైనా ఒకే kernel image boot అవుతుంది.

Microkernel designలో ఉండే ఖర్చు లేకుండా modules ఆ flexibilityను అందించాయి. ఒక driverను ప్రత్యేక processలో isolate చేస్తే ప్రతి callకు context switch మరియు message కోసం అదనపు ఖర్చు చెల్లించాలి. 1992లో ఆ ఖర్చు ఎక్కువగా ఉండేది.

Linux మిగిల్చిన ఖర్చును ముందుగానే పరిగణనలోకి తీసుకోవాలి: ఒక module పూర్తి kernel privilegesతో నడుస్తుంది. కాబట్టి ఒక తప్పు module ఒక processను మాత్రమే కాకుండా మొత్తం machineను down చేయవచ్చు. Out-of-tree modulesలో ఈ సమస్య ఎక్కువగా కనిపిస్తుంది. Mainlineలో లేని vendor driverను ప్రతి కొత్త kernelకు అనుగుణంగా మళ్లీ build చేయాలి. Upgrade సమయంలో DKMS ఇదే పని చేస్తుంది. ఆ build విఫలమైతే reboot తర్వాత device అందుబాటులో ఉండదు.

SMP పూర్తి కావడానికి పదిహేను సంవత్సరాలు ఎందుకు పట్టింది

జూన్ 1996లో విడుదలైన Linux 2.0, symmetric multiprocessing (SMP) కు మద్దతు ఇచ్చిన మొదటి kernel. అంటే ఒకే kernel లో ఒకటి కంటే ఎక్కువ CPUలు పనిచేయడం. మొదటి అమలులో big kernel lock (BKL) అనే ఒకే lock ఉపయోగించారు. అందువల్ల ఒకేసారి ఒక processor మాత్రమే kernel code లోకి ప్రవేశించగలిగేది. కాబట్టి user space లో గణనలు చేసే workload కు రెండవ CPU కొంత ప్రయోజనం ఇచ్చేది. system calls ఎక్కువగా ఉండే workload కు మాత్రం ప్రయోజనం చాలా తక్కువగా ఉండేది, ఎందుకంటే అవన్నీ అదే lock వెనుక queue లో వేచి ఉండేవి.

ఆ lock ను తొలగించడానికి పదిహేను సంవత్సరాలు పట్టింది. మిగిలిన వినియోగాలను fine-grained locking కు మార్చే పనిని ప్రధానంగా Arnd Bergmann చేశారు. 18 May 2011న విడుదలైన 2.6.39లో BKL ను తొలగించారు. Scheduler కూడా ఇదే నెమ్మదైన కాలక్రమంలో అభివృద్ధి చెందింది: 2.6.0లో O(1) scheduler, 2007లో 2.6.23 నుంచి Completely Fair Scheduler (CFS), అలాగే October 2023లో 6.6లో CFS స్థానాన్ని తీసుకున్న EEVDF.

అందుకే ఇప్పుడు 4 vCPU plan సాధారణ విషయంగా మారింది. అయితే ఇది తెలుసుకోవాల్సిన ఒక పరిమితిని కూడా చూపిస్తుంది. Shared virtual server పై మీ kernel మీ threads ను schedule చేస్తుంది, hypervisor మీ kernel ను schedule చేస్తుంది. top ను అమలు చేసి %st field ను చదవండి. Steal time అంటే మీ kernel ఉపయోగించడానికి సిద్ధంగా ఉన్న CPU సమయాన్ని host మరో guest కు కేటాయించడం. కాబట్టి మీ kernel లో చేసే tuning ద్వారా ఆ సమయాన్ని తిరిగి పొందలేరు.

kernel ఎలా నిర్మించబడుతుందో 2.6 సిరీస్ మార్చిన విధానం

2.6కి ముందు version numbers జతలుగా ఉండేవి. రెండో సంఖ్య సరి సంఖ్య అయితే అది stable series (2.4), బేసి సంఖ్య అయితే development series (2.5). 2.4ను 4 January 2001న విడుదల చేశారు. 2.6ను 17 December 2003న విడుదల చేశారు. అందువల్ల తదుపరి stable series కోసం users దాదాపు మూడు సంవత్సరాలు వేచి ఉండాల్సి వచ్చేది. Distributions అంతకాలం వేచి ఉండలేక backporting చేశాయి. ఒకే "2.4"ను విడుదల చేసిన ఇద్దరు vendors, వేలాది patches తేడా ఉన్న kernels ను అందించేవారు.

2.6 తర్వాత ఈ విభజనను తొలగించారు. ఇప్పుడు mainline దాదాపు రెండు వారాల merge window ను తెరుస్తుంది. ఆ సమయంలో కొత్త work ను స్వీకరిస్తుంది. తరువాత release candidates ను అమలు చేస్తుంది. మార్పులు స్థిరపడే వరకు ఈ ప్రక్రియ కొనసాగుతుంది. ఆపై ప్రతి 9 నుంచి 10 వారాలకు ఒకసారి release చేస్తుంది. kernel.org ఇప్పటికీ ఇదే cadence ను document చేస్తోంది. ఈ model లోని మరో భాగం 4 March 2005న వచ్చింది. ఆ రోజున stable tree యొక్క మొదటి release వెలువడింది. అది 2.6.11 కోసం fixes మాత్రమే కలిగిన update. దీనిని Greg Kroah-Hartman మరియు Chris Wright నిర్వహించారు. 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 ను అనుసరిస్తోంది, అలాగే ఆ branchకు ఇప్పటికీ fixes అందుతున్నాయా అన్నదే.

2005 ఏప్రిల్‌లో BitKeeper వివాదం git ఆవిర్భావానికి ఎలా దారితీసింది

2002 ఫిబ్రవరి నుంచి kernel అభివృద్ధి BitKeeperలో జరిగింది. ఇది 2.5 series నుంచి Larry McVoyకు చెందిన BitMover సంస్థ అభివృద్ధి చేసిన proprietary distributed version control system. BitMover kernel developersకు కొన్ని షరతులతో ఉచిత licence ఇచ్చింది: పోటీ version control toolపై పని చేయకూడదు, BitKeeperను reverse engineer చేయకూడదు. తాము పరిశీలించడానికి అనుమతి లేని toolతో ఉచిత kernelను అభివృద్ధి చేయడం చాలామంది developersకు నచ్చలేదు.

Andrew Tridgell BitKeeper repositoriesతో సంభాషించే ఒక programను ప్రదర్శించిన తర్వాత, 2005 ఏప్రిల్‌లో ఈ వ్యవస్థ విరిగిపోయింది. BitMover దీన్ని reverse engineeringగా పేర్కొని, ఉచిత licenceను ఉపసంహరించుకుంది. Development cycle మధ్యలో kernel తన version control systemను కోల్పోయింది.

gitపై పని 2005 ఏప్రిల్ 3న ప్రారంభమైంది. Torvalds దాన్ని ఏప్రిల్ 6న ప్రకటించాడు. ఏప్రిల్ 7న git self-hosting స్థితికి వచ్చింది. అంటే git యొక్క స్వంత history అప్పటికే gitలోనే భద్రపరచబడింది. అనేక branches యొక్క మొదటి merge ఏప్రిల్ 18న జరిగింది. 2005 జూన్‌లో git, 2.6.12 విడుదలను నిర్వహించింది. కొద్దికాలం తర్వాత Torvalds maintenance బాధ్యతను Junio Hamanoకు అప్పగించి kernelపై తిరిగి పని చేశాడు.

ఈ design సమస్య నుంచే నేరుగా రూపొందింది: వేలాది contributors, అలాగే ఎవరికీ నమ్మకం లేని network ద్వారా పరస్పరం ఒకరి నుంచి మరొకరు changes pull చేసుకునే maintainers. ప్రతి objectకు దాని content యొక్క hash ఆధారంగా పేరు ఉంటుంది. అందువల్ల పాత historyలో ఒక్క byte మార్చినా, దాని తర్వాతి ప్రతి commit పేరు మారుతుంది. అందుకే clone ఒక claim కాకుండా సాక్ష్యం. ప్రతి deploy pipeline, ప్రతి configuration repository, చాలా teams push చేసే code host మరియు మీరే నడపగల git server — ఇవన్నీ kernelకు సంబంధించిన ఒక licensing వివాదం నుంచి ఆవిర్భవించాయి.

LTS నమూనా హామీ ఇచ్చేది, ఇవ్వనిది

Mainline అనేది మీరు నడిపే విడుదల కాదు. Mainline విడుదల 9 నుంచి 10 వారాల తరువాత supersede అవుతుంది. ప్రతి విడుదల తరువాత stable tree కొన్ని వారాల పాటు fixes ను కలిగి ఉంటుంది. సాధారణంగా LTS అని రాసే longterm branches fixes ను సంవత్సరాల పాటు కలిగి ఉంటాయి. Distributions తమ builds కు వీటినే ఆధారంగా తీసుకుంటాయి.

December 2009లో విడుదలైన 2.6.32 వద్ద ఈ నమూనా తన సామర్థ్యాన్ని నిరూపించింది. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 మరియు Ubuntu 10.04 LTS ఇవన్నీ దీన్ని ship చేశాయి. ఈ branch February 2016 వరకు maintain చేయబడింది. అంటే ఇది విడుదలైన తరువాత ఆరు సంవత్సరాలకు పైగా కొనసాగింది.

ఈ హామీ ఒకటి కంటే ఎక్కువసార్లు మారింది. మొదట ఇది రెండు సంవత్సరాలు. తరువాత కొన్ని branches కు ఆరు సంవత్సరాలుగా మారింది. 2023లో stable maintainers default వ్యవధిని మళ్లీ రెండు సంవత్సరాలకు తగ్గించారు. కారణం పాత trees లో backporting చేయడానికి maintainer సమయం ఎక్కువగా పడటం, అలాగే పాత branches కు వాస్తవ testing తక్కువగా ఉండటం. 25 February 2026న ఆ branches పై ఆధారపడే companies తో చర్చించిన తరువాత Greg Kroah-Hartman మళ్లీ ఎక్కువ వ్యవధి అంచనాలను ప్రచురించారు. ప్రస్తుత 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
  }
]

August 2026 నాటికి kernel.org 6 longterm branches ను జాబితా చేస్తుంది. వాటిలో అత్యంత పాతది అయిన 5.10, Dec 2026లో ముగిసే సమయానికి 6.0 సంవత్సరాల పాటు fixes ను కలిగి ఉంటుంది. అత్యంత కొత్తది అయిన 6.18, Dec 2028 వరకు కొనసాగుతుందని అంచనా. అంటే 3.1 సంవత్సరాల fixes అందుబాటులో ఉంటాయి.

ఈ తేదీలను contract గా కాకుండా కనీస పరిమితిగా చూడండి. 6.6 మరియు 6.12 projections రెండూ February 2026లో మరింత ముందుకు మారాయి. అయితే ఎవరూ ఉపయోగించని branch ను అంతకుముందే తొలగించవచ్చు. సాధారణంగా మీకు బదులుగా distribution ఈ ఎంపిక చేస్తుంది: Debian 13, 6.12 ను ship చేస్తుంది. Ubuntu 26.04 LTS, 7.0 ను ship చేస్తుంది. ఇదే serverలో LTS మరియు interim release మధ్య ప్రశ్నకు సంబంధించిన ఆచరణాత్మక విషయం. మీరు Ubuntu 24.04ను 26.04కు upgrade చేసినప్పుడు మీ క్రింద ఉన్న వ్యవస్థలో వాస్తవంగా మారేది కూడా ఇదే.

దీనివల్ల ఒక సమస్య ఏర్పడుతుంది. Ubuntu 24.04లో uname -r అమలు చేస్తే సాధారణంగా 6.8.0-51-generic వంటి output కనిపిస్తుంది. ఇది upstream base కు distribution స్వంత backports కలిపినది. అందువల్ల ఆ number branch ఎక్కడ ప్రారంభమైందో మాత్రమే చెబుతుంది; అందులో ఏ fixes ఉన్నాయో చెప్పదు. ఈ కారణంగానే kernel version string ఆధారంగా kernel ను అంచనా వేసే scanners distribution kernels పై false alarms ఉత్పత్తి చేస్తాయి.

ప్రస్తుతం kernel ఏ విషయంపై వాదిస్తోంది

ప్రస్తుతం రెండు వాదనలు కొనసాగుతున్నాయి. రెండింటిలోనూ పని ఎవరు చేయాలనే ప్రశ్నే ఉంది.

2022 Decemberలో 6.1లో Rust infrastructureగా చేరింది. 7.0లో experimental అనే గుర్తింపు తొలగిపోయింది. అందువల్ల kernel యొక్క ప్రధాన భాషలు C, assembly, Rustగా ఉన్నాయి. Buildకు ఇక nightly compiler అవసరం లేదు. వివాదం maintenance గురించి. C maintainer ఒక interfaceను మార్చితే, వారు చూడని Rust bindings విరిగిపోవచ్చు. వాటిని సరిచేయడం ఎవరి బాధ్యత అనే విషయంపైనే వాదన జరుగుతోంది.

రెండవ వాదన AI contribution గురించి. Machine-assisted patches జాబితాలకు పెరుగుతున్న సంఖ్యలో చేరిన తరువాత, Sasha Levin July 2025లో ఒక policyని ప్రతిపాదించారు. ఆ పత్రం 23 December 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కు అనుకూలంగా ఉండాలి. Patchను పంపే వ్యక్తి దాన్ని review చేసి, దాని బాధ్యతను స్వీకరిస్తారు.

ఈ policy వెనుక ఉన్న ప్రధాన ఒత్తిడి review సమయం. Patchను రూపొందించడానికి కొన్ని seconds పడతాయి. దాన్ని review చేయడానికి maintainer యొక్క ఒక afternoon పడుతుంది. Tag ఈ అసమతుల్యతను పరిష్కరించదు. అయితే అది provenanceను కాపాడుతుంది. ప్రతి మార్పుకు ఎవరు సంతకం చేశారో historyలో నమోదవుతూనే ఉంటుంది. 2004లో DCOను ప్రవేశపెట్టడానికి రక్షించాలనుకున్న లక్షణం ఇదే.

మీరు అద్దెకు తీసుకున్న సర్వర్‌కు ఈ చరిత్ర అర్థం

• మీరు ఉపయోగిస్తున్న provider ప్రారంభించే kernel ను చదివి, మళ్లీ build చేయగలగడానికి licence కారణం. Proprietary software దానిపై ఇప్పటికీ నడవడానికి కూడా ఇదే కారణం.
• ఒక driver లోని bug మొత్తం machine ను reboot చేయడానికి monolithic design కారణం. ప్రతి kernel upgrade సమయంలో out-of-tree module ను మళ్లీ build చేయాల్సి రావడానికి కూడా ఇదే కారణం.
• Version number మీకు చాలా తక్కువ సమాచారాన్ని మాత్రమే అందించడానికి release model కారణం. Branch మరియు దాని end-of-life date దాదాపు మొత్తం సమాచారాన్ని అందిస్తాయి.
• మీరు అసలు ఏమి చేయగలరో virtualisation type నిర్ణయిస్తుంది. KVMలో మీరు మీ స్వంత kernel ను boot చేసి modules load చేయవచ్చు. Host kernel ను share చేసే container virtualisationలో uname -r host version ను చూపిస్తుంది, modprobe విఫలమవుతుంది, ఇంకా కొన్ని sysctls read-onlyగా ఉంటాయి.

FAQ

Linux kernel ఇప్పటికీ GPLv2 లోనే ఎందుకు ఉంది, GPLv3 లో ఎందుకు లేదు?

2007లో Torvalds GPLv3 ను స్వీకరించకూడదని నిర్ణయించారు. దీనికి ప్రధాన కారణం GPL code ను పంపిణీ చేసే పరికరం, ఆ code యొక్క సవరించిన సంస్కరణను కూడా స్వీకరించాల్సిందేనని నిర్దేశించే anti-tivoisation నిబంధన. Locked hardware ను తయారీదారు వ్యాపార నిర్ణయంగా ఆయన పరిగణిస్తారు. ఆచరణలో 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 లోనే నడుస్తాయి. ప్రస్తుతం load అయిన వాటిని lsmod చూపిస్తుంది. దీనివల్ల ఒకవైపు వేగం లభిస్తుంది. మరోవైపు ప్రభావ పరిధి పెద్దదిగా ఉంటుంది. లోపభూయిష్ట module మొత్తం machine ను panic చేయవచ్చు. Microkernel లో అదే పరిస్థితి ఒక process ను మాత్రమే ప్రభావితం చేస్తుంది. 1992 నుంచి ఈ తేడా కొంత తగ్గింది. దీనికి కారణాలు user space లో నడిచే FUSE filesystems మరియు kernel అమలు చేయడానికి ముందు ధృవీకరించే eBPF programs.

mainline, stable మరియు longterm kernels మధ్య తేడా ఏమిటి?

mainline అనేది Torvalds యొక్క tree. ఇది ప్రతి 9 నుంచి 10 వారాలకు విడుదల అవుతుంది. కొత్త features ముందుగా అక్కడే చేరతాయి. stable, ఇటీవలి mainline release ను తీసుకుని, కొన్ని వారాలపాటు bug fixes అందుకుంటుంది. longterm branches సంవత్సరాలపాటు fixes పొందుతూనే ఉంటాయి. Distributions తమ kernels ను వీటిపై ఆధారపడి నిర్మిస్తాయి. ప్రతి longterm branch కు అంచనా end-of-life date ను kernel.org చూపిస్తుంది.

Linux kernel, AI రాసిన code ను స్వీకరిస్తుందా?

అవును. December 2025లో అమలులోకి వచ్చిన policy ప్రకారం ఇది అనుమతించబడుతుంది. Tool పేరును Assisted-by: tag లో పేర్కొనాలి. AI agent Signed-off-by line ను జోడించకూడదు. Generated code GPL-2.0-only కు అనుకూలంగా ఉండాలి. Human submitter sign off చేస్తారు. అంటే వారు patch ను పరిశీలించి, Developer Certificate of Origin కింద దాని బాధ్యతను స్వీకరించారని అర్థం.

Server పై ఏ kernel version నడపాలి?

దాదాపు ప్రతి సందర్భంలో మీ distribution నిర్వహించే version ను నడపాలి. Distribution kernel అనేది longterm branch, backported fixes మరియు vendor testing కలయిక. మీ provider images మరియు support arrangements కూడా సాధారణంగా దీనినే ఆధారంగా తీసుకుంటాయి. నిర్దిష్ట driver లేదా feature అవసరమైనప్పుడు మాత్రమే కొత్త mainline kernel ను build చేయండి. మీరు మారబోయే branch యొక్క end-of-life date ను పరిశీలించిన తర్వాతే దానికి కట్టుబడండి.