Kasaysayan ng Linux kernel: mga desisyong nagtagal

Maikling kasaysayan ng Linux kernel

Mula sa version 0.01 noong September 1991 hanggang sa 7.x series na nagbo-boot sa mga server ngayon ang kasaysayan ng Linux kernel. Hindi ang listahan ng mga release ang pinakamahalagang bahagi nito. Ilang desisyon lamang ang humubog sa disenyo nito, at may epekto pa rin ang bawat isa sa server na nira-rentahan mo ngayong hapon.

Ang mga petsa at version number dito ay mula sa kernel.org at sa release history na inilalathala nito. Ang kasalukuyang estado noong August 2026: inilabas ang 7.0 noong 12 April 2026, ang 7.1 noong 14 June 2026, at nasa release candidate stage ang 7.2.

Bakit mahalaga pa rin ang pagpili sa GPL noong 1992

Inilabas ang Version 0.01 noong 17 September 1991 sa ilalim ng licence na isinulat mismo ni Torvalds. Kinailangan nitong ipamahagi ang source, at nagdagdag ito ng mas mahalagang linya: "Hindi mo ito maaaring ipamahagi kapalit ng bayad, kahit para sa mga gastos sa 'handling'." Noong 1991, ipinapamahagi ang software sa floppy disks, at may gastos ang pagkopya at pagpapadala ng mga floppy disk. Dahil sa clause na iyon, naging imposible ang isang commercial Linux distribution.

Binago niya ito. Inanunsyo ang paglipat sa GNU General Public License (GPL) sa release notes ng 0.12 noong January 1992, at nagkabisa ito noong 1 February 1992. Ang Version 0.95, noong March 1992, ang unang release na inilabas sa ilalim nito. Nakabatay sa pagbabagong iyon ang bawat negosyong kalaunan ay itinayo sa Linux.

GPL version 2 only ang kernel, at hindi ito lumipat sa version 3. Tumanggi si Torvalds noong 2007, higit sa lahat dahil sa anti-tivoisation rule sa GPLv3, na nag-aatas na ang device na nagse-ship ng GPL code ay dapat ding tumanggap ng binagong kopya ng code na iyon. Itinuring niya ang locked hardware bilang sariling business decision ng manufacturer. Noong 2017, inilabas ng mga kernel developer ang Kernel Enforcement Statement, na humihiram pa rin ng isang bahagi ng GPLv3: ang sinumang nag-aayos ng violation matapos itong ipaalam sa kanya ay nananatili ang kanyang licence, sa halip na tuluyang mawala ito sa unang breach.

Dalawang consequence ang mahalaga sa isang server. May karapatan ka sa katugmang source para sa kernel binary na bina-boot mo, kaya walang makapagbibigay sa iyo ng Linux kernel na hindi mo maaaring inspeksyunin o i-rebuild. At sinasabi sa copyright notice ng kernel na hindi saklaw ng licence ang mga user program na gumagamit ng kernel services sa pamamagitan ng mga normal na system call. Ito ang dahilan kung bakit maaaring mag-ship ang proprietary databases at monitoring agents para sa Linux nang walang problema sa licence. Sa permissive licence, kabaligtaran ang pressure, at mahalagang maunawaan ang pagkakaibang ito bago pumili ng platform: tingnan ang Linux at FreeBSD bilang mga server platform.

Bakit nanalo sa aktuwal na paggamit ang monolithic kernel

Noong 29 January 1992, nag-post si Andrew Tanenbaum ng mensaheng may pamagat na "LINUX is obsolete" sa comp.os.minix newsgroup. Dalawa ang kanyang iginiit. Ang monolithic kernel, kung saan tumatakbo ang mga driver at filesystem sa iisang privileged address space, ay disenyo noong 1970s. Samantala, ang microkernel, kung saan tumatakbo ang mga bahaging iyon bilang mga ordinaryong proseso, ang kinabukasan. Iginiit din niyang nakatali ang Linux sa Intel 386, kaya hindi ito kailanman maililipat sa ibang platform.

Sinagot ang pahayag tungkol sa portability sa pamamagitan ng pag-port. Nagdagdag ang Version 1.2 noong March 1995 ng Alpha, SPARC, at MIPS. Nagdagdag naman ang Version 2.0 noong June 1996 ng 64-bit Alpha port.

