Greg K-H: "Menulis kode baru dengan Rust menguntungkan semua orang"

Mengapa Rust perlu diadopsi ke kernel Linux

• Berdasarkan pengalaman meninjau hampir semua perbaikan bug kernel Linux dan masalah keamanan selama 15 tahun terakhir, saya ingin menjelaskan perlunya adopsi Rust
• Tidak semua perbaikan bug masuk ke pohon versi stabil, tetapi secara umum yang penting akan masuk, dan saya berada pada posisi untuk memeriksa semua CVE kernel

Batasan C dan keunggulan Rust

• Sebagian besar bug yang terjadi di kernel Linux berasal dari batasan struktural bahasa C
• Terutama, ada banyak bug yang muncul karena kesalahan sederhana, dan masalah seperti ini hampir tidak terjadi di Rust
  • Memory overwrite (Rust tidak menangkap semua kasus, tetapi dapat menyelesaikan sebagian besar)
  • Masalah pembersihan jalur error
  • Pemeriksaan nilai error yang terlewat
  • Bug use-after-free (digunakan setelah dibebaskan)
• Dengan mengadopsi Rust di kernel, developer dan maintainer bisa terlepas dari kesalahan mendasar seperti ini dan fokus pada masalah yang benar-benar sulit (kesalahan logika, race condition, dll.)

Codebase C yang ada tetap harus dipertahankan

• Saat ini kernel Linux terdiri dari lebih dari 30 juta baris kode C, dan mustahil menggantinya dengan Rust dalam waktu singkat
• Karena itu, upaya penguatan keamanan kode C yang dilakukan developer seperti Kees dan Gustavo tetap penting dan harus terus dilanjutkan
• Yang ideal bukanlah Rust menggantikan kode yang sudah ada, melainkan menulis kode baru (terutama driver) dengan Rust untuk mengurangi masalah

Keamanan API yang disediakan Rust

• Rust memungkinkan API internal kernel dirancang agar lebih aman dan lebih mudah digunakan
• Saat ini API kernel berbasis C rumit, mudah menimbulkan kesalahan, dan sering kali mengharuskan maintainer meninjaunya dengan sangat teliti
• Sebagai contoh, ada berbagai cara untuk menggunakan struktur seperti struct cdev dengan aman, dan dibutuhkan banyak pengalaman untuk memanfaatkannya dengan benar
• Dengan Rust, API bisa didefinisikan dengan lebih jelas, sehingga kemungkinan developer melakukan kesalahan dapat dikurangi secara signifikan
• Ini bukan hanya untuk pengguna Rust, tetapi juga perubahan yang membantu pengguna kode C yang sudah ada

Tanggapan terhadap kekhawatiran bahwa adopsi Rust akan sulit

• Rust bukan solusi ajaib → tetapi dapat menyelesaikan sebagian besar masalah yang ada
• Beban maintainer meningkat → tetapi developer yang menginginkan adopsi Rust-lah yang langsung mengerjakan hal tersebut
• Sulitnya memelihara codebase multibahasa → tetapi kernel Linux selama ini telah memecahkan masalah yang jauh lebih sulit

Kesimpulan

• Linux adalah alat yang digunakan banyak developer di seluruh dunia untuk memecahkan masalah, dan
• sekarang, jika ada tuntutan dari developer yang ingin menulis kode aman untuk hardware, itu tidak boleh diabaikan
• Model pengembangan Linux telah tumbuh hingga skala yang tidak pernah dibayangkan siapa pun, sambil menunjukkan kemampuan engineering yang luar biasa
• Kini saatnya melangkah menuju 20 tahun lebih perkembangan ke depan melalui adopsi Rust

Kita harus menerima teknologi dan ide baru, serta berupaya agar berhasil bersama komunitas.

[bus710]

Penerapan Rust, jika mempertimbangkan memory safety, tampaknya merupakan perubahan yang sulit dihindari. Mungkin akan ada upaya untuk menambal kembali lewat kompromi yang tepat.

