क्या Claude ने rsync में बग बढ़ाए?

 (alexispurslane.github.io)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude-सहायित रिलीज़ केवल rsync v3.4.2 और v3.4.3 दो ही हैं, और severity-weighted bug/10 commits के आधार पर यह दिखाने वाला कोई प्रमाण नहीं है कि इनमें पिछली रिलीज़ों की तुलना में असामान्य रूप से अधिक बग थे
  • sev/10c मुख्य मेट्रिक है, जिसमें बग severity स्कोर को 0~1 पर normalize करके हर रिलीज़ के लिए जोड़ा जाता है, फिर commits की संख्या से भाग देकर प्रति 10 commits के मान में बदला जाता है
  • v3.4.2 में 50 commits·9 Claude commits·0 bugs·0.00 sev/10c था, और v3.4.3 में 34 commits·28 Claude commits·17 bugs·3.29 sev/10c था; दोनों IQR के दो सिरों के आसपास आते हैं, और इनमें से कोई भी outlier नहीं है
  • Exact permutation test का p-value 46% था, Fisher's exact test का p-value 74% था, और odds ratio 1.06 था; यानी Claude रिलीज़ें किसी भी random 2 releases से बदतर हैं या median से ऊपर होने की अधिक संभावना रखती हैं, इसका लगभग कोई संकेत नहीं मिलता
  • v3.4.1 Claude लागू होने से पहले की रिलीज़ थी, फिर भी 59 bugs·9 commits·39.39 sev/10c के साथ पूरे डेटा में सबसे खराब मान उसी का था; rsync विवाद का केंद्र यह है कि historical distribution के बिना एक single regression को Claude से जोड़ दिया गया

पृष्ठभूमि और सवाल

  • मई 2026 के अंत में rsync विवाद एक Mastodon पोस्ट से शुरू हुआ, जिसमें v3.4.3 regression और उस रिलीज़ के Claude commits को जोड़ा गया; बाद में यह Hacker News और GitHub issue "Please Do Not Vibe Fuck Up This Software" तक फैल गया, और उस issue में 300 से अधिक टिप्पणियाँ जमा हुईं
  • बार-बार दोहराया गया मुख्य दावा यह था कि Claude-सहायित development ने पहले से स्थिर टूल में बग डाल दिए, और डेटा-आधारित सवाल यह था कि क्या Claude-सहायित रिलीज़ें ऐतिहासिक रिलीज़ों की तुलना में असामान्य रूप से अधिक buggy थीं
  • Lobsters पर यह सुझाव आया कि रिलीज़-दर-रिलीज़ regressions की time chart देखी जाए, और विश्लेषण का फोकस एक ही सवाल रहा: “क्या Claude-सहायित रिलीज़ें असामान्य रूप से अधिक buggy हैं?”

डेटा का दायरा और reproducibility

  • डेटा RsyncProject/rsync की v2.4.6 से v3.4.3 तक की उन 36 रिलीज़ों का है जिनके लिए bug data उपलब्ध है; Claude commits वाली रिलीज़ें केवल v3.4.2 और v3.4.3 हैं
  • मेट्रिक, methodology और data source का चयन इंसान ने सीधे किया, और इसमें statistics में master's degree रखने वाली जीवनसाथी की सलाह शामिल थी
  • डेटा संग्रह, DuckDB लोडिंग, view creation और statistical analysis scripts GLM 5.1 ने लिखे, लेकिन सभी numbers, statistics, cards और graphs statistical analysis चलाने वाले Python script ने automatic templates के जरिए डाले
  • reproducibility के लिए alexispurslane/rsync-analysis repository पूरी pipeline को शुरू से अंत तक चला सकती है