Sinagot ang pahayag tungkol sa disenyo sa pamamagitan ng isang compromise. Hindi kailanman naging microkernel ang Linux. Sa halip, nagkaroon ito ng loadable kernel modules: mga object file na maaari mong i-insert sa tumatakbong kernel at alisin muli, kaya hiwalay na nire-release ang driver mula sa kernel binary.

lsmod | head
modinfo virtio_net | head -5

Inililista ng lsmod ang mga kasalukuyang naka-load. Ipinapakita naman ng modinfo ang file na pinagmulan ng module at ang mga parameter na tinatanggap nito. Sa isang virtual server, modules ang bumubuo sa malaking bahagi ng disk at network path. Dahil dito, maaaring mag-boot ang iisang kernel image sa hardware na hindi pa nito nakikilala.

Nakuha ng modules ang flexibility na iyon nang walang cost na kaakibat ng microkernel design. Kapag inihiwalay ang isang driver sa sarili nitong proseso, kailangang magbayad para sa context switch at mensahe sa bawat tawag. Malaki ang cost na iyon noong 1992.

Ang cost na pinanatili ng Linux ang kailangang paghandaan: tumatakbo ang module na may buong kernel privileges. Kaya kapag may sira ang module, maaaring bumagsak ang buong machine sa halip na isang proseso lamang. Dito nagiging problema ang out-of-tree modules. Kailangang i-rebuild ang vendor driver na wala sa mainline para sa bawat bagong kernel. Ito ang ginagawa ng DKMS kapag may upgrade. Kapag nabigo ang build na iyon, mawawala ang device pagkatapos ng reboot.

Bakit umabot ng labinlimang taon ang pagkumpleto ng SMP

Ang Linux 2.0 noong June 1996 ang unang kernel na sumuporta sa symmetric multiprocessing (SMP), ibig sabihin, mahigit isang CPU ang nagpapatakbo ng iisang kernel. Gumamit ang unang implementation ng iisang lock, ang big kernel lock (BKL), kaya isang processor lang ang maaaring nasa loob ng kernel code sa bawat pagkakataon. Dahil dito, nakatulong ang ikalawang CPU sa workload na nagko-compute sa user space, ngunit kaunti lang ang naitulong nito sa workload na gumagamit ng system calls dahil pumipila ang mga iyon sa parehong lock.

Umabot ng labinlimang taon ang pagtanggal sa lock na iyon. Ang mga natitirang gumagamit nito ay inilipat sa fine-grained locking, pangunahin sa gawa ni Arnd Bergmann, at inalis ang BKL sa 2.6.39, na inilabas noong 18 May 2011. Mabagal din ang pag-usad ng scheduler: ang O(1) scheduler sa 2.6.0, ang Completely Fair Scheduler (CFS) mula 2.6.23 noong 2007, at ang EEVDF, na pumalit sa CFS sa 6.6 noong October 2023.

Dahil sa gawaing iyon, karaniwan na ngayon ang 4 vCPU plan. May limitasyon din itong mahalagang malaman. Sa isang shared virtual server, ang kernel mo ang nagso-schedule ng mga thread mo, at ang hypervisor ang nagso-schedule ng kernel mo. Patakbuhin ang top at basahin ang field na %st. Ang steal time ay CPU na handang gamitin ng kernel mo ngunit ibinigay ng host sa ibang guest, kaya walang tuning sa loob ng kernel mo ang makakabawi rito.

Bakit binago ng 2.6 series ang paraan ng pagbuo ng kernel

Bago ang 2.6, pares ang format ng mga version number. Ang even na pangalawang numero ay nangangahulugang stable series (2.4), habang ang odd ay development series (2.5). Inilabas ang 2.4 noong 4 January 2001 at ang 2.6 noong 17 December 2003, kaya halos tatlong taon naghintay ang mga user para sa susunod na stable series. Hindi makapaghintay ang mga distribution, kaya nag-backport sila ng mga pagbabago. Kapag parehong "2.4" ang ipinapadala ng dalawang vendor, maaaring libo-libong patch ang pagitan ng kanilang mga kernel.

