Historia ya Linux kernel: Maamuzi yaliyobadilisha mfumo

Historia fupi ya Linux kernel

Historia ya Linux kernel inaanza na toleo la 0.01 mnamo Septemba 1991 hadi mfululizo wa 7.x unaowaka kwenye seva leo. Orodha ya matoleo ndiyo sehemu isiyo na mvuto zaidi katika historia hii. Idadi ndogo ya maamuzi iliweka msingi wa mfumo huu, na kila uamuzi bado una athari kwenye mashine unayokodisha mchana huu.

Tarehe na namba za matoleo hapa zinatoka kernel.org na historia ya matoleo inayochapisha. Hali ya sasa, kufikia Agosti 2026: 7.0 ilifika tarehe 12 Aprili 2026, 7.1 tarehe 14 Juni 2026, na 7.2 iko katika hatua ya release candidates.

Kwa nini chaguo la GPL mnamo 1992 bado ni muhimu

Toleo la 0.01 lilichapishwa tarehe 17 Septemba 1991 chini ya leseni ambayo Torvalds aliandika mwenyewe. Ilihitaji chanzo (source) kisambazwe, na ikaongeza mstari mmoja uliokuwa na uzito zaidi: "Huruhusiwi kusambaza hii kwa malipo, hata gharama za 'ushughulikiaji'." Mnamo 1991, programu zilisafirishwa kwenye floppy disks, na kunakili pamoja na kutuma floppy disks kuligharimu pesa. Ibara hiyo ilifanya usambazaji wa kibiashara wa Linux kuwa usiowezekana.

Aliibadilisha. Hatua ya kuhamia GNU General Public License (GPL) ilitangazwa kwenye maelezo ya toleo la 0.12 mnamo Januari 1992 na ikaanza kutumika tarehe 1 Februari 1992. Toleo la 0.95, mnamo Machi 1992, lilikuwa toleo la kwanza kuchapishwa chini yake. Kila biashara iliyojengwa baadaye juu ya Linux inategemea mabadiliko hayo.

Kernel ni GPL toleo la 2 pekee, na haikuwahi kuhamia toleo la 3. Torvalds alikataa mnamo 2007, hasa kutokana na kanuni ya kupinga tivoisation katika GPLv3, ambayo inahitaji kifaa kinachosafirisha msimbo wa GPL pia kikubali nakala iliyorekebishwa ya msimbo huo. Alichukulia maunzi yaliyofungwa kama jambo la kibiashara la mtengenezaji mwenyewe. Mnamo 2017, watengenezaji wa kernel walichapisha Kernel Enforcement Statement, ambayo inakopa kipande kimoja cha GPLv3 hata hivyo: mtu anayerekebisha ukiukaji baada ya kuambiwa kuhusu hilo anabaki na leseni yake, badala ya kuipoteza kabisa katika ukiukaji wa kwanza.

Matokeo mawili yanajitokeza kwenye seva. Faili ya binary ya kernel unayoiwasha inabeba haki ya kupata chanzo kinacholingana, kwa hivyo hakuna mtu anayeweza kukupa Linux kernel ambayo huwezi kuikagua au kuijenga upya. Na notisi ya hakimiliki kwenye kernel inasema leseni haijumuishi programu za watumiaji zinazotumia huduma za kernel kupitia system calls za kawaida, ndiyo maana database za umiliki na mawakala wa ufuatiliaji (monitoring agents) husafirishwa kwa Linux bila kuvunja chochote. Leseni ya kuruhusu (permissive licence) huleta shinikizo la kinyume, na tofauti hiyo inafaa kueleweka kabla ya kuchagua jukwaa: tazama Linux na FreeBSD kama majukwaa ya seva.

Kwa nini kernel ya monolithic ilishinda kivitendo

Mnamo tarehe 29 Januari 1992, Andrew Tanenbaum alichapisha ujumbe wenye kichwa "LINUX is obsolete" kwenye newsgroup ya comp.os.minix. Alitoa madai mawili. Kernel za monolithic, ambapo viendeshi (drivers) na mifumo ya faili huendeshwa ndani ya nafasi moja ya anwani iliyopewa upendeleo, zilikuwa usanifu wa miaka ya 1970, wakati microkernels, ambapo sehemu hizo huendeshwa kama michakato ya kawaida, ndiyo yalikuwa mustakabali. Na Linux ilikuwa imefungwa kwenye Intel 386, kwa hivyo haingeweza kusafiri kamwe.

