Linux kernel வரலாறு: முக்கிய தொழில்நுட்ப முடிவுகள்

Linux kernel வரலாற்றின் சுருக்கமான வடிவம்

Linux kernel வரலாறு செப்டம்பர் 1991-ல் பதிப்பு 0.01-ல் தொடங்கி, இன்று servers-ல் இயங்கும் 7.x தொடர் வரை நீள்கிறது. இதன் release பட்டியல் இதில் மிகக் குறைவான முக்கியத்துவம் வாய்ந்த பகுதியாகும். ஒரு சில முடிவுகளே இதன் கட்டமைப்பைத் தீர்மானித்தன, ஒவ்வொன்றும் இன்று நீங்கள் வாடகைக்கு எடுக்கும் machine-ல் ஒரு தாக்கத்தை ஏற்படுத்துகின்றன.

இங்குள்ள தேதிகள் மற்றும் பதிப்பு எண்கள் kernel.org மற்றும் அது வெளியிடும் release வரலாற்றிலிருந்து பெறப்பட்டவை. ஆகஸ்ட் 2026 நிலவரப்படி தற்போதைய நிலை: 7.0 பதிப்பு 12 ஏப்ரல் 2026-லும், 7.1 பதிப்பு 14 ஜூன் 2026-லும் வந்தன, மேலும் 7.2 பதிப்பு release candidates நிலையில் உள்ளது.

1992-ல் GPL-ஐத் தேர்ந்தெடுத்ததன் முக்கியத்துவம்

பதிப்பு 0.01, 17 செப்டம்பர் 1991 அன்று Torvalds சொந்தமாக எழுதிய உரிமத்தின் கீழ் வெளியிடப்பட்டது. இது source code-ஐ விநியோகிக்க வேண்டும் என்று கட்டாயப்படுத்தியது, மேலும் முக்கியமான ஒரு வரியையும் சேர்த்தது: "இதற்கு நீங்கள் கட்டணம் வசூலிக்கக்கூடாது, 'கையாளுதல்' (handling) செலவுகளுக்குக் கூட வசூலிக்கக்கூடாது." 1991-ல் மென்பொருள் floppy disks மூலம் விநியோகிக்கப்பட்டது, அவற்றை நகலெடுத்து அனுப்புவதற்குச் செலவாகும். அந்த நிபந்தனை, வணிக ரீதியான Linux விநியோகத்தை சாத்தியமற்றதாக்கியது.

அவர் அதை மாற்றினார். GNU General Public License (GPL)-க்கு மாறியது ஜனவரி 1992-ல் 0.12 release notes-ல் அறிவிக்கப்பட்டு, 1 பிப்ரவரி 1992 முதல் நடைமுறைக்கு வந்தது. மார்ச் 1992-ல் வெளியான பதிப்பு 0.95, அதன் கீழ் வெளியிடப்பட்ட முதல் பதிப்பாகும். பிற்காலத்தில் Linux-ஐ அடிப்படையாகக் கொண்டு உருவான ஒவ்வொரு வணிகமும் அந்த மாற்றத்தையே சார்ந்துள்ளது.

Kernel, GPL version 2-ல் மட்டுமே உள்ளது, அது version 3-க்கு மாறவில்லை. 2007-ல் Torvalds இதற்கு மறுப்பு தெரிவித்தார்; இதற்கு முக்கிய காரணம் GPLv3-ல் உள்ள anti-tivoisation விதி ஆகும். இந்த விதி, GPL code-ஐக் கொண்ட ஒரு சாதனம், மாற்றியமைக்கப்பட்ட code-ஐயும் ஏற்க வேண்டும் என்று கூறுகிறது. பூட்டப்பட்ட hardware-ஐ தயாரிப்பாளரின் சொந்த விவகாரமாகவே அவர் கருதினார். 2017-ல், kernel உருவாக்குநர்கள் Kernel Enforcement Statement-ஐ வெளியிட்டனர். இது GPLv3-ன் ஒரு பகுதியை ஏற்றுக்கொண்டது: ஒரு மீறலைச் சுட்டிக்காட்டிய பிறகு அதைச் சரிசெய்பவர் தனது உரிமத்தைத் தக்கவைத்துக் கொள்ளலாம்; முதல் மீறலிலேயே உரிமத்தை நிரந்தரமாக இழக்க வேண்டியதில்லை.

