Dependensi wajib Rust akan diperkenalkan ke Debian APT mulai Mei 2026

• Manajer paket APT Debian akan mulai menyertakan kode dan dependensi berbasis Rust setelah Mei 2026
• Pada tahap awal, cakupan integrasi mencakup kompiler Rust, pustaka standar, dan ekosistem Sequoia
• Parser file .deb, .ar, .tar dan kode verifikasi tanda tangan HTTP menjadi area perbaikan utama dari sisi keamanan memori dan penguatan pengujian unit
• Port yang belum memiliki toolchain Rust perlu membangun lingkungan Rust dalam 6 bulan atau mengakhiri dukungan (sunset)
• Ini merupakan langkah untuk mendorong seluruh proyek beralih ke alat dan teknologi modern, agar tidak terhambat oleh kompatibilitas dengan perangkat keras lama

---

Rencana pengenalan kode Rust di APT

• Kode Rust dan dependensi keras (hard dependency) akan diperkenalkan ke APT setelah Mei 2026
  • Waktu penerapannya adalah setelah Mei 2026, dan tidak akan diberlakukan sebelumnya
• Cakupan integrasi awal dibatasi pada kompiler Rust, pustaka standar, dan ekosistem Sequoia

Tujuan peningkatan kualitas dan keamanan kode

• Kode parsing file .deb, .ar, .tar serta kode verifikasi tanda tangan HTTP menjadi target utama adopsi Rust
  • Disebutkan bahwa area ini akan sangat diuntungkan oleh bahasa yang aman terhadap memori dan sistem pengujian unit yang diperkuat

Persyaratan untuk pemelihara port

• Port yang belum memiliki toolchain Rust harus membangun lingkungan Rust dalam 6 bulan
  • Jika tidak, port tersebut dapat dihentikan (sunset)

Arah proyek

• Ditekankan bahwa proyek Debian perlu berkembang dengan memanfaatkan alat dan teknologi modern
  • Disebutkan bahwa perkembangan tidak boleh tertunda karena upaya menyesuaikan diri dengan perangkat keras lama atau perangkat retro computing

Informasi lain

• Pengirimnya adalah pengembang inti Debian dan Ubuntu Julian Andres Klode
• Email tersebut diposting di milis pengembang Debian debian-devel
• Terdapat lampiran tanda tangan PGP (signature.asc)
• Tidak ada penyebutan detail teknis tambahan atau perubahan jadwal

[GN⁺]

Komentar Hacker News

• Rasanya memang sudah waktunya. Tetap mempertahankan kode parser untuk data yang tidak tepercaya dalam C adalah utang teknis yang makin besar seiring waktu
  Rust juga tidak jauh lebih sulit ditulis daripada C, dan jika C dibuat ulang hari ini dengan mencerminkan pengetahuan saat ini tentang desain bahasa dan keamanan kode, kemungkinan hasilnya akan mirip Rust
  Kalau dukungan 32-bit x86 bisa dibuang karena alasan praktis, arsitektur seperti ini juga sama saja. Kalau benar-benar ingin mempertahankannya, backend toolchain Rust harus dibuat sendiri

  • Saat ini bahasa yang diizinkan untuk aplikasi inti di sistem dasar kira-kira hanya C, C++, Shell(bash), Perl, dan Python. Python ditambahkan sekitar 20 tahun lalu, dan Rust adalah bahasa pertama yang cukup dekat untuk menggantikan peran C
    Go yang paling mendekati, tetapi tidak pernah benar-benar dibahas untuk dipakai di sistem inti seperti systemd. Saya jadi penasaran apakah dulu juga ada perdebatan seperti ini saat C++, Python, dan Perl ditambahkan
  • Katanya “parser .deb, .ar, .tar dan kode verifikasi tanda tangan HTTP akan diuntungkan oleh bahasa yang aman terhadap memori”, tetapi saya ragu manfaat nyatanya apa kalau harus menulis ulang kode yang sudah matang selama 30 tahun ke bahasa baru
    Apakah benar sepadan membuang kode yang sudah teruji di medan perang lalu menciptakan masalah kompatibilitas dan bug baru?
  • Ada pendekatan yang lebih praktis untuk menyelesaikan masalah keamanan pada kode C lama, yaitu proyek Fil-C. Caranya adalah membuat C pada dasarnya lebih mirip bahasa terkelola, sehingga kebutuhan menulis ulang bisa dikurangi
  • Ini bukan cuma soal keamanan memori. Komunitas C yang menua membuat orang untuk pemeliharaan makin sulit dicari. Tim kami juga sedang memindahkan semua kode C/C++ ke bahasa lain. Sebagian besar pengembang C/C++ sekarang ada di kisaran umur 40-an dan tidak terlalu ingin pindah kerja
  • Saya sulit setuju dengan klaim bahwa Rust adalah penciptaan ulang C secara modern. Misalnya, kode widget jam di desktop COSMIC jauh lebih sulit dibaca dibanding kode C dengan tingkat kompleksitas serupa (seperti GNU coreutils)