मेट्रिक और bug attribution का तरीका

  • मुख्य मेट्रिक severity-weighted bugs per 10 commits, यानी sev/10c है, और इसका formula है sev/10c = (Σ severity/100 ÷ total_commits) × 10
  • commits को base branch में committer date के क्रम से sort किया गया, और हर release range को पिछले tag से उस tag तक के commits के रूप में लिया गया; pre·rc tags को boundaries से बाहर रखकर final release में absorb किया गया
  • bug sources तीन हैं: GitHub issues, rsync Bugzilla, और rsync mailing list; GitHub issues और mailing list bugs को report होने के ठीक पहले deploy हुई नवीनतम release से जोड़ा गया
  • Bugzilla items में “Version” field उस release को स्पष्ट करती है जिसमें bug report हुआ था, इसलिए उन्हें उसी release से जोड़ा गया
  • release-level analysis इसलिए चुना गया क्योंकि आलोचना का स्वरूप ही यह था कि “Claude commits वाली पूरी release ज्यादा buggy हो गई,” और अधिकतर bugs में यह स्पष्ट नहीं होता कि वे ठीक किस commit से आए

severity आकलन का तरीका

  • सभी bug reports को Qwen 3 35B ने 0~100 severity score दिया, और prompt में उसे वास्तविक user impact के नज़रिए से senior reliability engineer की भूमिका दी गई
  • 90~100 स्कोर silent data corruption·data loss·remote code execution या unauthorized access security vulnerabilities के लिए, 70~89 crashes·hangs·backup failures·build failures के लिए, और 50~69 workaround योग्य functional regressions के लिए रखा गया
  • Bugzilla और mailing list में body के बिना केवल titles थे, इसलिए model ने सिर्फ title देखकर मूल्यांकन किया; और जानकारी कम होने पर उसे 40~60 के middle range की ओर झुकने के लिए कहा गया
  • output के लिए structured output के JSON schema का उपयोग हुआ, जिसमें केवल integer severity स्वीकार की गई, और temperature 0 पर फिक्स रखा गया ताकि एक ही input पर एक ही score आए
  • feature requests, spam, AI से जुड़ी non-technical आपत्तियाँ, और खाली submissions जैसे 0-score issues को base bug count से बाहर रखा गया

Claude रिलीज़ों के statistical results

  • v3.4.2 में 50 commits में से 9 Claude commits थे, वास्तविक bugs 0 थे, sev/10c 0.00 था, और यह 0 percentile release थी
  • v3.4.3 में 34 commits में से 28 Claude commits थे, bugs 17 थे, sev/10c 3.29 था, और यह 77 percentile release थी
  • ऐतिहासिक IQR 0.29~2.59 sev/10c था; v3.4.2 IQR के ठीक नीचे और v3.4.3 IQR के ठीक ऊपर थी, यानी दोनों रिलीज़ें मध्य वितरण के दो उल्टे किनारों को घेरे हुए हैं
  • Exact permutation test में 595 संभव 2-release combinations में से 272 का mean Claude group mean 1.65 sev/10c या उससे अधिक निकला, इसलिए p-value 46% आई
  • Fisher's exact test ने median 0.74 sev/10c के आधार पर देखा कि क्या Claude रिलीज़ें median से ऊपर अधिक बार आती हैं, और इसका परिणाम p-value 74% तथा odds ratio 1.06 रहा

commits की संख्या और बदलाव का आकार

  • Claude रिलीज़ों में औसतन 42 commits थे, जबकि बिना Claude वाली रिलीज़ों में औसतन 185 commits थे; किसी random 2 releases के पास इतने या इससे अधिक commits होने की संभावना 88% थी
  • GitHub compare API के अनुसार Claude रिलीज़ों में औसतन 3,756 lines बदलीं, जबकि बिना Claude वाली रिलीज़ों में औसतन 696 lines; किसी random 2 releases में इतने या इससे अधिक changed lines होने की संभावना 5% थी
  • severity-weighted bug count Claude रिलीज़ों में औसतन 5.6 था, जबकि बिना Claude वाली रिलीज़ों में औसतन 14.9; किसी random 2 releases में इतने या इससे अधिक severity-weighted bugs होने की संभावना 77% थी
  • निष्कर्ष यह है कि Claude रिलीज़ों में changed lines बहुत अधिक थीं, लेकिन commits की संख्या या severity-weighted bug count अधिक नहीं था