ஒரு server-ல் இதற்குக் இரண்டு விளைவுகள் உள்ளன. நீங்கள் boot செய்யும் kernel binary-க்கு இணையான source code-ஐப் பெறும் உரிமை உங்களுக்கு உண்டு; எனவே, ஆய்வு செய்யவோ அல்லது மீண்டும் உருவாக்கவோ முடியாத ஒரு Linux kernel-ஐ யாரும் உங்களுக்கு வழங்க முடியாது. மேலும், kernel-ல் உள்ள பதிப்புரிமை அறிவிப்பு, சாதாரண system calls மூலம் kernel சேவைகளைப் பயன்படுத்தும் பயனர் நிரல்களுக்கு இந்த உரிமம் பொருந்தாது என்று கூறுகிறது. இதனால்தான், proprietary databases மற்றும் monitoring agents போன்றவை எதையும் பாதிக்காமல் Linux-ல் இயங்குகின்றன. ஒரு permissive உரிமம் இதற்கு நேர்மாறான அழுத்தத்தை உருவாக்குகிறது. ஒரு தளத்தைத் தேர்ந்தெடுக்கும் முன் அந்த வித்தியாசத்தைப் புரிந்துகொள்வது அவசியம்: server தளங்களாக Linux மற்றும் FreeBSD.

நடைமுறையில் monolithic kernel ஏன் வெற்றி பெற்றது

ஜனவரி 29, 1992 அன்று, Andrew Tanenbaum என்பவர் "LINUX is obsolete" என்ற தலைப்பில் comp.os.minix செய்திக்குழுவில் ஒரு செய்தியைப் பதிவிட்டார். அவர் இரண்டு கருத்துகளை முன்வைத்தார். Drivers மற்றும் filesystems ஆகியவை ஒரே privileged address space-க்குள் இயங்கும் monolithic kernels என்பது 1970-களின் வடிவமைப்பு என்றும், அந்தப் பகுதிகள் சாதாரண process-களாக இயங்கும் microkernels தான் எதிர்காலம் என்றும் அவர் கூறினார். மேலும், Linux என்பது Intel 386-உடன் பிணைக்கப்பட்டுள்ளதால், அது ஒருபோதும் பிற தளங்களுக்குச் செல்லாது என்றும் அவர் வாதிட்டார்.

இதற்கு, porting செய்வதன் மூலம் portability குறித்த வாதத்திற்குப் பதிலளிக்கப்பட்டது. மார்ச் 1995-ல் வெளியான 1.2 பதிப்பில் Alpha, SPARC மற்றும் MIPS சேர்க்கப்பட்டன. ஜூன் 1996-ல் வெளியான 2.0 பதிப்பில் 64-bit Alpha port சேர்க்கப்பட்டது.

வடிவமைப்பு குறித்த வாதத்திற்கு ஒரு சமரசத்தின் மூலம் பதிலளிக்கப்பட்டது. Linux ஒருபோதும் microkernel-ஆக மாறவில்லை. அதற்குப் பதிலாக, loadable kernel modules அறிமுகப்படுத்தப்பட்டன: இவை இயங்கிக்கொண்டிருக்கும் kernel-க்குள் நீங்கள் சேர்க்கக்கூடிய மற்றும் நீக்கக்கூடிய object files ஆகும். இதனால், ஒரு driver-ஆனது kernel binary-யிலிருந்து தனித்தே விநியோகிக்கப்படுகிறது.

lsmod | head
modinfo virtio_net | head -5

lsmod தற்போது என்னென்ன modules ஏற்றப்பட்டுள்ளன என்பதைப் பட்டியலிடுகிறது. modinfo அந்த module எந்தக் கோப்பிலிருந்து வந்தது மற்றும் அது ஏற்கும் parameters எவை என்பதைக் காட்டுகிறது. ஒரு virtual server-ல், disk மற்றும் network பாதையின் பெரும்பகுதி modules-ஆகவே இருக்கும்; இதனால்தான், ஒரு kernel image தான் இதுவரை பார்த்திராத வன்பொருளிலும் (hardware) boot ஆகிறது.

Microkernel வடிவமைப்பில் இருந்த செலவு இல்லாமல், modules அந்த நெகிழ்வுத்தன்மையை (flexibility) வழங்கின. ஒரு driver-ஐத் தனி process-ஆகப் பிரிப்பது என்பது, ஒவ்வொரு அழைப்பிற்கும் (call) ஒரு context switch மற்றும் message-க்குச் செலவு செய்வதாகும்; 1992-ல் அந்தச் செலவு மிக அதிகமாக இருந்தது.