Inalis ang paghihiwalay na ito pagkatapos ng 2.6. Nagbubukas na ngayon ang mainline ng merge window na humigit-kumulang dalawang linggo, tumatanggap ng bagong trabaho, pagkatapos ay nagpapatakbo ng mga release candidate hanggang maging stable ang mga pagbabago, at naglalabas ng bagong version bawat 9 hanggang 10 linggo, ayon sa patuloy na dokumentasyon ng kernel.org. Dumating ang kabilang bahagi ng model noong 4 March 2005, nang unang inilabas ang stable tree—isang update sa 2.6.11 na naglalaman lamang ng mga fix—na pinamahalaan nina Greg Kroah-Hartman at Chris Wright. Tumatanggap ang stable tree ng mga fix at tumatanggi sa mga feature.

Isang epekto nito: hindi na garantiya ang version number. Ang 3.0, 4.0, 5.0 at 7.0 ay hindi muling pagsulat ng kernel. Itinataas ni Torvalds ang unang numero kapag sapat nang malaki ang pangalawang numero para makainis sa kanya, kaya sinundan ng 7.0 ang 6.19 noong April 2026. Para sa isang server, ang mahalaga ay kung aling branch ang sinusubaybayan ng iyong distribution at kung tumatanggap pa ito ng mga fix.

Paano nagbunga ng git ang pagkasira ng BitKeeper noong Abril 2005

Mula Pebrero 2002, binuo ang kernel gamit ang BitKeeper, isang proprietary distributed version control system mula sa kumpanyang BitMover ni Larry McVoy, simula sa 2.5 series. Binigyan ng BitMover ang mga kernel developer ng libreng license na may mga kondisyon: hindi ka maaaring gumawa ng competing version control tool, at hindi mo maaaring i-reverse engineer ang BitKeeper. Hindi nagustuhan ng maraming developer na bumuo ng libreng kernel gamit ang tool na hindi nila pinapayagang suriin.

Nasira ang kasunduan noong Abril 2005, matapos magpakita si Andrew Tridgell ng program na kumokonekta sa mga BitKeeper repository. Tinawag iyon ng BitMover na reverse engineering at binawi nito ang libreng license. Naiwan ang kernel na walang version control system sa kalagitnaan ng development cycle.

Nagsimula ang paggawa sa git noong 3 Abril 2005. Inanunsyo ito ni Torvalds noong 6 Abril. Noong 7 Abril, self-hosting na ang git, ibig sabihin, nasa git na mismo ang sariling history nito. Isinagawa ang unang merge ng ilang branch noong 18 Abril. Noong Hunyo 2005, pinamahalaan ng git ang release ng 2.6.12. Di-nagtagal, ipinasa ni Torvalds kay Junio Hamano ang maintenance at bumalik siya sa kernel.

Direktang nagmula ang disenyo sa problema: libo-libong contributor at mga maintainer na kumukuha ng pagbabago mula sa isa't isa sa network na walang nagtitiwala. Pinapangalanan ang bawat object batay sa hash ng content nito, kaya kapag binago ang isang byte ng lumang history, nagbabago ang pangalan ng bawat commit pagkatapos nito. Kaya ang clone ay ebidensya, hindi pahayag lamang. Ang bawat deploy pipeline, bawat configuration repository, ang code host na ginagamit ng karamihan ng team sa pag-push at ang git server na maaari mong patakbuhin mismo ay nagmula sa pagtatalo tungkol sa license ng kernel.

Ano ang ipinapangako ng LTS model, at ano ang hindi nito ipinapangako

Hindi ang mainline ang karaniwang ginagamit mo. Napapalitan ang isang mainline release pagkalipas ng 9 hanggang 10 linggo. Nagdadala ang stable tree ng mga fix sa loob ng ilang linggo pagkatapos ng bawat release. Nagdadala naman ng mga ito sa loob ng maraming taon ang mga longterm branch, na karaniwang tinatawag na LTS. Ang mga branch na ito ang ginagamit na base ng mga distribution.

Ang 2.6.32, na inilabas noong December 2009, ang nagpatunay na gumagana ang model na ito. Ginamit ito ng RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1, at Ubuntu 10.04 LTS, at pinanatili ang branch hanggang February 2016, mahigit anim na taon matapos itong lumabas.

