Sejarah Kernel Linux: Keputusan yang Bertahan

Riwayat singkat kernel Linux

Riwayat kernel Linux dimulai dari versi 0.01 pada September 1991 hingga seri 7.x yang saat ini melakukan boot pada server. Daftar rilis adalah bagian yang paling tidak menarik. Sejumlah kecil keputusan membentuk struktur kernel ini, dan setiap keputusan masih berdampak pada mesin yang Anda sewa sore ini.

Tanggal dan nomor versi di sini berasal dari kernel.org dan riwayat rilis yang dipublikasikannya. Kondisi terkini per Agustus 2026: 7.0 dirilis pada 12 April 2026, 7.1 pada 14 Juni 2026, dan 7.2 berada dalam tahap release candidate.

Mengapa pilihan GPL pada 1992 masih penting

Version 0.01 diterbitkan pada 17 September 1991 berdasarkan lisensi yang ditulis sendiri oleh Torvalds. Lisensi tersebut mewajibkan distribusi source code dan menambahkan satu ketentuan yang lebih penting: "Anda tidak boleh mendistribusikan ini dengan biaya, bahkan biaya 'penanganan' sekalipun." Pada 1991, software didistribusikan melalui floppy disk, dan penggandaan serta pengiriman floppy disk memerlukan biaya. Ketentuan tersebut membuat distribusi Linux komersial tidak mungkin dilakukan.

Ia mengubahnya. Peralihan ke GNU General Public License (GPL) diumumkan dalam catatan rilis 0.12 pada Januari 1992 dan mulai berlaku pada 1 Februari 1992. Version 0.95, pada Maret 1992, merupakan rilis pertama yang diterbitkan berdasarkan lisensi tersebut. Setiap bisnis yang kemudian dibangun di atas Linux bergantung pada perubahan ini.

Kernel hanya menggunakan GPL version 2 dan tidak pernah beralih ke version 3. Torvalds menolaknya pada 2007, terutama karena aturan anti-tivoisation dalam GPLv3, yang mewajibkan perangkat yang mengirimkan kode GPL juga menerima salinan kode tersebut yang telah dimodifikasi. Ia menganggap hardware yang dikunci sebagai urusan bisnis produsennya sendiri. Pada 2017, pengembang kernel menerbitkan Kernel Enforcement Statement, yang tetap mengadopsi satu bagian dari GPLv3: pihak yang memperbaiki pelanggaran setelah diberi tahu tetap mempertahankan lisensinya, alih-alih kehilangannya secara permanen saat pelanggaran pertama terjadi.

Pada server, terdapat dua konsekuensi. Binary kernel yang Anda boot memberikan hak atas source code yang sesuai, sehingga tidak ada pihak yang dapat memberikan kernel Linux yang tidak boleh Anda periksa atau build ulang. Selain itu, pemberitahuan hak cipta pada kernel menyatakan bahwa lisensi tersebut tidak mencakup program pengguna yang menggunakan layanan kernel melalui system call normal. Karena itu, database proprietary dan monitoring agent dapat dirilis untuk Linux tanpa melanggar ketentuan apa pun. Lisensi permisif menimbulkan konsekuensi yang berlawanan, dan perbedaan ini perlu dipahami sebelum Anda memilih platform: lihat Linux dan FreeBSD sebagai platform server.

Mengapa kernel monolitik tetap unggul dalam praktik

Pada 29 Januari 1992, Andrew Tanenbaum mengirim pesan berjudul "LINUX is obsolete" ke newsgroup comp.os.minix. Ia menyampaikan dua klaim. Kernel monolitik, yang menjalankan driver dan filesystem dalam satu ruang alamat dengan hak istimewa, merupakan rancangan dari tahun 1970-an. Sebaliknya, microkernel, yang menjalankan komponen tersebut sebagai proses biasa, adalah masa depan. Ia juga menyatakan bahwa Linux terikat pada Intel 386 sehingga tidak akan pernah dapat dipindahkan ke platform lain.

Klaim tentang portabilitas dijawab melalui porting. Versi 1.2 pada Maret 1995 menambahkan Alpha, SPARC, dan MIPS. Versi 2.0 pada Juni 1996 menambahkan port 64-bit untuk Alpha.

