curl yang berjalan di 100 sistem operasi

• curl membatasi perubahan agar tetap bisa dibangun dan diuji bahkan di lingkungan lama, dan dalam pull request terbaru pun mensyaratkan bahwa perubahan tidak boleh merusak kompatibilitas dengan time_t 32-bit dan platform lawas
• Intinya bukan mempertahankan daftar platform sebanyak mungkin, melainkan menepati janji stabilitas ABI/API agar semuanya tetap berfungsi meski pengguna melakukan upgrade
• Yang lebih penting daripada jumlah pengguna sistem operasi tertentu adalah apakah ada orang yang benar-benar merawat dan memperbaikinya; selama masih ada maintainer, platform dengan sedikit pengguna pun bisa terus didukung
• curl dan libcurl meluas dengan prinsip yang berfokus pada portabilitas untuk tetap “bisa dibangun dan dijalankan” di berbagai sistem operasi, arsitektur CPU, dan konfigurasi yang tidak biasa
• Alasan utama perintah curl lama gagal biasanya bukan karena perubahan di curl, melainkan lebih karena perubahan lingkungan internet seperti host dan URL yang sudah hilang serta peralihan dari HTTP ke HTTPS

---

Kriteria perubahan yang tidak merusak platform lawas

• Dalam pull request curl terbaru, perubahan hanya bisa digabungkan ke repositori kode git jika tidak merusak build atau pengujian di platform lawas
• Perubahan tersebut terkait area time_t, dan karena curl sudah mendukung tipe time_t 32-bit, perilaku itu harus tetap dipertahankan
• time_t 32-bit memang sudah semakin terbatas penggunaannya dan keterbatasannya bisa makin besar saat mendekati 2038, tetapi banyak platform lawas masih tetap berada di versi 32-bit
• Persyaratan seperti ini memang membuat pekerjaan kontributor lebih sulit, tetapi di curl hal itu dianggap bagian dari proses menyempurnakan perubahan

Kompatibilitas adalah janji yang lebih besar daripada jumlah platform

• Proyek curl terus berupaya menjaga stabilitas dan kompatibilitas ABI serta API
• Aplikasi yang menggunakan libcurl dari pertengahan 2000-an masih dapat bekerja dengan cara yang sama meski di-upgrade ke libcurl terbaru tanpa perlu mengompilasi ulang aplikasinya
• Skrip curl yang ditulis pada awal 2000-an juga masih bisa diharapkan bekerja hampir dengan cara yang sama di rilis curl terbaru
• Kompatibilitas ini bukan sekadar slogan pemasaran, melainkan prinsip inti yang diberikan curl dan libcurl
  • Pengguna bisa mengandalkan curl
  • Bahkan jika ada rilis yang mengandung bug, mereka berusaha menyediakan pembaruan yang memungkinkan pengguna pindah ke versi baru tanpa penderitaan upgrade perangkat lunak yang biasa terjadi
• Sikap untuk tidak merusak sesuatu yang sudah bekerja dengan baik termasuk dalam standar pemeliharaan mereka

Penentu dukungan adalah maintainer

• Jumlah pengguna platform tertentu bukan motivasi utama dalam menentukan apakah curl akan terus mendukung platform tersebut
• Kriteria yang lebih penting adalah siapa yang bersedia mengerjakannya dan apakah pemeliharaan yang dibutuhkan benar-benar dilakukan
• Jika ada kontributor yang memastikan curl tetap berjalan di suatu platform, maka curl bisa terus berjalan bahkan di platform yang diketahui memiliki sedikit pengguna
• Saat sebuah platform benar-benar menghilang dari curl adalah ketika kode yang diperlukan untuk platform itu tidak lagi dipelihara
  • Kode yang tidak dipelihara pun bisa tetap dalam kondisi bekerja selama bertahun-tahun
  • Bahkan bisa butuh waktu lama sampai diketahui bahwa curl tidak lagi bekerja di platform tertentu