Ilang beses nang nagbago ang ipinapangakong panahon ng maintenance. Dalawang taon ito noon, at naging anim na taon para sa ilang branch. Noong 2023, ibinalik ng mga stable maintainer sa dalawang taon ang default dahil nangangailangan ng oras ng maintainer ang pag-backport sa mga lumang tree, at kaunti lamang ang aktuwal na testing sa mga lumang branch. Noong 25 February 2026, muling naglathala si Greg Kroah-Hartman ng mas mahahabang projection matapos makipag-usap sa mga kumpanyang umaasa sa mga branch na ito. Ang kasalukuyang framework ay mula tatlo hanggang anim na taon.

[
  {
    "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
  }
]

Nakalista sa kernel.org ang 6 longterm branch noong August 2026. Ang pinakaluma, 5.10, ay nakapagdala ng mga fix sa loob ng 6.0 taon kapag natapos ito sa Dec 2026. Ang pinakabago, 6.18, ay inaasahang tatakbo hanggang Dec 2028, na katumbas ng 3.1 taon ng mga fix.

Ituring ang mga petsang iyon bilang pinakamababang tagal, hindi bilang kontrata. Parehong inusog sa mas huling petsa noong February 2026 ang mga projection para sa 6.6 at 6.12, at maaari ring ihinto ang isang branch na wala nang gumagamit. Karaniwang ang distribution na ang pumipili para sa iyo: ginagamit ng Debian 13 ang 6.12, at ginagamit ng Ubuntu 26.04 LTS ang 7.0. Iyan ang praktikal na nilalaman ng tanong tungkol sa LTS laban sa interim release sa isang server, at iyan ang aktuwal na nagbabago sa ilalim kapag nag-upgrade ka mula Ubuntu 24.04 patungong 26.04.

May isang karaniwang maling akala na nagmumula rito. Ipinapakita ng uname -r sa Ubuntu 24.04 ang tulad ng 6.8.0-51-generic. Ang numerong iyon ay upstream base kasama ang sariling backport ng distribution. Ipinapakita nito kung saan nagsimula ang branch, hindi kung aling mga fix ang nasa loob nito. Dahil dito, nagbabangon ng mga false alarm ang mga scanner na hinuhusgahan ang kernel batay sa version string nito kapag sinusuri ang mga kernel ng distribution.

Ano ang pinagdedebatehan ng kernel ngayon

Dalawang usapin ang kasalukuyang pinagtatalunan, at kapwa ito tungkol sa kung sino ang gagawa ng trabaho.

Naging bahagi ng infrastructure ang Rust sa 6.1 noong December 2022. Sa 7.0, inalis ang experimental label. Dahil dito, ang pangunahing language ng kernel ay C, assembly, at Rust, at hindi na kailangan ng nightly compiler sa build. Tungkol sa maintenance ang hindi pagkakasundo. Kapag binago ng isang C maintainer ang isang interface, maaaring masira ang Rust bindings na hindi niya binabasa. Ang pinagtatalunan ay kung kaninong responsibilidad ang pag-aayos sa mga ito.

Ang ikalawang usapin ay ang kontribusyon ng AI. Nagmungkahi si Sasha Levin ng policy noong July 2025, matapos dumami ang machine-assisted patches na ipinapadala sa mga mailing list. Na-commit ang dokumento noong 23 December 2025 at bahagi na ito ng sariling process documentation ng kernel sa docs.kernel.org/process/coding-assistants.html. Hindi dapat magdagdag ang isang AI agent ng Signed-off-by tag, dahil pinatutunayan ng linyang iyon ang Developer Certificate of Origin (DCO), at tao lamang ang maaaring magpatunay nito. Ipinapahayag ang paggamit ng assistance sa pamamagitan ng Assisted-by: tag. Pinalitan ito mula sa Co-developed-by: habang nire-review, dahil hindi author ang isang tool. Dapat compatible sa GPL-2.0-only ang generated code. Nirereview ng taong nagpapadala ng patch ang patch, at siya ang may pananagutan dito.

Ang pangunahing dahilan ng policy ay ang oras para sa review. Ilang segundo lamang ang kailangan para mag-generate ng patch, ngunit maaaring abutin ng buong hapon ng maintainer ang pag-review nito. Hindi naaayos ng isang tag ang imbalance na iyon. Ang napapanatili nito ay provenance: patuloy na itinatala sa history kung sino ang lumagda para sa bawat pagbabago. Ito ang property na pinoprotektahan ng DCO nang ipakilala ito noong 2004.