Dai la uwezo wa kubebeka lilijibiwa kwa kufanya porting. Toleo la 1.2 mnamo Machi 1995 liliongeza Alpha, SPARC na MIPS. Toleo la 2.0 mnamo Juni 1996 liliongeza port ya 64-bit Alpha.

Dai la usanifu lilijibiwa kwa maelewano. Linux haikuwahi kuwa microkernel. Ilipata loadable kernel modules: faili za object unazoingiza kwenye kernel inayofanya kazi na kuziondoa tena, kwa hivyo kiendeshi husafirishwa kando na binary ya kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod huorodhesha kile kilichopakiwa hivi sasa. modinfo huchapisha faili ambayo moduli ilitoka na vigezo inavyokubali. Kwenye seva ya mtandaoni (virtual server), sehemu kubwa ya njia ya diski na mtandao ni moduli, ndiyo sababu image moja ya kernel huwasha kwenye vifaa ambavyo haijawahi kukutana navyo.

Moduli zilinunua unyumbufu huo bila gharama ambayo usanifu wa microkernel ulibeba. Kutenga kiendeshi katika mchakato wake mwenyewe kunamaanisha kulipia context switch na ujumbe kwenye kila wito, na mnamo 1992 gharama hiyo ilikuwa kubwa.

Gharama ambayo Linux ilihifadhi ndiyo inayopaswa kupangiwa: moduli huendeshwa kwa marupurupu kamili ya kernel, kwa hivyo moduli mbaya huangusha mashine nzima badala ya mchakato mmoja. Moduli za nje ya mti (out-of-tree) ndipo hili linapojitokeza. Kiendeshi cha muuzaji ambacho hakiko kwenye mainline lazima kijengwe upya dhidi ya kila kernel mpya, jambo ambalo DKMS hufanya wakati wa upgrade, na wakati ujenzi huo unaposhindwa, kifaa hukosekana tu baada ya reboot.

Kwa nini SMP ilichukua miaka kumi na mitano kukamilika

Linux 2.0 mnamo Juni 1996 ilikuwa kernel ya kwanza kusaidia symmetric multiprocessing (SMP), ikimaanisha zaidi ya CPU moja inayoendesha kernel moja. Utekelezaji wa kwanza ulitumia lock moja, big kernel lock (BKL), kwa hivyo processor moja tu ndiyo ingeweza kuwa ndani ya kernel code kwa wakati mmoja. Kwa hiyo, CPU ya pili ilisaidia kazi inayokokotoa katika user space, na ilisaidia kidogo sana na kazi ya system calls, kwa sababu hizo zilijipanga nyuma ya lock ileile.

Kuondoa lock hiyo kulichukua miaka kumi na mitano. Watumiaji waliosalia walihamishiwa kwenye fine-grained locking, kwa kiasi kikubwa na Arnd Bergmann, na BKL ilifutwa katika 2.6.39, iliyotolewa tarehe 18 Mei 2011. Scheduler ilisonga mbele kwa muda uleule wa polepole: O(1) scheduler katika 2.6.0, Completely Fair Scheduler (CFS) kutoka 2.6.23 mnamo 2007, na EEVDF, ambayo ilichukua nafasi ya CFS katika 6.6 mnamo Oktoba 2023.

Kazi hiyo ndiyo sababu mpango wa 4 vCPU haushangazi sasa. Pia inaashiria kikomo kinachofaa kujulikana. Kwenye virtual server inayoshirikiwa, kernel yako hupanga threads zako, na hypervisor hupanga kernel yako. Endesha top na usome sehemu ya %st. Steal time ni CPU ambayo kernel yako ilikuwa tayari kuitumia lakini mwenyeji (host) akaipa guest mwingine, kwa hivyo hakuna marekebisho ndani ya kernel yako yatakayoirejesha.

Kwa nini mfululizo wa 2.6 ulibadilisha jinsi kernel inavyojengwa

Kabla ya 2.6, namba za toleo zilikuja kwa jozi. Namba ya pili ikiwa shufwa ilimaanisha mfululizo thabiti (2.4), na ikiwa witiri ilimaanisha mfululizo wa maendeleo (2.5). Toleo la 2.4 lilitolewa tarehe 4 Januari 2001 na 2.6 tarehe 17 Desemba 2003, hivyo watumiaji walisubiri karibu miaka mitatu kwa ajili ya mfululizo thabiti uliofuata. Usambazaji (distributions) haukuweza kusubiri, hivyo walifanya backport. Wauzaji wawili waliokuwa wakisambaza "2.4" walikuwa na kernel zenye tofauti ya maelfu ya patches.

