yt-dlp: Bun सपोर्ट अब सीमित किया जाएगा और अंततः हटाया जाएगा

• हाल ही में Bun को Claude की मदद से Rust में फिर से लिखा गया है, और इसकी विकास दिशा “पूरी तरह vibe-coded” होती दिख रही है, जिससे आगे चलकर मेंटेनेंस का बोझ और भरोसेमंदी को लेकर समस्याएँ पैदा हो सकती हैं
• yt-dlp अब तक Bun को ejs के साथ संगत JavaScript runtime के रूप में इस्तेमाल करता रहा है, लेकिन अब Bun सपोर्ट को सीमित करेगा और हटाएगा
• अगली yt-dlp और/या ejs रिलीज़ से Bun सपोर्ट की सीमा 1.2.11 या उससे ऊपर और 1.3.14 या उससे नीचे तक रहेगी
• न्यूनतम समर्थित वर्ज़न पहले के 1.0.31 से बढ़ाकर 1.2.11 किया जा रहा है, क्योंकि 1.2.0 से पहले के Bun में ejs पैकेज बिल्ड करने पर ejs lock file को नज़रअंदाज़ किया जाता है, जो हाल के npm supply chain हमलों को देखते हुए गंभीर सुरक्षा चिंता मानी जा रही है
• निचली सीमा 1.2.0 नहीं बल्कि 1.2.11 रखने की वजह यह है कि 1.2.11 से पहले के Bun पर ejs test suite चलाया ही नहीं जा सकता
• ऊपरी सीमा 1.3.14 तय की गई है, क्योंकि यही वह आख़िरी रिलीज़ थी जो मूल Zig codebase से बिल्ड हुई थी

• एक टिप्पणी में कहा गया कि Deno भी “vibe coded” हो रहा है, लेकिन प्रबंधक ने जवाब दिया कि Claude का उपयोग करने और Claude पर पूरी तरह निर्भर होने में बड़ा फ़र्क है
• 1.3.4 से 1.3.14 तक के वर्ज़न भी Anthropic अधिग्रहण के बाद “vibe coding” से प्रभावित हो सकते हैं, इसलिए क्या उन्हें भी सपोर्ट से बाहर नहीं करना चाहिए — इस सवाल पर प्रबंधक ने कहा कि वह इसकी समीक्षा करेंगे
• कुछ उपयोगकर्ताओं ने विरोध किया कि वास्तविक समस्या सामने आने से पहले ही नए Bun वर्ज़न के चलने पर रोक लगाना बिना पर्याप्त आधार की पूर्व-प्रतिबंधात्मक कार्रवाई है; उनकी राय थी कि चेतावनी या फ़्लैग देकर चलने देना चाहिए
• एक अन्य टिप्पणी में बताया गया कि --js-runtimes के जरिए Bun binary path सीधे दिया जा सकता है, इसलिए सामान्य उपयोग में नया Bun इस्तेमाल करते हुए yt-dlp के लिए अलग से स्थिर Bun 1.3.14 निर्दिष्ट करना एक workaround हो सकता है

[crawler]

yt-dlp ऊपर से भले सरल दिखता हो, लेकिन असल में वीडियो डाउनलोडिंग रोकने के लिए Google की तरफ़ से लगातार ब्लॉक लगाए जाते रहे हैं, और जब भी ऐसे ब्लॉक आते हैं, यह किसी न किसी तरह उन्हें पार करता रहा है.

मुझे लगता है कि यह ऐसा समूह है जिसकी हैकर प्रवृत्ति, AI पर निर्भर रहना मुश्किल होने की वजह से, और भी प्रबल होना स्वाभाविक है, इसलिए ऐसा फैसला लेना भी अजीब नहीं है.

