Pengetahuan yang Terkutuk

 (immich.app)
4 poin oleh GN⁺ 2025-08-08 | 1 komentar | Bagikan ke WhatsApp
  • Berbagi daftar Pengetahuan yang Terkutuk yang didapat saat proses pengembangan Immich
  • Merangkum masalah tak terduga yang ditemukan di berbagai perangkat lunak dan lingkungan infrastruktur
  • Menyebutkan metadata EXIF, penanganan spasi YAML, PostgreSQL, dan masalah pada alat serta bahasa pemrograman
  • Beberapa masalah ini berhubungan langsung dengan keamanan, kompatibilitas platform, dan ketergantungan open-source
  • Fokus pada contoh nyata dan penyebabnya yang perlu diperhatikan oleh para pengembang

Ikhtisar

Tim pengembang Immich mengungkap Pengetahuan yang Terkutuk yang tidak ingin lagi mereka temui saat mengerjakan proyek ini. Ini adalah daftar jebakan dan masalah tak terduga yang mereka alami secara langsung di berbagai alat, bahasa, dan platform selama pengembangan serta operasional layanan nyata.

Daftar Pengetahuan yang Terkutuk

  • 4 Juni 2025

    • Actions di Zitadel adalah fitur yang terkutuk
    • Fitur custom scripting yang disediakan Zitadel berbasis mesin JS ternyata memiliki batasan karena tidak mendukung nama grup penangkapan (named capture group) pada regex

  • 30 Mei 2025

    • Microsoft Entra mendukung PKCE, tetapi tidak mendefinisikannya dalam dokumen penemuan OpenID
    • Akibatnya, fitur ini tidak terdeteksi dari sisi klien

  • 5 Mei 2025

    • Informasi ukuran pada metadata EXIF gambar dapat berbeda dari gambar aslinya
    • Perbedaan ini menyebabkan error pada operasi crop dan resize

  • 1 April 2025

    • Penanganan whitespace YAML sering kali berperilaku tidak seperti yang diharapkan
    • Karena sensitif terhadap format, ada risiko konten ditafsirkan berbeda dari yang dimaksud

  • 20 September 2024

    • File tersembunyi Windows tidak bisa dibuka dengan flag w
    • Jika digabung dengan opsi hide dot files pada SMB, kebingungan pada pencarian dan pemrosesan file meningkat

  • 7 Agustus 2024

    • Dalam skrip Bash dapat terjadi masalah carriage return (CRLF)
    • Jika Git melakukan konversi otomatis LF ke CRLF saat checkout, hal ini dapat menyebabkan error saat mengeksekusi skrip

  • 7 Agustus 2024

    • Pada Cloudflare Workers, fetch tetap menerapkan http secara default meski https disebutkan
    • Ini memicu masalah jaringan seperti loop redirect

  • 21 Juli 2024

    • Berbagi lokasi GPS di perangkat seluler menghapus metadata GPS dari gambar secara diam-diam jika aplikasi tidak memiliki izin lokasi
    • Berpengaruh pada akurasi layanan berbasis lokasi dan privasi

  • 3 Juli 2024

    • NOTIFY PostgreSQL hanya bekerja di dalam transaksi
    • Saat dipadukan dengan postgres-adapter milik socket.io, terjadi pencatatan WAL setiap 5 detik yang memicu beban tinggi

  • 3 Juli 2024

    • Setiap menjalankan npm script akan mengirim permintaan HTTP ke registry npm
    • Karena itu, menggunakan script untuk health check tidak efisien

  • 28 Juni 2024

    • Beberapa orang dalam komunitas JavaScript memaksa penambahan lebih dari 50 dependensi paket dengan alasan backward compatibility
    • Semua paket itu dikelola oleh pengguna yang sama

  • 25 Juni 2024

    • Implementasi bcrypt hanya menggunakan 72 byte pertama dari string
    • Karakter setelahnya diabaikan, sehingga password panjang menjadi tidak berguna

  • 31 Januari 2024

    • Objek Date JavaScript mengindeks tahun dan tanggal dari 1, tetapi bulan dari 0
    • Struktur ini mudah membingungkan

  • 9 Januari 2024

    • Sebelum Node.js v20.8, pada proyek CommonJS yang menggunakan opsi --experimental-vm-modules, saat modul ES memuat kembali modul CommonJS
      • Terjadi segfault yang membuat Node.js crash

  • 28 Desember 2023

    • Batas parameter PostgreSQL adalah 65.535
    • Menyebabkan batas performa pada bulk insert untuk kumpulan data berukuran besar

  • 26 Juni 2023

    • Ada API web yang hanya bisa dipakai di Secure Contexts
    • Contohnya, API clipboard hanya berfungsi pada lingkungan https atau localhost

  • 23 Februari 2023

    • Implementasi remove di TypeORM memengaruhi data input langsung
    • Bahkan dapat menghapus properti id dari objek asli

Kesimpulan

