GitHub और सॉफ़्टवेयर के खिलाफ अपराध

 (eblog.fly.dev)
1 पॉइंट द्वारा GN⁺ 22 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub को सॉफ़्टवेयर डेवलपमेंट इन्फ्रास्ट्रक्चर के केंद्र की तरह इस्तेमाल किया जाता है, लेकिन बार-बार होने वाले incidents, धीमे पेज और browser टूटने जैसी समस्याओं के कारण इसकी बुनियादी reliability पर सवाल उठते हैं
  • Microsoft ने कहा कि agentic workflows की वजह से लोड तेज़ी से बढ़ा, लेकिन GitHub और Copilot·agent फीचर्स को उसने खुद ही ज़ोर देकर आगे बढ़ाया और उपयोग के लिए प्रेरित किया—इस पर आलोचना भी बढ़ी
  • न्यूनतम repository प्रयोग में GitHub ने 291 requests, संकुचित response में 15MiB और विस्तारित रूप में 544,564 lines डाउनलोड कीं, जो Codeberg के 11 requests की तुलना में बहुत अधिक था
  • फ्रंटएंड माप में GitHub ने सामान्य heap में लगभग 69MiB इस्तेमाल किया, जबकि rust-lang pull request पेज ने 148MiB लिया; टेक्स्ट-केंद्रित पेज के लिए इसे अत्यधिक अपव्ययी माना गया
  • निष्कर्ष यह है कि GitHub की यह बर्बादी केवल product deterioration नहीं, बल्कि AI फीचर्स और investor-केंद्रित प्राथमिकताओं को उपयोगकर्ता समस्याओं के समाधान से ऊपर रखने वाली एक software failure है

GitHub की reliability और priorities

  • GitHub को सॉफ़्टवेयर डेवलपमेंट इन्फ्रास्ट्रक्चर के केंद्रीय हिस्से की तरह इस्तेमाल किया जाता है, लेकिन downtime, performance गिरावट और browser compatibility समस्याओं के कारण इसकी बुनियादी reliability पर संदेह किया जाता है
  • GitHub Status history में हर महीने दर्जनों incidents हैं, और आधिकारिक स्टेटस पेज तथा SLA के मानकों से देखें तो कुछ स्थितियाँ उल्लंघन जैसी लगती हैं
  • Firefox और Safari में यह अक्सर टूट जाता है, pull request comments और review पेज धीमे होते हैं, और RAM उपयोग तथा heap spikes अत्यधिक बताए जाते हैं
  • GitHub Actions को धीमा और कम documented कहा गया है, और logs स्क्रीन कई वर्षों से memory leak तथा browser crash का कारण रही है
  • setup-go जैसे बुनियादी actions के cache behavior को भी बिना invalidation वाला या ज़रूरत से ज़्यादा सरल बताया गया है
  • githubstars.com जैसी साइटें खुलेआम stars खरीदने का विज्ञापन करती हैं, और Carnegie Mellon paper के “fake stars are highly related to malicious activities” वाक्य का भी हवाला दिया गया है
  • GitHub को आदर्श रूप से उच्च-प्रदर्शन, उच्च-उपलब्धता, उच्च-क्षमता वाले distributed system की तरह काम करना चाहिए, लेकिन आकलन यह है कि वास्तविक product बुनियादी reliability से अधिक AI फीचर्स और agent flows को प्राथमिकता देता है