• Sebaliknya, bahkan platform dengan banyak pengguna pun sulit dipertahankan jika tidak ada maintainer yang punya kemauan dan pengetahuan untuk menangani masalah khas platform tersebut

Alasan menyebar ke berbagai lingkungan

• curl dan libcurl sangat fokus untuk bisa dibangun dan dijalankan di sebanyak mungkin lingkungan
• Sikap untuk tetap bekerja bahkan di konfigurasi yang unik atau aneh menjadi salah satu alasan mengapa ia tersebar ke banyak sistem operasi dan arsitektur CPU
• Banyak pengguna dan perusahaan masih terus memakai platform yang lama, niche, atau lawas
• Bagi mereka, mempertahankan kemampuan transfer curl sering kali lebih baik dari sisi keamanan daripada membuat implementasi pengganti sendiri
• Jika tidak ada kebutuhan untuk merusak fitur, maka membiarkan pengguna lama tetap mengandalkan curl dianggap pilihan yang lebih baik

Penghapusan dukungan berlangsung lambat dan terbuka

• curl juga kadang-kadang menghapus sebagian dukungan
• Target penghapusan utama adalah dukungan untuk library pihak ketiga yang penggunaannya menurun dan perlahan menghilang, tetapi penghapusan dukungan juga bisa terjadi di area lain
• Penghentian dukungan dilakukan secara lambat, hati-hati, dan dikomunikasikan secara terbuka
  • Pengguna yang ingin tahu harus bisa mengetahui perubahan itu lebih dulu
  • Pengguna harus bisa bersiap, atau menentangnya jika usulan tersebut terasa tidak adil
• Jika pengguna tidak bisa merasakan perubahan perilaku, maka itu tidak dianggap sebagai perubahan
• curl dibuat untuk pengguna, dan jika pengguna masih menginginkan suatu perilaku tetap ada, maka perilaku itu seharusnya dipertahankan

Alasan sebenarnya perintah lama gagal

• Protokol internet dan versinya muncul dan menghilang seiring waktu
• Sebagian besar baris perintah curl yang ditulis pada 2002 mungkin tidak lagi bekerja apa adanya saat ini
• Penyebab kegagalannya mungkin bukan curl itu sendiri, melainkan karena nama host dan URL yang digunakan saat itu sudah tidak lagi berfungsi
• Salah satu alasan besar mengapa perintah curl dari 2002 tidak lagi bekerja apa adanya saat ini adalah peralihan dari HTTP ke HTTPS
• Bahkan jika pada 2002 sudah ada situs yang memakai TLS atau SSL, hal itu belum umum saat itu, dan versi protokol TLS yang digunakan kala itu bisa dianggap tidak aman pada masa kini
• Library TLS modern dan curl dapat menolak koneksi ke konfigurasi TLS lama yang tidak diperbarui
• Bahkan jika biner curl dari 2002 masih disimpan lalu dijalankan hari ini, itu mungkin tidak akan bisa terhubung ke situs HTTPS modern
  • Hal itu bukan karena perubahan di curl, melainkan karena perubahan di lapisan protokol transport

[GN⁺]

Komentar Hacker News

• Pencapaian yang luar biasa. Curl benar-benar alat yang seperti berkah.
  Menarik bahwa Daniel menekankan time_t 32-bit sebagai titik penting kompatibilitas. Kalau tujuannya adalah tetap berjalan di berbagai sistem operasi, itu sepenuhnya masuk akal. Hanya saja 2038 sekarang tinggal 14 tahun lagi, dan jauh lebih dekat ke masa kini dibandingkan saat curl pertama kali dirilis. Saya penasaran kapan upaya mendukung waktu 32-bit akan dianggap tidak lagi sepadan. Dugaan saya, sekitar 3 bulan setelah tanggal Y2K38 lewat, mungkin bahkan lebih lama.