Mgawanyo huo uliondolewa baada ya 2.6. Sasa, mainline hufungua dirisha la kuunganisha (merge window) la takriban wiki mbili, hupokea kazi mpya, kisha huendesha release candidates hadi mambo yatulie, na hutoa toleo jipya kila baada ya wiki 9 hadi 10, mzunguko ambao kernel.org bado unauzingatia. Nusu nyingine ya mfumo huu ilianza tarehe 4 Machi 2005 na toleo la kwanza la stable tree, ambalo lilikuwa sasisho la marekebisho pekee kwa 2.6.11, likisimamiwa na Greg Kroah-Hartman na Chris Wright. Stable tree hupokea marekebisho pekee na hukataa vipengele vipya.

Athari moja: namba ya toleo iliacha kuwa ahadi. 3.0, 4.0, 5.0 na 7.0 siyo uandishi upya wa kernel. Torvalds huongeza namba ya kwanza wakati namba ya pili inapokuwa kubwa kiasi cha kumsumbua, ndiyo maana 7.0 ilifuata 6.19 mwezi Aprili 2026. Kinachojalisha kwa seva ni tawi gani ambalo usambazaji wako unafuatilia, na kama tawi hilo bado linapata marekebisho.

Jinsi mgogoro wa BitKeeper ulivyozalisha git mnamo Aprili 2005

Kuanzia Februari 2002, kernel ilitengenezwa kwa kutumia BitKeeper, mfumo wa umiliki wa usimamizi wa matoleo (distributed version control system) kutoka kampuni ya Larry McVoy, BitMover, kuanzia mfululizo wa 2.5. BitMover iliwapa watengenezaji wa kernel leseni ya bure yenye masharti: hukuwa na ruhusa ya kufanya kazi kwenye zana shindani ya usimamizi wa matoleo, na hukuwa na ruhusa ya kufanya reverse engineering kwenye BitKeeper. Watengenezaji wengi hawakupenda kujenga kernel huru kwa kutumia zana ambayo hawakuruhusiwa kuisoma.

Mfumo huo ulivunjika mnamo Aprili 2005, baada ya Andrew Tridgell kuonyesha programu iliyoweza kuwasiliana na hazina (repositories) za BitKeeper. BitMover iliita kitendo hicho kuwa ni reverse engineering na ikaondoa leseni ya bure. Kernel ilipoteza mfumo wake wa usimamizi wa matoleo katikati ya mzunguko wa maendeleo.

Kazi ya git ilianza tarehe 3 Aprili 2005. Torvalds alitangaza mfumo huo tarehe 6 Aprili. Kufikia tarehe 7 Aprili, git ilikuwa ikijihifadhi yenyewe (self-hosting), ikimaanisha kuwa historia ya git yenyewe ilikuwa tayari imehifadhiwa ndani ya git. Muunganiko (merge) wa kwanza wa matawi kadhaa ulifanyika tarehe 18 Aprili. Mnamo Juni 2005, git ilisimamia utolewaji wa 2.6.12. Torvalds alimkabidhi Junio Hamano jukumu la matengenezo muda mfupi baadaye na kurudi kwenye kernel.

Muundo wa git uliibuka moja kwa moja kutokana na tatizo hilo: maelfu ya wachangiaji, na wasimamizi wanaovuta (pull) kazi kutoka kwa wenzao kupitia mtandao ambao hakuna anayeuamini. Kila kitu (object) kinatambuliwa kwa hash ya maudhui yake, hivyo kubadilisha byte moja ya historia ya zamani kunabadilisha jina la kila commit inayofuata. Ndiyo maana clone ni ushahidi badala ya madai tu. Kila pipeline ya deployment, kila hazina ya usanidi, mwenyeji wa msimbo (code host) ambao timu nyingi hutuma kazi zao na seva ya git unayoweza kujiendeshea mwenyewe vilikua kutokana na mgogoro wa leseni kuhusu kernel.

Ahadi ya mfumo wa LTS, na yale ambayo haiiahidi

Mainline si toleo unalopaswa kulitumia. Toleo la mainline hubadilishwa baada ya wiki 9 hadi 10. Tawi la stable hubeba marekebisho kwa wiki chache baada ya kila toleo. Matawi ya muda mrefu, ambayo kwa kawaida huandikwa LTS, hubeba marekebisho hayo kwa miaka mingi, na hayo ndiyo matawi ambayo mifumo ya uendeshaji (distributions) hujengwa juu yake.

2.6.32, iliyotolewa mnamo Desemba 2009, ndipo mfumo huu ulipojithibitisha. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 na Ubuntu 10.04 LTS zote zilitumia toleo hilo, na tawi hilo liliendelezwa hadi Februari 2016, zaidi ya miaka sita tangu lilipoonekana.