सच कहूँ तो, इतना बड़ा प्रोजेक्ट इस तरह बहिष्कार कर रहा है, तो इसके लिए शुक्रगुज़ार महसूस होता है.
दरअसल, मुझे भी इस बात पर शक हुआ था कि Bun डेवलपर्स ने शुरुआत में कहा था कि वे बस प्रयोग के तौर पर पोर्टिंग करके देख रहे हैं, लेकिन उसके उलट यह बहुत जल्दी मेनस्ट्रीम में मर्ज हो गया; उस रफ़्तार से सारे कोड रिव्यू किए गए होंगे, यह संभव नहीं लगता, इसलिए लगा कि क्या सच में ऐसा होना ठीक है.

[roxie]

जितना देखते हैं, मामला उतना ही जटिल लगता है।

[gkhcdef]

क्वालिटी अच्छी है (x) बेंचमार्क अच्छा है (o)

[GN⁺]

Hacker News की राय

• यह फ़ैसला समझ में आता है। अगर ज़्यादातर कोड मेंटेनर ने खुद नहीं लिखा है, तो codebase को ठीक से समझना मुश्किल ही होगा।
  पूरे rewritten code की समीक्षा करना भी व्यवहारिक रूप से असंभव है। वहाँ ठीक 10 लाख lines का कोड है https://github.com/oven-sh/bun/pull/30412

  • मेरा नहीं मानना कि Zig से Rust में बदल जाने से अचानक यह समझना बंद हो जाता है कि कोई file क्या रखती है, कैसे काम करती है, और दूसरी files से कैसे जुड़ती है।
    आखिरकार वही बात अलग syntax में लिखी गई है, और शायद Rust developers को यह देखने में अच्छा नहीं लगता। Bun developers शायद ऐसा code चाहते थे जो उन्हें परिचित लगे।
    फिर भी, मुझे लगता है इसे 2.0 कहना चाहिए था। तब यह इतनी हड़बड़ी जैसा भी नहीं लगता। 1.3.14 में भी कुछ regressions हैं, लेकिन अभी Rust से जुड़ी छोटी-छोटी आग इतनी ज़्यादा हैं कि कोई उस पर खास ध्यान नहीं दे रहा।
    बड़ी समस्या यह है कि Bun लगातार चमकदार नई features के पीछे भागता है और चीज़ों को अंत तक पूरा नहीं करता। testing में Vitest का अधिकांश हिस्सा है, पर सब नहीं; Jest का अधिकांश है, पर सब नहीं; pnpm का अधिकांश है, पर सब नहीं। अब image feature भी आ गया है, तो sharp का अधिकांश है, पर सब नहीं। dev server भी Vite का अधिकांश है, लेकिन फिर भी पूरा नहीं। लंबे समय तक चलने वाली processes Node जैसी तो हैं, लेकिन उनमें memory leaks हैं, और शायद यही Rust transition की वजह रही हो।
    image routines वाली पोस्ट पढ़कर मेरा मन बैठ गया। वह फिर एक और चमकदार लक्ष्य था, और testing bugs के साथ मिलकर आखिरकार मैं पूरी तरह Vitest पर चला गया
  • लगभग 20 लाख lines का Zig code लिखा जा सकता था, और उसमें शामिल वही test suite चलती रह सकती थी, लेकिन 10 लाख lines का Rust code review नहीं किया जा सकता—यह बात बहुत भरोसेमंद नहीं लगती।
    मुझे यकीन नहीं कि यह rewrite खुद में अच्छा विचार है और सफल होगा, लेकिन इसके उलट वाली दलील भी उतनी ही कमज़ोर लगती है
  • यह high-turnover corporate culture में काफ़ी आम है। आपको 10 साल पुराने, लाखों lines वाले codebase को “maintain” करने वाली टीम में डाल दिया जाता है, और टीम में सबसे पुराना व्यक्ति भी बस 1–2 साल पुराना होता है।
    उन 10 लाख से ज़्यादा lines का क्या काम है, यह किसी को नहीं पता। कोई भी उसे लगन से संभालता नहीं। requirements ली जाती हैं, और जिसे छूना ज़रूरी है उसके अलावा बाकी सबको black box मान लिया जाता है।
    इसलिए एक ही काम करने वाली 14 background service implementations, उसी भूमिका की 8 dependencies, 6 overlapping frameworks, और style व approach में पूरी असंगति पैदा हो जाती है। फिर भी किसी को ज़्यादा फ़र्क नहीं पड़ता
  • जिन काफ़ी बड़े codebases पर मैं अभी काम कर रहा हूँ, उनमें कुछ ऐसे भी हैं जिन्हें agentic tools से generate करने वाले लोग खुद भी उनकी कार्यप्रणाली लगभग नहीं समझते।
    यह शुद्ध “vibe coding” से बेहतर है, लेकिन अगर हिस्सा महत्वपूर्ण न हो तो ठीक है; सच में गहराई से सोचना पड़ने वाले core infrastructure में यह स्वीकार्य नहीं लगता
  • वे Windows भी support करते हैं, और Windows में अभी भी ऐसा code लाखों lines में है जो मौजूदा मेंटेनर ने नहीं लिखा

