कृपया इस सॉफ़्टवेयर को vibe coding से बर्बाद मत कीजिए
(github.com/RsyncProject)- यह issue Closed स्थिति में समाप्त हुआ, और मुख्य पाठ में पुनरुत्पादन के चरण या सुधार प्रस्ताव नहीं थे, इसलिए जुड़े हुए branch·PR·milestone दिखाई नहीं देते
- मूल आपत्ति यह थी कि rsync में AI-सम्बंधित बदलाव आ रहे हैं और इससे स्थिरता डगमगा रही है; मुख्य पोस्ट बिना टेक्स्ट विवरण के, ज़्यादातर इमेज-केंद्रित थी
- एक उपयोगकर्ता ने बताया कि log2ram, rsync का उपयोग करने के कारण, उसका 3D प्रिंटर 100% CPU पर चलने लगा, और उसने इसे इस तरह बताया कि AI ने यह bug रोबोट तक पहुँचा दिया
- एक अन्य उपयोगकर्ता का कहना था कि rsync एक ऐसा स्थिर टूल था जिसे नई सुविधाओं या rewrite से अधिक security updates और bug fixes की ज़रूरत थी, लेकिन हाल की दो patch releases में ऐसी समस्याएँ आईं जिनमें मौजूदा फीचर्स को बदलना नहीं चाहिए था
- DFIR काम में rsync इस्तेमाल करने वाले एक उपयोगकर्ता ने समझाया कि सिर्फ़ इस तथ्य से कि अपडेट में AI शामिल है, संगठन की नीति के तहत इसे “AI tool” माना जाने लगा है और अब अतिरिक्त समीक्षा चाहिए
- विरोधी पक्ष का कहना था कि issue tracker वायरल शिकायतें दर्ज करने की जगह नहीं है; अगर ठोस bug report या reproduction steps नहीं हैं, तो इसे Discussions में ले जाना चाहिए या फिर fork करना चाहिए
- मुख्य टकराव इस बात पर बढ़ा कि एक पक्ष कहता है, “यह free software है, पसंद नहीं तो fork कर लो,” जबकि दूसरा पक्ष मानता है कि rsync पहले से ही एक core infrastructure tool है, इसलिए downstream pinning·fork पर चर्चा होना ही समस्या का संकेत है
- कुछ उपयोगकर्ताओं ने Rust rewrite या fork का ज़िक्र किया, लेकिन दूसरों ने कहा कि rsync को पसंद किए जाने का कारण उसकी stability और जैसा है वैसा ही काम करना है, और rewrite एक अलग project होना चाहिए
- AI उपयोग के समर्थक पक्ष का कहना था कि AI का हर उल्लेख “vibe slop” नहीं माना जाना चाहिए, और मार्च के बाद के commit log का सीधे audit करके बदलावों के कारण देखने चाहिए
- kaithar ने बताया कि हाल के काम में uninitialized memory read, wire protocol over/underflow, 32-bit timestamp, C standard से जुड़ी समायोजन जैसी bug·security flaw fixes और hardening शामिल हैं
- उसी टिप्पणी में यह भी कहा गया कि अगर 3.4.1 जैसे पुराने release पर pinned रहा जाए, तो कई CVE वाले version पर अटके रह सकते हैं, और regressions उन edge cases में हो सकते हैं जिन्हें tests पकड़ नहीं पाए
- निष्कर्षतः, यह issue किसी ठोस bug fix तक नहीं पहुँच सका और rsync जैसे लंबे समय से स्थिर infrastructure में AI-assisted development की trust·audit·governance को कैसे संभालना चाहिए, इस बहस के रूप में रह गया
1 टिप्पणियां
Hacker News की राय
यह भीड़ बनाकर चढ़ दौड़ने वाला रवैया सच में अजीब है, और कुछ लोग तो जैसे अविवेकपूर्ण तरीके से व्यवहार कर रहे हैं। इस लड़ाई में “जीतना” चाहने की प्रेरणा कुछ हद तक समझ में आती है, लेकिन यह तरीका बिल्कुल भी सही नहीं है और बस लोगों को कट्टरपंथी जैसा दिखाता है
issue page पर regression खोजकर 17 नतीजों को देखने में 5 मिनट ही लगते हैं। GitHub से पहले इस्तेमाल किए गए tracker में इससे भी ज़्यादा हो सकते हैं
यह व्यवहार बेहद मूर्खतापूर्ण है, और लगता है लोग AI से नफरत को सही ठहराने के लिए हर संभव चीज़ पकड़ रहे हैं। जैसे वे भूल गए हों कि AI से पहले भी लोग गलतियाँ करते थे
अगर यह सबूत है कि AI ने rsync के unresolved issues को अर्थपूर्ण रूप से बढ़ाया है, तो अच्छा होगा अगर वह दिखाया जाए। तब मैं खुशी से अपनी राय बदल लूँगा
यह इस commit का सीधा कारण न भी हो, तो भी यह दूसरी जमा हुई समस्याओं पर प्रतिक्रिया हो सकती है, और उसे अपने आप में ध्यान में रखा जाना चाहिए
लगता है लोग “AI [cultural metaphor] के बाद से सबसे बेहतरीन चीज़ है” जैसी बातों को ज़बरदस्ती निगलने से थक चुके हैं, इसलिए वे विरोध करने के लिए कोई भी तिनका पकड़ने की कोशिश कर रहे हैं, और मेरे हिसाब से यह काफी सामान्य प्रतिक्रिया है
अगर कोई भी यह न कहे कि users AI पर भरोसा नहीं करते, तो maintainer को यह पता कैसे चलेगा? rsync बहुत स्थिर रहा है। क्या लोगों को चुपचाप Openrsync पर चले जाना चाहिए और कुछ भी नहीं कहना चाहिए?
उनमें से एक लिंक नीचे की distributions में reported bugs के बड़े संग्रह तक ले जाता है (https://github.com/void-linux/void-packages/issues/60825)
vibecoding software की reputation को देखते हुए गुस्सा बहुत तर्कसंगत है। यहाँ तक कि जिन experts को लोग पसंद करते हैं, वे भी कहते हैं, “bugs से बचना है तो इसे बहुत खास तरीके से handle करना होगा, और शायद इसे सिर्फ domain को sketch करने वाले 0-version के लिए इस्तेमाल करना बेहतर है”
लेकिन यहाँ industry-standard backup core tool को “और features जोड़ने” की maintainer की मंशा के तहत, साफ तौर पर असुरक्षित तरीके से users के पैरों तले से खींच लिया जा रहा है
Timeshift thread में यह भी है कि “rsync update के बाद daily backup के दौरान CPU usage इतना बढ़ गया कि timeshift को हमेशा के लिए चलता रहने से रोकना पड़ा”
दूसरे शब्दों में, लोग इसलिए निराश और गुस्से में हैं क्योंकि जिस tool पर उन्होंने backup और data सौंपा था, वही भारी संख्या में regressions और नए bugs के साथ पूरे backup infrastructure को तोड़ रहा है, और इसकी वजह यह है कि core developer vibecoding कर रहा है
Simon Wilson जैसे vibecoding experts भी साफ कहते हैं कि यह सिर्फ “जब tool को एक खास तरीके से इस्तेमाल किया जाए” तभी संभव है, तो या तो यह maintainer ऐसा नहीं कर रहा, या फिर वह बात सच नहीं है
अगर उस thread को सच में पढ़ा जाए और सिर्फ दोनों लोगों की बहस वाले हिस्सों को न देखा जाए, तो कई reports हैं कि industry और government environments के users को इस software को update करने के लिए पूरी प्रक्रिया फिर से करनी पड़ रही है। क्योंकि software तुरंत अविश्वसनीय हो गया है, users को सीधा नुकसान पहुँचा रहा है, और इस software के होने का मकसद ही कमजोर कर रहा है
अगर मैं भी इस software पर 500GB से ज़्यादा backup छोड़कर बैठा होता तो शायद गुस्से में होता, और यह भी सोचता कि अगर कोई company नियमित रूप से backups test नहीं करती, तो 10 million dollar के data loss का सामना होने से पहले और कितनी समस्याएँ इसमें घुस चुकी होंगी
सच में समझ नहीं आता
एक मज़बूत software है जिसे अनगिनत लोग और services इस्तेमाल करते हैं। वह अच्छी तरह काम करता है, अपना काम करता है, और कभी-कभी बस छोटे bug-fix updates की ज़रूरत होती है
यहाँ AI की ज़रूरत ही क्यों है?
और यह भी समझ नहीं आता कि लोग “fork करके पुराना version इस्तेमाल करो” क्यों कह रहे हैं। उल्टा होना चाहिए। younamethetool-ai जैसा कोई parallel fork बनाओ और original को मत छेड़ो
क्या अब मुझे अपने पूरे system tools को fork करके maintain करना पड़ेगा?
बिना सबूत issue tracker में यह शिकायत करना कि AI software को बर्बाद कर रहा है, Hacker News में अक्सर चर्चा होने वाली open source contributors की harassment का एक रूप है [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“Issue tracker वायरल social media posts बटोरने की जगह नहीं है। कोई actionable bug report करो या खुद fork कर लो। developers की पसंद पर भड़ास निकालना productive नहीं है”
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“@II-Paulus-II बस करो। तुम्हें कुछ नहीं पता। तुमने हाथ से 0 features ship किए हैं। तुम्हारे code पर कोई निर्भर नहीं है। तुम बस ‘AI ने यह लिखा’ कहकर उंगली उठाने वाले व्यक्ति हो, जो toy projects और scripts को शुरू से लिखने की कथित नैतिक श्रेष्ठता के पीछे छिपा है। तुम न ship कर सकते हो, न adapt कर सकते हो, और यह भी नहीं समझते कि issue tracker इस तरह के रवैये की जगह नहीं है”
[1] https://news.ycombinator.com/item?id=43077833
मैंने विस्तार से नहीं पढ़ा, लेकिन “इस release में 6 CVE ठीक किए गए। इन छहों को VulnCheck ने CNA के रूप में assign किया। सभी मामलों में प्रभावित versions 3.4.2 या उससे नीचे हैं” यह पंक्ति “क्यों?” का काफ़ी मज़बूत जवाब लगती है
https://download.samba.org/pub/rsync/NEWS#3.4.3
पहली प्रतिक्रिया स्वाभाविक रूप से यही होगी कि उनसे कहो कहीं और जाएँ
अगर “जनता” project अपने हाथ में लेकर उसे maintain करना चाहती है, तो वह fork कर सकती है, लेकिन यह बड़ा thankless काम है
और फिर, open source project में कौन से tools इस्तेमाल करने हैं, यह बदलने के लिए किसी वजह की ज़रूरत भी नहीं होती, और न ही वे वह वजह आपको बताने के कर्ज़दार हैं
जिस तरह से वह issue खोला गया, वह सच में बेहद अप्रिय था, लेकिन maintainers ने rsync पर AI छोड़ दिया हो, यह बात समझ नहीं आती। ऐसा क्यों किया होगा? जब पहले से प्रतिष्ठा और भरोसा मिल चुका हो, किसी खास niche में नेतृत्व हो, market pressure से भी काफी हद तक बाहर हों, लोग उस tool को पसंद करते हों, और वह ठीक वही काम बहुत अच्छे से करता हो जो उसे करना चाहिए, तो फिर अपेक्षाकृत experimental कबाड़ आज़माने की क्या ज़रूरत है?
यह कुछ वैसा लगता है जैसे Matrix में वह छोटा-सा monologue, जिसमें कहा जाता है कि आदिम मानव मस्तिष्क स्वर्ग को स्वीकार नहीं कर पाता। आपने एक लगभग परफेक्ट tool बनाया, जीत हासिल की, अपने niche में लगभग अपरिवर्तनीय बन गए, भरोसेमंद रहे, और रूपक में कहें तो घर-घर का नाम बन गए। ऐसी चीज़ के साथ जुआ खेलना या उसे छेड़ना किसी के लिए भी समझ में नहीं आता, और सच में उलझन पैदा करता है
फिर भी, आधिकारिक issue tracker में इस तरह व्यवहार करना अब भी बहुत अप्रिय है। रवैया भी खराब है, और इसमें सद्भावना भी नहीं दिखती
लेकिन अब AI कहीं भी शुद्ध रूप से सकारात्मक नहीं दिखता, और generative AI के इस्तेमाल पर यह backlash मुझे जनता की ओर से एक अच्छी course correction लगता है
LLM के तुरंत मिलने वाले संतोष पर कुछ लेख हैं, और जितना ज़्यादा मैं इस tool का इस्तेमाल करने वाले लोगों से बातचीत करता हूँ, उतना लगता है कि यह सच में मूल समस्या हो सकती है। हमारी जीवविज्ञान इसको संभाल नहीं पा रही
मैं मूलतः बहुत होशियार लोगों को बेहद मूर्खतापूर्ण काम करते देख रहा हूँ, सिर्फ इसलिए कि slot machine ने उन्हें ऐसा बताया, और फिर जब slot machine फेल हो जाती है तो वे असहाय हो जाने की training भी ले चुके होते हैं
मुझे ऐसे व्यक्ति की तरह पेश किया जाता है जो प्रगति देख नहीं सकता, जबकि मैं सहकर्मियों को बेमतलब के benchmark बनाते और AI से बनी सुंदर graphs चिपकाते देखता हूँ
फिर मुझे चुनना पड़ता है कि या तो मुस्कुराकर इसे अच्छा काम बताऊँ, या उन्हें डाँटूँ कि यह benchmark उस हिस्से को test कर रहा है जो constant के रूप में hardcode है, इसलिए यह निरर्थक है। दोनों ही स्थितियों में मैं उन्हें समझदार सहकर्मी नहीं, बल्कि 7 साल के बच्चे की तरह treat कर रहा होता हूँ
rsync maintainers पूरी तरह आदर्श और जिम्मेदार maintainers हैं या अक्षम बच्चों जैसे, वे इस पैमाने पर कहीं भी हों, सच यह है कि हम जानते नहीं
लेकिन थोड़ा विषयांतर होने का जोखिम उठाते हुए, मेरे मन में यह बात आती है। Rsync जैसे mature software को changed lines of code जैसी activity की ज़रूरत नहीं होती, इस बिंदु को एक तरफ रख दें, और मान लें कि maintainers project को सबसे अच्छे इरादों से संभाल रहे हैं
अगर open source में यह हो रहा है, तो closed-source software quality की हालत कैसी होगी?
AI usage, यानी prompts या input की मात्रा, कर्मचारी मूल्यांकन में success metric की तरह शामिल की जा रही है, और लोग AI-जनित mass layoffs के खतरे से panic में हैं
चक्कर-सा आ जाता है
https://github.com/RsyncProject/rsync/issues/929#issuecommen... से बस इतना दिखता है कि यह अब पुराने Darwin और Linux < 5.6 पर काम नहीं करता, और Linux 5.6 एक ऐसा version है जिसे 2020 में ही deprecated किया जाना था। इसके अलावा कुछ और bugs भी हैं
आप यह उम्मीद नहीं कर सकते कि maintainer पुराने systems को support भी करे और हर बदलाव का असर पूरी तरह जानता भी हो। चाहे AI से किया गया हो या हाथ से, बात एक ही है
जानकारी के लिए, bug खुद Claude Code द्वारा किए गए 30656c5e commit में आया था, और लगता है कि साथ में किसी अनुपयुक्त व्यक्ति का review और testing भी था
https://github.com/RsyncProject/rsync/commit/30656c5e
किसी ने AI का इस्तेमाल करके हालिया rsync का bisect किया: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
कोई और ज़्यादा Claude Code के साथ इसे ठीक करने की कोशिश कर रहा है: https://github.com/RsyncProject/rsync/pull/930
संबंधित ticket: https://github.com/RsyncProject/rsync/issues/915
मेरी सलाह होगी कि 30656c5e से ठीक पहले वाले commit में और regression tests जोड़ें, functionality बनाए रखें, और उसके बाद आगे rebase करें
यह कोई “अनचाहा नया feature” नहीं था। Tridge bug report से जुड़े security issue को ठीक कर रहे थे। यह समझ में आता है। हम सब security issues से पिट रहे हैं। इन्हें ठीक करना वैकल्पिक नहीं है
मैं यह नहीं कहूँगा कि 10 साल पुराने software में वापस जाकर इसे संभालना मज़ेदार होता है, इसलिए यह प्रभावशाली है कि tridge कोशिश कर रहे हैं
इस गड़बड़ी से निकलने के लिए मैं भी LLM इस्तेमाल करने का दोषी हूँ। tridge क्या कर रहे हैं, यह मुझे नहीं पता, लेकिन मैं LLM के उगले गए code की हर पंक्ति जांचता हूँ। फिर भी bug अंदर घुस आने का खतरा साफ़ तौर पर बड़ा है
मैंने उस code को लंबे समय से नहीं देखा, और मैं पहले जितना उससे परिचित भी नहीं हूँ। इसलिए bugs का अंदर आ जाना कोई बहुत चौंकाने वाली बात नहीं है
इस पूरे विस्फोट में अजीब बात यह है कि मूल शिकायत करने वाला व्यक्ति अपने backup system को लेकर बहुत रक्षात्मक दिखता है, लेकिन tridge का commit सिर्फ 2 हफ्ते पहले का था। tridge बेहतरीन हैं, यह तो पता है, लेकिन ऐसी चीज़ को स्वाभाविक रूप से alpha software की तरह treat नहीं करना चाहिए था? वह सोच क्या रहा था? शायद उसे भी reliable systems बनाना थोड़ा सीखना चाहिए
कुछ साल पहले, इस तरह की पोस्ट के Hacker News मेन पेज पर आने की संभावना लगभग शून्य के करीब होती। बात सही है या गलत, उससे अलग, क्योंकि यहाँ ऐसे आम लोग भरे नहीं थे जो यह नहीं समझते कि किस तरह का व्यवहार अस्वीकार्य है
यहाँ बात इश्यू की हिंसक भाषा की हो रही है। लेकिन अब हम ऐसे लोगों से घिरे हुए हैं जो सबसे स्पष्ट बात भी अलग नहीं कर पाते
maintainers को यह बताने का यह तरीका नहीं है कि आप project की दिशा से सहमत नहीं हैं। यह issue पूरी तरह बेकार है। इससे बेहतर तो “vibe coded की वजह से टूटी” bug report होती
यही बात असल मुद्दे पर चोट करती है। किसी भी bug report ने कथित --compare-dest= regression को document करने की कोशिश तक नहीं की। Ctrl-F करके भी “compare-dest” का दोबारा ज़िक्र करने वाला कोई नहीं दिखा
बेकार AI-गुस्से वाले comments लिखने वाले लोग Opus 4.8 से rsync 3.4.3 और 3.4.1 चलवाकर regression को अच्छी तरह document करवा सकते थे, और टूटा commit
git bisectसे ढूँढकर 1000 गुना ज़्यादा professional और उपयोगी bug report बना सकते थेअगर समाज चाहता है कि इंसानी काम को AI के काम से ज़्यादा मूल्य मिले, तो इंसानों के लिए बेहतर होगा कि वे वे मूर्खतापूर्ण काम न करें जो केवल इंसान ही कर सकते हैं
क्या यह मेन पेज पर इसलिए नहीं आया होगा कि दूसरे लोग भी उस software के बारे में ऐसा ही महसूस करते हैं, जिसे वे हर दिन महत्वपूर्ण काम में इस्तेमाल करते हैं?
GitHub issues का काम नीरस होता है, और साफ है कि इसके लिए शायद ही कभी धन्यवाद मिलता है, लेकिन हक़ीक़त यह है कि rsync कई संवेदनशील pipelines की आधारशिला है
अगर आपको सचमुच लगता है कि यह विषय से बाहर है, तो शिष्ट प्रतिक्रिया issue को बंद करना है
अभी भी मुझे समझ नहीं आता कि क्या इतना स्पष्ट है। मेरे लिए “रुको। तुम्हें कुछ नहीं पता। तुमने अपने हाथ से 0 features deploy किए हैं। तुम्हारे code पर कोई निर्भर नहीं रहा” यह “please do not vibe fuckup this software” से कहीं अधिक हिंसक लगता है
उस issue thread में क्या किसी ने सचमुच issue को समझाया भी? जैसे reproduction steps, expected behavior और actual behavior
यह issue tracker में डाला गया था। “commit message में Claude का ज़िक्र है, और Bluesky पर किसी व्यक्ति को लगता है कि उसे जो अनिश्चित समस्या हुई वह उन commits से जुड़ी है” — यह कोई actionable issue नहीं है
बाकी सारी बहस को अलग रख दें, तो अगर यह मेरा project होता, मैं इसे “reproduction जानकारी की कमी” कहकर बंद और lock कर देता। AI, forks और गुस्सा निकालने पर सामान्य चर्चा के लिए बेहतर जगहें हैं
Linux < 5.6 इस्तेमाल करने वाले GitHub पर build नहीं कर सकते। मुझे यह काफ़ी मामूली regression लगता है। 5.6 की maintained versions, मुख्यतः extended security versions इस्तेमाल करने वालों के लिए distro maintainers build failure पकड़कर समय पर ठीक कर सकते हैं
path traversal attacks के खिलाफ hardening, chroot के बिना native rsync protocol इस्तेमाल करने वालों के लिए failures पैदा करती है। विडंबना यह है कि
chroot = noकी मज़बूती से सिफारिश नहीं की जातीहो सकता है आप automated तरीके से native rsync का इस्तेमाल न करने, बल्कि बिल्कुल भी न करने की सलाह देना चाहें। वह CVE जिसे यह commit ठीक करता है, ठीक इसी use case पर लागू होता है
https://www.cve.org/CVERecord?id=CVE-2026-29518
daemon + no chroot चाहिए। “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
इसलिए प्रभावित workflow सबसे कम सुरक्षित workflow है, और लोग मूलतः version rollback करने की सलाह दे रहे हैं
और अगर regression tests को यह पकड़ना चाहिए था, तो वह test पहले से लिखा हुआ होना चाहिए था
कुछ लोग शायद FOSS projects के बारे में भूल गए हैं
“15. वारंटी का अस्वीकरण
लागू कानून जितनी अनुमति देता है, इस program के लिए कोई वारंटी नहीं है। जब तक लिखित रूप में अन्यथा न कहा गया हो, copyright holders और/या अन्य पक्ष इस program को ‘जैसा है’ आधार पर देते हैं, और किसी भी प्रकार की, चाहे स्पष्ट हो या निहित, कोई वारंटी नहीं देते। इसमें merchantability या किसी विशेष उद्देश्य के लिए उपयुक्तता की निहित वारंटी भी शामिल है, पर इन्हीं तक सीमित नहीं। program की गुणवत्ता और performance का पूरा जोखिम आपके ऊपर है। अगर program में दोष निकलता है, तो आवश्यक servicing, repair या correction की पूरी लागत आप वहन करेंगे”
मैं project द्वारा लिए गए हर निर्णय, commit, patch, marketing, और अन्य फैसलों के बारे में शिकायत करने, बड़बड़ाने, आलोचना करने, गुस्सा होने, या किसी भी तरह की टिप्पणी करने का अधिकार सुरक्षित रखता हूँ। ऐसी टिप्पणियाँ किसी भी उद्देश्य के लिए उपयुक्तता की कोई वारंटी नहीं देतीं, और न ही इस बात की कोई निहित वारंटी कि वे सही, उपयोगी, या विनम्र होंगी। यदि मेरी टिप्पणियाँ अवांछित साबित हों, तो आपको उन्हें ऐसी जगह ठूँस देने का अधिकार है जहाँ धूप न पहुँचती हो
आप चाहें तो इस disclaimer को तब दिखा सकते हैं जब आपको अवांछित FOSS project criticism का सामना करना पड़े
मुझे समझ नहीं आता कि लोग यह क्यों नहीं समझते कि “वे जो चाहें कर सकते हैं” वाला रवैया दो-तरफ़ा होता है। users भी जो चाहें कर सकते हैं। पसंद न आए तो उसे व्यक्त कर सकते हैं
issue comments में से एक ने यह कहा
“अगर आप किसी बेघर व्यक्ति को मुफ्त सूप देते हैं, तो इसका मतलब यह नहीं कि आप उसमें पेशाब कर सकते हैं”
वह issue पहले ही बुरी तरह बिगड़ चुका था, और आपका तर्क भी वहाँ पहले ही आ चुका था। सब लोग इसे बेहतर ढंग से संभाल सकते थे, लेकिन कानूनी वाक्यांशों को आँख मूँदकर उद्धृत करने से न तो यह सुलझेगा, न बेहतर होगा
मैं इस विषय पर HN की तीसरी पोस्ट पढ़ रहा हूँ। हर बार वही ट्वीट, या Mastodon/Bluesky जैसी जगहों पर उसे जो भी कहा जाता है, वही पोस्ट बार-बार दोहराई जाती है। क्या किसी ने सच में समस्या को debug किया है?
वजह ढीले-ढाले तरीके से जनरेट किया गया code था, या फिर किसी असली security fix ने गलती से इसे तोड़ दिया? यानी ऐसे तरीके से, जैसा इंसान भी कर सकता था
यह anti-AI hysteria एक典型 का moral panic है
हर moral panic की तरह, 1 सच है या नहीं, यह पूरी तरह गौण है। असली बात 2 से लगभग यौनिक मुक्ति जैसा सुख पाना है
इस मामले में, मुझे पता है कि rsync में AI-generated code है। जैसे अब तक ज़्यादातर उपयोगी software में होता है। लेकिन online हर दिन witch hunt दिखती है, और हर witch hunt की तरह आरोप सच है या नहीं, यह ज़्यादा मायने नहीं रखता। hysteria खुद ही मकसद है
AI के आसपास जो गुस्सा दिख रहा है, वह इसलिए नहीं है कि आम लोग गलत जानकारी में हैं या messaging गलत है, बल्कि भौतिक वास्तविकता का सवाल है
इसी एक चीज़ को mass layoff के बहाने के रूप में इस्तेमाल किया जा रहा है, tech CEO लगभग रोज़ कह रहे हैं कि वे बाकी सबकी jobs भी छीन लेंगे, और बड़े cloud कंपनियाँ कमरे की सारी oxygen खींच रही हैं। game industry भी इससे सुरक्षित नहीं थी
इसे “बस एक सामान्य moral panic” कहना वैसा है जैसे समुद्र किस दिशा में पीछे हट रहा है यह देखकर भी उसी दिशा में सीधा दौड़ पड़ना
और आगे पढ़ने पर आप खुद भी “witch hunt”, “hysteria” जैसी भावनात्मक भाषा इस्तेमाल कर रहे हैं
क्या यह सचमुच witch hunt है? और क्या आप जान सकते हैं कि इंटरनेट के उस पार के लोग किसी यौनिक मुक्ति जैसी भावना के करीब पहुँच रहे हैं?
क्या आप भी दूसरों की भावनात्मक भाषा और ढीली सोच पर उसी तरह प्रतिक्रिया नहीं दे रहे?
GitHub issue कब से दूसरी platforms की posts के screenshot डालने की जगह बन गया?
मैंने ऐसा व्यवहार सिर्फ़ meme या मनोरंजन वाली सामग्री पोस्ट करने की जगहों पर देखा है
यहाँ कोई actionable bug report या feature request नहीं है। कोई text version भी नहीं है। original post का link तक नहीं है
क्या इसे पोस्ट करने वाले ने GitHub Issues को अपना निजी Twitter account समझ लिया है?