Linux-ல் இன்றும் இருக்கும் அந்தச் செலவை நாம் திட்டமிட்டு கையாள வேண்டும்: ஒரு module முழுமையான kernel உரிமைகளுடன் இயங்குகிறது, எனவே ஒரு தவறான module ஒரு process-ஐ மட்டும் பாதிக்காமல் முழு கணினியையும் முடக்கிவிடும். Out-of-tree modules-ல் தான் இந்தச் சிக்கல் அதிகம் ஏற்படுகிறது. Mainline-ல் இல்லாத ஒரு vendor driver-ஐ ஒவ்வொரு புதிய kernel-க்கும் ஏற்ப மீண்டும் உருவாக்க (rebuild) வேண்டும். இதையே upgrade-ன் போது DKMS செய்கிறது. அந்த build தோல்வியுற்றால், reboot-க்குப் பிறகு அந்தச் சாதனம் (device) கிடைக்காது.

SMP முடிவடைய ஏன் பதினைந்து ஆண்டுகள் ஆனது

ஜூன் 1996-ல் வெளியான Linux 2.0, symmetric multiprocessing (SMP)-ஐ ஆதரித்த முதல் kernel ஆகும். அதாவது, ஒரே kernel-ஐ ஒன்றுக்கும் மேற்பட்ட CPU-க்கள் இயக்க முடியும். இதன் முதல் அமலாக்கம், big kernel lock (BKL) என்ற ஒற்றை lock-ஐப் பயன்படுத்தியது. இதனால், ஒரு நேரத்தில் ஒரு processor மட்டுமே kernel code-க்குள் இருக்க முடியும். எனவே, இரண்டாவது CPU, user space-ல் கணக்கீடுகளைச் செய்யும் பணிச்சுமைக்கு உதவியது. ஆனால், system calls-ஐச் சார்ந்த பணிச்சுமைக்கு இது பெரிய அளவில் உதவவில்லை, ஏனெனில் அவை ஒரே lock-க்காக வரிசையில் காத்திருக்க வேண்டியிருந்தது.

அந்த lock-ஐ நீக்க பதினைந்து ஆண்டுகள் ஆனது. மீதமிருந்த பயனர்கள் fine-grained locking முறைக்கு மாற்றப்பட்டனர். இந்த வேலையை பெரும்பாலும் Arnd Bergmann செய்தார். இறுதியில், 18 மே 2011 அன்று வெளியான 2.6.39 பதிப்பில் BKL நீக்கப்பட்டது. Scheduler-ம் இதே மெதுவான காலவரிசையிலேயே முன்னேறியது: 2.6.0-ல் O(1) scheduler, 2007-ல் 2.6.23 பதிப்பில் Completely Fair Scheduler (CFS), மற்றும் அக்டோபர் 2023-ல் 6.6 பதிப்பில் CFS-க்கு மாற்றாக EEVDF அறிமுகமானது.

இந்த உழைப்பின் காரணமாகவே, இன்று 4 vCPU திட்டம் என்பது சாதாரணமாகக் கருதப்படுகிறது. இது கவனிக்க வேண்டிய ஒரு எல்லையையும் குறிக்கிறது. பகிரப்பட்ட virtual server-ல், உங்கள் kernel உங்கள் threads-ஐ நிர்வகிக்கிறது, hypervisor உங்கள் kernel-ஐ நிர்வகிக்கிறது. top கட்டளையை இயக்கி, %st புலத்தைப் பார்க்கவும். Steal time என்பது உங்கள் kernel பயன்படுத்தத் தயாராக இருந்தும், host அதை மற்றொரு guest-க்கு வழங்கிய CPU நேரமாகும். எனவே, உங்கள் kernel-க்குள் எந்த மாற்றங்களைச் செய்தாலும் இதைச் சரிசெய்ய முடியாது.

2.6 தொடர் kernel உருவாக்க முறையை எவ்வாறு மாற்றியது

