Sejarah perkembangan kernel Linux dari 0.01 hingga 7.x
Ketahui sejarah kernel Linux dari versi 0.01 hingga 7.x. Artikel ini membincangkan kesan peralihan lesen GPL, kelahiran Git, dan model LTS terhadap kestabilan pelayan masa kini.
Versi ringkas sejarah kernel Linux
Sejarah kernel Linux bermula daripada versi 0.01 pada September 1991 sehingga siri 7.x yang digunakan pada pelayan hari ini. Senarai keluaran merupakan bahagian yang paling kurang menarik. Sebilangan kecil keputusan telah menentukan bentuk sistem ini, dan setiap satunya masih memberi kesan kepada mesin yang anda sewa pada petang ini.
Tarikh dan nombor versi di sini diperoleh daripada kernel.org dan sejarah keluaran yang diterbitkannya. Keadaan semasa, setakat Ogos 2026: 7.0 tiba pada 12 April 2026, 7.1 pada 14 Jun 2026, dan 7.2 kini berada dalam fasa calon keluaran (release candidates).
Mengapa pilihan GPL pada tahun 1992 masih penting
Versi 0.01 diterbitkan pada 17 September 1991 di bawah lesen yang ditulis sendiri oleh Torvalds. Ia mensyaratkan kod sumber diedarkan, dan menambah satu baris yang lebih penting: "Anda tidak boleh mengedarkan ini dengan bayaran, walaupun untuk kos 'pengendalian'." Pada tahun 1991, perisian diedarkan menggunakan cakera liut, dan menyalin serta mengepos cakera liut memerlukan kos. Klausa tersebut menjadikan pengedaran komersial Linux mustahil.
Beliau mengubahnya. Peralihan kepada GNU General Public License (GPL) diumumkan dalam nota keluaran 0.12 pada Januari 1992 dan berkuat kuasa pada 1 Februari 1992. Versi 0.95, pada Mac 1992, merupakan keluaran pertama yang diterbitkan di bawah lesen tersebut. Setiap perniagaan yang dibina di atas Linux kemudiannya bergantung pada perubahan itu.
Kernel ini hanya menggunakan GPL versi 2, dan ia tidak pernah beralih kepada versi 3. Torvalds menolak pada tahun 2007, kebanyakannya disebabkan peraturan anti-tivoisation dalam GPLv3, yang mensyaratkan peranti yang mengandungi kod GPL mesti menerima salinan kod yang telah diubah suai. Beliau menganggap perkakasan yang dikunci sebagai urusan pengeluar itu sendiri. Pada tahun 2017, pembangun kernel menerbitkan Kernel Enforcement Statement, yang meminjam satu bahagian daripada GPLv3: sesiapa yang membetulkan pelanggaran selepas diberitahu akan mengekalkan lesen mereka, bukannya kehilangan lesen secara kekal pada pelanggaran pertama.
Dua akibat timbul pada pelayan. Binari kernel yang anda butkan membawa hak kepada kod sumber yang sepadan, jadi tiada sesiapa boleh memberikan anda kernel Linux yang tidak boleh anda periksa atau bina semula. Selain itu, notis hak cipta pada kernel menyatakan bahawa lesen tersebut tidak meliputi program pengguna yang menggunakan perkhidmatan kernel melalui panggilan sistem biasa, itulah sebabnya pangkalan data dan ejen pemantauan proprietari boleh diedarkan untuk Linux tanpa melanggar sebarang syarat. Lesen yang permisif mewujudkan tekanan yang bertentangan, dan perbezaan itu perlu difahami sebelum anda memilih platform: lihat Linux dan FreeBSD sebagai platform pelayan.
Mengapa kernel monolitik menang dalam praktiknya
Pada 29 Januari 1992, Andrew Tanenbaum menyiarkan mesej bertajuk "LINUX is obsolete" ke dalam newsgroup comp.os.minix. Beliau membuat dua dakwaan. Kernel monolitik, di mana pemacu dan sistem fail berjalan di dalam satu ruang alamat yang mempunyai keistimewaan, merupakan reka bentuk tahun 1970-an, manakala mikrokernel, di mana bahagian tersebut berjalan sebagai proses biasa, adalah masa depan. Dan Linux terikat dengan Intel 386, jadi ia tidak akan pernah boleh dipindahkan.
Dakwaan mengenai kebolehalihtanganan dijawab melalui proses porting. Versi 1.2 pada Mac 1995 menambah sokongan untuk Alpha, SPARC dan MIPS. Versi 2.0 pada Jun 1996 menambah port Alpha 64-bit.
Dakwaan mengenai reka bentuk dijawab melalui satu kompromi. Linux tidak pernah menjadi mikrokernel. Ia mendapat modul kernel yang boleh dimuatkan: fail objek yang anda masukkan ke dalam kernel yang sedang berjalan dan mengeluarkannya semula, supaya pemacu diedarkan secara berasingan daripada binari kernel.
lsmod | head
modinfo virtio_net | head -5lsmod menyenaraikan apa yang dimuatkan pada masa ini. modinfo mencetak fail asal modul tersebut dan parameter yang diterimanya. Pada pelayan maya, kebanyakan laluan cakera dan rangkaian adalah modul, itulah sebabnya satu imej kernel boleh but pada perkakasan yang tidak pernah ditemuinya sebelum ini.
Modul memberikan fleksibiliti tersebut tanpa kos yang perlu ditanggung oleh reka bentuk mikrokernel. Mengasingkan pemacu dalam prosesnya sendiri bermakna perlu membayar kos untuk penukaran konteks (context switch) dan mesej pada setiap panggilan, dan pada tahun 1992 kos tersebut adalah besar.
Kos yang dikekalkan oleh Linux adalah perkara yang perlu dirancang: modul berjalan dengan keistimewaan kernel penuh, jadi modul yang rosak akan menjatuhkan keseluruhan mesin dan bukannya satu proses sahaja. Modul luar-pohon (out-of-tree) adalah tempat di mana masalah ini berlaku. Pemacu vendor yang tidak berada dalam aliran utama (mainline) perlu dibina semula bagi setiap kernel baharu, iaitu tugas yang dilakukan oleh DKMS semasa naik taraf, dan apabila binaan tersebut gagal, peranti itu akan hilang selepas but semula.
Mengapa SMP mengambil masa lima belas tahun untuk disiapkan
Linux 2.0 pada Jun 1996 merupakan kernel pertama yang menyokong symmetric multiprocessing (SMP), bermakna lebih daripada satu CPU menjalankan satu kernel. Pelaksanaan pertama menggunakan satu kunci tunggal, iaitu big kernel lock (BKL), jadi hanya satu pemproses boleh berada di dalam kod kernel pada satu-satu masa. Oleh itu, CPU kedua hanya membantu beban kerja yang dikira dalam user space, dan tidak banyak membantu beban kerja system calls, kerana ia beratur di belakang kunci yang sama.
Menghapuskan kunci tersebut mengambil masa lima belas tahun. Pengguna yang masih ada telah ditukar kepada fine-grained locking, sebahagian besarnya oleh Arnd Bergmann, dan BKL telah dipadamkan dalam 2.6.39, yang dikeluarkan pada 18 Mei 2011. Penjadual (scheduler) bergerak pada skala masa perlahan yang sama: penjadual O(1) dalam 2.6.0, Completely Fair Scheduler (CFS) daripada 2.6.23 pada tahun 2007, dan EEVDF, yang menggantikan CFS dalam 6.6 pada Oktober 2023.
Usaha itulah sebabnya pelan 4 vCPU kini dianggap perkara biasa. Ia juga menandakan satu had yang perlu diketahui. Pada pelayan maya (virtual server) kongsi, kernel anda menjadualkan thread anda, dan hypervisor menjadualkan kernel anda. Jalankan top dan baca medan %st. Steal time ialah CPU yang kernel anda sedia untuk digunakan tetapi hos memberikannya kepada guest lain, jadi tiada penalaan di dalam kernel anda yang boleh memulihkannya.
Mengapa siri 2.6 mengubah cara kernel dibina
Sebelum 2.6, nombor versi hadir secara berpasangan. Nombor kedua yang genap bermaksud siri stabil (2.4), manakala nombor ganjil bermaksud pembangunan (2.5). 2.4 dikeluarkan pada 4 Januari 2001 dan 2.6 pada 17 Disember 2003, jadi pengguna menunggu hampir tiga tahun untuk siri stabil seterusnya. Pengedar tidak boleh menunggu, maka mereka melakukan backport. Dua vendor yang kedua-duanya mengeluarkan "2.4" sebenarnya membekalkan kernel dengan perbezaan beribu-ribu patch.
Pembahagian tersebut digugurkan selepas 2.6. Mainline kini membuka tetingkap gabungan (merge window) selama kira-kira dua minggu, menerima kerja baharu, kemudian menjalankan release candidate sehingga keadaan menjadi tenang, dan mengeluarkan versi baharu setiap 9 hingga 10 minggu, iaitu rentak yang masih didokumentasikan oleh kernel.org. Separuh lagi model tersebut tiba pada 4 Mac 2005 dengan keluaran pertama stable tree, iaitu kemas kini khusus untuk pembaikan bagi 2.6.11, yang diselenggara oleh Greg Kroah-Hartman dan Chris Wright. Stable tree hanya menerima pembaikan dan menolak ciri baharu.
Satu kesan sampingan: nombor versi tidak lagi menjadi satu janji. 3.0, 4.0, 5.0 dan 7.0 bukanlah penulisan semula. Torvalds menaikkan nombor pertama apabila nombor kedua menjadi cukup besar sehingga mengganggunya, itulah sebabnya 7.0 menyusuli 6.19 pada April 2026. Perkara yang penting bagi pelayan ialah cawangan mana yang dijejaki oleh pengedar anda, dan sama ada cawangan tersebut masih menerima pembaikan.
Bagaimana perbalahan BitKeeper menghasilkan git pada April 2005
Sejak Februari 2002, kernel dibangunkan menggunakan BitKeeper, iaitu sistem kawalan versi teragih proprietari daripada syarikat Larry McVoy, BitMover, bermula dengan siri 2.5. BitMover memberikan pembangun kernel lesen percuma dengan syarat tertentu: anda tidak dibenarkan membangunkan alat kawalan versi pesaing, dan anda tidak dibenarkan melakukan kejuruteraan terbalik terhadap BitKeeper. Ramai pembangun tidak menyukai idea membina kernel percuma menggunakan alat yang mereka tidak dibenarkan untuk kaji.
Keadaan menjadi tegang pada April 2005, selepas Andrew Tridgell mendemonstrasikan program yang boleh berhubung dengan repositori BitKeeper. BitMover melabelkan tindakan itu sebagai kejuruteraan terbalik dan menarik balik lesen percuma tersebut. Kernel kehilangan sistem kawalan versinya di tengah-tengah kitaran pembangunan.
Kerja pembangunan git bermula pada 3 April 2005. Torvalds mengumumkannya pada 6 April. Pada 7 April, git sudah mampu melakukan self-hosting, yang bermaksud sejarah git sendiri sudah disimpan di dalam git. Penggabungan pertama beberapa cawangan (branch) berjaya dilakukan pada 18 April. Pada Jun 2005, git menguruskan pengeluaran versi 2.6.12. Torvalds menyerahkan tugas penyelenggaraan kepada Junio Hamano tidak lama kemudian dan kembali menumpukan perhatian kepada kernel.
Reka bentuknya lahir terus daripada masalah yang dihadapi: ribuan penyumbang, dan penyelenggara yang menarik kod daripada satu sama lain merentasi rangkaian yang tidak dipercayai oleh sesiapa. Setiap objek dinamakan berdasarkan hash kandungannya, jadi mengubah satu bait sejarah lama akan mengubah nama setiap commit selepasnya. Itulah sebabnya klon merupakan bukti dan bukannya sekadar tuntutan. Setiap talian paip (pipeline) penggunaan, setiap repositori konfigurasi, hos kod yang digunakan oleh kebanyakan pasukan dan pelayan git yang boleh anda kendalikan sendiri berkembang daripada perbalahan pelesenan mengenai sebuah kernel.
Apa yang dijanjikan oleh model LTS, dan apa yang tidak
Mainline bukanlah versi yang anda jalankan. Keluaran mainline akan digantikan 9 hingga 10 minggu kemudian. Stable tree membawa pembaikan selama beberapa minggu selepas setiap keluaran. Cawangan jangka panjang, yang biasanya ditulis sebagai LTS, membawanya selama bertahun-tahun, dan inilah yang menjadi asas binaan bagi pengedaran (distribution).
2.6.32, yang dikeluarkan pada Disember 2009, merupakan titik di mana model ini membuktikan keberkesanannya. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 dan Ubuntu 10.04 LTS semuanya menggunakan versi ini, dan cawangan tersebut diselenggara sehingga Februari 2016, lebih enam tahun selepas ia muncul.
Janji ini telah berubah lebih daripada sekali. Ia bermula dengan dua tahun, kemudian enam tahun untuk beberapa cawangan. Pada tahun 2023, penyelenggara stable mengurangkan tempoh lalai kepada dua tahun, kerana proses backporting ke dalam tree lama memakan masa penyelenggara dan cawangan lama jarang mendapat ujian sebenar. Pada 25 Februari 2026, Greg Kroah-Hartman menerbitkan unjuran yang lebih panjang semula, selepas perbincangan dengan syarikat-syarikat yang bergantung pada cawangan tersebut, dan rangka kerja semasa berjalan dari tiga hingga enam tahun.
The data behind this chart
[
{
"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 menyenaraikan 6 cawangan jangka panjang setakat Ogos 2026. Yang paling lama, 5.10, akan membawa pembaikan selama 6.0 tahun apabila ia berakhir pada Dec 2026. Yang terbaharu, 6.18, diunjurkan berjalan sehingga Dec 2028, iaitu 3.1 tahun pembaikan.
Baca tarikh tersebut sebagai garis panduan minimum dan bukannya kontrak. Unjuran 6.6 dan 6.12 kedua-duanya berubah ke tarikh lebih lewat pada Februari 2026, dan cawangan yang tidak digunakan oleh sesiapa boleh digugurkan sebaliknya. Pengedaran anda biasanya membuat pilihan tersebut untuk anda: Debian 13 menggunakan 6.12, dan Ubuntu 26.04 LTS menggunakan 7.0. Jurang itu adalah kandungan praktikal bagi soalan LTS berbanding keluaran interim pada pelayan, dan itulah perkara yang sebenarnya berubah di bawah sistem anda apabila anda menaik taraf Ubuntu 24.04 kepada 26.04.
Satu perangkap timbul daripada perkara ini. uname -r pada Ubuntu 24.04 memaparkan sesuatu seperti 6.8.0-51-generic. Itu adalah asas upstream ditambah dengan backport daripada pengedaran itu sendiri, jadi nombor tersebut memberitahu anda di mana cawangan itu bermula dan bukannya pembaikan mana yang terkandung di dalamnya. Pengimbas yang menilai kernel berdasarkan rentetan versinya akan mencetuskan amaran palsu terhadap kernel pengedaran atas sebab ini.
Perkara yang sedang dipertikaikan oleh kernel pada masa ini
Terdapat dua hujah yang sedang hangat, dan kedua-duanya mengenai siapa yang perlu melakukan kerja tersebut.
Rust telah dimasukkan sebagai infrastruktur dalam 6.1 pada Disember 2022. Dalam 7.0, label eksperimental telah digugurkan, jadi bahasa teras kernel kini ialah C, assembly dan Rust, dan binaan (build) tidak lagi memerlukan pengkompil nightly. Pertikaian yang berlaku adalah mengenai penyelenggaraan. Seorang penyelenggara C yang menukar antara muka boleh merosakkan binding Rust yang tidak dibacanya, dan hujah yang timbul adalah tentang siapa yang bertanggungjawab untuk membaikinya.
Hujah kedua ialah mengenai sumbangan AI. Sasha Levin mencadangkan satu polisi pada Julai 2025, selepas jumlah patch bantuan mesin yang semakin meningkat sampai ke senarai mel. Dokumen tersebut telah dikomitkan pada 23 Disember 2025 dan kini berada dalam dokumentasi proses kernel sendiri di docs.kernel.org/process/coding-assistants.html. Ejen AI tidak dibenarkan menambah tag Signed-off-by, kerana baris tersebut mengesahkan Developer Certificate of Origin (DCO) dan hanya manusia yang boleh mengesahkannya. Bantuan diisytiharkan dengan tag Assisted-by:, yang ditukar daripada Co-developed-by: semasa semakan kerana alat bukanlah seorang pengarang. Kod yang dijana mestilah serasi dengan GPL-2.0-only. Manusia yang menghantar patch tersebut perlu menyemaknya dan memikul tanggungjawab ke atasnya.
Tekanan di sebalik polisi ini ialah masa semakan. Menjana patch hanya mengambil masa beberapa saat, manakala menyemaknya pula mengambil masa sepanjang petang seorang penyelenggara. Tag tidak menyelesaikan ketidakseimbangan tersebut. Apa yang ia kekalkan ialah asal usul (provenance): sejarah terus merekodkan siapa yang menandatangani setiap perubahan, iaitu sifat yang ingin dilindungi oleh DCO apabila ia diperkenalkan pada tahun 2004.
Apakah maksud sejarah ini bagi pelayan yang anda sewa
- Lesen inilah sebabnya anda boleh membaca dan membina semula kernel yang diboot oleh penyedia anda, serta sebab perisian proprietari masih boleh dijalankan di atasnya.
- Reka bentuk monolitik inilah sebabnya satu pepijat pemacu akan menyebabkan keseluruhan mesin but semula, dan sebab modul luar pokok (out-of-tree) perlu dibina semula pada setiap naik taraf kernel.
- Model keluaran inilah sebabnya nombor versi tidak memberikan banyak maklumat, manakala cawangan dan tarikh tamat hayatnya memberitahu anda hampir segala-galanya.
- Jenis virtualisasi menentukan perkara yang boleh anda lakukan: pada KVM anda memboot kernel anda sendiri dan memuatkan modul, manakala pada virtualisasi kontena yang berkongsi kernel hos,
uname -rmemaparkan versi hos,modprobegagal, dan beberapa sysctl adalah baca-sahaja (read-only).
FAQ
Mengapa kernel Linux masih menggunakan GPLv2 dan bukan GPLv3?
Torvalds membuat keputusan untuk tidak menggunakan GPLv3 pada tahun 2007, terutamanya disebabkan syarat anti-tivoisation yang memaksa peranti yang mengedarkan kod GPL untuk menerima versi kod yang telah diubah suai. Beliau menganggap perkakasan yang dikunci sebagai urusan pengeluar. Pelesenan semula hampir mustahil dilakukan secara praktikal kerana hak cipta kernel dipegang oleh ribuan penyumbang dan tiada perjanjian penyerahan hak untuk dirujuk. Kernel adalah GPL-2.0-only, jadi kod yang ditawarkan di bawah GPLv3 sahaja tidak boleh digabungkan.
Adakah kernel Linux merupakan kernel monolitik atau mikrokernel?
Monolitik, dengan modul yang boleh dimuatkan. Pemacu dan sistem fail berjalan di dalam ruang alamat kernel, dan lsmod menunjukkan modul yang sedang dimuatkan sekarang. Kesannya adalah kelajuan di satu pihak dan radius kerosakan di pihak yang lain: modul yang rosak boleh menyebabkan seluruh mesin mengalami kernel panic, sedangkan mikrokernel hanya akan kehilangan satu proses. Gambaran ini telah berubah sejak tahun 1992 melalui sistem fail FUSE dalam ruang pengguna dan program eBPF yang disahkan oleh kernel sebelum ia dijalankan.
Apakah perbezaan antara kernel mainline, stable dan longterm?
Mainline ialah tree milik Torvalds, dikeluarkan setiap 9 hingga 10 minggu, dan ciri baharu akan tiba di sana terlebih dahulu. Stable mengambil keluaran mainline terkini dan menerima pembetulan pepijat selama beberapa minggu. Cawangan longterm terus menerima pembetulan selama bertahun-tahun, dan ia merupakan asas kepada kernel yang dibina oleh pengedaran Linux. kernel.org menyenaraikan cawangan longterm semasa berserta tarikh jangkaan tamat hayat bagi setiap satunya.
Adakah kernel Linux menerima kod yang ditulis oleh AI?
Ya, di bawah polisi yang ditetapkan pada Disember 2025. Alat tersebut perlu dinamakan dalam tag Assisted-by:, ejen AI tidak boleh menambah baris Signed-off-by, dan kod yang dijana mestilah serasi dengan GPL-2.0-only. Penghantar manusia perlu melakukan sign-off, yang bermaksud mereka telah menyemak patch tersebut dan bertanggungjawab ke atasnya di bawah Developer Certificate of Origin.
Versi kernel manakah yang perlu saya jalankan pada pelayan?
Versi yang diselenggara oleh pengedaran anda, dalam hampir semua keadaan. Kernel pengedaran ialah cawangan longterm ditambah dengan pembetulan yang di-backport serta ujian daripada vendor, dan ia adalah apa yang diandaikan oleh imej pembekal dan aturan sokongan anda. Bina kernel mainline yang lebih baharu apabila anda memerlukan pemacu atau ciri khusus, dan semak tarikh tamat hayat cawangan yang anda ingin gunakan sebelum anda beralih kepadanya.