Klaim tentang rancangan dijawab melalui kompromi. Linux tidak pernah menjadi microkernel. Linux memperoleh loadable kernel modules: file objek yang dapat dimasukkan ke kernel yang sedang berjalan dan kemudian dihapus kembali, sehingga driver dapat dirilis secara terpisah dari binary kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod menampilkan daftar yang sedang dimuat saat ini. modinfo mencetak file asal module tersebut dan parameter yang diterimanya. Pada server virtual, sebagian besar jalur disk dan jaringan ditangani oleh modules. Karena itu, satu kernel image dapat melakukan boot pada hardware yang belum pernah dikenalnya.

Modules memberikan fleksibilitas tersebut tanpa biaya yang ditimbulkan oleh rancangan microkernel. Mengisolasi driver dalam prosesnya sendiri berarti harus membayar biaya context switch dan pesan pada setiap pemanggilan. Pada 1992, biaya tersebut besar.

Biaya yang tetap ditanggung Linux adalah hal yang harus diperhitungkan: module berjalan dengan hak istimewa penuh di kernel. Karena itu, module yang bermasalah dapat menjatuhkan seluruh mesin, bukan hanya satu proses. Masalah ini paling terlihat pada out-of-tree modules. Driver dari vendor yang tidak berada di mainline harus dibangun ulang untuk setiap kernel baru. Proses inilah yang dilakukan DKMS selama upgrade. Jika proses build tersebut gagal, perangkat akan tidak tersedia setelah reboot.

Mengapa SMP membutuhkan waktu lima belas tahun untuk diselesaikan

Linux 2.0 pada Juni 1996 adalah kernel pertama yang mendukung symmetric multiprocessing (SMP), yaitu lebih dari satu CPU yang menjalankan satu kernel. Implementasi pertama menggunakan satu lock, yaitu big kernel lock (BKL), sehingga hanya satu prosesor yang dapat berada di dalam kode kernel pada satu waktu. Karena itu, CPU kedua membantu workload yang melakukan komputasi di user space, tetapi hampir tidak membantu workload system call karena semua proses tersebut mengantre pada lock yang sama.

Penghapusan lock tersebut membutuhkan waktu lima belas tahun. Penggunaan yang tersisa dialihkan ke fine-grained locking, terutama oleh Arnd Bergmann, dan BKL dihapus pada 2.6.39 yang dirilis pada 18 Mei 2011. Scheduler mengalami perkembangan dalam rentang waktu yang sama panjang: scheduler O(1) pada 2.6.0, Completely Fair Scheduler (CFS) mulai 2.6.23 pada 2007, dan EEVDF yang menggantikan CFS pada 6.6 pada Oktober 2023.

Pekerjaan tersebut membuat paket 4 vCPU menjadi hal yang biasa saat ini. Namun, hal itu juga menunjukkan batas yang perlu dipahami. Pada server virtual bersama, kernel Anda menjadwalkan thread Anda, sedangkan hypervisor menjadwalkan kernel Anda. Jalankan top dan baca field %st. Steal time adalah CPU yang siap digunakan oleh kernel Anda, tetapi diberikan oleh host kepada guest lain. Karena itu, tidak ada tuning di dalam kernel Anda yang dapat memulihkannya.

Mengapa seri 2.6 mengubah cara kernel dibangun

Sebelum 2.6, nomor versi terdiri atas pasangan angka. Angka kedua genap berarti seri stabil (2.4), sedangkan angka kedua ganjil berarti seri pengembangan (2.5). 2.4 dirilis pada 4 Januari 2001 dan 2.6 pada 17 Desember 2003, sehingga pengguna harus menunggu hampir tiga tahun untuk seri stabil berikutnya. Distribusi tidak dapat menunggu, sehingga mereka melakukan backport. Dua vendor yang sama-sama merilis "2.4" dapat menyediakan kernel yang berbeda ribuan patch.