“Agentic” लोड और Microsoft की ज़िम्मेदारी

  • GitHub ने ‘an update on github availability’ में कहा कि 2025 के उत्तरार्ध से agentic development workflows तेज़ी से बढ़े हैं, और repository creation, pull request activity, API usage, automation तथा बड़े repository workloads में तेज़ वृद्धि हुई है
  • यह व्याख्या बढ़ते लोड को जैसे बाहरी घटना की तरह पेश करती है, लेकिन इससे यह आलोचना भी उठती है कि GitHub और उसकी मूल कंपनी Microsoft ने AI और “agents” को कई products में ठूँसकर खुद ही उनके उपयोग को बढ़ावा दिया
    • GitHub के लगभग हर पेज के top bar में AI के 3 buttons हैं, जिनमें से 2 सिर्फ agent शुरू करने के लिए हैं, और कई पेजों पर 4 buttons तक हैं
    • सामान्य repository landing page के ऊपर दाईं ओर Copilot चलाने के 4 तरीके मौजूद हैं
    • GitHub ने कई वर्षों तक tool usage cost को subsidize करके adoption बढ़ाया, और इसे खुद पर distributed denial-of-service को subsidize करने जैसा बताया गया है—इसके लिए यह आलोचनात्मक लिंक दिया गया है
  • Microsoft ने समझाया कि एक pull request Git repository, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches और databases को छू सकता है
  • बड़े पैमाने पर छोटी inefficiencies भी queue गहराने, cache miss, DB load, index delay और retry traffic amplification में बदल सकती हैं, लेकिन GitHub की inefficiency को “छोटी” नहीं बल्कि विशाल और दबावकारी बताया गया है
  • Microsoft ने “availability first, then capacity, then new features” कहा, लेकिन GitHub public changelog में उस update के बाद 30 दिनों के patch notes में “copilot” 59 बार, “agent” 8 बार आया, जबकि “performance” और “reliability” 0 बार आए
    • changelog filter में copilot category अलग से है, लेकिन performance और reliability category नहीं हैं
    • Visual Studio Code भी GitHub और “agentic” फीचर्स के साथ सीधे integrated है, और आलोचना यह है कि built-in terminal जैसी बुनियादी सुविधाएँ बिगड़ने के बावजूद agent फीचर्स जोड़े जा रहे हैं
  • Microsoft ने “unnecessary work” घटाने, caching सुधारने, critical services को isolate करने, single points of failure हटाने, performance-sensitive paths को migrate करने, hidden coupling कम करने, blast radius सीमित करने और graceful degradation लागू करने की बात कही; इसे system design के गलत होने की स्वीकारोक्ति माना गया

क्यों frontend backend समस्याओं का संकेत देता है

  • GitHub की reliability समस्याओं की जड़ backend और database में है, लेकिन वे बाहर से दिखती नहीं; इसके बजाय हर बार डाउनलोड होने वाले HTML, JavaScript और CSS जैसे frontend code को देखा जा सकता है
  • जैसे किसी pizza shop के dining area में चूहा दिखे तो kitchen के साफ़ होने पर भरोसा करना मुश्किल होता है, उसी तरह GitHub frontend की साफ़ दिखने वाली सड़न backend समस्याओं की ओर इशारा करती है, हालांकि उन्हें साबित नहीं करती
  • GitHub, GitLab और Codeberg की repository landing pages में link lists, छोटे UX elements, buttons, tabs और search box होते हैं; interactive media या images जैसे महंगे elements लगभग नहीं होते
  • ऐसे pages को अच्छे internet connection के बिना भी लगभग हर computer या phone पर सस्ते में चलना चाहिए, और दावा है कि GitHub अतीत में iPhone 4 और 3G connection पर वास्तव में ऐसा चलता था
  • यदि functionality एक जैसी हो, तो सबसे अच्छा code वह माना जाएगा जो network bandwidth, CPU time और RAM का सबसे कम उपयोग करे और जिसमें bugs सबसे कम हों
  • frontend bug count सीधे पता नहीं चल सकता, लेकिन ऐतिहासिक शोधों में bugs की संख्या आमतौर पर code lines की संख्या के अनुपात में बताई गई है
    • Steve McConnel, Code Complete, 2nd Ed (2004) में बताया गया है कि shipped software में industry average error rate प्रति 1000 lines of code पर 1 से 25 errors होता है
    • Microsoft Applications Division के बारे में उद्धृत है कि internal testing के दौरान प्रति 1000 lines of code पर 10 से 20 defects और shipped products में प्रति 1000 lines पर 0.5 defects देखे गए

