Vibecoding का खुलासा करने पर Emacs पैच ठुकराया गया

 (xlii.space)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS के लिए Emacs performance improvements हेतु बनाया गया एक छोटा patch emacs-devel में जमा किया गया, लेकिन GNU की उस नीति के कारण स्वीकार नहीं हुआ जो LLM-assisted work को नहीं मानती
  • योगदानकर्ता ने खुलासा किया कि GLM 5.2 ने issue खोजे और draft तैयार किया, लेकिन accuracy, impact analysis, fixes, manual testing और व्यक्तिगत जिम्मेदारी खुद संभाली
  • ठुकराया गया patch बहुत सीमित दायरे का 92-line patch था, और LLM उपयोग को छिपाया भी जा सकता था, इसलिए उनका तर्क है कि यह नीति उपयोग से अधिक ईमानदार खुलासे को दंडित करती है
  • GNU की चिंता LLM outputs की openness और कानूनी उपयोग-योग्यता के अधिक करीब थी, लेकिन वे open-weight models और वास्तविक industry use cases के आधार पर इससे असहमत हैं
  • उनका कहना है कि वे अब Emacs पर काम नहीं करेंगे, और हार्ड ड्राइव में मौजूद लगभग 40 performance-improvement patches में से हाल में सत्यापित कुछ ही सार्वजनिक किए हैं

macOS Emacs performance improvement work

  • Przemysław Alexander Kamiński ने कई महीनों तक macOS पर Emacs performance सुधारने पर काम किया और instrumentation hookups तथा benchmarks लिखने में समय लगाया
  • उन्होंने कई LLMs को Emacs codebase देकर specific issues खोजने को कहा, लेकिन कुल मिलाकर नतीजे अच्छे नहीं रहे
    • patches का विश्लेषण करने पर अक्सर impact छोटा निकलता था या समस्या को गलत समझा गया होता था
  • उस समय performance bottlenecks के बारे में उनका आकलन यह था
    • macOS पर मुख्य समस्या rendering issues और तेज allocation/deallocation से होने वाली memory thrashing है
    • macOS का system malloc तरीका memory compression की कमी के कारण virtual memory inflation और cache locality loss पैदा करता है
    • Emacs core में भी performance issues बाकी हैं
    • regexp processing कई जगह उपयोग होती है, इसलिए इसमें सुधार पूरे performance पर असर डाल सकता है

GLM 5.2 से मिला patch और submission process

  • उन्हें एक दोस्त से z.ai Max plan मिला, जिससे वे GLM 5.2 इस्तेमाल कर सके, और उनका आकलन है कि यह model code optimization में काफी सक्षम है
  • पहले से जमा अपने ज्ञान के आधार पर उन्होंने Emacs से जुड़े specific सवाल पूछे और GLM 5.2 को issue exploration और analysis का काम दिया
  • लगभग 3 घंटे बाद उन्हें कुछ reports मिलीं, और suggestions तथा code की समीक्षा करने के बाद उन्होंने हर item का impact test किया और benchmarks चलाए
  • patch submission के लिए चीजों को व्यवस्थित करने में समय लगता है, इसलिए उन्होंने सबसे promising item चुना और लेख लिखने से दो दिन पहले उसे emacs-devel mailing list पर भेजा
  • अगले दिन उन्हें पता चला कि GNU में LLM-assisted work स्वीकार न करने की नीति है, इसलिए patch नहीं लिया जाएगा

submission mail में बताई गई LLM उपयोग की सीमा

  • mailing list पर patch भेजते समय उन्होंने LLM उपयोग और अपनी review scope दोनों को स्पष्ट किया
    • issue discovery और patch draft तैयार करने का काम GLM 5.2 ने किया, और उन्होंने बताया कि GLM 5.2 चीन का एक open-weight model है
    • issue report की accuracy और impact का विश्लेषण उन्होंने स्वयं किया
    • patch की समीक्षा और संशोधन उन्होंने किए
    • patch का manual testing उन्होंने किया
    • कानूनी उद्देश्यों के लिए उन्होंने submission की authorship घोषित की और कहा कि वे यह दावा करने के लिए तैयार हैं कि उनका योगदान LLM से बड़ा है
    • उन्होंने submission के लिए पूरी व्यक्तिगत जिम्मेदारी लेने की घोषणा की
  • submission implementation scope में बहुत सीमित और आकार में छोटा था
    • सार्वजनिक किया गया patch 92 lines का है, और comments में इसके होने का कारण शामिल है
  • उनका मानना है कि इस patch को “slop” नहीं कहा जा सकता, हालांकि वे जोड़ते हैं कि हर कोई अपनी राय बना सकता है