• यह किसी की नस्ल या धर्म के खिलाफ भेदभाव नहीं है। अगर कोई बड़े पैमाने पर vibe-coded surface area नहीं चाहता, तो क्या उसे इसके लिए सफाई देनी चाहिए?
  लगता है लोग भूल रहे हैं कि यह developer की “कलात्मक” स्वतंत्रता का हिस्सा है, और software में स्वाभाविक रूप से राय शामिल होती है

  • GitHub issue की कुछ पोस्ट देखकर लगता है, कुछ लोग इसे ऐसे ले रहे हैं जैसे उनके धर्म का अपमान हो गया हो
  • comments देखकर लगता है, बहुत लोग मान रहे हैं कि शीर्षक Bun खुद के बारे में है
  • हाँ। fork करके सिर्फ minimum version number बढ़ाना मुश्किल नहीं होना चाहिए। मैंने देखा नहीं है, लेकिन संभव है कि कहीं सिर्फ एक संख्या बदलनी पड़े।
    अगर वह काम कर रहा है तो करता रहेगा। बस वे इसे support और maintain नहीं करना चाहते और issues fix नहीं करना चाहते
  • इसे नस्ल या धर्म वाले भेदभाव जैसा भी कहा जा सकता है, इस अर्थ में कि यह मनमाने और अर्थहीन मानदंडों पर बाहर करना है।
    अगर Rust में port किया गया Bun हर मापने योग्य पहलू में बेहतर है, सारे tests pass करता है, performance बराबर या बेहतर है, और पुराने bugs भी ठीक हैं, तो यह क्यों मायने रखे कि वह किस language में लिखा गया है और कैसे implement हुआ? असली बात यह है कि quality ज़्यादा अच्छी है।
    अगर आप Bun team पर Rust version release और approve करने के बाद भी भरोसा नहीं करते, तो फिर 2 हफ्ते पहले वाले Zig version पर भरोसा क्यों था, यह भी तार्किक नहीं बैठता। yt-dlp developers तब मूर्ख लगते हैं