प्रयोग की रूपरेखा और संग्रह विधि

  • confounding variables कम करने के लिए internet speed को “fast 3G” connection तक सीमित किया गया
    • यह network condition variability के प्रभाव को कम करने और ग्रामीण क्षेत्रों जैसी कम आदर्श परिस्थितियों में GitHub customer experience को simulate करने के लिए किया गया था
  • तीनों services में एक ही न्यूनतम repository ghsucks इस्तेमाल की गई
    • एक single branch master
    • एक single file README.md
    • issues, tags आदि अतिरिक्त elements 0
  • एक ही browser और एक ही computer इस्तेमाल किया गया
    • Firefox
    • Apple Macbook Pro M5 Max
    • 48GiB RAM
  • हर service में चार pages की जाँच की गई
    • “landing” page: code layout
    • “pull requests” या “merge requests” page
    • “issues” page
    • “settings” page
  • clean cache स्थिति में HTTP Archive(HAR) एकत्र करके network requests का विश्लेषण किया गया, और loading पूरी होने के बाद heap snapshots लेकर steady-state RAM usage के अनुमान निकाले गए
  • HAR analysis के लिए खुद लिखा गया anhar, compression-support analysis के लिए testcompress, और cross-check के लिए pagespeed.web.dev का उपयोग किया गया

heap उपयोग और मेमोरी की बर्बादी

  • डिफ़ॉल्ट repository पेज का heap उपयोग GitHub 69MiB, GitLab 68MiB, Codeberg 14MiB, eblog.fly.dev 1.3MiB मापा गया
  • https://github.com/rust-lang/rust/pulls के पहले issue पेज को render करने में 148MiB RAM का उपयोग हुआ
  • 148MiB मूल iPhone से भी ज़्यादा मेमोरी है, और कुछ links वाले text-केंद्रित पेज के लिए इसे बेहद गंभीर बर्बादी माना गया
  • तुलना के लिए दिए गए डिवाइस मेमोरी आँकड़े Apple iphone 1 128MiB, iphone 4 512MiB, Sony playstation 2 32MiB, Nintendo wii 88MiB आदि हैं

अनुरोध मात्रा और response आकार की तुलना

  • anhar एक Go प्रोग्राम है जो HAR JSON को parse करता है, response के HTML·CSS·JavaScript को deno fmt से अपने आप format करता है, फिर request·response size, MIME-वार कुल, load time, और response line count की गणना करता है
  • मुख्य metrics हैं request size, वास्तव में प्राप्त minified response size, deno fmt लागू करने के बाद expanded response size और line count, बेस HTML load time यानी Content-Load, और सभी content के load होने का समय यानी Load
  • Codeberg repository page के लिए कुल 11 requests, request 9KiB, response 1MiB, expanded response 1MiB, expanded 3,480 lines, Content-Load 2.934s, Load 3.172s मापा गया
  • GitHub repository page के लिए 291 requests, request 178KiB, minified response 15MiB, expanded response 22MiB, expanded 544,564 lines, Content-Load 843ms, Load 21.330s मापा गया
    • application/javascript: 214 requests, response 12MiB, expanded response 19MiB, expanded 481,849 lines
    • text/css: 42 requests, response 2MiB, expanded 60,016 lines
    • GitHub pulls: 266 requests, minified 14MiB, expanded 20MiB, expanded 487,922 lines, Content-Load 592ms, Load 6.754s
    • GitHub settings: 255 requests, minified 14MiB, expanded 20MiB, expanded 486,067 lines, Content-Load 778ms, Load 6.963s
  • GitLab, GitHub से छोटा है, लेकिन फिर भी भारी है
    • GitLab repository: 78 requests, response 8MiB, expanded 101,682 lines, Content-Load 6.880s, Load 12.941s
    • GitLab merge_requests: 65 requests, response 7MiB, expanded 90,567 lines, Content-Load 6.947s, Load 12.096s
    • GitLab edit: 117 requests, response 7MiB, expanded 71,916 lines, Content-Load 6.964s, Load 13.302s
  • कहा गया है कि GitHub खाली repository दिखाने के लिए भी लगभग 540K lines का code और data लाता है, जो DOOM 35K lines, Windows Quake 120K lines, MS-DOS 4.0 332K lines, और Zig toolchain 460K lines से भी ज़्यादा है
  • यह संरचना, जिसमें हर पेज 40 CSS files और सैकड़ों JavaScript files लाता है, समस्या मानी गई
  • सिद्धांत रूप में Webpack का chunk splitting core features और optional features को अलग कर सकता है और caching·CDN के लिए फ़ायदेमंद हो सकता है, लेकिन यहाँ इसकी वजह से हर file के लिए अलग HTTP request चाहिए, जिससे load धीमा होता है
  • खाली पेज देखने के लिए 22 सेकंड इंतज़ार करना स्वीकार्य नहीं माना गया, और 1GiB/s से अधिक fiber broadband तथा high-performance consumer processor पर भी repository के कुछ हद तक उपयोगी होने में 1 सेकंड से ज़्यादा लगने की बात कही गई