• Arus penulisan ulang sistem inti ke Rust memang kuat, tetapi saya ragu apakah keamanan benar-benar membaik hanya dengan menulis ulang alat-alat lama
  Saya paham bahwa memperkenalkan sistem baru itu sulit, tetapi tetap terasa seperti mempertahankan struktur yang ditumpuk berlapis-lapis di atas keputusan desain dari era telegraf

  • Ada dua alasan yang sering terdengar untuk penulisan ulang semacam ini.
    Pertama, hampir tidak ada kontributor baru yang mau menangani codebase C/C++ lama. Kalau dipindah ke Rust, masuknya pengembang baru jadi lebih mudah
    Kedua, keandalan diuji lewat frekuensi penggunaan, tetapi keamanan hanya diuji lewat serangan. Sulit mengatakan bahwa kode lama sudah melewati semua vektor serangan. Karena itu ada alasan kuat untuk memperkuat keamanan secara proaktif
  • uutils/coreutils berlisensi MIT, sedangkan GNU coreutils berlisensi GPL, jadi ada perbedaan lisensi. Dari sudut pandang perusahaan, ini bisa jadi poin penting
  • Karena memang harus ada yang belajar, menurut saya tidak masalah menulis ulang proyek yang sederhana dan mudah diuji sebagai latihan. Tapi apakah hasilnya layak menggantikan aslinya itu pembahasan yang berbeda

• Menurut utas email Debian, Rust sebenarnya sudah wajib di sebagian besar arsitektur rilis Debian
  Di email terkait, hanya alpha, hppa, m68k, dan sh4 yang disebut sebagai pengecualian. Saya penasaran bagaimana nasib arsitektur-arsitektur ini ke depan

  • Saya sungguh penasaran apakah masih ada orang yang memakai mesin-mesin tua seperti ini. Sebagian besar perangkat kerasnya sudah berumur lebih dari 20 tahun.
    Rust menyediakan target Tier 3 untuk m68k, tetapi tidak untuk arsitektur lain. Saya penasaran apa kasus penggunaan nyatanya
  • Menurut Debian Supported Architectures, platform-platform ini berstatus tidak resmi.
    Agak mengejutkan 32-bit x86 dan MIPS malah tidak ada sementara yang ini masih tersisa. Secara pribadi ada sedikit rasa nostalgia, tetapi saya juga tidak tahu dipakai untuk apa sekarang
  • m68k sudah punya port LLVM, jadi implementasi Rust memungkinkan. Backend LLVM untuk alpha, hppa, dan sh4 juga bernilai sebagai bahan referensi pendidikan
    Dulu LLVM pernah punya backend DEC Alpha, tetapi itu sudah sangat lama
  • Dari sudut pandang Ubuntu, arsitektur seperti ini tidak punya nilai komersial
  • Karena sudah benar-benar usang, ya tinggal berhenti di versi dukungan terakhir atau buat distribusi sendiri. Menambahkan dukungan Rust terasa tidak realistis

• Saya berharap komunitas Rust, alih-alih menyusup ke proyek yang sudah ada, membuktikan diri dengan langsung membuat teknologi modern yang benar-benar baru
  Proyek independen seperti Redox adalah contohnya, jadi sayang sekali upaya seperti itu tidak lebih didorong

  • Ini adalah keputusan resmi Debian untuk menambahkan dependensi Rust. Bukan paksaan dari penggemar Rust dari luar
    Memang ada fanatik yang suka bilang “tulis ulang pakai Rust”, tetapi kasus kali ini berbeda
  • ripgrep adalah contoh tepat untuk itu. Dibuat dari nol, dan orang-orang benar-benar menyukainya

• Saya tidak keberatan memakai pustaka standar Rust, tetapi saya tidak ingin menarik 500 paket cargo hanya untuk membangun parser deb yang sederhana