• Ada hal yang dipelajari para developer ketika mereka makin dekat dengan tim operasi. Semakin banyak pihak yang bergantung, semakin besar bebannya. Infrastruktur dan sistem pusat kehilangan kelincahan ketika sudah cukup banyak hal bergantung padanya, dan perubahan kecil pun menjadi sangat sulit.
  Kalau di layanan sendiri yang punya backend dan frontend Anda ingin merombak API di antara keduanya, siapa yang peduli. Lakukan saja.
  Tapi kalau Anda ingin menghilangkan edge case aneh di template dasar karena “jelek”, Anda harus melihat 20 layanan lama, 20 layanan setengah modern yang tidak ingin disentuh orang, lalu 50 layanan lain yang memakainya. Itu baru pekerjaan yang dibutuhkan untuk memahami sebesar apa perubahan tersebut. Pada tahap ini bahkan belum bicara soal menjalankan perubahan sebenarnya atau melakukan reverse engineering terhadap rahasia yang rumit.
  Saya tidak akan menyebutnya pekerjaan glamor, tetapi terus menopang sang bintang utama yang bersinar sambil mengubah semuanya di bawah tanpa ada yang menyadari memberi kebanggaan tersendiri bagi roadie atau pengelola.

• Di daftar itu ada cukup banyak yang sudah lebih dari 25 tahun tidak punya rilis. Apakah build saat ini masih dibuat untuk SCO, Xenix, OS/2, NextStep?
  Saya pernah menjalankan beberapa di antaranya, dan tahu bahwa curl ada di sana, tetapi menurut pengalaman saya curl itu selalu versi yang setidaknya sudah berumur 15 tahun.
  Kalau Anda bilang tidak ingin merusak suatu matriks dukungan, sementara sebagian besar matriks itu sudah lewat jauh lebih dari 10 tahun sejak build terakhir, bagaimana Anda tahu bahwa itu benar-benar tidak rusak?

  • Menurut saya 25 tahun pun sudah sangat murah hati.
    Saya tidak yakin bisa di-build untuk Xenix. GCC terbaru yang bisa dijadikan target adalah 2.7, dan itu pun sudah versi purba. Apalagi kalau mempertimbangkan kode jaringan. Mungkin maksudnya lebih ke “pada suatu waktu pernah berjalan di sistem-sistem itu”.
  • Dibandingkan itu, AmigaOS masih sangat bugar. Rilis terbarunya keluar pada 2021.
  • Kalau Xenix atau OS/2 tidak berubah, kenapa build Curl lama tiba-tiba rusak di sana?
  • SkyOS juga contoh yang bagus. Pada titik ini, tampaknya lebih aman menghapusnya daripada berasumsi ada orang yang benar-benar menjalankannya di SkyOS.

• Terkait pernyataan “banyak sekali pengguna dan perusahaan tetap bersikeras memakai platform lama, niche, dan legacy, dan tidak ada yang bisa kita lakukan”, kebanyakan orang, termasuk developer proprietary closed source sekalipun, membuat perangkat lunak yang di bagian awal lisensinya memuat kalimat seperti “program ini didistribusikan dengan harapan akan berguna, tetapi tanpa jaminan apa pun, termasuk jaminan tersirat atas kelayakan jual atau kesesuaian untuk tujuan tertentu”.
  Itu biayanya rendah.
  Sebaliknya, sebagian orang termasuk saya mengembangkan perangkat lunak yang dijamin sesuai tujuan, dengan jaminan yang eksplisit dan absolut.
  Itu sangat mahal dan lambat.
  Jika sesuatu yang rusak bisa membuat orang meninggal, merusak lingkungan, atau menyebabkan kerugian jutaan dolar, masuk akal untuk terus memakai platform lama dan niche yang telah diperiksa menyeluruh oleh developer yang sangat lambat dan hati-hati selama 30–40 tahun.
  Setidaknya itulah yang saya katakan pada diri sendiri ketika menatap Ada di INTEGRITY di atas PowerPC.

  • Dalam satu kalimat itu Anda bertentangan dengan diri sendiri.
    Kalau satu orang meninggal bisa berujung pada kerugian jutaan dolar, sebaiknya jangan memakai perangkat lunak atau platform yang kumpulan developernya sekecil “jumlah pemain juggling Prancis yang mengidap penyakit Wilson”.