Pengetahuan yang terkutuk ini adalah jebakan yang kerap ditemui dalam pengembangan dan operasional layanan nyata. Bagi pengembang, mengenali batasan tersembunyi pada setiap alat, bahasa pemrograman, dan lingkungan secara dini membantu mencapai pemecahan masalah yang efisien dan pengembangan layanan yang lebih stabil.

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-08
Komentar Hacker News

  • Saya sudah sangat suka ini sejak pertama kali melihatnya. Setelah melihat commit contoh (di sini), saya makin suka. Yang paling saya suka adalah adanya pencatatan “pengetahuan terkutuk” bersama dengan kode yang memecahkan masalahnya. Kesan pertama saya adalah fitur ini dibutuhkan di setiap proyek. Lognya bukan sekadar katarsis; ia mengubah berbagai masalah menjengkelkan menjadi pengalaman belajar yang positif. Jika dibuka ke publik, kita bisa berempati dengan orang yang mengalami masalah yang sama, dan juga bisa jadi alat untuk mencegah kejadian serupa di masa depan.

    • Biasanya saya menuliskan informasi semacam ini langsung di pesan commit. Saat seseorang melihat satu baris kode dan berpikir, “Kenapa ini dibuat seenaknya? Bukannya cukup ___ begini saja?”, penjelasan langsung ini sangat berguna.

  • Bagian ‘tidak bisa mengikat 65 ribu placeholder PostgreSQL dalam satu query’ membuat saya terkejut. Pada dasarnya ini bukan ide yang terlalu bagus, jadi sulit menyalahkan PostgreSQL. Saat membaca komentar issue GitHub, tampaknya pendekatan yang masuk akal adalah merefaktor ORM agar memecah query besar menjadi beberapa query kecil. Secara pribadi, saya merasa sekitar 3.000–5.000 baris per query terasa pas. Ada yang menyarankan strategi lain: memuat data lebih dulu ke tabel TEMP lalu join nanti—terutama COPY … FROM—yang katanya lebih baik untuk performa. Tapi itu membutuhkan perubahan kode yang terlalu besar dan akhirnya strategi itu pun ditinggalkan. Secara umum ini adalah kumpulan kisah pengalaman yang sangat berguna; sangat berguna sebagai contoh peringatan.

    • Saya merasa “mencoba itu sendiri adalah ide terkutuk.” Saat membaca seluruh daftar, saya mendapat kesan bahwa “daftar kutukan” bukan sekadar jebakan desain atau deadlock, melainkan pelajaran yang dipelajari langsung saat para pengembang benar-benar bertumbuk. Memang tiap informasi punya tingkat kematangan yang berbeda dan beberapa memang masih berjalan, tetapi nilainya lebih terasa bila dipahami sebagai log pengalaman pribadi dalam engineering.

    • Mirip dengan berusaha memproses semua nama file dalam file system sekaligus memakai alat seperti xargs tanpa karakter NUL. Jika ada nama file yang aneh/rusak, atau memori tidak cukup, memang bermasalah. Lebih baik gunakan alat seperti find -print0 dan parallel -0/xargs -0. Dan hati-hati juga: sed, grep, dll bisa memicu error sekuens karakter multibyte jika dipakai tanpa LC_ALL=C.

    • Saya pernah mengalami langsung saat upsert massal rekaman lewat ORM sampai kena error 65 ribu binding. Saat ada kolom tipe array SQL di tabel, tiap item yang disisipkan perlu dibinding, sehingga jumlah variabel binding berfluktuasi. Jadi meski dua kali jalan menunjukkan jumlah baris/kolom yang sama, jumlah variabel yang perlu dibinding bisa berubah dan jadi kondisi yang tidak stabil.

    • Strategi lain bisa dengan mengirim nilai sebagai argumen array (text[] atau int[]). PostgreSQL juga menangani ini dengan baik. Memang ANY() sedikit lebih lambat daripada IN(), tetapi bisa menyimpan banyak ID dalam satu parameter. Mungkin ORM-nya tidak mendukung.

    • Saya juga menangkap poin ini. Membuat sebanyak itu binding jelas cara yang terkutuk. Kalau pemrosesan massal, sebagian besar sebaiknya pakai COPY. Satu contoh Postgres “terkutuk” lain: nama prepared statement diam-diam dipotong sampai NAMEDATALEN-1 (di mana NAMEDATALEN adalah 64). Ini sudah begini sejak 2001, dan sebenarnya sudah ada sebelumnya juga. ORM harus menyadari hal ini. Kasus orang menggunakan nama prepare lebih dari 60 karakter itu jarang, tapi ORM itu pengecualian.

  • Entri ‘menambahkan 50 paket tambahan’ benar-benar mengguncang. Penulis paket itu pasti menaikkan jumlah download secara drastis. Jika melihat bandwidth dan ruang disk yang terbuang secara global, ini benar-benar sayang. Jadi saya bertanya-tanya apakah ini sekadar untuk membangun reputasi.

    • Maintainer paket yang ditunjuk dalam “pengetahuan terkutuk” ini adalah anggota TC39. Dia adalah tokoh yang sering memicu kontroversi di beberapa proyek JavaScript besar. Ada juga dugaan soal motif finansial terkait isu polyfill tertentu, tetapi karena pendapatan GitHub Sponsor atau Tidelift tidak besar, saya berpikir mungkin dia memang menjunjung tinggi prinsip kompatibilitas. Menjelang Mei 2025, pandangan saya tentang ini agak berubah. Ia melakukan maintenance penting secara konsisten, dan saya juga melihat peran untuk terus menyuarakan opini yang salah di komunitas mungkin justru dibutuhkan.

    • Bisa jadi ini karena reputasi atau kepribadian yang unik, tetapi ada tafsiran ekstrem bahwa ini juga merupakan semacam persiapan awal untuk serangan rantai pasok perangkat lunak berskala besar.

    • Penulisnya hampir pasti ljharb.

  • NTFS Alternate Data Streams (ADS) di Windows memungkinkan menyembunyikan file tak terbatas di dalam file yang sudah ada. macOS secara bawaan juga menghasilkan banyak file tersembunyi dan sementara berupa data fork, xattr, dan pengindeksan Spotlight (md) pada semua volume yang bisa dilepas. Solusinya: mdutil -X /Volumes/path/to/vol Dan opt-out telemetry terlalu banyak (go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter, dan banyak lagi menimbulkan kekhawatiran privasi).

    • Opt-out telemetry: pada go, data telemetry pada dasarnya hanya disimpan lokal. Saat pengguna mengizinkan, hanya sebagian data yang disetujui yang bisa diunggah ke telemetry.go.dev. Pengaturan unggahan dapat diaktifkan dengan “go telemetry on”, dan dimatikan sepenuhnya dengan “go telemetry off” (lihat dokumentasi).

    • Yang benar-benar bermanfaat hanyalah opt-out telemetry.

  • Untuk laporan bahwa “npm registry dipanggil via HTTP setiap kali npm script dijalankan”, saya penasaran apakah itu benar. Kalau benar, itu perilaku yang sama sekali tidak masuk akal untuk sebuah package manager.

    • Mungkin ini adalah proses pengecekan update npm. Biasanya kalau versinya lama muncul notifikasi untuk update.

    • Sepertinya memang karena pengecekan update. Kadang-kadang banner update muncul.

  • Sepertinya ada satu poin yang terlewat. Pembahasan waktu/tanggal EXIF ini sebenarnya sudah jadi debat lama. Isu referensi 1, Isu referensi 2, Isu referensi 3

    • Tanggal/waktu sendiri gampang jadi hal yang “terkutuk”. Meski tampaknya berjalan normal, fitur terkait selalu punya potensi bermasalah kapan pun. Lebih rentan lagi jika nilainya menyertakan timezone atau daylight saving.

  • Saya teringat dokumen “Madness beyond the gates” mengenai Hadoop dan Kerberos (tautan). Artikel ini berkali-kali menyelamatkan saya dari titik hampir menyerah. Terima kasih banyak untuk penulisnya, Steve. Sulit membayangkan seberapa repot proses mendapatkan “pengetahuan terkutuk” ini.

  • Konsep mengumpulkan “pengetahuan terkutuk” dalam satu tempat sangat bagus. Saya memang sepakat bahwa ini adalah kegagalan yang hanya bisa dialami saat benar-benar tenggelam di sebuah proyek. Ke depan, saya akan membuat daftar seperti ini di setiap proyek.

  • Item ini bukan kutukan, tetapi isu keamanan/privasi terkait manajemen izin pada OS seluler.

  • Ide yang bagus! Saya penasaran apakah orang lain juga ingin berbagi pengetahuan terkutuk mereka. Dari pengalaman saya, nama file MacOS juga bisa jadi kutukan:

  1. Secara default, MacOS tidak membedakan huruf besar-kecil dalam nama file (file.txt dan FILE.txt dianggap sama)
  2. Jika nama file disimpan di MacOS dalam bentuk NFC, kadang-kadang dapat berubah menjadi NFD

  • Tahun 1995 saat membuat beta Windows 95, saya pertama kali membuat CDDB. Saya merilis nama-nama track CD ke file .ini, lalu proyeknya dihentikan karena batasan ukuran .ini 64KB.

  • Benar. Begitu membuat volume sistem atau data case-sensitive APFS atau HFS+, masalah pasti muncul.

  • Poin “1” tadi memang hanya pengaturan bawaan. HFS dan APFS sama-sama punya opsi case-sensitive. NTFS juga berperilaku serupa. Karena sistem file ini case-retentive, kita bisa menulis begini

 $ echo yup > README.txt
 $ cat ReAdMe.TXT
 yup
 $ ls
 README.txt

Masalah utamanya adalah Steam menolak proses instalasi pada file system yang case-sensitive (meski ada versi Linux juga).