2.6-க்கு முன்பு, version எண்கள் ஜோடிகளாக இருந்தன. இரண்டாவது எண் இரட்டையாக இருந்தால் அது stable தொடர் (2.4), ஒற்றையாக இருந்தால் அது development தொடர் (2.5). 2.4 பதிப்பு 4 ஜனவரி 2001-லும், 2.6 பதிப்பு 17 டிசம்பர் 2003-லும் வெளியானது. எனவே, அடுத்த stable தொடருக்காக பயனர்கள் கிட்டத்தட்ட மூன்று ஆண்டுகள் காத்திருக்க வேண்டியிருந்தது. Linux distributions-ஆல் அவ்வளவு காலம் காத்திருக்க முடியவில்லை, அதனால் அவர்கள் backport செய்தனர். "2.4" என்று பெயரிடப்பட்டிருந்தாலும், இரண்டு வெவ்வேறு vendors வழங்கிய kernels ஆயிரக்கணக்கான patches வேறுபாடுகளைக் கொண்டிருந்தன.

2.6-க்குப் பிறகு இந்த பிளவு கைவிடப்பட்டது. தற்போது mainline சுமார் இரண்டு வாரங்களுக்கு merge window-ஐத் திறந்து புதிய பணிகளை ஏற்கும். பின்னர் release candidates வெளியிடப்பட்டு, பணிகள் அமைதியடையும் வரை தொடரும். kernel.org ஆவணங்களின்படி, ஒவ்வொரு 9 முதல் 10 வாரங்களுக்கும் ஒருமுறை புதிய பதிப்பு வெளியிடப்படுகிறது. இந்த மாதிரியின் மற்றொரு பகுதி 4 மார்ச் 2005 அன்று stable tree-ன் முதல் வெளியீட்டுடன் தொடங்கியது. இது 2.6.11-க்கான பிழைத்திருத்தங்களை (fixes) மட்டுமே கொண்ட பதிப்பாகும், இதை Greg Kroah-Hartman மற்றும் Chris Wright பராமரித்தனர். Stable tree பிழைத்திருத்தங்களை மட்டுமே ஏற்கும், புதிய அம்சங்களை (features) நிராகரிக்கும்.

இதன் ஒரு பக்க விளைவு: version எண் ஒரு வாக்குறுதியாக இருப்பதை நிறுத்திவிட்டது. 3.0, 4.0, 5.0 மற்றும் 7.0 ஆகியவை முழுமையாக மீண்டும் எழுதப்பட்டவை அல்ல. இரண்டாவது எண் தனக்கு சங்கடமான அளவுக்கு பெரியதாக வளரும்போது, Torvalds முதல் எண்ணை உயர்த்துகிறார். இதனால்தான் ஏப்ரல் 2026-ல் 6.19-க்கு பிறகு 7.0 வெளியானது. ஒரு server-க்கு முக்கியமானது என்னவென்றால், உங்கள் distribution எந்த branch-ஐப் பின்பற்றுகிறது மற்றும் அந்த branch-க்கு இன்னும் பிழைத்திருத்தங்கள் கிடைக்கிறதா என்பதுதான்.

BitKeeper முறிவு எவ்வாறு ஏப்ரல் 2005-ல் git-ஐ உருவாக்கியது

பிப்ரவரி 2002 முதல், 2.5 தொடக்கத்திலிருந்து, Linux kernel-ஆனது Larry McVoy-ன் BitMover நிறுவனத்தின் தனியுரிம விநியோகிக்கப்பட்ட பதிப்பு கட்டுப்பாட்டு அமைப்பான (proprietary distributed version control system) BitKeeper-ல் உருவாக்கப்பட்டது. BitMover, kernel உருவாக்குநர்களுக்கு சில நிபந்தனைகளுடன் இலவச உரிமத்தை வழங்கியது: போட்டியிடும் பதிப்பு கட்டுப்பாட்டு கருவியில் நீங்கள் பணியாற்றக்கூடாது, மேலும் BitKeeper-ஐ reverse engineer செய்யக்கூடாது. ஒரு இலவச kernel-ஐ உருவாக்கும்போது, அதன் கருவியை ஆய்வு செய்ய அனுமதி இல்லாததை பல உருவாக்குநர்கள் விரும்பவில்லை.

ஏப்ரல் 2005-ல், Andrew Tridgell என்பவர் BitKeeper repositories-உடன் தொடர்பு கொள்ளும் ஒரு நிரலைச் செய்து காட்டிய பிறகு, இந்த உறவு முறிந்தது. BitMover இதை reverse engineering என்று கூறி, இலவச உரிமத்தை ரத்து செய்தது. ஒரு மேம்பாட்டு சுழற்சியின் நடுவில் kernel தனது பதிப்பு கட்டுப்பாட்டு அமைப்பை இழந்தது.