GNU policy पर आपत्ति

  • वे GNU की policy का सम्मान करते हैं, लेकिन उससे सहमत नहीं हैं, और उनके अनुसार policy के लिए पर्याप्त आधार नहीं है
  • वे LLM उपयोग को छिपा सकते थे, लेकिन उन्होंने इसे साफ-साफ बताया, और उनके अनुसार इसी वजह से submission को नुकसान हुआ
    • इसलिए वे आलोचना करते हैं कि यह policy LLM उपयोग से अधिक ईमानदार खुलासे को दंडित करती है
    • उनका कहना है कि वे LLM पर बिल्कुल भरोसा नहीं करते, इसलिए LLM-assisted work को कम नहीं बल्कि अधिक review और scrutiny की जरूरत है
  • policy का पूरा context आंतरिक GNU lists में चर्चा होने के कारण स्पष्ट नहीं है, और वे कहते हैं कि पिछली बातचीतों में उन्हें जो संदेह दिखे वे इस बात के करीब थे कि LLM contribution पर्याप्त रूप से open है या कानूनी रूप से उपयोग योग्य है
  • open-weight models की openness पर सवाल उठाने वाले तर्क से वे सहमत नहीं हैं
    • उदाहरण के लिए, उनका कहना है कि अगर local environment में Qwen 3.6 का उपयोग ठीक माना जाए लेकिन OpenRouter के जरिए उपयोग गलत हो, तो ऐसा भेद बेतुका है
    • उनका कहना है कि GLM 5.2 एक open-weight model है, और अगर आपके पास 256GB RAM और 24GB VRAM है, तो उसे local में चलाकर “SaaS बंद है” वाले तर्क से बचा जा सकता है
    • वे प्रतिप्रश्न करते हैं कि इंटरनेट पर भी बहुत-सा non-free content है, तो क्या उसी तर्क से submissions बनाते समय internet access भी प्रतिबंधित कर देना चाहिए?
  • वे कानूनी चिंताओं से भी सहमत नहीं हैं
    • उनका कहना है कि game companies IP और LLM को लेकर अधिक संवेदनशील हैं, फिर भी LLM उपयोग दिखाई देता है; ChatGPT के 1 अरब active users हैं; और लाखों से लेकर करोड़ों के बीच organizations रोजाना LLM output का उपयोग करती हैं
    • वे स्पष्ट करते हैं कि वे अमेरिकी वकील नहीं हैं, लेकिन उनकी समझ में copyright registration की समस्या उस पक्ष से जुड़ी है जो copyright notice लगाता है
    • GNU की इस प्रवृत्ति से वे सहमत नहीं हैं कि अपने वकीलों और अपने मत को सबसे अधिक वजन दिया जाए

Emacs work बंद करना और सार्वजनिक किए गए patches

  • उनका कहना है कि GNU को अपने निर्णय लेने की स्वतंत्रता है और उन्हें उसकी आलोचना करने की स्वतंत्रता है
  • वे आलोचना करते हैं कि policy पर आंतरिक चर्चा करते हुए उपयोगकर्ताओं के प्रति जो पारदर्शिता नहीं दिखाई गई, वह उतनी ही खुली है जितनी Meta का Facebook की दिशा पर आंतरिक फैसला लेना
  • नतीजतन, उन्होंने कहा कि वे अब Emacs work नहीं करेंगे
    • उनका कहना है कि उन्हें स्वैच्छिक काम में यह सुनना पसंद नहीं कि वे “गलत जगह मेहनत कर रहे हैं”
  • उनकी हार्ड ड्राइव में लगभग 40 performance-improvement patches हैं; कुछ एक-दूसरे से overlap करते हैं और कुछ का वास्तविक impact अभी साबित नहीं हुआ है
  • हाल में सत्यापित किए गए, काम करने वाले और सार्थक असर दिखाने वाले कुछ patches ही उन्होंने public किए हैं, और उनका कहना है कि ये patches वास्तव में फर्क पैदा करते हैं

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

