Tolong jangan merusak perangkat lunak ini dengan vibe

• Isu ini berakhir dengan status Closed, dan karena merupakan tulisan pengajuan masalah tanpa langkah reproduksi atau usulan perbaikan di isi utamanya, tidak terlihat branch, PR, atau milestone yang terhubung
• Keberatan awalnya adalah kekhawatiran bahwa perubahan yang melibatkan AI masuk ke rsync dan menggoyahkan stabilitas, dan isi postingan diunggah terutama berupa gambar tanpa penjelasan teks
• Seorang pengguna melaporkan bahwa karena log2ram memakai rsync, printer 3D miliknya berjalan pada CPU 100%, dan menyebut AI seolah memasukkan bug ini ke robot
• Pengguna lain menilai rsync adalah alat stabil yang tidak memerlukan fitur baru atau penulisan ulang, melainkan hanya pembaruan keamanan dan perbaikan bug, dan bahwa dalam dua rilis patch terbaru telah muncul masalah yang seharusnya tidak mengubah fungsi yang ada
• Seorang pengguna yang memakai rsync untuk pekerjaan DFIR menjelaskan bahwa hanya karena AI terlibat dalam pembaruan, menurut kebijakan organisasinya itu kini harus diperlakukan sebagai “alat AI” dan memerlukan peninjauan tambahan
• Dari pihak sebaliknya, ada yang menegaskan bahwa issue tracker bukan tempat untuk meluapkan keluhan yang bersifat viral, dan tanpa laporan bug yang konkret atau langkah reproduksi, topik seperti ini seharusnya dipindahkan ke Discussions atau di-fork
• Benturan utamanya membesar di antara posisi “ini perangkat lunak gratis, jadi kalau tidak suka silakan fork” dan posisi bahwa rsync sudah menjadi alat infrastruktur inti, sehingga pembicaraan tentang pinning atau fork di sisi downstream itu sendiri adalah tanda adanya masalah
• Sebagian pengguna menyebut penulisan ulang dalam Rust atau fork, tetapi pengguna lain menegaskan bahwa alasan rsync dicintai adalah stabilitas dan tetap bekerja seperti biasa, dan bahwa penulisan ulang adalah proyek terpisah
• Dari kubu yang membela penggunaan AI, ada yang meminta agar semua penyebutan AI tidak langsung dicap sebagai “vibe slop”, dan bahwa log commit sejak Maret harus diaudit langsung untuk memeriksa alasan tiap perubahan
• kaithar menjelaskan bahwa pekerjaan terbaru mencakup perbaikan bug dan cacat keamanan serta hardening seperti pembacaan memori yang belum diinisialisasi, over/underflow protokol wire, timestamp 32-bit, dan penyesuaian terkait standar C
• Komentar yang sama juga membantah bahwa mengunci ke rilis lama seperti 3.4.1 dapat membuat pengguna tetap berada pada versi dengan banyak CVE, dan bahwa regresi bisa muncul dari edge case yang lolos dari pengujian
• Pada akhirnya, isu ini tidak mengerucut ke perbaikan bug yang konkret, dan tetap menjadi perdebatan tentang bagaimana menangani kepercayaan, audit, dan tata kelola pengembangan berbantuan AI dalam infrastruktur jangka panjang yang stabil seperti rsync

[GN⁺]

Opini Hacker News