git-க்கான பணிகள் ஏப்ரல் 3, 2005 அன்று தொடங்கின. Torvalds ஏப்ரல் 6 அன்று இதை அறிவித்தார். ஏப்ரல் 7-க்குள் git தன்னைத்தானே நிர்வகிக்கத் தொடங்கியது (self-hosting), அதாவது git-ன் சொந்த வரலாறு git-லேயே சேமிக்கப்பட்டது. பல கிளைகளின் முதல் இணைப்பு (merge) ஏப்ரல் 18 அன்று நடைபெற்றது. ஜூன் 2005-ல், 2.6.12 release-ஐ git நிர்வகித்தது. Torvalds சிறிது காலத்திற்குப் பிறகு பராமரிப்புப் பொறுப்பை Junio Hamano-விடம் ஒப்படைத்துவிட்டு kernel பணிக்குத் திரும்பினார்.

இதன் வடிவமைப்பு அந்தச் சிக்கலிலிருந்தே உருவானது: ஆயிரக்கணக்கான பங்களிப்பாளர்கள், மற்றும் யாரும் நம்பாத ஒரு நெட்வொர்க் வழியாக ஒருவருக்கொருவர் மாற்றங்களை இழுக்கும் (pull) பராமரிப்பாளர்கள். ஒவ்வொரு பொருளும் (object) அதன் உள்ளடக்கத்தின் hash மூலம் பெயரிடப்படுகிறது, எனவே பழைய வரலாற்றில் ஒரு byte-ஐ மாற்றினாலும், அதற்குப் பின் வரும் ஒவ்வொரு commit-ன் பெயரும் மாறிவிடும். இதனால்தான் ஒரு clone என்பது வெறும் கோரிக்கை அல்ல, அது ஒரு ஆதாரமாகும். ஒவ்வொரு deploy pipeline, ஒவ்வொரு configuration repository, பெரும்பாலான குழுக்கள் code-ஐ அனுப்பும் தளம் மற்றும் நீங்கள் சொந்தமாக இயக்கக்கூடிய git server ஆகிய அனைத்தும் ஒரு kernel உரிம விவாதத்திலிருந்து உருவானவை.

LTS மாதிரி எதை உறுதி அளிக்கிறது, எதை அளிக்கவில்லை

Mainline என்பது நீங்கள் பயன்படுத்த வேண்டியது அல்ல. ஒரு mainline release 9 முதல் 10 வாரங்களுக்குப் பிறகு மாற்றப்பட்டுவிடும். Stable tree ஒவ்வொரு release-க்கு பிறகும் சில வாரங்களுக்குத் தேவையான திருத்தங்களை (fixes) வழங்குகிறது. Longterm branches, பொதுவாக LTS என்று அழைக்கப்படுபவை, பல ஆண்டுகளுக்குத் திருத்தங்களை வழங்குகின்றன; இவற்றின் அடிப்படையிலேயே Linux distributions உருவாக்கப்படுகின்றன.

டிசம்பர் 2009-ல் வெளியான 2.6.32, இந்த மாதிரி தன்னை நிரூபித்த இடமாகும். RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 மற்றும் Ubuntu 10.04 LTS ஆகிய அனைத்தும் இதையே பயன்படுத்தின. இந்த branch பிப்ரவரி 2016 வரை பராமரிக்கப்பட்டது, அதாவது இது வெளியான ஆறு ஆண்டுகளுக்கு மேலாக நீடித்தது.

இந்த உறுதிமொழி பலமுறை மாறியுள்ளது. முதலில் இரண்டு ஆண்டுகளாக இருந்தது, பிறகு சில கிளைகளுக்கு ஆறு ஆண்டுகளாக உயர்ந்தது. 2023-ல், stable maintainers இயல்புநிலை காலத்தை மீண்டும் இரண்டு ஆண்டுகளாகக் குறைத்தனர். பழைய கிளைகளில் 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
  }
]