• Mungkin masuk akal menunggu sampai port Rust-for-GCC stabil
  Kernel juga tidak berencana menjadikan Rust wajib sebelum dukungan GCC tersedia.
  Kalau sudah ada beberapa implementasi, bahasanya akan terasa kurang labil
  Tetapi kalau dukungan arsitektur diputus sekarang, nanti saat toolchain Rust sudah ada prosedur untuk kembali bisa menjadi rumit

  • Sebenarnya arsitektur-arsitektur ini sudah lebih dari 10 tahun tidak masuk Debian. Perubahan kali ini bukan membuat mereka baru saja terlempar keluar
  • Tidak ada dukungan resmi, dan pemeliharaannya hanya diurus individu di waktu luang. Kecuali ada perusahaan yang mau menangani pemeliharaan jangka panjang, sulit untuk kembali
  • GCCRS bahkan belum bisa membangun libcore, dan masih di level Rust 1.50. Rasanya akan perlu beberapa tahun lagi sebelum layak sebagai kompiler umum
    Malah kemungkinan rustc_codegen_gcc stabil lebih dulu
  • Port-port ini tidak masuk rilis resmi Debian, dan hanya didistribusikan lewat kanal unstable

• Perlu diingat bahwa penulis email diskusi Rust Debian ini adalah pemelihara paket keepassxc
  Ada utas lama yang menyebut ia juga pernah bersikap kasar kepada pengembang upstream dan pengguna

  • Saya juga langsung mengecek setelah melihat email itu, lalu tertawa karena teringat utas lama tersebut
  • Sejujurnya, ungkapan yang dia pakai memang keras, tetapi lebih blak-blakan daripada menghina. Buat saya ini terlihat seperti drama yang tidak perlu
  • Postingan HN-nya sendiri tidak agresif, tetapi beberapa orang tampaknya bereaksi berlebihan
  • Budaya seperti ini memang merajalela di dunia perangkat lunak bebas. Menurut saya, kecenderungan mengejar sosok pengguna ideal ketimbang pengguna nyata sudah berlanjut sejak era GNOME 3 dan Mozilla

• Menarik melihat bagaimana pendapat seseorang bisa berubah. Tautan ke pernyataan sebelumnya

  • Menyenangkan melihat sikap yang mau mengubah pandangan seiring waktu
  • Adopsi Rust di APT juga mungkin merupakan keputusan administratif, seperti transisi coreutils

• Saya menganggap Rust hanya tren sesaat (hype). Di dunia embedded, C tetap rajanya.
  Saya belum pernah melihat orang di sekitar saya benar-benar memakai atau bahkan mempertimbangkan Rust

  • Menarik kesimpulan dari “di sekitar saya tidak ada” rasanya terlalu berlebihan. Banyak juga pengembang embedded yang memakai Rust
  • Di internal AWS, layanan inti seperti EC2, IAM, DynamoDB, dan S3 ditulis dalam Rust.
    Performa dan efisiensi memori tetap terjaga sambil mempercepat pengembangan.
    Satu-satunya kelemahan hanya ukuran biner. Menurut saya masa depan Rust sudah sangat kokoh
  • Rust juga kuat di ranah embedded, tetapi dukungan dari vendor masih kurang sehingga beban kerja awal per perangkat keras cukup besar.
    Meski begitu, daya tariknya bukan hanya keamanan memori, tetapi juga kualitas keseluruhan bahasa dan toolchain
  • Dengan avr-rust, esp-rs, cortex-m, dan lainnya, ekosistem embedded pun pelan-pelan berubah
  • Di Microsoft, Google, dan lainnya pun Rust sedang dibahas dan sudah diterapkan ke produk nyata

• Menurut saya lingkungan polyglot hanya menambah masalah.
  Python, Node, Go, Rust, dan lain-lain masing-masing butuh toolchain serta pengelola paket sendiri, jadi makin rumit
  Kita menghilangkan buffer overflow dengan Node, lalu malah menambah serangan rantai pasok.
  Lebih baik mulai dari nol saja, dan kalau memang ingin memakai Rust secara menyeluruh, yang tepat adalah berkontribusi ke Redox OS

  • Secara realistis, tiap bahasa punya kelebihan dan kekurangan sendiri, dan Debian sebagai OS yang pragmatis memang perlu mendukung berbagai bahasa
    Menulis ulang semuanya dalam satu bahasa itu tidak realistis, dan terlalu mendorong Redox juga bisa jadi justru tidak efisien
    Rust sudah cukup terbukti, dan sebagai bahasa terkompilasi yang peluang merusak sistem saat modifikasi lebih rendah dibanding C, ia punya nilai jelas
    Membuang arsitektur lama juga bukan hal yang tidak masuk akal
  • Untuk proyek sebesar Debian, memperluas pilihan adalah keputusan yang masuk akal. Menambahkan Rust adalah keputusan yang cukup bisa dipahami
    Bahasa mana yang harus dihapus atau ditambahkan adalah urusan para pemelihara Debian
  • Linux sebenarnya sudah menyerah dalam perang melawan kompleksitas sejak puluhan tahun lalu