Ahadi hiyo imebadilika zaidi ya mara moja. Ilikuwa miaka miwili, kisha miaka sita kwa matawi mengine. Mnamo 2023, watunza toleo la stable walipunguza muda wa kawaida hadi miaka miwili, kwa sababu kuingiza marekebisho (backporting) kwenye matawi ya zamani hugharimu muda wa watunzaji na matawi ya zamani hayapati majaribio ya kutosha. Mnamo 25 Februari 2026, Greg Kroah-Hartman alichapisha makadirio marefu zaidi tena, baada ya majadiliano na makampuni yanayotegemea matawi hayo, na mfumo wa sasa una muda wa kuanzia miaka mitatu hadi sita.

[
  {
    "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 inaorodhesha 6 matawi ya muda mrefu kufikia Agosti 2026. Tawi la zamani zaidi, 5.10, litakuwa limebeba marekebisho kwa 6.0 miaka litakapomalizika mnamo Dec 2026. Tawi jipya zaidi, 6.18, linatarajiwa kudumu hadi Dec 2028, ambayo ni 3.1 miaka ya marekebisho.

Soma tarehe hizo kama kiwango cha chini badala ya mkataba. Makadirio ya 6.6 na 6.12 yote yalisogezwa mbele mnamo Februari 2026, na tawi ambalo halitumiwi na mtu yeyote linaweza kufutwa badala yake. Distribution yako kwa kawaida hufanya uamuzi huo kwa ajili yako: Debian 13 inatumia 6.12, na Ubuntu 26.04 LTS inatumia 7.0. Pengo hilo ndilo maudhui halisi ya swali la LTS dhidi ya toleo la muda kwenye seva, na ndilo linalobadilika kikweli chini ya mfumo wako unapofanya upgrade ya Ubuntu 24.04 kwenda 26.04.

Mtego mmoja hutokana na hili. uname -r kwenye Ubuntu 24.04 huchapisha kitu kama 6.8.0-51-generic. Hiyo ni base ya upstream pamoja na backports za distribution yenyewe, kwa hivyo namba hiyo inakuambia tawi lilianzia wapi na si marekebisho yapi yaliyomo ndani yake. Programu za kuchanganua (scanners) zinazohukumu kernel kwa kutumia version string yake hutoa kengele za uongo dhidi ya kernel za distribution kwa sababu hii hasa.

Mambo ambayo kernel inajadili kwa sasa

Kuna mijadala miwili inayoendelea, na yote inahusu nani anapaswa kufanya kazi hiyo.

Rust ilianza kutumika kama miundombinu katika 6.1 mnamo Desemba 2022. Katika 7.0, lebo ya majaribio iliondolewa, hivyo lugha kuu za kernel sasa ni C, assembly, na Rust, na ujenzi (build) hauhitaji tena nightly compiler. Mgogoro uliopo unahusu matengenezo. Mtunza-kanuni (maintainer) wa C anayebadilisha interface anaweza kuvunja bindings za Rust ambazo hajazisoma, na mjadala ni kuhusu nani ana jukumu la kuzirekebisha.

Mjadala wa pili ni kuhusu mchango wa AI. Sasha Levin alipendekeza sera mnamo Julai 2025, baada ya ongezeko la patches zinazosaidiwa na mashine kufika kwenye orodha za barua pepe. Hati hiyo iliidhinishwa tarehe 23 Desemba 2025 na sasa ipo katika nyaraka za mchakato wa kernel kwenye docs.kernel.org/process/coding-assistants.html. Wakala wa AI haruhusiwi kuongeza tag ya Signed-off-by, kwa sababu mstari huo unathibitisha Developer Certificate of Origin (DCO) na ni mtu pekee anayeweza kuithibitisha. Usaidizi hutangazwa kwa tag ya Assisted-by:, ambayo ilibadilishwa kutoka Co-developed-by: wakati wa uhakiki kwa sababu zana si mwandishi. Kanuni (code) iliyozalishwa lazima iwe inaoana na GPL-2.0-only. Binadamu anayetuma patch ndiye anayeihakiki na kubeba dhima yake.

Shinikizo nyuma ya sera hii ni muda wa kuhakiki. Kuzalisha patch huchukua sekunde chache, na kuikagua huchukua mchana mzima wa mtunza-kanuni. Tag hairekebishi usawa huo. Kinachohifadhiwa ni asili (provenance): historia inaendelea kurekodi nani aliyesaini kila mabadiliko, ambayo ndiyo sifa ambayo DCO ilianzishwa kuilinda mnamo 2004.

Maana ya historia hii kwa seva unayokodisha

• Leseni ndiyo sababu unaweza kusoma na kujenga upya kernel inayowashwa na mtoa huduma wako, na ndiyo sababu programu za umiliki zinaendelea kufanya kazi juu yake.
• Usanifu wa monolithic ndiyo sababu hitilafu moja ya driver huwasha upya mashine nzima, na ndiyo sababu module ya nje ya mti (out-of-tree) lazima ijengwe upya kila kernel inapopandishwa daraja.
• Mfumo wa release ndiyo sababu namba ya version haikupi taarifa nyingi, wakati branch na tarehe yake ya mwisho wa matumizi (end-of-life) inakuambia karibu kila kitu.
• Aina ya virtualisation huamua kile unachoweza kufanya: kwenye KVM unawasha kernel yako mwenyewe na kupakia modules, wakati kwenye container virtualisation inayoshiriki kernel ya host, uname -r huonyesha version ya host, modprobe inafeli, na baadhi ya sysctls ni za kusoma tu (read-only).

FAQ

Kwa nini Linux kernel bado inatumia GPLv2 na si GPLv3?

Torvalds aliamua dhidi ya GPLv3 mwaka 2007, hasa kutokana na sharti lake la kuzuia "tivoisation", ambalo hulazimisha kifaa kinachosafirisha msimbo wa GPL kukubali pia toleo lililorekebishwa la msimbo huo. Yeye anaona maunzi yaliyofungwa ni suala la mtengenezaji. Kubadilisha leseni ni jambo lisilowezekana kivitendo, kwa sababu hakimiliki ya kernel inashikiliwa na maelfu ya wachangiaji na hakuna makubaliano ya makabidhiano ya haki za hakimiliki ya kutegemea. Kernel ni GPL-2.0-only, kwa hivyo msimbo unaotolewa chini ya GPLv3 pekee hauwezi kuunganishwa.

Je, Linux kernel ni monolithic kernel au microkernel?

Ni monolithic, yenye moduli zinazoweza kupakiwa. Viendeshi (drivers) na mifumo ya faili huendesha ndani ya nafasi ya anwani ya kernel, na lsmod huonyesha zile zilizopakiwa sasa hivi. Athari yake ni kasi kwa upande mmoja na hatari ya mfumo mzima kwa upande mwingine: moduli yenye hitilafu inaweza kusababisha mashine nzima kupata panic, ambapo microkernel ingepoteza mchakato mmoja tu. Picha imebadilika tangu 1992 kupitia mifumo ya faili ya FUSE katika user space na programu za eBPF ambazo kernel huzihakiki kabla ya kuziendesha.

Kuna tofauti gani kati ya mainline, stable na longterm kernels?

Mainline ni mti wa Torvalds, unaotolewa kila baada ya wiki 9 hadi 10, na vipengele vipya hufika hapo kwanza. Stable huchukua toleo la hivi karibuni la mainline na kupokea marekebisho ya hitilafu kwa wiki chache. Matawi ya longterm huendelea kupokea marekebisho kwa miaka mingi, na ndiyo ambayo usambazaji (distributions) hujengea kernel zao. kernel.org huorodhesha matawi ya sasa ya longterm pamoja na tarehe inayokadiriwa ya mwisho wa maisha (end-of-life) kwa kila moja.

Je, Linux kernel inakubali msimbo ulioandikwa na AI?

Ndiyo, chini ya sera iliyoidhinishwa mnamo Desemba 2025. Zana hiyo lazima itajwe katika tag ya Assisted-by:, wakala wa AI hapaswi kuongeza mstari wa Signed-off-by, na msimbo uliotengenezwa lazima uwe sambamba na GPL-2.0-only. Mwanadamu anayewasilisha msimbo husaini (sign-off), jambo linalomaanisha kuwa amepitia patch hiyo na anawajibika kwayo chini ya Developer Certificate of Origin.

Ni toleo gani la kernel ninalopaswa kutumia kwenye seva?

Toleo linalotunzwa na usambazaji wako, katika karibu kila hali. Kernel ya usambazaji ni tawi la longterm pamoja na marekebisho yaliyorejeshwa (backported fixes) na majaribio ya muuzaji, na ndilo toleo ambalo picha za mtoa huduma wako na makubaliano yako ya usaidizi yanategemea. Jenga kernel mpya ya mainline unapohitaji kiendeshi au kipengele maalum, na hakikisha tarehe ya mwisho wa maisha ya tawi unalohamia kabla ya kulichagua.