- Dalam kenyataan saat ini, bahkan fungsi sederhana pun melibatkan ribuan dependensi dan puluhan juta baris kode, sehingga pembengkakan perangkat lunak itu sendiri menjadi penyebab besar kerentanan keamanan
- Keamanan tidak hanya ditentukan oleh kepadatan bug, tetapi juga oleh jumlah total kode yang bisa dijangkau penyerang, dan permukaan serangan yang terlalu luas secara tidak perlu dapat berujung pada insiden nyata
- Ekosistem dependensi Electron JS, Node.js, image Docker, serta npm·PyPI membuat jumlah dan asal kode yang dideploy menjadi kabur, dan bahkan aplikasi untuk membuka pintu garasi pun bisa melibatkan lebih dari 50 juta baris kode aktif
- Rust, sanitizer, dan fuzzer meningkatkan kualitas kode, tetapi kegagalan desain logis seperti mengeksekusi kode di dalam dokumen secara otomatis sulit dicegah hanya dengan menghilangkan bug
- Trifecta menyediakan fitur berbagi gambar dengan 1.600 baris kode baru, sekitar 5 dependensi inti, dan ukuran total 3MB, menunjukkan bahwa perangkat lunak modern tetap bisa dibuat dengan kode dan dependensi yang terbatas
Kondisi keamanan perangkat lunak yang membahayakan
- Kondisi keamanan perangkat lunak belakangan ini sangat buruk
- Selama setahun terakhir, terjadi kasus pelanggaran serius pada perangkat lunak standar industri seperti Ivanti, MOVEit, Outlook, Confluence, Barracuda Email Security Gateway, serta Citrix NetScaler ADC·NetScaler Gateway
- Bahkan perusahaan dengan sumber daya besar seperti Apple dan Google juga melakukan kesalahan keamanan yang membahayakan pelanggan
- Karena ada persepsi bahwa perangkat lunak telah menjadi terlalu berbahaya, nasihat untuk tidak menjalankannya sendiri dan menyerahkannya pada X as a service atau cloud kini menjadi hal yang umum
- Asumsi bahwa cloud membuat perangkat lunak yang rentan menjadi dapat dipercaya juga mulai goyah
- Platform email Microsoft diretas, termasuk email pemerintah yang bersifat rahasia
- Kekhawatiran tentang keamanan cloud Azure masih ada
- Okta mengalami pelanggaran kedua dalam dua tahun, dan setelah itu kasus peretasan pada pengguna Okta terus muncul secara mencurigakan
- UE mendorong tiga legislasi untuk menangani keamanan perangkat lunak
- NIS2: untuk layanan penting
- Cyber Resilience Act: untuk hampir semua perangkat lunak komersial dan perangkat elektronik
- Product Liability Directive: memperluas cakupan tanggung jawab hingga perangkat lunak
Kerentanan muncul dari kualitas kode dan jumlah kode sekaligus
- Keamanan perangkat lunak bergantung pada dua sumbu
- Kepadatan masalah keamanan dalam source code
- Jumlah kode yang dapat diakses peretas
- Semakin banyak kode, semakin besar risikonya
- Bahkan jika kepadatan bug rendah, celah yang bisa dieksploitasi tetap dapat ditemukan di dalam jutaan baris kode
- Kasus iMessage menunjukkan masalah yang timbul ketika permukaan serangan meluas
- Bahkan iMessage yang tidak diinginkan langsung diproses di iPhone untuk membuat pratinjau
- Apple mendukung berbagai format gambar, dan bahkan PDF yang berisi font terkompresi yang aneh ikut diproses
- Format lama tersebut pada praktiknya memuat semacam bahasa pemrograman, dan penyerang bisa memakainya untuk menjelajahi kelemahan lain di ponsel
- Apple sebenarnya bisa mengurangi permukaan serangan dengan membatasi pratinjau ke jauh lebih sedikit format gambar, atau ke satu format “known good”
- EU Cyber Resilience Act juga secara eksplisit menyatakan bahwa vendor harus meminimalkan permukaan serangan
Kode yang lebih baik saja tidak cukup
- Upaya untuk meningkatkan kualitas kode sebenarnya sudah ada
- Bahasa yang aman secara memori seperti Rust
- Alat penguat keamanan seperti AddressSanitizer
- Fuzzer yang secara otomatis memodifikasi input untuk menemukan kerentanan dan bug
- Namun, banyak masalah keamanan berasal dari logika di bawahnya, bukan dari bug pada kodenya sendiri
- Kerentanan email Barracuda berasal dari library pihak ketiga yang memindai spreadsheet Excel untuk pemeriksaan virus tetapi ternyata benar-benar mengeksekusi kode
- Keputusan untuk memasukkan fitur yang mengeksekusi kode di dalam dokumen secara otomatis tidak akan terselesaikan meski semua bug dalam kode berhasil dihilangkan
Tidak mengetahui apa yang sebenarnya dideploy
- Perangkat lunak modern telah menjadi begitu besar sehingga sulit mengetahui apa yang sebenarnya sedang dideploy
- Dalam “A Plea for Lean Software” pada 1995, Niklaus Wirth mengkritik perangkat lunak yang sudah membengkak hingga skala megabyte
- Sistem operasi Oberon miliknya hanya berukuran 200KB, termasuk editor dan compiler
- Sekarang bahkan ada proyek yang file konfigurasinya saja melebihi 200KB
- Saat ini aplikasi tipikal bisa dibangun di atas Electron JS
- Electron JS mencakup Chromium dan Node.js
- Node.js memberi akses ke puluhan ribu paket JavaScript
- Diperkirakan hanya dengan menggunakan Electron JS saja, minimal sudah bisa masuk 50 juta baris kode jika dependensi ikut dihitung
- Aplikasi mengambil ratusan hingga ribuan paket pendukung, dan dependensi kembali menarik dependensi lain
- Apa tepatnya yang masuk ke dalam build bisa berubah setiap hari
- Beberapa paket secara default dapat mengekspos pengguna kepada pengiklan atau broker data
- Aplikasi untuk mengendalikan perangkat di rumah juga bisa terhubung ke stack perangkat lunak milik Amazon, dan stack itu pun dapat memakai Node.js serta berbagai dependensi
- Akibatnya, bahkan untuk membuka pintu garasi saja bisa berjalan lebih dari 50 juta baris kode aktif di atas banyak image sistem operasi dan banyak server
Beban container dan rantai pasok dependensi
- Dulu yang didistribusikan adalah keluaran compiler atau kumpulan file untuk diinterpretasikan, dan dalam proses instalasi serta konfigurasi kita harus memikirkan apa saja yang ada di dalam paket
- Sekarang, dengan container, sering kali bukan hanya perangkat lunaknya yang didistribusikan, tetapi juga file sistem operasi untuk menyamakan lingkungan eksekusi
- Pada praktiknya, sering kali yang didistribusikan adalah image disk komputer yang nyaris lengkap
- Di Docker Hub ada banyak image yang ukurannya melebihi 350MB
- Container bisa dipakai untuk tujuan yang baik, tetapi cara pemakaiannya di dunia nyata dapat sangat meningkatkan jumlah kode yang dideploy
- Juga tidak pasti apakah update keamanan pada dependensi benar-benar sampai ke aplikasi akhir
- Sulit mengetahui apakah bug pemrosesan gambar yang dulu didorong cepat oleh Google dan Apple untuk diperbarui masih tetap ada di aplikasi Electron
- Ekosistem npm punya riwayat pengambilalihan repositori paket, pembajakan, dan hidup kembali paket dengan nama yang sama
- PyPI juga mengalami masalah serupa
- Dependensi memang perlu ditinjau, tetapi sulit mengharapkan orang untuk rutin memeriksa ribuan di antaranya
- Menerapkan ulang semuanya sendiri juga bukan jawaban, dan ada modul bagus seperti SQLite yang kemungkinan justru lebih aman daripada implementasi buatan sendiri
Trifecta: alat berbagi gambar yang dibuat dengan kode kecil
- Trifecta adalah perangkat lunak berbagi gambar mandiri yang minimalis tetapi tetap benar-benar bisa dipakai
- Pengguna bisa berbagi gambar dengan mudah lewat drag-and-drop di browser
- Jika memakai imgur, banyak cookie dan tracker terpasang di browser, dan orang yang melihat gambar yang dibagikan pun bisa dipaksa menerima tracker
- Alat berbagi gambar self-hosted yang ada juga banyak yang berbasis framework besar sehingga dianggap sulit dipercaya
- Trifecta dibuat kecil agar seluruh kodenya bisa ditinjau hanya dalam beberapa jam
- 1.600 baris source code baru
- Sekitar 5 dependensi penting
- Total ukuran kode 3MB
- Sebagai pembanding, solusi berbagi gambar lain yang disebutkan didistribusikan sebagai image Docker berukuran 288MB
- Solusi berbagi foto lain berbasis Node ternyata memiliki 1.600 dependensi dan lebih dari 4 juta baris JavaScript
- Trifecta bukan untuk situs publik tempat orang acak mengunggah gambar, melainkan cocok untuk perusahaan atau penggunaan pribadi
Masalah ketika kompleksitas disalahartikan sebagai kekuatan
- Salah satu reaksi umum terhadap Trifecta adalah menyarankan agar deployment dilakukan memakai paket Amazon Web Services
- Ini tidak sejalan dengan tujuan perangkat lunak mandiri yang tidak bergantung pada layanan eksternal
- Ada juga tanggapan bahwa Docker diperlakukan tidak adil, tetapi tetap diakui bahwa container dapat digunakan untuk tujuan yang baik
- Dalam makalahnya pada 1995, Niklaus Wirth menunjukkan kecenderungan orang untuk mengira kompleksitas sebagai kecanggihan
- Seperti kata Tony Hoare, ada dua cara dalam merancang perangkat lunak
- Membuat program begitu sederhana sehingga kesalahannya jelas tidak ada
- Membuatnya begitu rumit sehingga tampak tidak memiliki kesalahan yang jelas
- Wirth melihat tekanan waktu sebagai penyebab utama perangkat lunak membengkak
- Tekanan waktu menghambat perencanaan yang matang
- Itu mendorong orang untuk cepat menambah dan mengubah sesuatu alih-alih memperbaiki solusi yang sudah cukup baik
- Sedikit demi sedikit, itu merusak standar kualitas dan rasa tuntas para engineer
- Ledakan ukuran perangkat lunak bukanlah hukum alam, melainkan sesuatu yang harus dikurangi oleh software engineer
Mengurangi jumlah kode adalah langkah keamanan
- Saat ini dunia mendeploy terlalu banyak kode
- Sebagian besar adalah kode pihak ketiga
- Sebagian masuk tanpa sengaja
- Sebagian besar tidak diperiksa dengan memadai
- Akibatnya muncul permukaan serangan yang sangat besar, dengan sejumlah besar kode biasa-biasa saja terekspos di dalamnya
- Upaya meningkatkan kualitas kode tetap berlanjut, tetapi banyak eksploitasi berasal dari kegagalan logika, dan kemajuan untuk mendeteksinya relatif lebih sedikit
- Hanya dengan mengurangi jumlah kode yang diekspos ke dunia saja, perbaikan besar sudah mungkin dicapai
- Waktu peluncuran produk mungkin akan bertambah, tetapi legislasi yang akan datang dapat membuat vendor menangani keamanan dengan lebih serius
- Trifecta dan Oberon menunjukkan bahwa banyak fungsi tetap bisa diberikan dengan kode dan dependensi yang terbatas
1 komentar
Komentar Hacker News
Dalam 『A Deepness in the Sky』 karya Vernor Vinge, umat manusia menyebar di antara bintang-bintang hanya dengan teknologi sub-cahaya, dan kapal antarbintang digambarkan sebagai campuran teknologi tua dari berbagai sistem bintang dan peradaban
Sistem komputernya juga sudah berevolusi terlalu lama sehingga sebagian besar kodenya tidak lagi dipahami siapa pun; orang hanya memakainya lalu membangun lapisan baru di atasnya
Khususnya, ada satu tokoh yang merupakan insinyur sistem lama, termasuk salah satu manusia hidup tertua karena berulang kali menjalani keadaan hibernasi dan perjalanan dalam waktu lama. Di masa depan, ketika semua orang sudah membangun banyak lapisan di atas sistem itu, pengetahuannya tentang cara kerja dan kerentanan pada zamannya justru menjadi keunggulan besar
Menurut saya Vinge menangkap sesuatu dengan tepat
Yang pertama adalah misteri nyata yang harus dipecahkan oleh sains modern dan orang-orang yang sangat cerdas, sedangkan yang kedua lebih mendekati kurangnya minat
Jika Anda membayar cukup mahal, seorang insinyur yang kompeten akan membongkar mesin cuci itu dan menemukan cacat persisnya, tetapi tidak ada yang mau membayar biaya itu; orang akan membuangnya dan membeli yang baru
Pengetahuan perangkat lunak masa lalu jelas termasuk kategori kedua. Jika menggali bagian mana pun, pada akhirnya kita bisa memahaminya sepenuhnya, tetapi untuk sebagian besar kasus, jauh lebih murah dan praktis untuk mengabaikannya atau menambahkan lapisan lain di atasnya
Ceritanya tentang umat manusia di masa depan yang melupakan aritmetika dasar, lalu ketika seseorang menemukannya kembali, para penguasa mencoba memanfaatkannya untuk perang. Saya paham pesan yang ingin disampaikan, tetapi menurut saya latarnya terlalu tidak realistis dan konyol sehingga kehilangan kekuatannya
Untuk diskusi lebih lanjut, lihat http://lambda-the-ultimate.org/node/4424
Kita sudah mengalami masalah seperti ini. Paman saya yang berusia 60-an memelihara perangkat lunak pengangkutan truk lama yang ditulis dalam COBOL, dan pekerjaan untuk teknologi jadul seperti ini memang ada. Kalau berminat, bisa saya kenalkan
Masalah dasarnya sama seperti insiden left-pad. Kita menertawakan insinyur junior tanpa pengawasan yang memasang dependensi sembarangan, tetapi setelah puluhan tahun dan beberapa generasi pengembang, pada akhirnya sebagian besar perangkat lunak sampai taraf tertentu akan bergantung pada dependensi yang tidak diketahui
Bayangkan harus menerapkan pembaruan pada tahun 2100; pembaruan itu akan didorong melalui sistem manajemen dependensi npm pada masa itu. Pada saat yang sama, mungkin ada perangkat-perangkat dependen berskala tata surya yang membutuhkan pembaruan keamanan, triliunan perangkat, dan cache perantara yang tidak jelas apakah sudah mutakhir. Saya bahkan tidak bisa membayangkan seperti apa pohon dependensi semacam itu
Bekerja di lingkungan yang mengharuskan kita menggali kode framework untuk sampai ke inti masalah juga menyebalkan. Rasanya seperti membuang-buang waktu
Bloat terlihat di sebagian besar library npm. Para pembuatnya tidak tahu desain yang baik, dan mencoba membuat setiap library melakukan segalanya
Misalnya, sebuah library konversi encoding string memasukkan pemuatan file, penyimpanan, unduhan internet, sampai tool command-line ke dalam repositori yang sama. Library seharusnya hanya melakukan satu tugasnya sendiri, dan menyerahkan sisanya kepada pengguna
Sisi Rust juga tidak terlihat lebih baik. Kalau mencoba memperbaiki dokumentasi Rust, Anda akan melihat sekitar 1.000 crate terpasang
Masalahnya bukan pada bahasanya, melainkan bahwa siapa pun bisa mengunggah library, dan pada kenyataannya memang sembarang orang mengunggahnya. Orang-orang yang “hanya ingin menyelesaikan pekerjaan” memilih library dengan fitur paling banyak, dan karena tidak mau menulis kode yang sebenarnya cukup 3 baris di luar library, mereka menuntut lebih banyak fitur. Seperti, “Bisakah ditambahkan rendering PDF juga?”
Saya tidak tahu pasti solusinya, tetapi terpikir untuk membuat kelompok advokasi dan badge Low Dependency, agar para penulis library menginginkan badge itu, dan pengguna juga mencarinya saat memilih library
Sebaliknya, jika menginginkan library dengan sedikit dependensi, Anda akan mengambil beberapa library yang melakukan banyak hal
Dari sudut pandang saya, library yang agak tebal dengan sedikit dependensi, dibuat oleh penulis yang saya percayai, lebih baik. Lodash memang besar, tetapi versi modul ES6-nya mendukung tree shaking, dan pada dasarnya berperan sebagai standard library yang tidak dimiliki JavaScript. date-fns juga serupa untuk Date. Untuk menutup celah pada library inti JavaScript, saya hampir selalu memasukkan keduanya secara default di hampir semua proyek
Dulu saya pernah mengerjakan kontrak Ruby on Rails, dan masalah performanya begitu parah sampai kami mengembangkan dalam mode rilis. Server sampai tidak mampu mendeteksi perubahan file dan melakukan reload otomatis
Suatu hari saya muak dan mulai menyelidikinya, dan jumlah gem yang ditarik begitu banyak sampai saya bahkan tidak ingat berapa. Salah satunya benar-benar hanya gem untuk menghemat 3 baris kode
Setelah itu saya menjauh dari komunitas RoR. Baru-baru ini, setelah beberapa tahun, saya kembali mengambil kontrak RoR; meski tidak separah dulu, tetap saja belum bagus
Beberapa komunitas sama sekali tidak menghargai risiko yang dibawa dependensi
Di sisi lain, fakta bahwa repositori Git mana pun bisa meng-host library Go, dan siapa pun bisa menggunakannya dari URL itu, benar-benar praktis
Pertama, pembuat paket ingin menjadikannya karier, dan satu-satunya cara mendapat perhatian adalah membuat sangat banyak paket. Jadi mereka terus membuat paket yang bergantung pada paket lain buatan mereka sendiri, dan mencoba memasukkan satu atau dua paket berguna mereka ke dalam kode orang lain
Kedua, ada orang-orang yang percaya bahwa pemecahan masalah selalu melibatkan paket baru. Mereka tidak peduli berapa banyak dependensinya, atau apakah masalah sebenarnya memang sulit. Akibatnya, alih-alih belajar cara memecahkan masalah, mereka mempelajari API dari wrapper berbintang 4 di GitHub
Idealnya, tool seperti ini menghabiskan waktu membosankan untuk memangkas paket yang tidak perlu, meminimalkan tanggung jawab tiap paket, menata lingkungan secara masuk akal, lalu melakukan cache secara mandiri sehingga dependensi pada LLM dihilangkan. Bentuk yang bagus adalah hanya memanggil pemeriksa pembaruan atau kurator ketika masalah terjadi
Sejujurnya, ini salah satu masalah terburuk dalam software modern, dan menurut saya membuat lebih dari 50% proyek menjadi tidak layak dipakai. Karena ini masalah yang membosankan tetapi bisa diselesaikan, ia sangat cocok untuk agen LLM yang benar-benar baik, dan keberadaannya akan sangat membantu
“Pernahkah Anda melihat pesawat modern? Pernahkah Anda mengikuti bagaimana garis-garisnya berevolusi dari tahun ke tahun? Pernahkah Anda berpikir bahwa bukan hanya pesawat, melainkan semua hal yang dibuat manusia—upaya industrial manusia, perhitungan, malam-malam yang dihabiskan di atas gambar teknik—pada akhirnya bermuara pada satu prinsip yang unik dan dominan: kesederhanaan tertinggi?
Seolah-olah ada hukum alam yang memerintahkan bahwa untuk menyempurnakan lengkung furnitur, lunas kapal, atau badan pesawat hingga mendekati kemurnian purba seperti lengkung dada atau bahu manusia, diperlukan eksperimen dari banyak generasi perajin. Kesempurnaan tampaknya dicapai bukan ketika tidak ada lagi yang bisa ditambahkan, melainkan ketika tidak ada lagi yang bisa dihapus.”
— Antoine de Saint Exupéry, Terre des Hommes
Kalau ditulis seperti “membuka pintu garasi bisa memerlukan lebih dari 50 juta baris kode aktif dan image sistem operasi di beberapa server”, rasanya benar-benar gila
Memikirkan berapa banyak kode yang berjalan di mesin yang saya pakai untuk mengetik tulisan ini saja sudah membuat pusing. Kode-kode yang belum pernah saya tinjau, dan mungkin hampir tidak pernah mendapat tinjauan ketat
Yah, saya kembali memasang dependensi npm dulu
Analogi “perangkat lunak kini dianggap begitu berbahaya sampai orang disarankan untuk tidak menjalankannya sendiri. Sebagai gantinya, mereka diminta menyerahkannya kepada penyedia ‘X as a service’ atau sekadar ‘cloud’. Bandingkan dengan situasi hipotetis ketika mobil begitu sering terbakar sehingga orang disarankan untuk tidak mengemudi sendiri, melainkan menyerahkan kemudi kepada profesional yang selalu diikuti petugas pemadam kebakaran ahli” terasa sangat ingin saya kutip
Mantan pacar saya punya alasan rasional untuk tidak memercayai “cloud” karena tumbuh besar di bekas Blok Timur. Namun alternatifnya hanyalah berharap laptop HP termurah yang ia beli tidak hilang. Setelah sedikit edukasi, setidaknya ia bisa lebih tenang untuk bagian itu
Masalahnya adalah kurangnya edukasi secara umum dan kurangnya pertimbangan atas konsekuensinya. Pada akhirnya orang harus menerima risikonya, belajar sendiri, atau bergantung pada SaaS dan penyedia cloud. Saya sudah melihat banyak air mata, dan sangat jarang melihat orang benar-benar belajar sendiri
Ini soal tanggung jawab pribadi, tetapi karena tidak ada yang mau memikul tanggung jawab itu, menyerahkannya kepada ahli bisa menjadi solusi yang tidak seburuk memercayai diri sendiri. Jawaban yang benar adalah edukasi, tetapi itu luar biasa sulit
Perangkat lunak tidak bisa menjadi lebih ramping. Untuk itu dibutuhkan waktu, keahlian, dan tenaga mahal; tidak cukup hanya orang yang menyambung contoh dari 12 stack teknologi berbeda untuk membuat Franken-suit
Saya developer independen, dan orang yang tahun lalu baru belajar node.js lalu dalam sehari merakit node.js, container, layanan DB hosting AWS apa saja, Lambda, object storage, Cloudflare, YAML, React, Vite, dan dependensi lain menjadi webapp yang generik tetapi tetap rapuh, selalu memasang harga lebih rendah daripada saya
Perangkat lunak yang ramping, cepat, murah dijalankan, dan juga lebih murah dirawat memang lebih murah dalam jangka panjang, tetapi sulit ditulis secara menguntungkan
Dulu ada mimpi bahwa sistem menyediakan hook dan routine standar yang dipakai semua orang untuk antarmuka dan sebagainya. Bayangkan hal-hal seperti Macintosh Toolbox atau QuickDraw
Konon tugas utama developer adalah menulis logika program, sementara perubahan atau penambahan seharusnya transparan. System call akan menjalankan pekerjaan yang sama dengan mulus meski kode internal berubah, dan fitur baru akan menjadi superset dari fitur lama sehingga kode lama tetap bisa dikompilasi atau dijalankan tanpa masalah, sementara software baru memperoleh kemampuan lebih besar
Dengan cara ini, pemeliharaan akan lebih mudah, antarmuka menjadi ternormalisasi, dan karena banyak bergantung pada system call, kode juga akan menjadi ramping. Saat itu ada suasana bahwa library eksternal sebaiknya dihindari
Mimpi ini cepat runtuh; pikirkan saja DLL. Banyak package management dan packaging saat ini tampaknya lebih mirip pekerjaan memastikan library yang benar tersedia
Pada masa itu, pengembangan software skala besar masih nyaris dalam masa bayi, jadi bisa dimengerti kalau hasilnya tidak sesuai harapan. Sekarang pengalaman kolektif tentang masalah seperti ini sudah banyak terkumpul, dan saya penasaran apakah kesimpulannya adalah mimpi ini secara waras memang mustahil diwujudkan, atau justru setelah cukup lama mengalami kondisi berantakan saat ini, kita mulai mengarah ke percobaan ulang yang lebih modern
Jika kita menginginkan software yang cepat, ramping, stabil, dan aman, meski sulit mendapatkan keempatnya sekaligus, saya tidak yakin keadaan sekarang sedang bergerak ke arah itu
Lisp awal memasukkan sangat sedikit hal ke dalam bahasa, tetapi Raku mendorong sampai hal-hal kecil yang biasanya cocok menjadi library npm ke dalam spesifikasi bahasa
C membiarkan Anda menentukan sendiri cara membangun kode, tetapi kebanyakan bahasa terkompilasi baru menyertakan semacam build tool
Ada hal-hal yang cukup efektif di lanskap ini, tetapi itu terjadi di luar konteks “kamu, mesin, proyek baru” yang memandu karya Wirth. Masalahnya, hal ini cenderung datang bersama ambang dependensi raksasa seperti database atau browser engine, dan jika Anda tidak menyukai cara dependensi itu dibuat, pada akhirnya Anda akan tidak bahagia
Inilah yang terus saya katakan tentang Rust
Jika 70% kerentanan C++ lama benar-benar terkait memori, maka per baris kode, jumlah kerentanannya bisa 70% lebih sedikit daripada C++
Tetapi jika di Rust Anda menarik ratusan package dan jumlah baris kode menjadi 10 kali lipat, ceritanya lain
30% dari 100 ribu baris lebih besar secara total daripada 100% dari 10 ribu baris
Sesuatu seperti QT pun, kalau ditulis dengan Rust, kemungkinan akan menjadi ratusan crate tersendiri, tetapi jumlah kode dan tingkat risiko yang ditanggung akan persis sama
Namun masalah besarnya adalah kerentanan. Mana yang lebih baik: memperbaiki bug di satu shared library sehingga ratusan library ikut beres, atau memperbaiki ratusan library satu per satu?
Fakta bahwa Rust memudahkan menarik banyak dependensi kecil alih-alih beberapa dependensi raksasa tidak relevan. Itu bukan berarti menulis lebih banyak kode
Misalnya, apakah crate
regexdi Rust dihitung sebagai dependensi? Di C++, itu ada di standard libraryApakah Boost dihitung sebagai satu dependensi di C++? Jika di Rust, itu kira-kira akan setara dengan sekitar 30 crate terpisah
Seberapa banyak eksekusi kode jarak jauh yang ada pada program Rust dibandingkan C++? Saya rasa frekuensi eksekusi kode jarak jauh di C++ jauh lebih dari 70% lebih tinggi daripada di Rust
Belakangan ini aplikasi biasanya dibuat dengan Electron JS, tetapi sepertinya belum banyak yang tahu bahwa kita juga bisa memakai kontrol web native tiap platform tanpa membundel Electron
Dengan begitu, aplikasi yang didistribusikan bisa berukuran dalam satuan kilobyte. Pendekatan ini memberi kebebasan untuk memakai bahasa backend atau stack teknologi apa pun selama bisa berkomunikasi dengan web view
Bukankah sekarang PWA seharusnya sudah bisa dipakai untuk persentase aplikasi yang cukup besar?
Saya tidak begitu tahu, tetapi bukankah Discord juga bisa menjadi PWA alih-alih aplikasi Electron?
Celah terbesarnya mungkin perbedaan antara sesuatu yang kuat yang setara dengan SQLite dan IndexedDB, tetapi tetap saja sebagian besar aplikasi tampaknya tidak benar-benar membutuhkan bahasa kueri yang tingkatnya lebih tinggi daripada model B-tree IndexedDB
Sekali lagi bersorak untuk filosofi suckless. Hidup
[0 ]https://suckless.org/