• मुझे Bun इस्तेमाल करना सच में बहुत पसंद है, इसलिए Anthropic acquisition के बाद दिशा का इस तरह बदलना थोड़ा दुखद है।
  मैं batteries-included वाला अच्छा Node चाहता हूँ, लेकिन यह नहीं चाहता कि वह vibe-coded हो

  • सोच रहा हूँ कि vibe-coded conversion की वजह से वास्तव में कोई बड़ी समस्या हुई भी है या नहीं।
    इसका मतलब यह नहीं कि मैं merge का समर्थन करता हूँ। मैं इस तरह की YOLO engineering approach के खिलाफ हूँ। बस घोषणा के बाद की खबरें नहीं देखीं, तो जानना चाहता हूँ कि transition कैसा चल रहा है
  • Bun team के मुताबिक, Anthropic acquisition से पहले ही यह कई महीनों से vibe coding के साथ चल रहा था
  • acquisition के समय लोगों को उम्मीद थी कि Bun लगभग पहले जैसा ही चलता रहेगा, और यह देखना काफ़ी विडंबनापूर्ण है कि वह उम्मीद पूरी तरह उलट गई और टूट गई।
    बेशक, मज़ेदार नहीं बल्कि बेहद दुखद अर्थ में विडंबनापूर्ण
  • अगर “vibe coding” की वजह से कोई ठोस समस्या साबित नहीं हुई है, तो बिना असली सबूत देखे उसे सीधे खारिज कर देना क्या उसी तरह की प्रतिक्रिया नहीं है जिसकी आलोचना की जा रही है?

• यह फ़ैसला engineering से ज़्यादा political judgment जैसा लगता है। क्या आपने Rust rewrite के बाद Bun में segmentation faults, out-of-memory, security vulnerabilities, या bugs बढ़ते देखे हैं?
  बेशक नहीं, क्योंकि rewrite अभी शामिल ही नहीं हुई है। यह ऐसा लगता है जैसे AI की भागीदारी का विचार ही बुरा लगा और उसी पर फ़ैसला कर लिया गया।
  engineering tools को मूड से नहीं, बल्कि इस आधार पर चुना जाता है कि वे इच्छित काम करते हैं या नहीं। अगर Bun में bugs बढ़ते हैं और वह खराब software लगे, तो मैं उसे नहीं इस्तेमाल करूँगा, लेकिन वह फ़ैसला data पर आधारित होगा। Jarred ने Bun के साथ बहुत प्रभावशाली काम किया है, और ऐसा नहीं लगता कि वह अपने quality bar से नीचे rewrite release करेगा, इसलिए मैं देखना चाहूँगा कि आगे क्या होता है

  • उल्टा देखें तो, Bun की नई development process segmentation faults, out-of-memory, या security vulnerabilities बढ़ाती है या नहीं, यह yt-dlp की तरफ़ से प्रयोग करके साबित करना उनका दायित्व नहीं है।
    अगर उन्हें वाजिब रूप से लगता है कि security vulnerabilities बढ़ सकती हैं, तो users पर प्रयोग करना लापरवाही भी माना जा सकता है।
    ज़िम्मेदार विकल्प ज़्यादा करीब यह है: “अभी main से कटे नए Bun release पर अपने software के execution को तुरंत support नहीं करेंगे।”
    हाँ, यह अफ़सोस की बात है कि यह भविष्य के releases का दोबारा मूल्यांकन करने की योजना नहीं, बल्कि आगे भी कभी support न करने के इरादे जैसा दिख रहा है। हालांकि yt-dlp developers किसी के ऋणी नहीं हैं
  • यह ज़रूरी नहीं कि राजनीतिक हो। yt-dlp शायद राजनीतिक ढंग से व्यवहार कर रहा हो, लेकिन core dependency को production में 6 महीने से 1 साल तक व्यापक उपयोग से पहले adopt न करने का सिद्धांत आम तौर पर राजनीति नहीं है।
    10 लाख lines की पूरी rewrite, उसी ABI के साथ भी, व्यवहार में लगभग एक नया runtime है, और कई downstream consumers के लिए इसे production dependency बनाना असुविधाजनक है।
    बहस के लिए मान लें कि Bun पूरी तरह इंसानों ने हाथ से दोबारा लिखा होता, तब भी स्थिति वही रहती। मुझे लगता है ऐसा फ़ैसला काफ़ी standard है, और व्यक्तिगत रूप से मुझे भी Bun की LLM rewrite quality शायद कुल मिलाकर अच्छी लगे, लेकिन मैं अपने product या company को इस पर दाँव नहीं लगाऊँगा। जोखिम भरे बदलाव मैं अपने software में खुद चुनना चाहता हूँ, किसी downstream dependency की वजह से मजबूरी में नहीं लेना चाहता
  • अगर आप segmentation faults, out-of-memory और दूसरी समस्याओं के बढ़ने का इंतज़ार करते हैं, तो तब तक आप समस्या से बचने में असफल हो चुके होंगे। मुझे यह दिशा सही लगती है, और इतिहास दिखाएगा कि कौन सही था
  • projects में governance बहुत महत्वपूर्ण है। Bun के authors का नए मालिकों के आगे झुकना यह दिखाता है कि उनकी प्राथमिकताएँ कहाँ हैं।
    मैं बैठकर यह इंतज़ार नहीं करूँगा कि bugs फूटें और सब कुछ टूटना शुरू हो जाए।
    अगर किसी project के लोग “tool काम करता है या नहीं” जैसी सोच से ही चुनते हैं, तो मैं उसे अपनी dependencies से हटा दूँगा
  • engineering के मूल तत्वों में से एक है मौजूदा trajectory का अनुमान लगाना। उस हिसाब से बुरा एहसास देने वाले tools से बचना पूरी तरह समझदारी है।
    जिस tool के train wreck बनने की आशंका हो, उससे दूर जाने का सबसे आसान समय integration से पहले होता है