• Penggiringan massa ini benar-benar aneh, dan sebagian tampaknya bertindak tidak rasional. Saya bisa sedikit memahami motivasi ingin “menang” dalam pertarungan ini, tetapi jelas bukan dengan cara seperti ini, karena hanya membuat mereka terlihat seperti kaum fanatik
  Cukup 5 menit untuk mencari regression di halaman issue dan menelusuri 17 hasil. Mungkin bahkan ada lebih banyak di pelacak yang dipakai sebelum GitHub
  Perilaku seperti ini sangat bodoh, dan orang-orang tampaknya berpegangan pada apa pun yang bisa dipakai untuk membenarkan kebencian terhadap AI. Seolah mereka lupa bahwa orang juga melakukan kesalahan sebelum AI ada
  Kalau memang ada bukti bahwa AI secara berarti meningkatkan jumlah issue rsync yang belum terselesaikan, silakan tunjukkan. Saya akan dengan senang hati mengubah pendapat saya

  • Ini tidak harus dilihat hanya sebagai “orang-orang membenci AI lalu berpegangan pada apa saja”. Ketika orang merasa ada masalah pada sesuatu, mereka akan bertindak
    Mungkin ini bukan penyebab langsung dari commit kali ini, tetapi bisa jadi merupakan reaksi terhadap masalah lain yang terakumulasi, dan itu sendiri layak dipertimbangkan
    Tampaknya orang-orang lelah dipaksa menelan narasi seperti “AI adalah hal terbaik sejak [analogi budaya]”, lalu berusaha melawan dengan berpegang pada jerami apa pun yang ada, dan menurut saya itu reaksi yang cukup normal
  • Cara berbondong-bondong dengan gambar meme memang aneh. Namun, bahasa yang dipakai sendiri berada pada tingkat yang biasa Tridgell lihat di LKML, jadi itu bukan kekhawatiran utamanya
    Jika tidak ada yang menyuarakan kekhawatiran bahwa pengguna tidak mempercayai AI, bagaimana maintainer bisa mengetahuinya? rsync selama ini sangat stabil. Apakah orang-orang harus diam-diam pindah ke Openrsync dan tidak mengatakan apa-apa?
  • Jika alat yang sangat stabil dan tepercaya tiba-tiba mulai menurun, menurut saya kemarahan orang sangat bisa dibenarkan. Linux Mint Timeshift memiliki issue yang merangkum berbagai regresi yang terbuka di halaman issue rsync, dan ini tampaknya hanya diperkenalkan setelah vibecoding (https://github.com/linuxmint/timeshift/issues/548)
    Salah satu tautan di sana mengarah ke kumpulan bug yang lebih besar yang dilaporkan di distro turunan (https://github.com/void-linux/void-packages/issues/60825)
    Mengingat reputasi software vibecoding, kemarahan ini sangat masuk akal. Bahkan para pakar yang saya sukai pun mengatakan hal seperti “agar tidak menghasilkan bug, ini harus ditangani dengan cara yang sangat spesifik, dan mungkin sebaiknya hanya dipakai untuk versi 0 guna memetakan domain”
    Namun di sini, alat inti backup standar industri sedang ditarik karpetnya dari bawah pengguna dengan cara yang jelas tidak aman, demi niat maintainer untuk “menambahkan lebih banyak fitur”
    Di thread Timeshift juga ada laporan bahwa “setelah pembaruan rsync, penggunaan CPU selama backup harian menjadi sangat parah sampai saya harus menghentikan timeshift yang terus berjalan selamanya”
    Dengan kata lain, orang frustrasi dan marah karena alat yang mereka percayai untuk backup dan data mereka sedang merusak seluruh infrastruktur backup mereka dengan sangat banyak regresi dan bug baru, dan alasannya adalah pengembang intinya melakukan vibecoding
    Bahkan pakar vibecoding seperti Simon Wilson juga secara eksplisit mengatakan bahwa ini hanya mungkin “jika Anda menangani alatnya dengan cara tertentu”, jadi maintainer ini entah tidak melakukannya atau pernyataan itu memang tidak benar
    Jika benar-benar membaca thread tersebut dan tidak hanya melihat sekilas bagian dua orang yang saling bertengkar, ada beberapa laporan bahwa pengguna di lingkungan industri dan pemerintahan harus mengulang seluruh prosedur mereka untuk bisa memperbarui software ini. Software itu langsung menjadi tidak bisa dipercaya, menimbulkan kerugian langsung bagi pengguna, dan meruntuhkan alasan keberadaannya sendiri
    Saya juga akan marah jika mempercayakan backup lebih dari 500GB pada software ini, dan saya akan bertanya-tanya berapa banyak lagi masalah yang sudah masuk tetapi belum terungkap sampai suatu perusahaan tidak menguji backup-nya secara rutin lalu mengalami kehilangan data senilai 10 juta dolar
  • Terasa seperti sindrom perilaku anti-AI
  • AI sudah menjadi isu politik partisan, dan semua konsekuensinya ikut menyertainya. Pada titik ini, ini mirip seperti mengeluh bahwa matahari terbit dari timur :(

• Benar-benar tidak paham
  Ada perangkat lunak yang kokoh yang dipakai banyak orang dan layanan. Berfungsi dengan baik, menjalankan tugasnya, dan kadang hanya perlu pembaruan kecil untuk memperbaiki bug
  Jadi kenapa AI diperlukan di sini?
  Lagi pula aku juga tidak paham kenapa orang bilang, “fork saja dan pakai versi sebelumnya.” Justru seharusnya kebalikannya. Buat fork paralel seperti younamethetool-ai dan jangan sentuh yang asli
  Apa sekarang aku harus mem-fork dan memelihara seluruh tool sistemku?

  • Soal “kenapa AI diperlukan di sini”, seperti juga disebut di banyak komentar issue, pengembang yang berkontribusi ke paket open source-lah yang berhak menentukan cara mereka bekerja
    Mengeluh di issue tracker tanpa bukti bahwa AI merusak perangkat lunak adalah salah satu bentuk perundungan terhadap kontributor open source yang sering dibahas di Hacker News [1]
    https://github.com/RsyncProject/rsync/issues/929#issuecommen...
    “Issue tracker bukan tempat memanen postingan media sosial yang viral. Laporkan bug yang bisa ditindaklanjuti atau fork sendiri. Meluapkan emosi soal pilihan pengembang tidaklah produktif”
    https://github.com/RsyncProject/rsync/issues/929#issuecommen...
    “@II-Paulus-II berhenti. Kamu tidak tahu apa-apa. Kamu belum pernah merilis satu pun fitur secara manual. Tidak ada seorang pun yang bergantung pada kodenmu. Kamu cuma penuding ‘AI yang menulis ini’ yang bersembunyi di balik superioritas moral karena menulis proyek mainan dan skrip dari nol. Kamu tidak bisa merilis, tidak bisa beradaptasi, dan bahkan tidak paham bahwa issue tracker bukan tempat untuk sikap seperti ini”
    [1] https://news.ycombinator.com/item?id=43077833
  • Aku 100% setuju dengan sentimen “tolong jangan rusak pekerja yang stabil dan andal ini”
    Aku belum membacanya secara rinci, tetapi kalimat “6 CVE diperbaiki dalam rilis ini. Keenamnya ditugaskan oleh VulnCheck sebagai CNA. Untuk semua kasus, versi yang terdampak adalah 3.4.2 atau lebih lama” tampaknya merupakan jawaban yang cukup kuat untuk pertanyaan “kenapa?”
    https://download.samba.org/pub/rsync/NEWS#3.4.3
  • Menyedihkan melihat rasa berhak yang harus ditanggung banyak pengembang open source. Bayangkan membuat sesuatu gratis sebagai hobi, lalu harus menghadapi kerumunan marah yang tidak pernah membayar sepeser pun hanya karena kamu melakukan sesuatu yang tidak mereka sukai
    Reaksi pertama yang wajar rasanya memang ingin menyuruh mereka pergi saja ke tempat lain
  • Bukankah itu keputusan maintainer? Kalau mereka memutuskan ingin menulis lebih banyak pengujian dengan AI, ya lakukan saja. Mereka juga tidak berutang apa pun kepada publik
    Jika “publik” ingin mengambil alih proyek itu, memelihara, dan melanjutkannya, mereka bisa melakukan fork, tetapi itu pekerjaan yang minim apresiasi
  • Kenapa maintainer harus mem-fork repositorinya sendiri? Itu tidak masuk akal. Lalu siapa yang akan memelihara repositori lama?
    Lagi pula, dalam proyek open source, perubahan alat yang dipakai juga tidak perlu punya alasan, dan alasan itu pun bukan sesuatu yang mereka utangkan kepadamu

• Cara isu itu dibuka memang sangat menjengkelkan, tetapi saya tidak paham mengapa para maintainer tampak seperti melepas AI ke rsync. Kenapa melakukan itu? Mereka sudah punya reputasi dan kepercayaan, memimpin di ceruk tertentu, bebas dari tekanan pasar, orang-orang menyukai alat itu, dan alat itu melakukan persis apa yang perlu dilakukan dengan sangat baik, jadi mengapa mencoba macam-macam yang relatif eksperimental?
  Rasanya seperti monolog singkat di Matrix tentang bagaimana pikiran manusia yang primitif tidak bisa menerima surga. Mereka membuat alat yang sempurna, menang, hampir tak tergantikan di ceruknya, bisa dipercaya, dan secara kiasan sudah menjadi nama yang dikenal semua orang. Mempertaruhkannya atau mengutak-atiknya tidak masuk akal bagi siapa pun dan benar-benar membingungkan
  Meski begitu, melakukan hal seperti itu di issue tracker resmi tetap tindakan yang sangat tidak menyenangkan. Sikapnya juga buruk dan tidak terlihat ada itikad baik

  • Kalau ini terjadi beberapa tahun lalu, saya rasa saya akan membela para maintainer dengan aktif. Memelihara proyek open source apa pun itu melelahkan dan jarang dihargai, dan untuk proyek yang sudah mapan seperti rsync apalagi
    Tetapi sekarang AI tidak terlihat sebagai hal yang sepenuhnya positif di mana pun, dan saya melihat penolakan terhadap penggunaan AI generatif ini sebagai koreksi arah publik yang baik
    Ada tulisan-tulisan yang membahas kepuasan instan dari penggunaan LLM, dan makin banyak saya berinteraksi dengan orang-orang yang memakai alat ini, makin saya merasa ini mungkin benar-benar masalah intinya. Biologi kita tidak sanggup menanganinya
    Saya melihat orang-orang yang sebenarnya sangat pintar melakukan hal-hal yang benar-benar bodoh hanya karena mesin slot mengatakannya, dan bahkan terlatih menjadi tak berdaya ketika mesin slot itu gagal
    Saya diperlakukan seperti seorang Luddite yang tidak bisa melihat kemajuan, sementara saya melihat rekan kerja membuat benchmark yang tidak berarti dan menempelkan grafik indah buatan AI
    Lalu saya harus memilih antara tersenyum dan berpura-pura itu kerja yang bagus, atau memarahi mereka karena benchmark itu tidak bermakna karena menguji bagian yang nilainya dipatok sebagai konstanta. Apa pun pilihannya, hasilnya saya memperlakukan mereka bukan sebagai rekan cerdas, melainkan seperti anak 7 tahun
  • Jawaban untuk “mengapa?” adalah karena semua orang, termasuk forum ini, kecanduan kepuasan instan dari LLM. Itu kesombongan murni: melihat sekilas output lalu percaya bahwa itu bekerja seperti yang mereka bayangkan
  • Apakah pendapat ini dibuat hanya dari melihat issue itu, atau ada bukti nyata? Tautan GitHub ini memang menarik, tetapi selain “Claude” hampir tidak ada konteks tentang drama apa yang sebenarnya terjadi
    Entah para maintainer rsync ada di titik mana antara maintainer sempurna dan bertanggung jawab sampai anak-anak yang tidak kompeten, kita sebenarnya tidak tahu
  • Saya setuju bahwa melepas AI ke rsync itu sulit dipahami, dan saya juga setuju bahwa cara isu ini diangkat sangat menjengkelkan
    Namun dengan risiko sedikit keluar dari topik, saya jadi terpikir begini. Selain fakta bahwa perangkat lunak matang seperti Rsync tidak membutuhkan pergerakan seperti jumlah baris kode yang diubah, mari kita asumsikan para maintainer mengelola proyek ini dengan niat terbaik
    Jika ini terjadi di open source, lalu bagaimana kondisi kualitas perangkat lunak tertutup?
    Penggunaan AI, yaitu banyaknya prompt/input, masuk ke evaluasi karyawan seolah-olah itu metrik keberhasilan, dan orang-orang panik karena ancaman PHK massal akibat AI
    Mengerikan
  • Yang benar-benar tidak saya pahami adalah bagaimana orang bisa bilang AI sudah dilepas ke rsync padahal baik Anda maupun saya sama sekali tidak tahu bagaimana Claude digunakan
    https://github.com/RsyncProject/rsync/issues/929#issuecommen... menunjukkan bahwa itu tidak lagi berjalan di Darwin lama dan Linux < 5.6, padahal Linux 5.6 sudah dijadwalkan usang pada 2020. Ada juga beberapa bug lain
    Kita tidak bisa berharap maintainer mendukung sistem lama dan mengetahui semua dampak dari sebuah perubahan. Mau dikerjakan dengan AI atau manual, tetap sama saja

• Sebagai catatan, bug itu sendiri masuk lewat 30656c5e yang dibuat oleh Claude Code, dan tampaknya juga ada review serta pengujian oleh orang yang mungkin kurang tepat
  https://github.com/RsyncProject/rsync/commit/30656c5e
  Seseorang memakai AI untuk melakukan bisect pada rsync terbaru: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
  Upaya seseorang untuk memperbaikinya dengan lebih banyak Claude Code: https://github.com/RsyncProject/rsync/pull/930
  Tiket terkait: https://github.com/RsyncProject/rsync/issues/915
  Saya sarankan menambahkan lebih banyak tes regresi ke commit tepat sebelum 30656c5e, lalu melakukan rebase ke depan sambil mempertahankan fungsionalitas

  • Kalau begitu, keluhan awalnya tampak salah
    Ini bukan “fitur baru yang tidak diinginkan”. Tridge sedang memperbaiki masalah keamanan yang terkait dengan laporan bug itu. Bisa dimengerti. Kita semua sedang dihantam masalah keamanan. Memperbaikinya bukan pilihan
    Saya tidak akan bilang menyenangkan harus kembali ke perangkat lunak berumur 10 tahun untuk menangani ini, jadi saya terkesan bahwa tridge berusaha
    Saya juga bersalah memakai LLM untuk melewati kekacauan semacam ini. Saya tidak tahu persis apa yang dilakukan tridge, tetapi saya memeriksa setiap baris kode yang dikeluarkan LLM. Meski begitu, risikonya bug tetap lolos jelas besar
    Saya sudah lama tidak melihat kode itu, dan juga tidak seakrab dulu. Jadi ada bug yang lolos bukanlah hal yang terlalu mengejutkan
    Hal aneh dari ledakan ini adalah orang yang awalnya mengeluh tampaknya sangat protektif terhadap sistem backup-nya, tetapi commit tridge itu baru dua minggu lalu. Saya tahu tridge hebat, tetapi bukankah hal seperti ini jelas harus diperlakukan seperti perangkat lunak alpha? Sebenarnya dia berpikir apa? Mungkin dia juga perlu sedikit belajar cara membangun sistem yang bisa dipercaya

• Kalau ini terjadi beberapa tahun lalu, kemungkinan tulisan seperti ini naik ke halaman utama Hacker News nyaris mendekati 0. Terlepas dari benar atau salah isinya, dulu tempat ini tidak dipenuhi orang kebanyakan yang tidak paham perilaku seperti apa yang tidak bisa diterima
  Yang dimaksud di sini adalah bahasa yang kasar dalam issue itu. Namun sekarang kita dikelilingi orang-orang yang bahkan tidak bisa membedakan hal yang paling jelas sekalipun

  • Membuka issue berjudul “Please Do Not Vibe Fuck Up This Software” hanya berdasarkan satu tangkapan layar dari layanan mirip Twitter dan “seseorang yang entah siapa” yang katanya menemukan bug jelas tidak pantas
    Itu bukan cara mengatakan kepada maintainer bahwa Anda tidak setuju dengan arah proyek. Issue itu sepenuhnya tidak berguna. Jauh lebih baik kalau itu berupa laporan bug tentang sesuatu yang “rusak karena vibe coded”
    Ini tepat mengenai intinya. Tidak ada satu pun laporan bug yang bahkan mencoba mendokumentasikan regresi --compare-dest= yang diklaim. Bahkan setelah Ctrl-F pun, saya tidak melihat ada orang yang menyebut “compare-dest” lagi
    Orang-orang yang menulis komentar marah tentang AI yang tidak berguna itu sebenarnya bisa saja menyuruh Opus 4.8 menjalankan rsync 3.4.3 dan 3.4.1, mendokumentasikan regresinya secara menyeluruh, lalu menemukan commit yang merusak dengan git bisect, sehingga menghasilkan laporan bug yang 1000 kali lebih profesional dan berguna
    Jika masyarakat ingin pekerjaan manusia dinilai lebih tinggi daripada pekerjaan AI, sebaiknya hindari tindakan bodoh yang hanya dilakukan manusia
  • Hal yang sama juga bisa dikatakan soal penggunaan istilah merendahkan seperti “normies”
    Bukankah mungkin itu naik ke halaman utama karena orang lain juga merasakan hal yang sama tentang software yang mereka gunakan setiap hari untuk pekerjaan penting?
    Memang benar issue GitHub itu klise dan jelas pekerjaan yang sulit dihargai, tetapi secara realistis rsync adalah fondasi banyak pipeline sensitif
  • Menyebut issue itu “kasar” terasa aneh. Kalau dibaca sedikit saja, jelas skalanya besar dan tidak ada pihak terkait yang punya keunggulan moral
    Jika Anda benar-benar yakin itu di luar topik, tanggapan yang sopan adalah menutup issue tersebut
    Saya masih tidak terlalu paham apa yang dianggap begitu jelas. Bagi saya, “berhenti. kamu tidak tahu apa-apa. kamu sudah merilis 0 fitur dengan tangan. tidak ada seorang pun yang bergantung pada kodemu” terdengar jauh lebih kasar daripada “please do not vibe fuckup this software”
  • Mungkin saya memang jadi terlalu sinis. Semakin banyak komentar di HN dan issue GitHub terasa seperti bot yang memancing kemarahan orang lain, termasuk para maintainer
  • Saya suka komentar ini karena cukup samar sehingga bisa berlaku untuk kedua pihak :)

• Adakah orang di thread issue itu yang benar-benar menjelaskan issue-nya? Maksud saya langkah reproduksi, perilaku yang diharapkan, dan perilaku aktual
  Ini diposting di pelacak issue. “Ada penyebutan Claude di pesan commit, dan seseorang di Bluesky merasa masalah tak spesifik yang dia alami mungkin terkait commit-commit itu” bukanlah issue yang bisa ditindaklanjuti
  Mengesampingkan semua perdebatan lain, kalau itu proyek saya, saya akan menutup dan menguncinya karena “kurang informasi reproduksi”. Ada tempat yang lebih baik untuk diskusi umum tentang AI, fork, dan pelampiasan amarah

  • Issue sebenarnya tampaknya kira-kira seperti ini
    Pengguna Linux < 5.6 tidak bisa build dari GitHub. Bagi saya ini terlihat seperti regresi yang cukup sepele. Orang yang memakai versi pemeliharaan 5.6, terutama versi keamanan tambahan, kemungkinan maintainer distro mereka akan menemukan kegagalan build itu dan memperbaikinya tepat waktu
    Penguatan terhadap serangan path traversal menyebabkan kegagalan bagi pengguna yang memakai protokol rsync native tanpa chroot. Ironisnya, chroot = no memang tidak terlalu disarankan
    Anda mungkin bahkan bisa berargumen bahwa rsync native seharusnya tidak dipakai secara otomatis, atau bahkan tidak dipakai sama sekali. CVE yang diperbaiki commit tersebut justru tepat berlaku untuk kasus penggunaan ini
    https://www.cve.org/CVERecord?id=CVE-2026-29518
    Diperlukan daemon + no chroot. “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
    Jadi workflow yang terdampak adalah workflow yang paling rentan, tetapi orang-orang justru menyarankan untuk menurunkan versi
    Lagi pula, kalau pengujian regresi seharusnya menangkap ini, maka pengujian itu seharusnya sudah ditulis sebelumnya

• Sebagian orang tampaknya lupa tentang proyek FOSS
  “15. Penyangkalan garansi
  Sepanjang diizinkan oleh hukum yang berlaku, tidak ada garansi untuk program ini. Kecuali dinyatakan lain secara tertulis, pemegang hak cipta dan/atau pihak lain menyediakan program ini ‘sebagaimana adanya’ tanpa garansi apa pun, baik tersurat maupun tersirat, termasuk namun tidak terbatas pada jaminan tersirat tentang kelayakan jual atau kesesuaian untuk tujuan tertentu. Seluruh risiko terkait kualitas dan kinerja program ada pada Anda. Jika program terbukti cacat, Anda menanggung biaya seluruh layanan, perbaikan, atau koreksi yang diperlukan”

  • Ada juga penafian pengguna OSS
    Saya berhak mengeluh, ngomel, mengkritik, marah, atau memberi komentar lain atas setiap keputusan proyek, commit, patch, pemasaran, atau keputusan lainnya. Komentar tersebut tidak menjamin kesesuaian untuk tujuan apa pun, juga tidak mencakup jaminan tersirat bahwa komentar itu benar, berguna, atau ramah. Jika komentar saya ternyata tidak diinginkan, Anda berhak menaruhnya di tempat yang tidak membahayakan siapa pun
    Silakan cetak penafian ini sebagai referensi saat menghadapi kritik yang tidak diinginkan terhadap proyek FOSS
    Saya tidak paham kenapa orang tidak bisa mengerti bahwa sikap “mereka boleh melakukan apa yang mereka mau” itu berlaku dua arah. Pengguna juga boleh melakukan apa yang mereka mau. Kalau tidak suka, mereka boleh mengungkapkannya
  • Secara hukum memang boleh, tetapi kalau begitu ya Anda cuma jadi orang yang buruk
    Salah satu komentar di issue itu mengatakan begini
    “Hanya karena Anda memberi sup gratis kepada tunawisma bukan berarti Anda boleh kencing di dalamnya”
  • “Tanpa garansi” tidak sama dengan “tanpa keluhan”. Kalau iya, tidak akan ada alasan untuk memiliki pelacak issue dan bagian diskusi
    Issue tersebut sudah telanjur kacau, dan argumen Anda juga sudah muncul di sana. Semua orang sebenarnya bisa menanganinya dengan lebih baik, tetapi mengutip teks hukum secara membabi buta tidak akan menyelesaikan atau memperbaiki apa pun

• Ini sudah ketiga kalinya saya membaca posting HN tentang topik ini. Setiap kali, yang berulang hanya tweet yang sama, atau posting yang entah bagaimana disebut di Mastodon/Bluesky dan sejenisnya. Apakah ada yang benar-benar sudah debugging masalah ini?
  Apakah penyebabnya kode yang dihasilkan secara ceroboh, atau justru perbaikan keamanan yang sah yang kebetulan merusaknya? Maksud saya, dengan cara yang juga bisa saja dilakukan manusia

  • Ada sebagian daftarnya di https://github.com/RsyncProject/rsync/issues/929#issuecommen...

• Histeria anti-AI ini adalah kepanikan moral yang sangat khas

  1. Mengidentifikasi sesuatu sebagai buatan AI
  2. Menyerang dan mengucilkan orang yang mungkin terlibat dalam pembuatannya
     Seperti semua kepanikan moral, apakah poin 1 benar atau tidak sepenuhnya bersifat sekunder. Intinya adalah mendapatkan semacam pelepasan yang nyaris seksual dari poin 2
     Dalam kasus ini, saya tahu memang ada kode buatan AI di rsync. Seperti halnya sebagian besar perangkat lunak berguna pada masa sekarang. Namun di internet kita melihat perburuan penyihir setiap hari, dan seperti semua perburuan penyihir, apakah tuduhannya benar tidak terlalu penting. Histerianya sendiri adalah tujuannya
  • Berbahaya jika menolak memahami apa yang sedang terjadi secara luas sekarang, dan apa yang sedang terjadi di thread ini, lalu terus memberi sinyal bahwa kita tidak perlu memahaminya
    Kemarahan yang muncul di sekitar AI bukan karena publik salah paham atau karena pesannya keliru, melainkan persoalan realitas fisik
    Satu hal ini dipakai sebagai alasan untuk PHK massal, para CEO teknologi hampir setiap hari mengatakan akan mengambil pekerjaan semua orang lain juga, dan perusahaan cloud raksasa sedang mengisap semua oksigen di dalam ruangan. Bahkan industri game pun tidak aman
    Sikap yang melihat ini sebagai “sekadar kepanikan moral yang khas” itu seperti melihat ke arah mana laut sedang surut lalu berlari lurus ke sana
  • Melihat pemikiran yang longgar seperti “Intinya adalah mendapatkan semacam pelepasan yang nyaris seksual dari poin 2” membuat saya sulit menanggapi jawaban itu dengan serius
    Kalau dibaca lebih lanjut, Anda sendiri juga memakai bahasa emosional seperti “perburuan penyihir” dan “histeria”
    Apakah ini benar-benar perburuan penyihir? Dan apakah kita bisa tahu bahwa orang-orang di seberang internet sedang mendekati pelepasan seksual?
    Bukankah Anda juga merespons bahasa emosional dan pemikiran longgar orang lain dengan cara yang sama?

• Sejak kapan issue GitHub menjadi tempat untuk mengunggah tangkapan layar posting dari platform lain?
  Perilaku seperti ini biasanya hanya saya lihat di tempat untuk meme atau konten hiburan
  Tidak ada laporan bug yang bisa ditindaklanjuti atau permintaan fitur. Tidak ada versi teksnya. Bahkan tidak ada tautan ke posting aslinya
  Apakah orang yang mengunggah ini mengira GitHub Issues adalah akun Twitter pribadinya?

  • Mengunggah tangkapan layar adalah cara yang lebih mudah untuk mencegah respons LLM otomatis. Sebab kebanyakan memakai model teks tanpa kemampuan visi yang biayanya lebih murah