Model rilis stabil kernel Linux dimulai pada tahun 2005, ketika ditetapkan bahwa model pengembangan {i>kernel<i} yang ada (rilis baru setiap 2-3 bulan) tidak memenuhi kebutuhan sebagian besar pengguna. Pengguna menginginkan perbaikan bug yang dilakukan selama 2-3 tahun tersebut bulan, dan distribusi Linux merasa sulit untuk memperbarui {i>kernel<i} tanpa umpan balik dari komunitas {i>kernel<i}. Secara umum, upaya untuk menjaga {i>kernel<i} individu aman dan dengan perbaikan bug terbaru adalah masalah besar dan membingungkan yang berbeda oleh banyak orang yang berbeda.
Rilis {i>kernel<i} stabil didasarkan langsung pada rilis, dan merupakan dirilis setiap minggu atau lebih, tergantung pada berbagai faktor eksternal (waktu dalam setahun, patch yang tersedia, workload pemeliharaan, dll.). Penomoran kandang kuda dimulai dengan jumlah rilis {i> kernel<i}, dan jumlah tambahan ditambahkan di bagian akhir. Misalnya, {i>kernel<i} 4.4 dirilis oleh Linus, dan maka rilis {i>kernel<i} stabil berdasarkan {i> kernel<i} ini diberi nomor 4.4.1, 4.4.2, 4.4.3, dan seterusnya. Urutan ini biasanya dipersingkat dengan angka 4.4.y ketika merujuk pada pohon rilis {i>kernel<i} yang stabil. Setiap pohon rilis {i> kernel<i} stabil memiliki dikelola oleh satu pengembang {i>kernel<i}, yang bertanggung jawab untuk memilih {i>patch<i} yang diperlukan untuk rilis dan mengelola proses peninjauan/rilis.
Kernel stabil dipertahankan selama siklus pengembangan saat ini. Setelah Linus merilis {i>kernel<i} baru, pohon rilis {i>kernel<i} stabil sebelumnya dihentikan dan pengguna harus berpindah ke {i>kernel<i} yang baru dirilis.
Kernel stabil jangka panjang
Setelah setahun menjalankan proses rilis baru yang stabil, dipastikan bahwa ada banyak berbagai pengguna Linux ingin {i>kernel<i} mendukung dukungan lebih dari sekadar beberapa bulan. Sebagai respons, rilis {i>kernel<i} yang didukung Jangka Panjang (LTS) dibuat, dengan kernel LTS pertama (2.6.16) dirilis pada 2006. Sejak saat itu, sebuah {i>Kernel<i} LTS telah dipilih setahun sekali dan komunitas {i>kernel<i} mempertahankan bahwa {i>kernel<i} selama minimal 2 tahun.
Pada saat penulisan ini, {i>kernel<i} LTS adalah 4.4.y, 4.9.y, 4.14.y, rilis 4.19.y, 5.4.y, dan 5.10.y. {i>Kernel<i} baru dirilis setiap minggu. Karena kebutuhan beberapa pengguna dan distribusi, beberapa {i>kernel<i} tambahan yang lebih lama dikelola oleh pengembang {i>kernel<i} pada siklus rilis yang lebih lambat. Informasi tentang semua {i>kernel<i} stabil jangka panjang, siapa yang bertanggung jawab atas mereka, dan berapa lama mereka dikelola, dapat ditemukan di kernel.org rilis.
Kernel LTS merilis rata-rata 6-8 patch yang diterima per hari, sedangkan rilis {i>kernel<i} stabil berisi 10-15 {i>patch<i} per hari. Jumlah {i>patch<i} berfluktuasi per rilis mengingat waktu pengembangan terkait saat ini rilis {i>kernel<i}, dan variabel eksternal lainnya. {i>Kernel<i} LTS yang lebih tua, lebih sedikit {i>patch<i} yang diterapkan karena banyak perbaikan bug terbaru yang tidak relevan dengan {i>kernel<i} yang lebih lama. Namun, semakin tua sebuah {i>kernel<i}, semakin sulit untuk melakukan {i>backport<i} perubahan yang perlu diterapkan karena perubahan codebase. Namun meskipun mungkin ada jumlah {i>patch<i} keseluruhan yang diterapkan lebih rendah, upaya dalam memelihara {i>kernel<i} LTS lebih besar daripada mempertahankan {i>kernel<i} yang stabil.
Aturan patch kernel stabil
Aturan untuk apa yang bisa ditambahkan ke rilis {i>kernel<i} yang stabil tetap ada hampir identik sejak diperkenalkan dan diringkas di bawah ini:
- Harus benar dan sudah teruji.
- Tidak boleh lebih dari 100 baris.
- Harus memperbaiki satu hal saja.
- Harus memperbaiki sesuatu yang telah dilaporkan sebagai masalah.
- Dapat berupa ID perangkat baru atau quirk untuk hardware, tetapi tidak menambahkan software baru fungsionalitasnya.
- Harus sudah digabungkan ke dalam Linus Torvalds hierarki.
Aturan terakhir, "Harus sudah digabungkan ke Linus Torvalds' pohon", mencegah komunitas {i>kernel<i} agar tidak kehilangan perbaikan. Komunitas tidak menginginkan perbaikan ke dalam rilis {i>kernel<i} stabil yang belum ada di organisasi Linus Torvalds pohon, sehingga bahwa siapa pun yang melakukan upgrade tidak akan pernah melihat regresi. Hal ini mencegah banyak masalah yang dapat diselesaikan oleh project lain yang mempertahankan cabang stabil dan pengembangan miliki.
Update kernel
Komunitas {i>kernel<i} Linux telah menjanjikan basis penggunanya bahwa tidak ada upgrade merusak apa pun yang berfungsi di rilis sebelumnya. Bahwa janji itu masih berlaku sampai hari ini. Regresi memang terjadi, tetapi itu adalah yang tertinggi {i>bug<i} prioritas dan bisa diperbaiki dengan cepat, atau perubahan yang menyebabkan regresi dengan cepat dikembalikan dari hierarki pohon {i>kernel<i} Linux.
Promise ini berlaku untuk kedua pembaruan {i>kernel<i} stabil secara bertahap, serta pembaruan besar yang lebih besar yang terjadi setiap tiga bulan. Namun, komunitas kernel hanya dapat membuat promise ini untuk kode yang digabungkan ke dalam Hierarki kernel Linux. Kode apa pun yang digabungkan ke dalam {i> kernel<i} perangkat yang tidak ada di rilis kernel.org tidak diketahui dan interaksi dengannya tidak pernah dapat direncanakan, atau bahkan dipertimbangkan.
Perangkat berbasis Linux yang memiliki kumpulan {i> patch<i} yang besar dapat memiliki masalah besar ketika memperbarui ke {i>kernel<i} yang lebih baru, karena banyaknya perubahan di antara setiap rilis (10-14 ribu perubahan per rilis). Patchset SoC dikenal bermasalah dengan pembaruan ke {i> kernel<i} yang lebih baru karena ukurannya yang besar dan modifikasi dari arsitektur tertentu, dan terkadang kode {i>kernel<i} inti. Sebagai seorang hasilnya, sebagian besar vendor SoC mulai menstandarkan penggunaan rilis LTS untuk perangkat mereka, sehingga perangkat tersebut dapat menerima pembaruan {i>bug<i} dan keamanan langsung dari komunitas {i>kernel<i} Linux.
Keamanan
Saat melakukan rilis {i>kernel<i}, komunitas {i>kernel<i} Linux hampir tidak pernah mendeklarasikan perubahan tertentu sebagai perbaikan keamanan. Hal ini karena masalah dasar kesulitan dalam menentukan apakah perbaikan {i>bug<i} adalah perbaikan keamanan atau tidak pada saat itu dari pembuatan. Selain itu, banyak perbaikan bug yang ditentukan hanya terkait dengan keamanan setelah sekian lama berlalu, maka komunitas {i> kernel<i} sangat menyarankan untuk mengambil semua perbaikan bug yang dirilis.
Ketika masalah keamanan dilaporkan ke komunitas {i> kernel<i}, masalah itu akan diperbaiki sesegera mungkin dan meluncurkannya ke sistem pengembangan dan rilis yang stabil. Seperti dijelaskan di atas, perubahan tersebut hampir tidak pernah dijelaskan sebagai "perbaikan keamanan", namun terlihat seperti perbaikan {i>bug<i} lainnya untuk {i>kernel<i}. Ini adalah dilakukan untuk memberikan kemampuan kepada pihak terdampak untuk memperbarui sistem mereka sebelum pelapor masalah akan mengumumkannya.
Untuk mengetahui detail tentang cara melaporkan {i>bug<i} keamanan ke komunitas {i>kernel<i} untuk mendapatkan masalah tersebut diselesaikan dan diperbaiki sesegera mungkin, lihat Bug keamanan dalam Panduan pengguna dan administrator kernel Linux di www.kernel.org.
Karena {i>bug<i} keamanan tidak diumumkan ke publik oleh tim {i>kernel<i}, CVE angka untuk masalah terkait {i>kernel<i} Linux biasanya dirilis berminggu-minggu, berbulan-bulan, terkadang bertahun-tahun setelah perbaikan digabungkan ke dalam yang berbeda.
Jaga sistem yang aman
Saat menerapkan perangkat yang menggunakan Linux, kami sangat menyarankan Update kernel LTS diambil oleh produsen dan didistribusikan ke pengguna mereka setelah pengujian yang tepat menunjukkan bahwa pembaruan berfungsi dengan baik. Kode ini memiliki beberapa keunggulan:
- Rilis telah ditinjau oleh pengembang {i>kernel<i} secara keseluruhan, bukan di bagian individu.
- Sulit untuk menentukan patch mana yang memperbaiki "keamanan" masalah dan mana yang tidak. Hampir setiap rilis LTS berisi setidaknya satu rilis yang diketahui perbaikan keamanan, dan banyak yang belum “tidak diketahui.”
- Jika pengujian menunjukkan masalah, komunitas developer {i>kernel<i} akan bereaksi dengan cepat untuk menyelesaikan masalah.
- Upaya untuk mengecualikan hanya perubahan yang Anda jalankan yang menghasilkan {i>kernel<i} yang tidak mungkin digabungkan dengan benar dengan rilis upstream mendatang.