• यह Rust conversion के बारे में है, लेकिन अभी release नहीं हुई है।
  वे “expected compatibility and security issues” कह रहे हैं, लेकिन Zig version वाला Bun भी काफ़ी crash होता है।
  अच्छा होता अगर yt-dlp यह link करता कि expected compatibility issues क्यों हैं, उसका ठोस आधार क्या है। दोनों projects के पास test suites हैं, तो आदर्श दुनिया में तेज rewrite संभव होनी चाहिए।
  शायद वे स्थिति को और भड़काना नहीं चाहते, लेकिन अगर उन्हें कोई ठोस समस्या मिली है, तो मैं उसे देखना चाहूँगा।
  Bun.rs को minor release नहीं बल्कि 1.4 या 2.0 होना चाहिए था, और alpha/beta releases भी होने चाहिए थे

  • अगर वास्तव में किसी project ने Bun.rs में गंभीर regressions दिखाने वाला data साझा किया होता, तो बात अलग होती।
    लेकिन इसे public हुए सिर्फ एक हफ्ता हुआ है, और अभी तक असली regression data लगभग नहीं दिख रहा। ज़्यादा यह “बस पसंद नहीं आया” वाली शिकायत जैसा लग रहा है

• यह तर्क कुछ हद तक ऐसा पढ़ाई देता है जैसे “libfoo अब vim की जगह emacs से develop होने लगा है, इसलिए अब उस पर भरोसा नहीं किया जा सकता।”
  बेशक यह बिल्कुल वही बात नहीं है, लेकिन कुछ हद तक ऐसा एहसास देता है।
  software में एकमात्र सच्चाई यह है कि मेरे use case में क्या यह काम करता है। AI से पहले भी यह पता नहीं होता था कि author ने सख़्ती से काम किया या बस random कोशिशें करता रहा जब तक कुछ चल न पड़ा।
  यानी मैंने methodology या इस्तेमाल किए गए tools की जाँच करके software का आकलन नहीं किया। मैंने ऐसे बहुत software इस्तेमाल किए हैं जिनके test suites नहीं थे या खराब थे, और memory safety पसंद करने वाले लोग भी C में लिखे tools इस्तेमाल करते हैं, और उल्टा भी।
  इसलिए “मुझे AI का इस्तेमाल करने का तरीका पसंद नहीं, इसलिए मैं इसे नहीं इस्तेमाल करूँगा” वाला तर्क उतना ही कमज़ोर लगता है जितना यह कहना कि author के editor पसंद नहीं आए इसलिए उपयोग बंद कर दिया

  • कुछ लोग सच में यह चिंता करते हैं कि चीज़ें किस तरह बनाई गईं, और उसी आधार पर तय करते हैं कि वे उस प्रक्रिया से सहमत हैं या नहीं।
    अगर ऐसा न होता, तो fair-trade chocolate/coffee जैसी अवधारणा भी मौजूद न होती
  • वह analogy कुछ ज़्यादा ही खींची हुई है। यह न एक ही मैदान है, न पास-पड़ोस का मैदान
  • तो एक कदम आगे चलते हैं: मान लें आपने हर महीने के पहले सोमवार को पूरे codebase को नई language में दोबारा लिखने वाला cron job लगा दिया—Rust से C++, फिर Go, Swift, और फिर वापस।
    क्या product इस्तेमाल करने वाले customers के लिए भी यह लगभग वही बात होगी जैसे किसी maintainer ने editor बदल लिया हो, यानी एक अप्रासंगिक विवरण?
  • ज़्यादातर लोग मानेंगे कि किस text editor का उपयोग हुआ, उसका लिखे गए code पर अर्थपूर्ण असर नहीं पड़ता।
    लेकिन LLM के बारे में यह बात बहुत कम लोग कहेंगे।
    vibe Bun पुरानी Bun जितनी अच्छी या उससे बेहतर हो सकती है, लेकिन अभी हम यह कैसे जानें?
    और यह कहना भी सही नहीं कि “हमें कभी पता नहीं होता था कि software सख़्ती से बना है या नहीं, इसलिए methodology से निर्णय नहीं लेते थे।” कुछ लोग किसी project को अपनाने या उसका उपयोग जारी रखने से पहले खुद यह जाँचते हैं कि उसमें स्वीकार्य स्तर की rigor है या नहीं। मैं भी महत्वपूर्ण चीज़ों में ऐसा ही करता हूँ।
    और अधिकतर लोग reputation signals का उपयोग करते हैं—वे perfect नहीं होते, लेकिन उनका कुछ correlation होता है, वे काफी हो सकते हैं, और सीधे manual review से कहीं आसान होते हैं