ஆகஸ்ட் 2026 நிலவரப்படி, kernel.org 6 longterm கிளைகளைப் பட்டியலிடுகிறது. பழமையான கிளை, 5.10, Dec 2026-ல் முடிவடையும் போது, அது 6.0 ஆண்டுகளாகத் திருத்தங்களைக் கொண்டிருந்திருக்கும். புதிய கிளை, 6.18, Dec 2028 வரை நீடிக்கும் என்று கணிக்கப்பட்டுள்ளது, இது 3.1 ஆண்டுகாலத் திருத்தங்களைக் குறிக்கிறது.

இந்தத் தேதிகளை ஒரு ஒப்பந்தமாகப் பார்க்காமல், குறைந்தபட்ச காலக்கெடுவாகப் பார்க்கவும். 6.6 மற்றும் 6.12 கணிப்புகள் இரண்டும் பிப்ரவரி 2026-ல் நீட்டிக்கப்பட்டன; அதேசமயம் யாரும் பயன்படுத்தாத ஒரு கிளையை முன்னரே நிறுத்தவும் வாய்ப்புள்ளது. உங்கள் distribution வழக்கமாக உங்களுக்காக இந்தத் தேர்வைச் செய்கிறது: Debian 13 ஆனது 6.12-ஐயும், Ubuntu 26.04 LTS ஆனது 7.0-ஐயும் வழங்குகிறது. அந்த இடைவெளிதான் server-ல் LTS மற்றும் interim release குறித்த கேள்வியின் நடைமுறைப் பொருளாகும், மேலும் Ubuntu 24.04-ஐ 26.04-க்கு upgrade செய்யும்போது உண்மையில் உங்கள் கணினியின் உள்ளே மாறுவதும் இதுவேயாகும்.

இதிலிருந்து ஒரு சிக்கல் எழுகிறது. Ubuntu 24.04-ல் uname -r கட்டளையை இயக்கினால், அது 6.8.0-51-generic போன்ற ஒன்றை வெளியிடும். இது upstream base மற்றும் distribution-ன் சொந்த backports ஆகியவற்றின் கலவையாகும். எனவே, அந்த எண் branch எங்கு தொடங்கியது என்பதை மட்டுமே காட்டுகிறதே தவிர, அதில் என்னென்ன திருத்தங்கள் உள்ளன என்பதைக் காட்டாது. kernel-ன் version string-ஐ வைத்து அதன் பாதுகாப்பை மதிப்பிடும் scanners, இந்த காரணத்தினாலேயே distribution kernels-க்குத் தவறான எச்சரிக்கைகளை (false alarms) வழங்குகின்றன.

தற்போது kernel-ல் விவாதிக்கப்படும் விஷயங்கள்

தற்போது இரண்டு விவாதங்கள் நடைபெற்று வருகின்றன, இவை இரண்டுமே பணியை யார் செய்வது என்பது குறித்தவை.

Rust, 2022 டிசம்பர் மாதம் 6.1 பதிப்பில் உள்கட்டமைப்பாக இணைக்கப்பட்டது. 7.0 பதிப்பில் experimental என்ற முத்திரை நீக்கப்பட்டது, எனவே kernel-ன் முக்கிய மொழிகளாக C, assembly மற்றும் Rust ஆகியன உள்ளன; build செய்வதற்கு இனி nightly compiler தேவையில்லை. இந்த விவாதம் பராமரிப்பு (maintenance) சார்ந்தது. ஒரு C maintainer, interface-ஐ மாற்றும்போது, தான் வாசிக்காத Rust bindings-ஐ உடைக்கக்கூடும்; அவற்றைச் சரிசெய்ய வேண்டியது யாருடைய பொறுப்பு என்பதுதான் விவாதம்.

இரண்டாவது விவாதம் AI பங்களிப்பு பற்றியது. இயந்திர உதவியுடன் உருவாக்கப்பட்ட patches-ன் எண்ணிக்கை அதிகரித்ததைத் தொடர்ந்து, 2025 ஜூலை மாதம் Sasha Levin ஒரு கொள்கையை முன்மொழிந்தார். இந்த ஆவணம் 2025 டிசம்பர் 23 அன்று சமர்ப்பிக்கப்பட்டது, தற்போது இது kernel-ன் சொந்த செயல்முறை ஆவணத்தில் docs.kernel.org/process/coding-assistants.html உள்ளது. ஒரு AI agent, Signed-off-by tag-ஐச் சேர்க்கக்கூடாது, ஏனெனில் அந்த வரி Developer Certificate of Origin (DCO)-ஐ உறுதிப்படுத்துகிறது, அதை ஒரு மனிதரால் மட்டுமே செய்ய முடியும். உதவி பெறப்பட்டதை Assisted-by: tag மூலம் தெரிவிக்க வேண்டும்; ஒரு கருவி (tool) ஆசிரியராக இருக்க முடியாது என்பதால், மதிப்பாய்வின் போது இது Co-developed-by: என்பதிலிருந்து மாற்றப்பட்டது. உருவாக்கப்பட்ட code, GPL-2.0-only உரிமத்திற்கு இணக்கமாக இருக்க வேண்டும். patch-ஐ அனுப்பும் மனிதர் அதை மதிப்பாய்வு செய்து, அதற்கான பொறுப்பை ஏற்க வேண்டும்.