• Salah satu alasan popularitas ini mungkin adalah lisensi permisif. Saya kira lisensinya MIT, tetapi sepertinya agak berbeda [1]. Ada yang bisa menjelaskan dengan bahasa sederhana apa perbedaan utamanya dengan MIT? Halaman hak cipta tidak menjelaskan secara rinci.
  [1] https://curl.se/docs/copyright.html

  • Dibandingkan lisensi MIT, klausul tambahan utamanya tampaknya bagian ini:
    “Kecuali sebagaimana tercantum dalam pemberitahuan ini, nama pemegang hak cipta tidak boleh digunakan untuk mengiklankan atau mempromosikan penjualan, penggunaan, atau transaksi lain atas perangkat lunak ini tanpa izin tertulis sebelumnya dari pemegang hak cipta.”
  • Seperti tertulis di halaman itu, tampaknya ini lisensi khusus yang terinspirasi dari lisensi MIT/X11. Perbedaannya dengan MIT/X11 tampaknya hanya bagian awal penyangkalan garansi yang dipersingkat. Ada entri terpisah di SPDX [1].
    [1] https://spdx.org/licenses/curl.html
  • Sepertinya lisensi MIT dicampur dengan klausul ketiga dari lisensi BSD 3-Clause.

• Saya kira hampir 100 itu hanya versi Linux saja, jadi mengejutkan bahwa meskipun semua versi Linux dihitung sebagai satu sistem operasi, tetap ada 100.

  • Memang, tetapi mereka menghitung iOS, iPadOS, dan watchOS sebagai sistem operasi terpisah, jadi sebenarnya sekitar 98 sistem operasi. Segitu sih… siapa pun bisa melakukannya…

• Menulis kode dengan mempertimbangkan berbagai sistem legacy menurut pengalaman pribadi umumnya membuat kode menjadi lebih baik.
  Anda jadi lebih mengikuti praktik coding yang sudah dikenal seperti penamaan, tipe, dan modularisasi, dan kepatuhan terhadap standar juga menjadi lebih baik kecuali di bagian yang ditandai jelas. Abstraksi menjadi lebih kuat, bug berkurang terutama di platform modern, dan sistem build juga lebih kokoh. Kode menjadi otomatis kompatibel dengan platform masa depan, atau setidaknya sangat mudah dibuat kompatibel.
  Namun jika hanya menargetkan beberapa sistem legacy, hal ini mungkin tidak berlaku karena Anda bisa bertahan dengan kombinasi tambalan dan hack yang khas.

• Aneh rasanya mencantumkan FreeDOS, DR-DOS, dan MS-DOS sebagai sistem operasi yang terpisah. Mereka sangat mirip satu sama lain, dan tidak seperti berbagai keluarga Unix yang berbeda, pada dasarnya kompatibel ABI.

  • Hampir begitu. Seperti kita semua tahu, DR-DOS, MS-DOS, dan PC-DOS sekitar 99% kompatibel, dan masalah muncul ketika Anda sial menginjak 1% itu. DR-DOS melakukan reverse engineering terhadap MS-DOS, dan bahkan lisensi PC-DOS milik IBM tidak memberi akses ke semua hal yang dilakukan Microsoft di MS-DOS.
  • DR-DOS jelas sistem operasi terpisah karena merupakan keturunan langsung CP/M dengan kompatibilitas ABI MS/PC-DOS. FreeDOS juga begitu. Jika melihat bagian internalnya, masing-masing punya cukup banyak perbedaan.
  • OPENSTEP dan NeXTSTEP juga dicantumkan sebagai sistem operasi terpisah…

• Meski begitu, orang-orang ingin menulis ulang ini dengan Rust. Apakah Rust benar-benar bisa menargetkan semua arsitektur dan sistem operasi itu?

  • Mengapa ada orang yang ingin menulis ulang curl? Apa masalahnya memakai C?

• Bacaan terkait: tulisan tentang bagaimana curl lahir dan sejarah yang dilaluinya (1)
  (1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...