version regime और पूर्व outliers

  • v2.x रिलीज़ों का औसत 1.11 sev/10c था, जबकि v3.x रिलीज़ों का औसत 4.23 sev/10c था; यानी v3.x में bug rate अधिक दिखता है
  • केवल v3.x की तुलना करने पर भी Claude रिलीज़ें मध्य स्तर पर या उससे बेहतर आती हैं; Claude को outlier जैसा दिखाने के लिए अपेक्षाकृत शांत पुराने दौर से तुलना करनी पड़ेगी और Claude से पहले हुए बदलावों का दोष Claude पर डालना होगा
  • Wald–Wolfowitz runs test में Claude के बिना 35 रिलीज़ों पर observed runs 13, random expectation 18.5, z=-1.88, p=0.060 मिला; 0.05 threshold पर यह randomness को खारिज करने जितना मजबूत नहीं है
  • v3.4.1 Claude से पहले की रिलीज़ थी, फिर भी 59 bugs·9 commits·39.39 sev/10c के साथ इसने पूरे dataset में सबसे ऊँचा bug rate दर्ज किया
  • v3.4.1, v3.4.0 के अगले दिन आई एक hotfix release थी, और इसने सभी दूसरी रिलीज़ों को कम-से-कम एक digit के अंतर से पीछे छोड़ते हुए सबसे ऊँचा bug rate दिखाया, लेकिन उस समय AI को दोष देने का कोई आधार नहीं था

व्याख्या और सीमाएँ

  • डेटा के अनुरूप व्याख्या यह है कि “अभी की दो Claude रिलीज़ें सांख्यिकीय रूप से ऐतिहासिक रिलीज़ों से अलग नहीं दिखतीं”
  • v3.4.3 का 3.29 sev/10c और 77 percentile होना इसे ऊँचा तो बनाता है, लेकिन यह extreme value नहीं है; इससे ऊँचे score वाली 8 ऐतिहासिक रिलीज़ें मौजूद हैं
  • “Claude ने स्पष्ट रूप से चीज़ों को बदतर बनाया” यह दावा release distribution, permutation test, या Fisher test—किसी से भी समर्थित नहीं होता
  • दूसरी ओर, “Claude commits आम तौर पर आगे भी चीज़ों को बदतर नहीं बनाएँगे” यह निष्कर्ष भी इस डेटा से नहीं निकलता; फिलहाल इतना ही कहा जा सकता है कि ये दो रिलीज़ें सामान्य दायरे में हैं
  • इस मेट्रिक की सीमा यह है कि यह commit complexity या security work intensity को control नहीं कर पाता, इसलिए यह एक blunt tool है