Namun, secara pribadi, kata kunci Rust agak sulit tertangkap di mata saya, dan ketika melihatnya lagi lama setelahnya saya juga sering sulit mengingatnya, jadi rasanya memang agak susah untuk benar-benar akrab dengannya ;;;;

Saya paham semuanya memang hal-hal yang dibutuhkan, tetapi kadang terasa seperti dipaksa menghafal kata kerja tak beraturan dalam bahasa Inggris. Meski begitu, memang benar juga bahwa hasil karya yang ditulis dengan Rust cenderung menimbulkan lebih sedikit masalah di lapangan.....

[lostid]

Saya rasa keputusan untuk tidak memasukkan bahasa yang masih belum matang ke dalam kernel tidak pantas mendapat kecaman sebesar ini. Kalau diminta mencari orang di sekitar Anda yang benar-benar mahir menggunakan Rust sekarang juga, bukankah hampir tidak ada? Menurut saya, tidak akan terlambat jika bahasa ini dimasukkan setelah menjadi lebih matang dan jumlah penggunanya sudah cukup banyak, meski tidak harus sebanyak pengguna bahasa legacy.
Saya percaya kegunaan bahasa Rust bisa dibuktikan dengan cukup, bahkan tanpa harus diterapkan pada kernel Linux.

[pcpenpal]

Cukup mengejutkan bahwa Rust, bahkan pada tingkat seperti sekarang, masih disebut sebagai "bahasa yang belum matang". Namun terlepas dari itu, saya juga merasa aneh kalau upaya untuk setidaknya mengurangi porsi bahasa yang tidak aman di kernel masih sampai mendapat kecaman sebesar ini. Di sekitar kita pun, tidak banyak orang yang cukup mahir menulis kode aman dalam C hingga bisa berkontribusi ke kernel, bukan? Daripada terus berharap C akan menjadi lebih matang lagi, sekarang justru tampaknya belum terlambat, ketika tuntutan era baru sudah cukup jelas terbentuk.

Rust sudah berguna, dan upayanya untuk masuk ke kernel kemungkinan bukan untuk membuktikan bahwa ia berguna.

[aer0700]

Saat pertama kali memutuskan untuk mengadopsi Rust, rasanya memang pasti ada pembahasan soal itu.
Kalau dipikir-pikir, antara yang mahir C dan yang mahir Rust, jumlah talent pool jelas jauh lebih besar di pihak C.
Tapi di sisi lain, programmer yang sudah punya pengetahuan domain lengkap belajar satu bahasa lagi rasanya bukan hal sebesar itu,
meski tingkat kemahiran yang dituntut dari orang-orang yang menangani kernel tentu jadi cerita yang berbeda...

[roxie]

Pendapat ini juga bagus.

[nemo1275]

Saya sama sekali tidak mengerti klaim yang menyuruh untuk melakukan fork lalu keluar. Memangnya kenapa Linus harus melakukan fork dan keluar dari Linux?

[regentag]

Apakah ada yang menyuruh Linus untuk melakukan fork lalu pergi? Sepertinya saya belum melihat ada orang yang mengatakan hal seperti itu dalam perdebatan ini..

[cloverhearts]

Saya juga pengguna Rust, tetapi jika kode Rust dan kode C bercampur, tanpa aturan yang ketat di proyek open source tentang sampai sejauh mana kode Rust diizinkan, menurut saya itu akan menjadi tidak terkendali atau setidaknya biaya review dan pemeliharaannya akan naik sangat besar, jadi saya melihat bahwa pilihan paling bijak adalah melakukan fork tanpa menambahkannya.

[aer0700]

Saya tidak terlalu paham kernel, tetapi rasanya akan bagus jika kode C bisa diterjemahkan otomatis ke Rust. Tentu saja, selain masalah penerjemahan kode, mungkin juga ada masalah manusianya.