• development work में LLM के उपयोग के तरीके को समझाने के लिए नए शब्द की बहुत ज़रूरत है। “vibe coding” की एक सख़्त परिभाषा है, लेकिन लगता है किसी को परवाह नहीं।
  यह मानना सच में मुश्किल है कि Rust port पूरी तरह 100% “vibe” में ही किया गया था, जैसे मूल परिभाषा कहती है।
  यह सकारात्मक और नकारात्मक भावनाओं के मिले-जुले कीचड़ में बदल गया है, और अगर “vibe coding” को सामान्य LLM-usage slur की तरह इस्तेमाल किया जाए, तो असल समस्या क्या है यह समझना बहुत मुश्किल हो जाता है।
  मैं development में मदद के लिए LLM इस्तेमाल करता हूँ, और engineer जिन लगभग सभी metrics की परवाह करेंगे, उनमें मैं बेहतर काम ज़्यादा तेज़ी से कर रहा हूँ

  • vibe coding का मूल मतलब था “बस vibes के हवाले छोड़ देना [...] और यहाँ तक भूल जाना कि code नाम की कोई चीज़ मौजूद है”
    https://x.com/karpathy/status/1886192184808149383
    इस खास port के मामले में, यह इतनी तेज़ी से हुआ कि साफ़ लगता है इंसानों ने translation की validity verify नहीं की। आगे manual verification वास्तव में होगी भी या नहीं, यह भी स्पष्ट नहीं है।
    हालाँकि Dijkstra के मानदंड से देखें तो AI आने से बहुत पहले से ज़्यादातर software projects पहले ही “vibe coding” कर रहे थे—यानी vibes पर छोड़कर correctness के अस्तित्व को भूल जाना।
    जटिल code की correctness सुनिश्चित करना कठिन है, लेकिन अब जब data center के भीतर 100 करोड़ hackers का युग आ गया है, तो यह धीरे-धीरे वैकल्पिक चीज़ नहीं रह जाएगी।
    अतिरिक्त: “Bun के pre-release Rust port में 13,365 unsafe blocks हैं”
    https://news.ycombinator.com/item?id=48239790
  • यह दावा करने के विपरीत कि LLM से बेहतर काम तेज़ी से होता है, studies यह संकेत देती हैं कि यह तेज़ न भी हो सकता है, बल्कि धीमा भी हो सकता है।
    तकनीक इतनी नई है कि research कठिन है, लेकिन आशावादी नज़रिए से भी empirical evidence कुछ क्षेत्रों में बस करीब 3% improvement ही दिखाता है।
    code लिखना हमारे काम में अक्सर bottleneck नहीं होता