चर्चा किए गए confounding factors

  • Hacker News के एक user का मानना था कि CVE response security fixes ने 2007 से code में मौजूद coding errors को उजागर किया
  • Lobsters के एक user ने causal chain दी: “LLM → known security issues में वृद्धि → सामान्य से अधिक बदलाव की ज़रूरत → सामान्य से अधिक regressions”
  • Andrew Tridgell ने बताया कि AI-generated CVE reports की बाढ़ ने rsync के attack surface में तेज़ और व्यापक बदलाव की माँग पैदा की
  • इन confounding factors को शामिल करने पर समस्या Claude से ज़्यादा बढ़े हुए security work और उससे आई higher change volume के करीब लगती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की राय

  • आगे चलकर vibe coding से आगे बढ़ने वाले FOSS प्रोजेक्ट्स को इस्तेमाल करते रहना है या नहीं, यह हर कोई खुद तय कर सकता है। लेकिन मेंटेनर के vibe coding tools पर जाने के बाद कम्युनिटी ने जो गुस्सा दिखाया, वह काफ़ी चौंकाने वाला था, और लेख में दिया गया अनुभवजन्य डेटा कम-से-कम उस प्रैक्टिस बदलाव के असर को बेहतर संदर्भ देता है
    मेंटेनर द्वारा यह coding तरीका अपनाने के बाद भरोसा बना रहेगा या और टूटेगा, यह समय के साथ ही पता चलेगा

    • सोचता हूँ कि इस बदलाव पर गुस्सा करने वालों में से वास्तव में कितनों ने rsync में सार्थक योगदान दिया था या पैसे दिए थे

  • यह विश्लेषण बिल्कुल वही था जिसकी मुझे उम्मीद थी, बल्कि उससे भी ज़्यादा। खासकर “सभी metrics, methodology, और data sources मैंने खुद चुने, अपनी पत्नी से सलाह करके, जो Penn State University में statistics में master's हैं” वाला हिस्सा अच्छा लगा, और वास्तविक statistics expert को शामिल करना और इसे पढ़ने में आसान लेख बनाना शानदार था
    इसमें “हर 10 commits पर bugs” वाला एकल metric इस्तेमाल किया गया, लेकिन लगता है कि SI prefix का इस्तेमाल करके इसे प्रति commit decibugs कहना का मौका चूक गया

    • सहमत। यह मेरी पोस्ट नहीं है, लेकिन अच्छा लगा कि किसी ने गरमाई हुई पक्ष-विपक्ष बहस से आगे बढ़कर code quality पर पड़े असर को data के साथ दिखाया

  • open source प्रोजेक्ट्स की सफलता perception पर बहुत ज़्यादा निर्भर करती है, इसलिए लोग GitHub stars भी पैसे देकर खरीदते हैं। दुर्भाग्य से इस बार perception की समस्या नियंत्रण से बाहर जाकर एक talking point बन गई है, और कोई भी data इसे बदलने में मुश्किल से काम आएगा
    आगे चलकर “rsync मेंटेनर ने LLM इस्तेमाल किया और वह टूट गया” जैसी बात AI skeptics द्वारा “data centers रोज़ 5 लाख gallons साफ पानी बर्बाद करते हैं”, “METR research ने कहा कि LLM productivity घटाते हैं” जैसे talking points के साथ उठाई जाएगी
    मैं यह कहने की कोशिश नहीं कर रहा कि मैं AI skeptic हूँ या नहीं, बल्कि यह कि इस विषय पर बहसें आम तौर पर ऐसे ही चलती हैं

    • वह “talking point” क्यों है, क्या वह बस तथ्य नहीं है?
    • पता नहीं लेखक data के ज़रिए किसी को मनाने की कोशिश कर रहा है या नहीं। मुझे यह लेख rsync के tool adoption के इर्द-गिर्द हुई तीखी बहस में data context जोड़ने जैसा लगा
      लेकिन यह कहना सही है कि लेख में बाकी non-quantitative factors पूरी तरह गायब हैं, और शायद ऐसा जानबूझकर किया गया क्योंकि evangelists और skeptics दोनों तरफ़ का शोर पहले से ही काफ़ी है

  • rsync के इतिहास की सबसे खराब release, Claude के आने से पहले की थी, और हर 10 commits पर 39.39 bugs थे — यह बहुत महत्वपूर्ण और अनुमानित निष्कर्ष है
    अगर users और developers के बीच testing, quality assurance जैसी processes software की correctness सुनिश्चित नहीं कर पातीं, तो LLM हो या न हो, bugs release हो ही जाएंगे। LLM इस process में नुकसान भी पहुँचा सकता है और मदद भी कर सकता है

    • सहमत। cURL की हाल की पोस्ट शायद इसका उल्टा उदाहरण दिखाती है
      कई सालों से स्थापित मजबूत software engineering practices की वजह से, ऐसे AI tools से bugs ढूँढने की उपयोगिता कुल मिलाकर कम हो गई है
    • rsync के भविष्य को लेकर मेरी कुछ चिंताएँ हैं। सबसे बड़ा मुद्दा यह है कि rsync असल में कई सालों से लगभग पूरा हो चुका प्रोजेक्ट था, लेकिन AI का इस्तेमाल करते हुए मौजूदा test code को हटाया गया, उसे Python test suite से बदला गया, और काफी समय तक पुराने tests साथ चलाकर correctness verify नहीं की गई
      मेरे हिसाब से यह गैर-जिम्मेदाराना है। खासकर इसलिए कि rsync का मुख्य उद्देश्य कीमती data को transfer करना है, और उस data की integrity बिल्कुल अहम है

  • “AI-विरोधी users की तरह यह आखिरकार हिंसक fantasies तक escalated हो गया” जैसी भाषा से बचना चाहिए। इससे लेखक न सिर्फ़ उन कुछ लोगों को सामान्यीकृत करता है जिनसे वह असहमत है, बल्कि उन पाठकों को भी दूर कर देता है जो मूल रूप से उससे सहमत नहीं हैं, जिससे वे लोग ही लेख नहीं पढ़ते जिन्हें शायद सबसे ज़्यादा पढ़ना चाहिए
    अलग बात है कि पिछले versions की तुलना में इसमें bugs ज़्यादा हैं या कम, इससे मुझे ज़्यादा फर्क नहीं पड़ता। मेरे लिए अहम यह है कि इसे ऐसे तरीके से develop किया जा रहा है जो software development के उस तरीके से मेल नहीं खाता जिसे मैं सही मानता हूँ। अगर efficiency के अलावा भी समस्याएँ हो सकती हैं, इसकी बुनियादी समझ ही नहीं है, तो इस रुख को उचित बताकर किसी को मनाने की उम्मीद नहीं है
    अच्छी बात यह है कि अगर चाहूँ नहीं, तो rsync का यह version इस्तेमाल न करूँ, और LLM इस्तेमाल होने से पहले वाले forked विकल्प को चुनूँगा

    • इस लेख में बहुत गुस्सा भरा हुआ था, इसलिए मैं इसे ज़्यादा देर तक पढ़ नहीं पाया और छोड़ दिया। अगर यह ज़्यादा निष्पक्ष बनने की कोशिश करता, या कम-से-कम ऐसा दिखता, तो बेहतर होता
      यह भी मददगार नहीं था कि इसमें एक पुराना meme दोहराया गया, जिसे बहुत पहले खारिज किया जा चुका है — यानी कि पहला bug report वही issue था जिस पर लोग टूट पड़े थे। असल पहला bug report अलग था

  • अभी की पोस्ट ईमानदारी से मुझे बेहतर लगती है। लेकिन “यह मेट्रिक commit complexity, security sensitivity, और bug severity को control नहीं कर पाता। यह एक कुंद tool है जो एक-line typo fix और CVE patch में फ़र्क नहीं कर पाता” वाला हिस्सा, LLM बुरा है वाली मेरी स्थिति से देखें तो, असल आलोचना को मिस करता है
    मेरी और दूसरों की आलोचना यह है कि AI ऐसे commits की बाढ़ ला देता है जो बड़े होते हैं, समझने में आसान नहीं होते, और complexity बढ़ाते हैं। LLM समर्थक भी कुछ ऐसा ही कहते हैं, फिर दशकों से परखी हुई “PR पढ़ो” प्रथा से गोलपोस्ट खिसकाकर “LLM को सब कुछ test कर पाना चाहिए” पर ले जाते हैं। लेकिन code complexity कि तकनीकी debt है, यह समस्या गायब नहीं होती
    इस मामले में bug severity बहुत ऊँची है। backup workflow सचमुच टूट गया था। rsync backup के लिए बहुत इस्तेमाल होता है, और लोग इसे इतना “battle-tested” मानते आए हैं कि patch update से backup scripts टूट सकती हैं, ऐसा वे सोचते भी नहीं
    यह कहा जा सकता है कि LLM का buggy software बनाना बस एक accident था, या maintainer को LLM workflow बदलना चाहिए और test coverage बढ़ानी चाहिए। maintainer ने वास्तव में यही कहा भी। लेकिन गुस्से का केंद्र यह है कि इस tool ने उस भरोसे को तोड़ा
    सच में, आजकल LLM programmers की एक नई किस्म है जो कहती है कि वे “code पढ़ते ही नहीं”। वजह यह है कि पढ़ने में बहुत समय लगता है और यह आम programmers के code से ज़्यादा जटिल होता है। Code पढ़ना मतलब दूसरे व्यक्ति के mental model को सीखना, लेकिन LLM tools एक consistent mental model दे ही नहीं पाते
    अलग बात, site accessibility भी देखनी चाहिए। मेरी नज़र काफ़ी अच्छी है और मैं अभी late 20s में हूँ, फिर भी cream/yellow background पर हल्का gray text पढ़ना सच में तकलीफ़देह है

    • उद्धृत हिस्सा मुझे उलझा रहा है। पोस्ट में इस्तेमाल किया गया मेट्रिक तो हर 10 commits पर bugs की संख्या को severity weight देने जैसा लग रहा है; क्या लेखक खुद से विरोधाभास कर रहा है? या मैं ग़लत पढ़ रहा हूँ?
    • जिन लोगों का workflow टूटा, उनके लिए यह सीखने का अच्छा मौका है कि open source software और GPL license क्या हैं, और वे किस तरह की guarantees देते हैं
      मुझे नहीं लगता कि लोगों ने खुद वह bug ढूँढ लिया होगा। मेरा अनुमान है कि rsync users में 90% से ज़्यादा अभी भी वह पुराना version चला रहे होंगे जिसमें यह bug नहीं है। मैं भी उन्हीं में से एक हूँ 
      $ uname -a  
Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64