Ano ang ibig sabihin ng kasaysayang ito para sa server na nirerenta mo

• Ang license ang dahilan kung bakit maaari mong basahin at i-rebuild ang kernel na bina-boot ng provider mo, at kung bakit tumatakbo rito ang proprietary software.
• Ang monolithic na disenyo ang dahilan kung bakit nire-reboot ng isang bug sa driver ang buong machine, at kung bakit kailangang i-rebuild ang isang out-of-tree module sa bawat kernel upgrade.
• Ang release model ang dahilan kung bakit kaunti lang ang sinasabi ng version number, samantalang halos lahat ay ipinapakita ng branch at end-of-life date nito.
• Ang uri ng virtualization ang nagtatakda kung ano ang maaari mong gawin: sa KVM, bina-boot mo ang sarili mong kernel at naglo-load ng modules; samantalang sa container virtualization na nakikibahagi sa kernel ng host, ipinapakita ng uname -r ang version ng host, nagfa-fail ang modprobe, at read-only ang ilang sysctl.

FAQ

Bakit GPLv2 pa rin ang Linux kernel at hindi GPLv3?

Nagpasya si Torvalds na huwag gamitin ang GPLv3 noong 2007, pangunahin dahil sa anti-tivoisation requirement nito. Pinipilit nito ang device na nagre-release ng GPL code na tumanggap din ng modified na bersyon ng code na iyon. Para kay Torvalds, usapin ng negosyo ng manufacturer ang naka-lock na hardware. Halos imposibleng gawin sa praktika ang relicensing dahil libo-libong contributor ang may copyright sa kernel, at walang assignment agreement na maaaring gamitin bilang fallback. GPL-2.0-only ang license ng kernel, kaya hindi maaaring i-merge ang code na GPLv3 lamang ang license.

Monolithic kernel ba o microkernel ang Linux kernel?

Monolithic ito, na may loadable modules. Tumatakbo sa loob ng address space ng kernel ang mga driver at filesystem, at ipinapakita ng lsmod ang mga kasalukuyang naka-load. Ang kapalit nito ay bilis sa isang panig at mas malawak na epekto sa kabilang panig: maaaring mag-panic ang buong machine dahil sa faulty module, samantalang isang process lang ang mawawala sa microkernel. Bahagyang nagbago ang katangiang ito mula noong 1992 dahil sa FUSE filesystems na tumatakbo sa user space at eBPF programs na vina-validate ng kernel bago patakbuhin.

Ano ang pagkakaiba ng mainline, stable, at longterm kernels?

Ang mainline ay tree ni Torvalds. Nire-release ito bawat 9 hanggang 10 linggo, at dito unang pumapasok ang mga bagong feature. Kinukuha ng stable ang pinakabagong mainline release at tumatanggap ito ng mga bug fix sa loob ng ilang linggo. Patuloy na nakatatanggap ng mga fix sa loob ng maraming taon ang longterm branches, at dito binabatay ng mga distribution ang kanilang kernels. Inililista ng kernel.org ang kasalukuyang longterm branches at ang inaasahang end-of-life date ng bawat isa.

Tumatanggap ba ang Linux kernel ng code na isinulat ng AI?

Oo, batay sa policy na pinagtibay noong December 2025. Dapat pangalanan ang tool sa isang Assisted-by: tag, hindi dapat magdagdag ang AI agent ng Signed-off-by line, at kailangang compatible ang generated code sa GPL-2.0-only. Nag-si-sign off ang human submitter. Ibig sabihin, sinuri nila ang patch at inaako nila ang responsibilidad dito alinsunod sa Developer Certificate of Origin.

Aling kernel version ang dapat kong patakbuhin sa server?

Sa halos lahat ng sitwasyon, ang kernel na minamaintain ng iyong distribution. Ang distribution kernel ay binubuo ng longterm branch, mga backported fix, at testing ng vendor. Ito rin ang inaasahan ng mga image ng iyong provider at ng support arrangements mo. Mag-build ng mas bagong mainline kernel kung kailangan mo ng partikular na driver o feature. Bago ka mag-commit dito, suriin ang end-of-life date ng branch na lilipatan mo.