compression support की तुलना

  • compression को client·server·बीच के network path का load कम करने का उपयोगी तरीका बताया गया
  • gzip एक परखा हुआ compression standard है और हर website को इसका support करना चाहिए, जबकि zstd के performance गुण अच्छे हैं लेकिन यह अधिक आधुनिक तरीका है, इसलिए इसका support “हो तो अच्छा” स्तर का माना गया
  • testcompress एक Go प्रोग्राम है जो यह test करता है कि कोई URL gzip और zstd compression support करता है या नहीं, और support न होने पर response body को सीधे compress करके संभावित बचत दिखाता है
  • eblog.fly.dev/startingsystems3.html: supported encoding zstd gzip, मूल 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
  • github.com/ef0xa/ghsucks: supported encoding gzip, मूल 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks: supported encoding gzip, मूल 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks: supported encoding n/a, मूल 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

PageSpeed मोबाइल परिणाम

  • pagespeed.web.dev के mobile measurement में Codeberg को First Contentful Paint 1.2s, Largest Contentful Paint 1.3s, Interaction to Next Paint 86ms के साथ PASS मिला
  • eblog.fly.dev को First Contentful Paint 1.1s, Largest Contentful Paint 1s, Interaction to Next Paint N/A के साथ PASS मिला
  • GitHub को First Contentful Paint 1.8s, Largest Contentful Paint 2.1s, Interaction to Next Paint 242ms के साथ FAIL मिला
  • GitLab को First Contentful Paint 2.1s, Largest Contentful Paint 2.4s, Interaction to Next Paint 243ms के साथ FAIL मिला