Pemisahan tersebut dihapus setelah 2.6. Mainline kini membuka merge window selama sekitar dua minggu, menerima pekerjaan baru, lalu menjalankan release candidate sampai pengembangan stabil, dan merilis versi baru setiap 9 hingga 10 minggu, sesuai siklus yang masih didokumentasikan kernel.org. Bagian lain dari model ini mulai diterapkan pada 4 Maret 2005 melalui rilis pertama stable tree, yaitu pembaruan untuk 2.6.11 yang hanya berisi perbaikan, yang dikelola oleh Greg Kroah-Hartman dan Chris Wright. Stable tree menerima perbaikan dan menolak fitur.

Salah satu dampaknya adalah nomor versi tidak lagi menjadi jaminan. 3.0, 4.0, 5.0, dan 7.0 bukanlah penulisan ulang. Torvalds menaikkan angka pertama ketika angka kedua sudah cukup besar hingga mengganggunya. Karena itu, 7.0 mengikuti 6.19 pada April 2026. Hal yang penting bagi server adalah cabang mana yang dilacak oleh distribusi Anda dan apakah cabang tersebut masih menerima perbaikan.

Bagaimana keretakan BitKeeper menghasilkan git pada April 2005

Sejak Februari 2002, kernel dikembangkan menggunakan BitKeeper, sistem kontrol versi terdistribusi berpemilik dari perusahaan Larry McVoy, BitMover, yang dimulai pada seri 2.5. BitMover memberikan lisensi gratis kepada pengembang kernel dengan beberapa syarat: Anda tidak boleh mengembangkan alat kontrol versi pesaing dan tidak boleh melakukan rekayasa balik terhadap BitKeeper. Banyak pengembang tidak suka membangun kernel gratis menggunakan alat yang tidak boleh mereka pelajari.

Kerja sama itu berakhir pada April 2005, setelah Andrew Tridgell mendemonstrasikan program yang berkomunikasi dengan repositori BitKeeper. BitMover menganggapnya sebagai rekayasa balik dan mencabut lisensi gratis tersebut. Kernel kehilangan sistem kontrol versinya di tengah siklus pengembangan.

Pengerjaan git dimulai pada 3 April 2005. Torvalds mengumumkannya pada 6 April. Pada 7 April, git sudah digunakan untuk mengelola pengembangannya sendiri. Artinya, riwayat git sendiri sudah disimpan dalam git. Penggabungan pertama beberapa branch dilakukan pada 18 April. Pada Juni 2005, git mengelola rilis 2.6.12. Tidak lama kemudian, Torvalds menyerahkan pemeliharaan kepada Junio Hamano dan kembali mengerjakan kernel.

Rancangannya muncul langsung dari masalah tersebut: ribuan kontributor serta maintainer yang saling melakukan pull melalui jaringan yang tidak dipercayai siapa pun. Setiap objek diberi nama berdasarkan hash kontennya. Karena itu, perubahan satu byte pada riwayat lama akan mengubah nama setiap commit setelahnya. Itulah sebabnya clone merupakan bukti, bukan sekadar klaim. Setiap pipeline deployment, setiap repositori konfigurasi, host kode yang digunakan sebagian besar tim untuk melakukan push dan server git yang dapat Anda jalankan sendiri berkembang dari perdebatan lisensi tentang kernel.

Apa yang dijanjikan model LTS, dan apa yang tidak dijanjikannya

Mainline bukan versi yang Anda jalankan. Rilis mainline digantikan 9 hingga 10 minggu kemudian. Stable tree membawa perbaikan selama beberapa minggu setelah setiap rilis. Cabang longterm, yang biasanya ditulis sebagai LTS, membawa perbaikan tersebut selama bertahun-tahun. Distribusi membangun rilisnya berdasarkan cabang-cabang ini.

2.6.32, yang dirilis pada Desember 2009, membuktikan bahwa model ini berhasil. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1, dan Ubuntu 10.04 LTS semuanya merilisnya. Cabang tersebut dipelihara hingga Februari 2016, lebih dari enam tahun setelah pertama kali dirilis.