[regentag]

Jika memang ada banyak orang yang ingin membawa Rust ke kernel, bukankah mereka bisa melakukan fork lalu membuat proyek baru? Kemudian, saat sudah cukup matang, distro-distro utama mungkin akan beralih ke kernel berbasis Rust.
Saya benar-benar tidak paham kenapa mereka saling bertengkar.

[gurugio]

Saya tidak begitu tahu apakah Anda punya pengalaman dalam pengembangan kernel, jadi saya juga kurang tahu harus menjelaskan bagaimana.
Pertama-tama, menerapkan bahasa Rust bukan berarti mengganti kernel menjadi Rust. Anda mungkin bisa bertanya, bukankah cukup dipisahkan lalu membuat kernel lain?
Bukan berarti ingin membuat kernel dengan bahasa Rust, melainkan hanya membuat wrapper dalam Rust untuk antarmuka perangkat driver di kernel, sehingga hanya perangkat driver saja yang bisa
dibuat dengan Rust. Jadi, beralih ke proyek baru tidak ada artinya.

[regentag]

Saya belum pernah mengembangkan untuk Linux.
Sepertinya wrapper Rust untuk device driver memiliki struktur yang tidak bisa dipisahkan dari kernel...

[mammal]

Sungguh ironis melihat komunitas Linux, yang selama ini membenarkan gaya bicara toksik demi stabilitas kernel, sekarang justru menganggap respons seperti 'kalau tidak suka, fork saja' sebagai jawaban yang masuk akal.

[regentag]

Saya bukan bagian dari komunitas Linux, tetapi...

[roxie]

Saya rasa mereka dan penulis komentar ini tidak boleh dianggap sebagai komunitas yang sama.

[jeiea]

Sepertinya ada hal yang sulit diprediksi: apakah hasil fork ini akan menjadi migrasi, atau justru memasuki masa perang antarkerajaan.
Bahkan setelah melakukan fork, sepertinya juga bukan situasi yang menyenangkan untuk terus mengikuti perubahan dari upstream.

[savvykang]

https://id.news.hada.io/topic?id=16860
Melihat fork Realtime Linux baru digabungkan setelah 20 tahun, bukankah seharusnya keputusan untuk melakukan fork dibuat dengan sangat hati-hati?

[regentag]

Saya mengatakan itu setelah melihat ini.
Fitur real-time sudah lama bisa dipertahankan sebagai proyek yang terpisah dari kernel, dan siapa pun yang membutuhkan bisa mengambilnya lalu menerapkannya ke kernel untuk digunakan.

[ilsubyeega]

Saya memang pengguna Rust, tetapi saya terkesan dengan komentar hgwxx7_ yang diposting di r/rust1.

Saya rasa yang dilakukan Greg dengan sangat baik di sini adalah menunjukkan kepemimpinan teknis. Kepemimpinan tidak berarti selalu benar. Memang dia benar, tetapi itu bukan intinya.

Kepemimpinan berarti mengajak orang lain menempuh jalan yang menurutnya terbaik. Dia tidak membentak, memarahi, atau memaksa para maintainer yang tidak setuju. Sebaliknya, pertama-tama dia mengakui kekhawatiran mereka yang sangat valid tentang memelihara code base dengan dua bahasa. Ini bagus, karena mereka memang benar soal itu, hidup mereka memang akan menjadi lebih sulit sebelum akhirnya menjadi lebih mudah.

Lalu dia menutupnya dengan nada yang menginspirasi, menunjukkan bahwa mereka sudah melakukan hal-hal yang jauh lebih sulit dan ini sepenuhnya berada dalam kemampuan mereka. Dia dengan halus mendorong mereka untuk menyambut para pengembang R4L.

Benar-benar kelas master dalam kepemimpinan.
Saya tidak tahu apakah maintainer lain akan teryakinkan saat mereka membaca ini. Tetapi sulit bagi saya untuk membayangkan ajakan yang lebih meyakinkan daripada yang ini.