सेवा-वार मूल्यांकन

  • GitHub

    • लगभग 300 फ़ाइलें, कोड और डेटा की करीब 550,000 पंक्तियाँ लाता है, और अनुमानित बग की संख्या 550 बताई गई है
    • Content-Load लगभग 800ms, कुल Load लगभग 7s, और steady-state heap लगभग 69MiB के रूप में संक्षेपित किया गया है
    • gzip समर्थित है, लेकिन zstd समर्थित नहीं है
    • मूल्यांकन F है, और कहा गया है कि कोड का भार बहुत अधिक है
    • यह भी आलोचना की गई है कि GitHub इस्तेमाल हो या न हो, हर पेज पर सभी themes लोड करता है
    • pagespeed.web.dev के अनुसार JavaScript और CSS की 528KiB पूरी तरह इस्तेमाल नहीं होती, इसलिए माना गया है कि कटौती यहीं से शुरू की जा सकती है
    • सुझाव दिया गया है कि अगर GitHub पर ही बने रहना है, तो इसे GitHub के अपने SLA का उल्लंघन मानते हुए refund पाने के लिए support ticket जमा किया जाए

  • GitLab

    • Content-Load लगभग 7s, Load लगभग 13s है, और यह 70 से अधिक फ़ाइलों में 7MiB, लगभग 10,000 पंक्तियाँ लाता है
    • steady-state heap लगभग 68MiB है, और gzip समर्थित है लेकिन zstd समर्थित नहीं है
    • मूल्यांकन D+ है; कहा गया है कि यह GitHub जितना फिजूलखर्च नहीं है, लेकिन बहुत अधिक resources लाता है और उनका सही उपयोग नहीं कर पाता
    • यह 1MiB से अधिक JavaScript और CSS लाता है, लेकिन उसका कुछ हिस्सा वास्तव में बिल्कुल इस्तेमाल नहीं होता, और उपयोग में आने वाले कोड में भी 3MiB chunk है जिसे parse करने में ही 255ms लगते हैं
    • माना गया है कि landing page को 55,000 पंक्तियों की CSS की जरूरत नहीं है, और CSS व JavaScript दोनों को मौजूदा स्तर के लगभग दसवें हिस्से तक घटाया जा सकता है

  • Codeberg/Forgejo

    • Content-Load 2.9s, Load 3.1s है, और यह 11 फ़ाइलों में 1MiB, लगभग 1,100 पंक्तियाँ लाता है
    • steady-state heap लगभग 14MiB है, और यह gzip और zstd दोनों को समर्थित नहीं करता
    • मूल्यांकन C+ है; कहा गया है कि बुनियाद ठीक है, लेकिन बारीकियों और अनुभव पर ध्यान की कमी है
    • HTML minify न करना एक छोटी समस्या मानी गई है, लेकिन compression का समर्थन न होना बड़ी कमी माना गया है
    • समस्या के रूप में यह बताया गया है कि अधिकांश JavaScript और CSS पेज rendering के लिए जरूरी नहीं हैं, फिर भी वे rendering-blocking तरीके से लोड होते हैं
    • सुझाव दिया गया है कि requests की संख्या घटाने के लिए JavaScript और CSS payload को मिलाया जाए, और HTML समेत HTTP payload पर gzip और zstd compression का समर्थन दिया जाए
    • यह भी एक फायदा बताया गया है कि यह free software है, इसलिए किसी दूसरे instance या self-hosting पर migrate किया जा सकता है

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html को Content-Load 76ms, Load 1.1s, 5 फ़ाइलें 766KiB, और लगभग 3,800 पंक्तियों के रूप में मापा गया
    • एकल HTML फ़ाइल 576KiB है और zstd से compress होकर लगभग 70KiB तक आ जाती है
    • steady-state heap लगभग 11MiB है, और यह zstd व gzip दोनों को समर्थित करता है
    • मूल्यांकन A- है; कुल मिलाकर अच्छा माना गया है, लेकिन HTML को compression ध्यान में रखने पर भी बड़ा और दोहरावपूर्ण बताया गया है, और एक request में पूरी हो सकने वाली page को 5 requests की जरूरत पड़ती है

सिर्फ उत्पाद के बिगड़ने की नहीं, लागत की समस्या

  • “enshittification” को इस प्रक्रिया के रूप में संक्षेपित किया गया है कि एक अच्छा product पहले users और business customers के पक्ष में शुरू होता है, फिर users के खिलाफ बदलता है, फिर business customers के भी खिलाफ बदलता है, और अंततः operator के पक्ष में हो जाता है
  • कहा गया है कि Microsoft और GitHub का Embrace, Extend, Extinguish से भी संबंध पूरी तरह अलग नहीं है, लेकिन यहाँ की समस्या अलग है क्योंकि यह users और business customers ही नहीं, Microsoft के लिए भी लागत पैदा करती है
  • फूला हुआ codebase सीधे server और bandwidth लागत बढ़ाता है, और साथ ही अस्थिर और भारी codebase को बनाए रखने में engineering समय परोक्ष रूप से खर्च कराता है
  • यदि माना जाए कि GitHub में लगभग 800 engineers हैं और हर व्यक्ति सप्ताह में 40 घंटे, साल में 48 सप्ताह काम करता है, तो यह प्रति वर्ष 1,536,000 engineer-hours के बराबर होता है
  • माना गया है कि frontend की अधिकांश समस्याएँ सिर्फ pagespeed की सिफारिशों का पालन करने से ही सक्षम engineers द्वारा एक सप्ताह के भीतर ठीक या कम की जा सकती हैं
  • तर्क दिया गया है कि low-level सुधार लागत घटा सकते हैं, फिर भी उनके उपेक्षित रहने का कारण या तो उदासीनता, चरम अक्षमता, या AI और investors-केंद्रित leadership द्वारा अवरोध है
  • software को एक शक्तिशाली और सुंदर औज़ार के रूप में बताया गया है, क्योंकि एक बार उसे सही तरीके से लिख दिया जाए तो उसे पूरी तरह, हमेशा के लिए, और मुफ्त में कॉपी कर सभी के उपयोग के लिए उपलब्ध कराया जा सकता है
  • निष्कर्ष यह है कि GitHub और समान सेवाओं की फिजूलखर्ची और अक्षमता सिर्फ एक खराब product नहीं, बल्कि software के खिलाफ अपराध है

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