1 टिप्पणियां

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

  • लगता है लेखक ने "open weight" में open का मतलब गलत समझ लिया है
    सिर्फ इसलिए कि अंतिम matrix chunks सार्वजनिक हैं और उन्हें कुछ हद तक fine-tune किया जा सकता है, इसका यह मतलब नहीं कि उन्हें बनाने में इस्तेमाल की गई training material भी open source थी। OSI seems to agree भी लगभग ऐसा ही मानता दिखता है, और अगर ऐसा है, तो copyright समस्या का बिल्कुल समाधान नहीं हुआ है
    बिना किसी प्रतिफल के सद्भावना से योगदान देना चाहने वाले व्यक्ति के प्रति सहानुभूति है, लेकिन GNU ने नियम साफ़-साफ़ लिख रखे हैं, और वहाँ जाकर अगर आप कहें "मैंने बस थोड़ा-सा उल्लंघन किया, और यह patch है", तो उसके reject होने में कोई हैरानी नहीं होनी चाहिए। reject होने की वजह ईमानदारी नहीं थी, बल्कि यह थी कि उसने वही काम किया जिसे साफ़ तौर पर मना किया गया था

    • तो क्या non-disclosure agreement के तहत मिलने वाली datasheet के आधार पर लिखे गए drivers भी सब free software नहीं माने जाएंगे? और अगर किसी manufacturer के कर्मचारी ने internal docs और अपनी विशेषज्ञ जानकारी का इस्तेमाल करके driver लिखा हो, तो उसे कैसे देखा जाना चाहिए?
    • training material क्यों प्रासंगिक है, यह मुझे साफ़ नहीं है। अगर output को स्वतंत्र रूप से इस्तेमाल, redistribute और modify किया जा सकता है, तो मैं उसे काफ़ी हद तक open मानूँगा

  • उम्मीद है लेखक आज यह सीखेगा कि अरबों लोग भी गलत हो सकते हैं। Normalization of deviance विचलन को सही नहीं ठहराता, बल्कि यह समझाता है कि वह विचलन कैसे फैलता रहता है
    chatbot psychosis में दिखने वाले पैटर्नों में से एक यह है कि जो इंसान असहमत हों या अलग राय दें, उन्हें शत्रु की तरह देखा जाता है। chatbot ने जिन narremes पर training ली है, उनमें यह नज़रिया शामिल है कि user ही protagonist है, उसके ऊपर-पीछे कैमरा है, और उसकी कहानी एक पढ़ने योग्य personal narrative है। chatbot की post-processed preferred narrative सीधे user को प्रभावित करती है और उसके protagonist-बोध को मज़बूत करती है, और जब user काफ़ी "ionized" हो जाता है, तो वह neutral रुख भी स्वीकार नहीं कर पाता
    इस मामले में मैं सुझाव दूँगा कि लेखक the original discussion पढ़े, जिसे उसने न link किया और न quote किया। Emacs community ने लेखक के साथ विनम्र, ग्रहणशील, प्रश्न पूछने वाली, रुचि दिखाने वाली और स्वागतपूर्ण भूमिका निभाई। patch को reject करते समय भी उन्होंने लेखक को दोष देने के बजाय GNU policy पर ध्यान रखते हुए नरमी से बात की

    • असली discussion का link लेख में न डालना, ईमानदारी से कहूँ तो, बहुत बड़ा red flag है। यह सोचकर हैरानी होती है कि मैंने इसे पहले नोटिस नहीं किया
    • narremes वाला Wikipedia लेख सिर्फ एक paragraph का है और उस पर [incomprehensible] टैग लगा है
      फिर भी, context से इसका मतलब समझ में आ जाता है, और यहाँ यह उपयोगी और उपयुक्त अवधारणा लगती है

  • GNU Project को सिर्फ अमेरिकी copyright मुद्दों की नहीं, बल्कि दुनिया भर की copyright चिंताओं की परवाह करनी होती है। अमेरिकी क़ानून भी अभी पूरी तरह settled नहीं है
    GNU यह सुनिश्चित करना चाहता है कि महत्वपूर्ण contributions पर उसका copyright 100% उसके पास हो। यहाँ लेखक की legal interpretation मायने नहीं रखती; GNU Project सिर्फ सुरक्षित रास्ता अपना रहा है। LLM को लेकर उसकी शायद दूसरी चिंताएँ भी होंगी, जिन पर अभी बात ही नहीं हुई है

    • ईमानदारी से कहें तो मौजूदा case law के हिसाब से लेखक की अमेरिकी क़ानून की समझ भी गलत है[1]। मौजूदा precedents के अनुसार LLM-generated code copyright protection के योग्य नहीं होता, इसलिए उस पर license भी नहीं लगाया जा सकता और वह अपने-आप public domain में चला जाता है
      ऊपर से अगर किसी repository में LLM-generated code हो और उसे स्पष्ट रूप से अलग करके चिह्नित न किया गया हो, तो पूरी repository को copyright protection और licensing—दोनों के लिए अयोग्य माना जा सकता है
      दूसरे शब्दों में, अगर लेखक झूठ बोलकर code commit करवा देता, तो वह पूरे Emacs codebase की license validity को जोखिम में डाल सकता था
      यह सब उस लगभग भ्रमपूर्ण और अहंकारी रवैये से अलग बात है जिसमें कहा जा रहा है कि "मैं वकील नहीं हूँ, लेकिन वकील साफ़ तौर पर गलत हैं"। वह क़ानून के कुछ हिस्से पढ़कर, उसी समय वकीलों को अहंकारी भी कह रहा है
      [1] यह जानकारी लगभग दो महीने पहले कंपनी की legal team से हुई बातचीत के समय तक की अद्यतन स्थिति पर आधारित है

  • मुझे नहीं पता कि "अगर उसने झूठ बोला होता तो मान लिया जाता" कोई अर्थपूर्ण तर्क है भी या नहीं

    • यही logic license पर भी लागू की जा सकती है। अगर आप किसी proprietary codebase से कुछ copy करके लाएँ और झूठ बोल दें कि यह आपने खुद लिखा है, तो patch स्वीकार हो सकता है। लेकिन सच बताने पर reject हो जाएगा। तो क्या निष्कर्ष यह है कि license बुरी चीज़ है?
    • हाँ। no-LLM policy के बारे में अक्सर यह तर्क सुनने को मिलता है कि "तो लोग बस झूठ बोल देंगे"
      क्या यह उस तरह के लोगों के बारे में कोई अच्छी बात कहता है?
      मुझे नहीं लगता कि maintainers को LLM के पक्ष या विपक्ष की policy को लेकर परेशान किया जाना चाहिए। वे काम कर रहे हैं, और उन्हें यह चुनने का अधिकार है कि किन contributions का मूल्यांकन, स्वीकार या reject करना है
      बेशक, शिकायत करना ठीक है। यह व्यक्ति अपने blog पर अपना पक्ष रख रहा है, और चर्चा इसी तरह आगे बढ़ती है। लेकिन मैं इसकी framing से सहमत नहीं हूँ। यहाँ समस्या "ईमानदारी" नहीं है। अगर no-LLM policy घोषित की गई थी, तो ऐसे project में LLM का उपयोग करके योगदान देने में समय खर्च करने की ज़िम्मेदारी उसी व्यक्ति की है, जो ऐसी contribution चाहता ही नहीं
      यह वैसा ही है जैसे किसी vegan को मांस या cheese वाला खाना देना, और फिर यह शिकायत करना कि वह सिर्फ इसलिए नहीं खा रहा क्योंकि आपने सामग्री "ईमानदारी से" बता दी। "अगर मैंने नहीं बताया होता तो उसे पता नहीं चलता कि इसमें dairy है" अच्छा नहीं लगता, और "अगर मैंने नहीं बताया होता तो उसे पता नहीं चलता कि मैंने LLM इस्तेमाल किया" भी वैसा ही है
    • सहमत। मैंने नए शीर्षक के रूप में Vibecoding gets Emacs patch rejected सुझाया था। vibe coding स्वीकार करने की ईमानदारी, copyright infringement स्वीकार करने की ईमानदारी जैसी ही है। reject होने की जड़ वजह ईमानदारी नहीं है
    • मेरा मानना है कि LLM का इस्तेमाल करके ईमानदारी से बताना patch reject होने की वजह है। LLM का इस्तेमाल करके झूठ बोलना न सिर्फ patch reject होने, बल्कि आगे के contribution प्रयासों पर रोक लगने की भी वजह है

  • GNU और FSF पेशेवर कानूनी सलाह पर काफ़ी पैसा लगाते हैं। लेकिन यह संभावित contributor मानो इंटरनेट पर किसी के कहने पर उस पेशेवर सलाह को नज़रअंदाज़ करने की सिफारिश कर रहा है
    अगर आपने पेशेवर सलाह के लिए पैसे दिए हैं, तो उसका पालन करना ही तर्कसंगत है, और अगर आप सहमत नहीं हैं, तो किसी दूसरे विशेषज्ञ को ढूँढना चाहिए। किसी रैंडम इंटरनेट commenter की सलाह की वजह से उसे अनदेखा करना "लगभग व्यंग्यात्मक" नहीं, बस मूर्खतापूर्ण है

    • किसी project में योगदान देना मतलब खुद को सामने रखना और एक vulnerable स्थिति में खड़ा होना है। ख़ासकर जब "code काम करता हो" और आपकी निजी असुविधा भी दूर कर रहा हो, तब rejection और भी मुश्किल लग सकती है
      rejection से अलग, आगे चलकर काफ़ी दिलचस्प कानूनी मिसालें बन सकती हैं। बड़े model provider किसी तरह की indemnity दे सकते हैं और कह सकते हैं, "यह code हमने बनाने में मदद की है, इसलिए आप चाहें तो इस पर copyright claim कर सकते हैं," या उल्टा वे इस मुद्दे को आक्रामक तरीके से आगे बढ़ाकर कह सकते हैं कि इसका स्वामित्व उनका है और कुछ खास उपयोगों के लिए license लेना होगा। Claude अभी code यूज़र को देता है, लेकिन वह किस तरह की indemnity देता है, यह मुझे नहीं पता। बाकी models के बारे में भी ज़्यादा जानकारी नहीं है

  • क्या तुम्हें पता था कि अपराध तभी अवैध होता है जब पकड़े जाओ

  • मैं GNU का कोई बड़ा fan नहीं हूँ, लेकिन LLM coding tools क्या GNU दर्शन के ठीक उलट नहीं हैं? यह वैसा है जैसे cat cafe में dog ले जाओ और फिर बाहर निकाले जाने पर नाराज़ हो जाओ

  • मुझे लगता है कि शीर्षक को "Honesty gets Emacs patch rejected" से Vibecoding gets Emacs patch rejected में बदलना बहुत बेईमानी है
    लेखक की तरह अगर आपने AI tools की मदद ली हो, लेकिन code पर इतना समय और समझ लगाई हो, तो वह साफ़ तौर पर vibe coding नहीं है। अगर आपने AI से बस "Emacs को तेज़ बना दो" कहा होता और जो निकला उसे आँख बंद करके submit कर दिया होता, तो उसे vibe coding कहते, लेकिन पोस्ट पढ़कर साफ़ है कि ऐसा नहीं हुआ

    • "honesty" वाला शीर्षक भी बेईमानी था। patch honesty की वजह से reject नहीं हुआ, बल्कि policy violation की वजह से हुआ
    • मैं "vibe coding" शब्द की आपकी व्याख्या से सहमत हूँ, लेकिन लोग इस शब्द का इतना अलग-अलग मतलब लेते हैं कि मैं इसे उतना बेईमान नहीं कहूँगा
      मैं होता तो शायद शीर्षक "Breaking contribution policy gets Emacs patch rejected" रखता। उसमें अब भी तंज़ है, लेकिन उसका जवाब देना मुश्किल होता

  • यहाँ जो बात सबसे ज़्यादा उभरती है, वह यह है कि लेखक कहता है कि वह दो महीने से लगातार इस पर काम कर रहा था, जबकि जिस model के बारे में वह बताता है कि समस्या ढूँढने और सुलझाने में उसका इस्तेमाल किया, वह 12 दिन पहले जारी हुआ था
    मैं समझ सकता हूँ कि लेखक काफ़ी ग़ुस्से में है, लेकिन आख़िरकार open source मुझे किसी अधिकार देने से ज़्यादा, पहले से बने code को इस्तेमाल करने का एक विशेषाधिकार लगता है। फ़ायदा यह हो सकता है कि शायद इस में दम हो, और macOS के बारे में उसने जो लिखा है वह मोटे तौर पर सही है, इसलिए Emacs developers समय निकालकर इसे देख सकते हैं। लेकिन macOS शायद उनका मुख्य फ़ोकस नहीं होगा

  • यह साबित करने का एक आसान तरीका है कि यह policy कितनी मूर्खतापूर्ण है। दूसरे monitor पर LLM-assisted PR diff खोलकर रखो, और primary monitor पर बदलावों को शुरुआत से हाथ से फिर लिख दो। variable names और comments का text भी थोड़ा बदल दो
    अब यह इंसान द्वारा लिखा गया code हो गया, इसलिए इसे merge किया जा सकता है

    • दुनिया भर की कई jurisdictions में LLM output को लेकर जो copyright और कानूनी सवाल हैं, उन्हें देखते हुए यह बहुत भोला नज़रिया है