• समझ नहीं आता कि इतने लोग इस फ़ैसले से इतना दबाव क्यों महसूस कर रहे हैं। अगर आप सच में vibe coding के शौकीन हैं, तो बेहतर yt-dlp खुद vibe code कर सकते हैं या मौजूदा वाले को fork करके अपने हिसाब से बना सकते हैं, है न?

  • मैंने बहुत सुना है कि vibe coding की वजह से software बनाना इतना आसान हो गया है कि कोई भी इसे पल भर में बना सकता है।
    यहाँ तक कहा गया कि लोग हर काम के लिए one-off personal software vibe code करेंगे।
    अगर ऐसा है, तो vibe coders को किसी भी software decision पर शिकायत नहीं करनी चाहिए। अपनी पसंद का personal fork vibe code करना तो बच्चों का खेल होना चाहिए, है न? क्या यही vibe coding का वादा नहीं था?
  • ऊपर से yt-dlp में पहले से ही third-party interpreter plugins का support है। वे बस यह कह रहे हैं कि वे Bun को खुद support नहीं करना चाहते, और किसी दूसरे को अपनी पसंद की चीज़ इस्तेमाल करने देने का infrastructure पहले से मौजूद है।
    यह उस गलत entitlement का उदाहरण है जो लोग अक्सर ऐसे projects के प्रति महसूस करते हैं जिन्हें दूसरे लोग अपने समय और मेहनत से maintain करते हैं। अपनी मनचाही feature के लिए दूसरों के समय और श्रम को मनमाने ढंग से volunteer कर देना चाहना हमेशा चौंकाने वाला होता है।
    जो लोग काम कर रहे हैं, उन्हें फ़ैसला लेने का अधिकार है, और अगर पसंद न हो तो खुद fork कर लें। यह ecosystem शुरू से ऐसा ही रहा है।
    yt-dlp आज भी आश्चर्यजनक रूप से आसानी से छेड़छाड़ करने लायक है
  • बहुत से AI fans के लिए, सबके लिए नहीं लेकिन कई के लिए, यह लगभग धर्म जैसा काम करता है। वे यह कहकर संतुष्ट नहीं होते कि सब अपने-अपने रास्ते चलें और इतिहास तय करे कि software बनाने का कौन-सा तरीका बेहतर है; वे चाहते हैं कि हर कोई उनसे सहमत हो।
    मैं दफ़्तर में भी यही देख रहा हूँ, और AI के मामले में ईमानदार technical disagreement की अनुमति न होना सच में पागल कर देने वाला है

• मुझे समझ नहीं आता कि Bun rewrite के बारे में कैसा महसूस करूँ।
  एक तरफ़, codebase का अधिकांश हिस्सा review नहीं हुआ—यह बहुत डरावना लगता है।
  दूसरी तरफ़, सुनने में आया है कि यह लगभग बिना regressions के tests pass कर रहा है।
  शायद मुझे उस क्षेत्र का पर्याप्त अनुभव नहीं है, लेकिन मैं tests पर इतना भरोसा करके code पढ़े बिना पूरी तरह निर्भर नहीं हो पाता