1 टिप्पणियां

 
GN⁺ 22 시간 전
Lobste.rs टिप्पणियाँ

  • अच्छा होता अगर इस तुलना में Trac और Sourcehut भी शामिल होते

  • 4 AI agent बटन मज़ेदार हैं, और लेख में दिए गए सापेक्ष आँकड़े भी दिलचस्प हैं, लेकिन मैं GitHub का बचाव करने की कोशिश बिल्कुल नहीं कर रहा हूँ फिर भी लेख के कुछ विवरणों में संदर्भ की कमी है, इसलिए वे लेखक की दलील को पर्याप्त रूप से समर्थन देते नहीं लगते
    idle memory usage इस बात का संकेत हो सकता है कि GitHub, Codeberg की तुलना में ज़्यादा काम कर रहा है, लेकिन 48GB RAM computer पर absolute RAM usage की तुलना Apollo guidance computer से करके कोई सार्थक निष्कर्ष निकालना मुश्किल है
    minified JavaScript bundle को format करके lines of code का अनुमान लगाना, और फिर dependency को छोड़कर किसी Zig project की line count से उसकी तुलना करना भी apples-to-oranges तुलना है। फिर तो Zig executable को decompile करके देखना चाहिए कि उसमें कितनी lines निकलती हैं
    Codeberg के लिए यह सिफारिश भी समझ नहीं आती कि “requests की संख्या कम करने के लिए JavaScript और CSS payloads को जोड़ देना चाहिए।” HTTP request के “extra overhead” की बात देखकर तो यह भी संदेह होता है कि लेखक को HTTP/2 के बारे में पता है या नहीं
    web page performance पर और भी बहुत कुछ कहा जा सकता है, लेकिन वह किसी अलग पोस्ट के लिए छोड़ता हूँ, और इसी तरह के विषय पर बेहतर नज़रिए के लिए Danluu की 2017 वाली web bloat पोस्ट फिर से पढ़ने की सलाह दूँगा: https://danluu.com/web-bloat

  • अगर लेखक यह देख रहा हो, तो Casey Muratori और Uncle Bob की बहस भी देखना अच्छा रहेगा। पहले वाले ने काफी दिलचस्प performance regression ढूँढा था
    “मैं खुद को रोक नहीं पाया और Chrome performance capture देख लिया, और मुझे पता चल गया कि culprit कौन था :) वह ‘emoji picker’ था!”
    “मैंने code बस सरसरी तौर पर देखा, लेकिन लगता है कि दिक्कत यह है कि हर character type करने पर ‘emoji picker’ पीछे जाकर यह जाँचता है कि अभी जो type किया गया वह emoji है या नहीं”
    उफ़। हालाँकि इस मामले में culprit GitHub frontend code नहीं बल्कि Chromium-based browser भी हो सकता है

  • यह कहना कि “Codeberg स्वतंत्र donations पर निर्भर है और free volunteers द्वारा दिया गया product है” सही नहीं है
    Codeberg members पर निर्भर है। सिर्फ membership fee के मामले में नहीं, policy के स्तर पर भी, और अभी membership fee भर से full-time staff रखना संभव नहीं है इसलिए यह volunteers पर काफ़ी निर्भर है, लेकिन मेरी समझ से contractors भी हैं
    मैंने Codeberg को बहुत गहराई से follow नहीं किया है (मैं sourcehut को पसंद करता हूँ), लेकिन cooperative होना उसके value proposition के मुख्य हिस्सों में से एक है। वह अपने खर्च भी पारदर्शी ढंग से प्रकाशित करने की कोशिश करता है। उदाहरण: https://blog.codeberg.org/codebergs-budget-of-2026.html
    अगर आप Codeberg इस्तेमाल करते हैं, तो अभी member बनने पर विचार कर सकते हैं: https://join.codeberg.org/

  • मुझे GitHub सच में नापसंद है। मेरी समस्या uptime नहीं है, बल्कि यह है कि यह बेहूदगी की हद तक धीमा है और बहुत memory खाता है। “इस आकार का diff default रूप से नहीं दिखाया जाता” — क्या यह सच में गंभीर हैं
    यह एक तर्कसंगत development workflow में भी टूटा हुआ है। PR को rebase करो तो review feedback और comments गायब हो जाते हैं, commit को squash करो तो review feedback और comments भी गायब हो जाते हैं
    किसी खास comment का link हो, तब भी अगर वह commit गायब हो जाए तो comment भी साथ गायब हो जाता है \o/
    bug fix हो तो PR बनाने को कहा जाता है, और अगर वह bug किसी दूसरे change से ठीक भी हो जाए, तब भी PR और bug एक ही स्तर पर मौजूद रहते हैं, इसलिए dead PR review queue में हमेशा पड़ा रहता है
    अगर मैं जानना चाहूँ कि इस commit ने कौन-सा bug ठीक किया, तो यह मुझे सिर्फ PR history दिखाता है। जैसे bug नहीं, PR देखो; और bug जानना है तो खुद जाकर bug ढूँढो

    • “pull request” का concept खुद git की तरह Linux kernel development से आया है। इसमें kernel maintainer से patch को mainline में “pull” करने का अनुरोध किया जाता है
      GitHub ने इस flow को “fork” बटन से और आसान बनाया, centralized usernames लाकर इसे ज़्यादा “social” बना दिया, फिर issue tracker और wiki जोड़कर दुनिया पर कब्ज़ा कर लिया। व्यावसायिक रूप से यह वाकई प्रतिभाशाली कदम था
      लेकिन पूरा flow अब भी open source development के लिए बना है, जहाँ अलग-अलग लोग patches को “pull” करने का अनुरोध करते हैं
      जिन करीबी development teams का असली mechanism “branch पर चर्चा करो और merge approve करो” है, उन्हें “pull request” क्यों इस्तेमाल करना चाहिए, यह मेरी समझ से बाहर है। pull आखिर किससे करना है? सब कुछ उसी repository में है, और changes पहले ही push किए जा चुके हैं
      terminology की बात छोड़ भी दें, तो stacked changes, stable comments, और changeset diff की कमी समझ से परे है
      फिर से यह उबाऊ GitHub शिकायत पोस्ट करने के लिए माफ़ी। क्या कोई बेहतर विकल्प है? हाँ, मैं किसी को उसे इस्तेमाल करने पर मजबूर तो नहीं कर सकता…

  • “axis labels या individual data points के बिना graph हमेशा संदिग्ध लगते हैं” जैसी प्रतिक्रिया मैंने GitHub द्वारा प्रकाशित graphs के बारे में कई बार देखी है
    graph में maximum values दिख रही हैं, इसलिए दृश्य रूप से यह अनुमान लगाया जा सकता है कि y-axis के midpoint लगभग 45M, 0.7B, 10M हैं। बेशक, जब तक यह चुपके से log scale न हो और load 100000 गुना न बढ़ा हो
    मैं यहाँ खराब graph को “suspicious” नहीं कहूँगा, बस communication में कमजोर कहूँगा। व्यक्तिगत रूप से मुझे raw ggplot output लगभग हमेशा बेहतर लगती है
    कुल भावना से मैं सहमत हूँ, लेकिन मोटे घोड़े और बहुत सारी tables वाले हिस्से में थोड़ा साथ बनाए रखना मुश्किल लगा। हालाँकि, अगर मैं GitHub की हर कमी की सूची बना रहा होता, तो शायद मैं भी पागल होकर मोटे घोड़े पर सवार होकर सूर्यास्त में गायब होने के सपने देखने लगता
    मैंने भी इसी तरह सूची बनानी शुरू की थी, लेकिन UX/performance समस्याएँ लगभग 12 तक पहुँचते-पहुँचते छोड़ दिया
    इस लेख का thorough analysis अच्छा है, और उम्मीद है GitHub team इसे सच में ध्यान से देखेगी
    जैसा मैंने पहले कहा था, Microsoft को GitHub पर कुछ performance engineers लगाने चाहिए। जब तक मुख्य performance metrics सच में key performance indicators का हिस्सा नहीं बनते, यह bloat बढ़ता रहेगा और दूसरे platforms ज़्यादा आकर्षक लगेंगे। अगर अगला GitHub CEO आए, तो उम्मीद है वह इसे प्राथमिकता देगा

    • आप मान रहे हैं कि graph का y-axis 0 से शुरू होता है। इस तरह के business-style graphs में ऐसा बहुत बार नहीं होता
      “ज़बरदस्त growth” दिखाने के लिए graph line पूरे चित्र क्षेत्र को तिरछे काटती हुई जाती है, लेकिन y-axis केवल 100 से 101 तक होती है — ऐसा काफ़ी आम है

  • मैं इस बात से सहमत हूँ कि “GitHub Actions logs memory leak करते रहे हैं और कई सालों से मेरे browser को क्रैश करते रहे हैं, और stdout को कहीं बस pipe कर देने का तरीका अभी भी नहीं है”
    दुर्भाग्य से Forgejo ने भी यह विरासत में पाया है। कई बार failed build notification मिलने पर मैं जल्दी से phone पर देखना चाहता हूँ, लेकिन काफ़ी बार phone browser output को लोड ही नहीं कर पाता

  • इस लेख पर क्लिक करते समय मुझे पूरा यक़ीन था कि यह GitHub uptime पर एक और शिकायत होगी, लेकिन यह देखकर सुखद आश्चर्य हुआ कि इसमें GitHub, GitLab, Codeberg की मौजूदा समस्याओं का शांत और तर्कसंगत मूल्यांकन किया गया है और solutions भी सुझाए गए हैं
    अच्छा होता अगर तुलना में Tangled भी शामिल होता
    लेखक को थोड़ा CSS लिखना चाहिए ताकि साइट mobile पर भी पढ़ी जा सके। मुझे browser reading mode इस्तेमाल करना पड़ा
    एकमात्र बात जिससे मैं सहमत नहीं हूँ, वह यह दावा है कि किसी भी site को एक से ज़्यादा JavaScript/CSS files नहीं लानी चाहिए
    अगर वे 5.5 लाख lines of JavaScript सब एक ही file में हों, तो parsing और execution में बहुत ज़्यादा समय लगेगा। CSS को bundle किया जा सकता है, लेकिन उदाहरण के लिए एक common chunk और एक route-specific chunk वाला pattern उपयोगी हो सकता है। इस तरह का approach या ऐसा ही कुछ व्यापक रूप से इस्तेमाल होगा, ऐसा लगता है

  • यह पेज पढ़ा ही नहीं जा सकता
    और अगर GitHub पसंद नहीं है, तो उसे मत इस्तेमाल करो। हैरानी होती है कि लोगों के पास इतनी लंबी शिकायत सूची इकट्ठी करने का समय है। या तो वे इसके लिए पैसे पा रहे हैं, या फिर कोई और चीज़ इस्तेमाल कर सकते हैं