Durasi dukungan ini telah berubah lebih dari sekali. Awalnya dua tahun, kemudian enam tahun untuk beberapa cabang. Pada 2023, para maintainer stable mengurangi durasi default menjadi dua tahun karena melakukan backport ke tree lama membutuhkan waktu maintainer, sementara cabang lama hanya menerima sedikit pengujian nyata. Pada 25 Februari 2026, Greg Kroah-Hartman kembali menerbitkan proyeksi yang lebih panjang setelah berdiskusi dengan perusahaan yang bergantung pada cabang-cabang tersebut. Kerangka kerja saat ini menetapkan durasi antara tiga hingga enam tahun.

[
  {
    "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 mencantumkan 6 cabang longterm per Agustus 2026. Cabang tertua, 5.10, akan membawa perbaikan selama 6.0 tahun ketika masa dukungannya berakhir pada Dec 2026. Cabang terbaru, 6.18, diproyeksikan tetap berjalan hingga Dec 2028, yaitu 3.1 tahun dukungan perbaikan.

Anggap tanggal-tanggal tersebut sebagai batas minimum, bukan kontrak. Proyeksi untuk 6.6 dan 6.12 sama-sama diperpanjang pada Februari 2026, tetapi cabang yang tidak digunakan siapa pun dapat dihentikan lebih awal. Distribusi Anda biasanya menentukan pilihan ini: Debian 13 merilis 6.12, sedangkan Ubuntu 26.04 LTS merilis 7.0. Perbedaan tersebut merupakan isi praktis dari pertanyaan LTS dibandingkan rilis interim pada server, dan itulah perubahan nyata pada sistem ketika Anda meningkatkan Ubuntu 24.04 ke 26.04.

Hal ini menimbulkan satu jebakan. uname -r pada Ubuntu 24.04 mencetak sesuatu seperti 6.8.0-51-generic. Nilai tersebut menunjukkan basis upstream yang ditambah backport dari distribusi itu sendiri. Karena itu, angkanya menunjukkan dari mana cabang tersebut dimulai, bukan perbaikan apa saja yang ada di dalamnya. Scanner yang menilai kernel berdasarkan string versinya memunculkan peringatan keliru terhadap kernel distribusi karena alasan ini.

Hal yang sedang diperdebatkan oleh kernel saat ini

Ada dua perdebatan yang sedang berlangsung, dan keduanya berkaitan dengan pihak yang mengerjakan suatu tugas.

Rust menjadi bagian dari infrastruktur pada 6.1 pada Desember 2022. Pada 7.0, label eksperimental dihapus. Dengan demikian, bahasa inti kernel adalah C, assembly, dan Rust, serta proses build tidak lagi memerlukan compiler nightly. Perselisihan ini berkaitan dengan pemeliharaan. Maintainer C yang mengubah suatu interface dapat merusak binding Rust yang tidak mereka tinjau. Perdebatan berfokus pada pihak yang bertanggung jawab untuk memperbaikinya.

Perdebatan kedua berkaitan dengan kontribusi AI. Sasha Levin mengusulkan kebijakan pada Juli 2025 setelah volume patch yang dibantu mesin meningkat di mailing list. Dokumen tersebut di-commit pada 23 Desember 2025 dan kini berada dalam dokumentasi proses kernel di docs.kernel.org/process/coding-assistants.html. Agen AI tidak boleh menambahkan tag Signed-off-by karena baris tersebut menyatakan Developer Certificate of Origin (DCO), dan hanya manusia yang dapat menyatakannya. Bantuan AI dinyatakan dengan tag Assisted-by:, yang diubah dari Co-developed-by: selama proses review karena tool bukanlah author. Kode yang dihasilkan harus kompatibel dengan GPL-2.0-only. Manusia yang mengirim patch tersebut meninjaunya dan bertanggung jawab atas patch itu.

Tekanan yang melatarbelakangi kebijakan ini adalah waktu review. Pembuatan patch hanya memerlukan beberapa detik, sedangkan peninjauannya dapat menghabiskan waktu satu sore maintainer. Tag tidak mengatasi ketimpangan tersebut. Namun, tag mempertahankan provenance: riwayat tetap mencatat pihak yang menandatangani setiap perubahan. Inilah aspek yang hendak dilindungi oleh DCO sejak diperkenalkan pada 2004.

Makna riwayat ini bagi server yang Anda sewa

• Lisensi tersebut memungkinkan Anda membaca dan membangun ulang kernel yang dijalankan oleh penyedia, serta memungkinkan software proprietary tetap berjalan di dalamnya.
• Desain monolitik menyebabkan satu bug pada driver me-reboot seluruh mesin, dan menyebabkan modul out-of-tree harus dibangun ulang setiap kali kernel di-upgrade.
• Model rilis menyebabkan nomor versi hanya memberikan sedikit informasi, sedangkan branch dan tanggal end-of-life memberikan hampir seluruh informasi yang Anda perlukan.
• Jenis virtualisasi menentukan hal-hal yang dapat Anda lakukan: pada KVM, Anda menjalankan kernel sendiri dan memuat modul. Pada virtualisasi berbasis container yang menggunakan kernel host bersama, uname -r menampilkan versi milik host, modprobe gagal, dan beberapa sysctl bersifat read-only.

FAQ

Mengapa kernel Linux masih menggunakan GPLv2 dan bukan GPLv3?

Torvalds menolak GPLv3 pada 2007, terutama karena persyaratan anti-tivoisation yang mewajibkan perangkat yang merilis kode GPL juga menerima versi modifikasi dari kode tersebut. Menurutnya, perangkat keras yang dikunci merupakan urusan bisnis produsen. Relisensi juga hampir tidak mungkin dilakukan dalam praktik karena hak cipta kernel dimiliki ribuan kontributor dan tidak ada perjanjian pengalihan hak yang dapat dijadikan dasar. Kernel menggunakan GPL-2.0-only, sehingga kode yang hanya ditawarkan berdasarkan GPLv3 tidak dapat digabungkan.

Apakah kernel Linux merupakan kernel monolitik atau microkernel?

Kernel Linux bersifat monolitik dan mendukung modul yang dapat dimuat. Driver dan filesystem berjalan di dalam ruang alamat kernel, dan lsmod menampilkan komponen yang sedang dimuat. Dampaknya adalah kecepatan di satu sisi dan cakupan kerusakan yang lebih besar di sisi lain: modul yang bermasalah dapat menyebabkan seluruh mesin mengalami kernel panic, sedangkan microkernel hanya akan kehilangan satu proses. Perbedaan ini berkurang sejak 1992 melalui filesystem FUSE di ruang pengguna dan program eBPF yang diverifikasi kernel sebelum dijalankan.

Apa perbedaan antara kernel mainline, stable, dan longterm?

Mainline adalah tree milik Torvalds yang dirilis setiap 9 hingga 10 minggu, dan fitur baru pertama kali masuk ke sana. Stable mengambil rilis mainline terbaru dan menerima perbaikan bug selama beberapa minggu. Branch longterm terus menerima perbaikan selama bertahun-tahun, dan distribusi menggunakan branch tersebut sebagai dasar kernel mereka. kernel.org mencantumkan branch longterm saat ini beserta tanggal akhir masa pakai yang diproyeksikan untuk masing-masing branch.

Apakah kernel Linux menerima kode yang ditulis oleh AI?

Ya, berdasarkan kebijakan yang ditetapkan pada December 2025. Tool tersebut harus disebutkan dalam tag Assisted-by:, agen AI tidak boleh menambahkan baris Signed-off-by, dan kode yang dihasilkan harus kompatibel dengan GPL-2.0-only. Pengirim manusia harus menandatangani persetujuan, yang berarti mereka telah meninjau patch tersebut dan bertanggung jawab atasnya berdasarkan Developer Certificate of Origin.

Versi kernel mana yang sebaiknya saya jalankan di server?

Dalam hampir semua kasus, gunakan versi yang dipelihara oleh distribusi Anda. Kernel distribusi merupakan branch longterm yang dilengkapi perbaikan yang di-backport serta pengujian dari vendor. Kernel tersebut juga menjadi asumsi dasar image dari provider dan pengaturan dukungan Anda. Bangun kernel mainline yang lebih baru jika Anda memerlukan driver atau fitur tertentu. Sebelum menggunakannya, periksa tanggal akhir masa pakai branch yang akan Anda gunakan.