[gurugio]

Saya ingat saat menghubungi beliau karena perlu backport ke versi stable atau hal serupa, beliau tetap merespons dengan baik meski sedang sangat sibuk.

[codemasterkimc]

"Rust bukanlah jawaban yang mutlak, tetapi lebih mendekati jawaban dibanding Java dan Python" -codemaster kimc-

[GN⁺]

Opini Hacker News

• Jika ada binding Rust, ABI internal kernel tidak bisa berevolusi dengan bebas, dan ada risiko proyek terpecah antara inti C dan sisi Rust. Namun, jika API internal distabilkan, hal itu bisa menguntungkan Linux
• Komunitas dan orang-orang adalah masalah utamanya. Jika orang-orang yang saat ini mengerjakan kernel tidak menyukai arah ini, itu adalah masalah besar
• Kepemimpinan Linux tampaknya tidak fokus pada masalah manusia. Dipertanyakan di mana bukti bahwa orang-orang yang saat ini mengembangkan kernel setuju dengan arah ini
• Ada orang-orang yang berpikir bahwa menerima Rust membawa lebih banyak penderitaan daripada manfaat. Mereka berpikir manfaat yang sama bisa didapat dengan cara lain
  • Misalnya, bounds checking dan penyederhanaan alokasi/dealokasi sederhana seperti RAII mungkin bisa dilakukan tanpa Rust
  • Dengan menjadikan Clang sebagai compiler wajib dan mengadopsi ekstensi semacam itu, efeknya bisa didapat dengan lebih mudah
• Jika kode/driver baru ditulis dalam Rust, bug jenis ini tidak akan muncul. Ini menguntungkan semua orang
• Kebanyakan orang menginginkan memory safety, tetapi tidak ingin menjadi maintainer secara menyeluruh
• Tujuan nyata proyek ini adalah memodernisasi permukaan API kernel internal. Seberapa jauh API ini bisa ditulis dalam Rust adalah tolok ukur terbaik untuk mengukur kemajuan
• Sebagai orang yang telah melihat hampir semua perbaikan bug kernel dan masalah keamanan selama 15 tahun terakhir, sebagian besar bug berasal dari corner case kecil di C. Di Rust, masalah seperti ini hilang
• Jika kode/driver baru ditulis dalam Rust, bug jenis ini tidak akan muncul. C++ tidak memberikan keuntungan ini
• Rust membuat kesalahan saat mendefinisikan API kernel menjadi hampir mustahil. Ini membuat Linux secara keseluruhan menjadi lebih baik
• Binding Rust terlihat seperti sihir, tetapi ada kemauan untuk belajar dan bekerja sama dengan para pengembang
• Rust bukan peluru perak yang menyelesaikan semua masalah, tetapi membantu dalam banyak hal
• Linux adalah alat bagi semua orang untuk memecahkan masalah. Ketika pengembang menulis kode untuk perangkat keras, mereka ingin bug seperti ini tidak terjadi
• Codebase campuran lintas bahasa memang sulit dirawat, tetapi kita adalah pengembang kernel. Kita harus menerima ide baru dan berusaha berhasil bersama
• Pernyataan ini diperlukan untuk mendorong diskusi ini maju
• Fokusnya memang pada keunggulan teknis, tetapi upaya untuk mempelajari bahasa pemrograman/toolchain baru tidak dinilai dengan semestinya
• Menguasai bahasa pemrograman baru bukan hal yang mudah, dan beberapa maintainer mungkin tidak menginginkannya karena minat/motivasi pribadi
• Masalah di komite bahasa C++ menunjukkan bahwa semua orang seharusnya meninggalkan bahasa itu secepat mungkin.

[hbahk42]

Apakah komentar kebencian seperti ini tidak bisa dilaporkan?

[kodingwarrior]

Saya setuju.