இந்தக் கொள்கையின் பின்னணியில் உள்ள அழுத்தம் மதிப்பாய்வு நேரத்தைப் பற்றியது. ஒரு patch-ஐ உருவாக்க சில நொடிகள் மட்டுமே ஆகும், ஆனால் அதை மதிப்பாய்வு செய்ய ஒரு maintainer-க்கு ஒரு மதிய நேரம் தேவைப்படும். ஒரு tag இந்தச் சமநிலையின்மையைச் சரிசெய்யாது. இது பாதுகாப்பது provenance-ஐ மட்டுமே: ஒவ்வொரு மாற்றத்திற்கும் யார் கையொப்பமிட்டார்கள் என்ற வரலாற்றைப் பதிவு செய்கிறது; 2004-ல் DCO அறிமுகப்படுத்தப்பட்டதன் நோக்கமே இந்த உரிமையைப் பாதுகாப்பதுதான்.

நீங்கள் வாடகைக்கு எடுக்கும் server-க்கு இந்த வரலாறு என்ன உணர்த்துகிறது

• நீங்கள் வாடகைக்கு எடுக்கும் server-ல் இயங்கும் kernel-ஐ வாசிப்பதற்கும், மீண்டும் உருவாக்குவதற்கும் இந்த உரிமம் (licence) தான் காரணம்; proprietary software-கள் அதில் இயங்குவதற்கும் இதுவே அடிப்படை.
• Monolithic வடிவமைப்பு காரணமாகவே, ஒரு driver-ல் ஏற்படும் பிழை முழு இயந்திரத்தையும் reboot செய்ய வைக்கிறது; மேலும், out-of-tree module-களை ஒவ்வொரு kernel upgrade-ன் போதும் மீண்டும் உருவாக்க வேண்டியுள்ளது.
• Release model காரணமாகவே, version எண் உங்களுக்கு மிகக் குறைந்த தகவலையே தருகிறது; ஆனால், branch மற்றும் அதன் end-of-life தேதி ஆகியவை கிட்டத்தட்ட அனைத்தையும் உணர்த்திவிடுகின்றன.
• Virtualisation வகைதான் நீங்கள் எதைச் செய்ய முடியும் என்பதைத் தீர்மானிக்கிறது: KVM-ல் நீங்கள் சொந்த kernel-ஐ boot செய்து module-களை ஏற்றலாம்; ஆனால், host kernel-ஐப் பகிரும் container virtualisation-ல், uname -r host-ன் version-ஐக் காட்டும், modprobe தோல்வியடையும், மேலும் பல sysctl-கள் read-only நிலையில் இருக்கும்.

FAQ

Linux kernel ஏன் இன்னும் GPLv3-க்கு மாறாமல் GPLv2-லேயே உள்ளது?

2007-ல் Torvalds GPLv3-ஐ நிராகரித்தார். இதற்கு முக்கிய காரணம் அதன் 'anti-tivoisation' நிபந்தனை ஆகும். GPL குறியீட்டைக் கொண்ட ஒரு சாதனம், மாற்றியமைக்கப்பட்ட குறியீட்டையும் ஏற்க வேண்டும் என்று இந்த நிபந்தனை கட்டாயப்படுத்துகிறது. பூட்டப்பட்ட வன்பொருளை (locked hardware) தயாரிப்பாளரின் வணிக உரிமையாக அவர் கருதுகிறார். மேலும், நடைமுறையில் உரிமத்தை மாற்றுவது சாத்தியமற்றது; ஏனெனில், kernel-ன் பதிப்புரிமை ஆயிரக்கணக்கான பங்களிப்பாளர்களிடம் உள்ளது, மேலும் குறியீட்டை ஒப்படைக்கும் ஒப்பந்தம் (assignment agreement) எதுவும் இல்லை. Linux kernel GPL-2.0-only என்பதால், GPLv3-ன் கீழ் மட்டும் வழங்கப்படும் குறியீடுகளை இதில் இணைக்க முடியாது.