$ port info rsync  
rsync @3.4.1 (net)  
[...]
      अगर इसने ध्यान खींचा है, तो इतना समझने के लिए Steven Pinker होने की ज़रूरत नहीं कि अभी community का काफ़ी हिस्सा भ्रम में है। यह स्वीकार करना आसान नहीं कि LLM इंसानों से बेहतर programming कर सकते हैं
      जिन लोगों ने अपनी identity और self-esteem को programming skill या profession पर टिकाया था, वे अब दोहरे संकट का सामना कर रहे हैं: भविष्य की livelihood/market value को लेकर अनिश्चितता, और identity crisis
      डर, uncertainty, और doubt से निपटना मुश्किल होता है, और LLM कंपनियाँ share price बढ़ाने के लिए इन प्रभावों को बढ़ाने में पूरी कोशिश कर रही हैं। अगर October के बाद market में तेज़ correction आता है, तो शायद यह amplification mechanism भी कमज़ोर पड़े
      दुनिया भर के programmers में बहुत छोटा हिस्सा, यानी जो code को art form की तरह देखते हैं, शायद LLM का उपयोग training और skill improvement के लिए करेंगे

  • यह पोस्ट regression का ज़िक्र करने वाले comments बहुत quote करती है, लेकिन analysis खुद regression नहीं बल्कि सिर्फ bug reports को measure करता है। यह bugs को उस release से नहीं जोड़ती जिसमें वे introduce हुए, बल्कि उस release से जोड़ती है जिसमें वे report हुए, और release severity को commit count से नापती है, जबकि release duration या distribution adoption जैसे साफ़ factors को छोड़ देती है
    मुझे समझ नहीं आता कि यह कैसे तर्कसंगत है

  • निजी तौर पर मैं LLM इस्तेमाल करने वाले projects से बचता हूँ। कोई बहुत ठोस कारण नहीं है; बस यह मुझे बहुत अप्रिय लगता है, कुछ वैसे ही जैसे कोई “kek” या “fren” जैसे शब्द इस्तेमाल करे तो मैं उसे बिना किसी खास वजह के आगे interaction न करने का संकेत मान लेता हूँ
    अभी LLM उपयोग को नापसंद करने के लिए जो explanations दिए जाते हैं, वे मुझे उलटी दिशा में जोड़ी गई rationalization जैसे लगते हैं। Ethics, quality जैसी मौजूदा चिंताएँ सही हैं, लेकिन अगर वे समस्याएँ हल भी हो जाएँ, तो भी मेरे जैसे AI-विरोधी झुकाव वाले लोग अचानक सहज हो जाएँगे, ऐसा नहीं लगता
    इसलिए जिन projects में “AGENTS.md”, Claude co-authored commits वगैरह हों, उनसे मैं किसी ठोस वजह के बिना बचता हूँ। बस यह मुझे अप्रिय लगता है, मेरी पसंद के खिलाफ़ है, और bugs हों या न हों, उससे फ़र्क नहीं पड़ता। शायद और लोग भी ऐसा ही महसूस करते हों

  • लेखक से कहूँ तो, पहली बात, fantasy तो भाषा है। व्यवहार में आप यह कह रहे हैं कि वह बात भाषा तक ही रुकी, या कम से कम आप यह दावा नहीं कर रहे कि उसका कोई nonverbal escalation हुआ
    दूसरी बात, अगर ऐसा दावा करना है तो किसी नज़दीकी statistics expert से पूछना चाहिए कि इसे कैसे support किया जा सकता है। सिर्फ़ यह कि कुछ लोगों ने ऐसी posts कीं, इससे यह दावा सार्थक रूप से support नहीं होता कि वह “typical” है
    मेरी अपनी anecdotal observation, जिसे मैं statistics से support नहीं कर रहा, यह है कि “AI-विरोधी” users आम तौर पर LLM के उन जगहों में घुस आने पर, जहाँ वह मददगार नहीं है, हिंसक होने से ज़्यादा दुखी होते हैं

    • कभी-कभी मैं बहुत लंबे और विस्तार से लिखे गए ऐसे posts देखता हूँ जो LLM विरोधियों के एक हिस्से, आम तौर पर उन लोगों का जो LLM पर भावनात्मक या सामाजिक प्रतिक्रिया देते हैं, खंडन करने की कोशिश करते हैं। ऐसे posts को साफ़-साफ़ समझाना मुश्किल है, लेकिन वे बहुत bad-faith लगते हैं, और जैसे कमज़ोर पर वार किया जा रहा हो
      वे इतने विस्तार में जाते हैं कि भावनात्मक दृष्टिकोण से उनका जवाब देना मुश्किल हो जाता है, और आख़िर में बात कुछ ऐसी लगती है: “समस्या LLM नहीं है; सही इस्तेमाल हो तो यह amplification tool है। AI-विरोधी लोग बस नहीं समझते, और पीछे छूट जाने से डरते हैं”
      मैं rsync maintainers के काम को किसी बहस में घटाकर नहीं दिखाना चाहता, इसलिए मुझे नहीं पता कि मैं इसका कोई प्रभावी counterargument कैसे बनाऊँ
      यहाँ की statistics open source maintenance के नज़रिए से दिलचस्प हो सकती हैं, लेकिन निष्कर्ष अजीब तरह से एक तरफ़ झुका हुआ लगता है, और इससे यह एहसास भी रहता है कि GitHub-style open source वह रूप नहीं है जिसमें मैं योगदान देना चाहता हूँ
      फिर भी, rsync repository में maintainer पर लोगों का झुंड बनाकर टूट पड़ना बिल्कुल अच्छा नहीं था
    • सार्वजनिक हिंसक fantasy को अस्वीकार्य कहना सही है। यह ऐसी चीज़ नहीं है जिसे हम सभ्यता के रूप में लक्ष्य बनाना चाहें। लेकिन लेखक ने उसे “typical” कहा, यह सामान्यीकरण मुझे खटकता है
      anecdotal observation के मामले में, यह comic सही बात कहती है। मुझे ठोस और measurable दावे देखना पसंद है, partly इसलिए कि मुझे numbers पसंद हैं, और partly इसलिए कि online discussions को आख़िरी panel वाली आदर्श दुनिया के थोड़ा और क़रीब लाया जा सके

  • विश्लेषण के लिए धन्यवाद, लेकिन methodology को लेकर भरोसा नहीं बन रहा। मैं ऐसे metrics के बारे में जानना चाहूँगा जैसे हर commit में core code — यानी test या documentation नहीं, बल्कि actual code — की बदली गई lines की संख्या से गुणा किया गया difference unit bug count, और यह विश्लेषण कि release के बाद किसी तय bug count तक पहुँचने में कितना समय लगता है
    हालांकि, इस बार की release को दूसरी releases की तुलना में कहीं ज़्यादा attention मिला, इसलिए bugs ज़्यादा report हुए होने की संभावना भी काफ़ी है। इस वजह से कोई बहुत convincing metric बनाना मुश्किल लगता है। “release के कुछ हफ्तों बाद के हिसाब से क्या यह typical है?” जैसे सवाल भी शायद बहुत उपयोगी न हों