Linux kernel என்பது monolithic kernel-ஆ அல்லது microkernel-ஆ?

இது monolithic kernel, இதில் loadable modules வசதி உள்ளது. Drivers மற்றும் filesystems ஆகியவை kernel-ன் address space-க்குள் இயங்குகின்றன. தற்போது ஏற்றப்பட்டுள்ள modules-ஐக் காண lsmod கட்டளையைப் பயன்படுத்தலாம். இதன் விளைவாக வேகம் கிடைக்கிறது, ஆனால் பாதிப்பு ஏற்படும் அபாயமும் (blast radius) அதிகம்: ஒரு faulty module முழு கணினியையும் முடக்கலாம் (panic). microkernel-ல் ஒரு process மட்டுமே பாதிக்கப்படும். 1992-க்கு பிறகு, user space-ல் இயங்கும் FUSE filesystems மற்றும் kernel-ஆல் சரிபார்க்கப்படும் eBPF programs ஆகியவற்றால் இந்த நிலை சற்று மாறியுள்ளது.

Mainline, stable மற்றும் longterm kernels-க்கு இடையே உள்ள வேறுபாடு என்ன?

Mainline என்பது Torvalds-ன் tree ஆகும்; இது 9 முதல் 10 வாரங்களுக்கு ஒருமுறை வெளியிடப்படுகிறது, புதிய அம்சங்கள் முதலில் இதில் தான் சேரும். Stable என்பது மிக சமீபத்திய mainline வெளியீட்டை எடுத்து, சில வாரங்களுக்கு bug fixes-ஐ மட்டும் பெறுவதாகும். Longterm கிளைகள் பல ஆண்டுகளுக்குத் திருத்தங்களைப் பெறுகின்றன; விநியோகங்கள் (distributions) இவற்றின் அடிப்படையிலேயே தங்கள் kernels-ஐ உருவாக்குகின்றன. kernel.org தளத்தில் தற்போதைய longterm கிளைகளும், ஒவ்வொன்றின் எதிர்பார்க்கப்படும் ஆயுட்காலமும் (end-of-life date) பட்டியலிடப்பட்டுள்ளன.

AI எழுதிய குறியீட்டை Linux kernel ஏற்றுக்கொள்கிறதா?

ஆம், டிசம்பர் 2025-ல் கொண்டுவரப்பட்ட கொள்கையின்படி ஏற்கப்படுகிறது. பயன்படுத்தப்பட்ட கருவியின் பெயர் Assisted-by: tag-ல் குறிப்பிடப்பட வேண்டும். AI agent ஒரு Signed-off-by வரியைச் சேர்க்கக்கூடாது. உருவாக்கப்பட்ட குறியீடு GPL-2.0-only உடன் இணக்கமாக இருக்க வேண்டும். சமர்ப்பிக்கும் நபர் (human submitter) அந்த patch-ஐ ஆய்வு செய்து, Developer Certificate of Origin-ன் கீழ் அதற்குப் பொறுப்பேற்க வேண்டும்.

Server-ல் எந்த kernel version-ஐப் பயன்படுத்த வேண்டும்?

பெரும்பாலான சந்தர்ப்பங்களில், உங்கள் விநியோகம் (distribution) வழங்கும் kernel-ஐயே பயன்படுத்த வேண்டும். ஒரு distribution kernel என்பது longterm கிளை, அதனுடன் backported fixes மற்றும் விற்பனையாளரின் சோதனை ஆகியவற்றின் கலவையாகும். உங்கள் provider-ன் images மற்றும் support ஒப்பந்தங்கள் இதைத்தான் எதிர்பார்க்கின்றன. ஒரு குறிப்பிட்ட driver அல்லது அம்சம் தேவைப்படும்போது மட்டும் புதிய mainline kernel-ஐ உருவாக்கவும். நீங்கள் மாறப்போகும் கிளையின் end-of-life தேதியைச் சரிபார்த்துவிட்டு, அதற்குப் பிறகு முடிவெடுக்கவும்.