GitHub incident के बिना बीते दिन

 (dayswithoutgithubincident.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Days Without GitHub Incidents एक ऐसा पेज है जो GitHub incident के बिना बीते दिनों की संख्या दिखाता है
  • फिलहाल दिनों वाला हिस्सा सिर्फ ... days के रूप में दिखता है, इसलिए सटीक संख्या की पुष्टि नहीं हो पाती
  • High Score को 2026 वर्ष के रूप में दिखाया गया है
  • पेज पर दिखाई देने वाले मुख्य आँकड़े मौजूदा दिनों की संख्या और High Score हैं
  • मौजूदा दिनों की संख्या अंक के बजाय placeholder के रूप में दिखाई देती है

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • मैंने हाल ही में अपने सभी प्रोजेक्ट्स को self-hosted Forgejo इंस्टेंस पर शिफ्ट किया है, और अब तक काफ़ी संतुष्ट हूँ। यह तेज़ भी है
    अगर आप GitHub का विकल्प ढूँढ रहे हैं, तो इसे देखना ठीक रहेगा; विकल्प मौजूद हैं

    • अब यह ट्रेंड में नहीं है, लेकिन self-hosted GitHub alternatives में Phabricator का सम्मानपूर्वक ज़िक्र होना चाहिए
      बल्कि इसका “पुराना” UI आजकल की दूसरी चीज़ों के बहुत ख़राब हो जाने के बीच एक फ़ायदे जैसा लगता है
    • मुझे GitHub से हमेशा एक तरह की अनिच्छा रही, लेकिन git पहली बार देखने के तुरंत बाद से ही प्रभावशाली लगा
      मैंने अपने पर्सनल प्रोजेक्ट्स को एक पुराने Gitea इंस्टेंस से Forgejo में शिफ्ट किया, और मैं बहुत संतुष्ट हूँ
    • Gitea कैसा है?

  • मुझे नहीं लगता कि पूरे प्लेटफ़ॉर्म को एक ही संख्या में समेट देना उचित है। यह कुछ वैसा है जैसे पूरे AWS को एक ही संख्या में जोड़ देना

    • दूसरी तरफ़, अगर आप किसी हद तक जटिल deployment चला रहे हैं, तो CPU, memory, I/O, application metrics, subscribers, active users/sessions जैसे dashboards में दब जाना बहुत आसान है
      इसलिए पूरे सिस्टम की स्थिति को एक single number में व्यक्त करने का तरीका सोचना उपयोगी है। उदाहरण के लिए active user sessions को database connections की संख्या से भाग देकर memory capacity के हिसाब से normalize किया जा सकता है
      अगर वह एक single-digit संख्या हो, तो उसके सामान्य दायरे की आदत पड़ जाती है और उसे हमेशा किसी साफ़ दिखने वाली जगह पर रखा जा सकता है। यह details नहीं दिखाती, लेकिन अगर value बदलती है तो फिर specific metrics देखने जा सकते हैं, इसलिए बुनियादी “सब ठीक है?” जाँच के shorthand के रूप में यह अच्छी तरह काम कर सकती है
    • अगर status page को अभी की तरह टुकड़ों में बाँटकर git push और git pull outages को अलग-अलग track किया जाए, और यह बात बस हल्की अतिशयोक्ति वाला मज़ाक भर न लगे, तो यह आँखों में धूल झोंकना और SLA को फुलाना के क़रीब है, और इसे नज़रअंदाज़ नहीं किया जाना चाहिए
      Git, issues, pull requests, Actions जैसे core areas हैं जिन्हें लगभग हर कोई इस्तेमाल करता है, और उनमें से एक भी टूट जाए तो साइट टूटी हुई मानी जानी चाहिए। Status page को दिखाना चाहिए कि ऐसा कितनी बार होता है
    • यह साफ़ तौर पर एक meme site है, और संख्या जितनी कम हो, meme उतना मज़ेदार बनता है
      जो लोग सच में सटीक जानकारी ढूँढ रहे होंगे, वे official status page पर ही जाएँगे
    • अगर सिर्फ़ S3, EC2, EKS, RDB को लें और उनकी uptime अभी पूरे GitHub जैसी होती, तो सबको पता होता
      repository wiki, commit stats, gist जैसी चीज़ों में ऐसी दिक्कतें आना इतना महत्वपूर्ण नहीं है। महत्वपूर्ण है PR, Actions, Discussions जैसी services का संयोजन, जिन्हें साथ में इस्तेमाल किया जाता है और जो एक-दूसरे पर निर्भर हैं
      दोनों systems के हर component के लिए एक single percentage भी बना दें, तब भी GitHub ही पीछे रहेगा। शायद बिना outage वाले दिन कुछ ज़्यादा हो जाएँ, लेकिन यह कोई सरल तुलना नहीं है
    • user के नज़रिए से यह गणना समझ में आती है। लेकिन MSFT या GitHub के नज़रिए से यह संख्या काफ़ी शर्मनाक metric है
      वे चाहेंगे कि लोग प्लेटफ़ॉर्म की हर सुविधा का इस्तेमाल करें और मज़बूत dependency बने, लेकिन अगर कुछ हिस्से लगातार टूटते रहें, तो users को और features अपनाने का भरोसा मिलना मुश्किल है
      जितनी ज़्यादा चीज़ें आप इस्तेमाल करते हैं, उनमें से किसी एक के समस्या पैदा करने की संभावना उतनी बढ़ती है, लेकिन अब ऐसा लगता है कि इन कंपनियों के लिए reliability लक्ष्य ही नहीं रही

  • हमारे लिए यह सचमुच business continuity का मुद्दा है। हम कुछ हद तक GitHub Enterprise में बँधे हुए हैं, लेकिन अगर यह हालत जारी रही, तो हमें cloud से on-premises पर जाना पड़ सकता है

    • अगर आप उस दिशा में जाते हैं, तो ज़रूरी है कि सभी Actions को local में cache करके रखा जाए। नहीं तो बहुत ज़्यादा फ़र्क नहीं पड़ेगा

  • मैं अभी tangled.org पर इस्तेमाल के लिए self-hosted Knot सेट कर रहा हूँ
    मुख्य वजह यह है कि AtProto शानदार है और self-hosting मज़ेदार है, लेकिन यह भी कि मैं उस infrastructure का मालिक बनना चाहता हूँ जो मेरे प्रोजेक्ट्स को host करता है
    इस मामले में Tangled का Knot system एक मज़बूत abstraction जैसा लगता है। Data को AtProto Repository में host किया जाता है, लेकिन उसे दुनिया के सामने दिखाने वाले AtProto Application की hosting और management किसी third party को सौंपी जा सकती है
    अगर Tangled गायब भी हो जाए, तो मैं अपना AtProto login किसी दूसरे platform पर ले जाकर अपने Knot की तरफ़ point कर सकता हूँ, और hosting setup वैसे का वैसा रह सकता है। इंटरनेट के किसी कोने में अलग-थलग पड़े पूरे web app को ख़ुद host करने की तुलना में यह काफ़ी ज़्यादा सुविधाजनक है

  • यहाँ GitHub का बचाव करने वाली बहुत-सी बातें हैं। कई अरब डॉलर की कंपनी का बचाव करना थोड़ा अजीब है, ख़ासकर तब जब वही open source software के भारी बहुमत की मेज़बानी कर रही हो
    शायद goodwill काम कर रही हो। लेकिन जिन प्रोजेक्ट्स से आप प्यार करते हैं उनमें हिस्सा लेने के लिए किसी बड़ी कंपनी की internal politics और practices को स्वीकार करना पड़े, यह बात हमेशा निगलने में मुश्किल रही है। मुझे GitHub का कोई कर्ज़ महसूस नहीं होता
    ख़ासकर तब और भी नहीं, जब वे अपनी तरफ़ का सौदा निभा न पाएँ। Azure credits के ढेर जैसे बड़े मुआवज़े के बदले वे दुनिया भर के software repositories तक खुली पहुँच रखते हैं

    • सवाल को उल्टा करके देखें तो, GitHub का विरोध करने की ऐसी क्या वजह है कि operations बनाए रखने की कोशिश कर रहे साथी इंसानों को न्यूनतम दयालुता और सम्मान भी न दिया जाए?
      क्या आप business entity और उसके पीछे मेहनत करने वाले लोगों को अलग करके नहीं देख सकते?
      उन्हें भी पता है कि हमारी तरह लोग उन पर निर्भर हैं। उन्हें पता है कि उनकी service दुनिया की software development क्षमता के “dial tone” जैसी है, और वे उसके असर को लेकर संवेदनशील भी हैं
      #hugops कहाँ गया? क्या वह बस इसलिए गायब हो जाता है क्योंकि वे लोग ऐसी कंपनी में काम करते हैं जो आपको पसंद नहीं?
    • ठीक-ठीक कहें तो यह Microsoft जैसी trillion-dollar company का बचाव है
    • मुझे लगता है यह इस बात पर निर्भर करता है कि आप पैसे दे रहे हैं या नहीं। अगर आप भुगतान करते हैं, तो आपकी अपेक्षाएँ मज़बूत होनी चाहिए और जवाबदेही भी माँगी जानी चाहिए
      अगर आपको मुफ्त service मिल रही है, तो नाराज़ होना भी उचित है, लेकिन साथ ही आपको उतना ही मिल रहा है जितना आपने चुकाया है
    • यह हैरानी की बात है कि acquisition के बाद भी GitHub के बारे में धारणा ज़्यादा नहीं बदली
      WSL के साथ मिलकर बहुत से लोगों के लिए संतुलन बन गया था, और लगता था कि Microsoft फिर से “चलो, फिलहाल भरोसा कर लेते हैं” वाली तरफ़ आ गया है
      यह मामला सिर्फ़ operations cost ही नहीं, बल्कि अब तक की बहुत-सी goodwill भी वापस ले रहा है। अचानक नकारात्मक कवरेज ज़्यादा दिखने लगी है और उसे नज़रअंदाज़ करना मुश्किल हो गया है
    • कई अरब डॉलर की कंपनी का जान लगाकर बचाव करने वाले दो समूह हैं: HN users और Nintendo fans

  • कहा जा रहा है कि GitHub के commits साल-दर-साल 14 गुना बढ़ गए हैं

    • क्या AI agents इसे spam की तरह ठेल रहे हैं?
    • यह commits हैं, या pushes? load measurement के नज़रिए से commits की संख्या कोई ख़ास मायने रखने वाला मानदंड नहीं है
    • 14 गुना तो पागलपन वाली बात है। ख़ासकर जब real-world software की quality और quantity में लगभग कोई बदलाव नहीं आया
      उम्मीद की जा सकती थी कि नई agent-style coding क्षमता से असली value बनेगी और quality सुधरेगी। लेकिन जो दिख रहा है वह enshittification और ठहराव है। आख़िर इन सारे tokens से हो क्या रहा है?
    • अगर GitHub के commits साल-दर-साल 14 गुना बढ़ गए, तो उससे क्या?
      अगर Microsoft scale नहीं कर सकता, तो फिर कौन कर सकता है? अगर वे service नहीं दे सकते, तो जब तक दे सकें तब तक उसे बेचना बंद कर देना चाहिए
      यह 90 के दशक के बीच वाले AOL dial-up busy signal fiasco की पुनरावृत्ति है। बस फ़र्क इतना है कि इस बार लोग गुस्सा होने के बजाय उस बेचैन और थकी हुई trillion-dollar company के लिए बहाने बना रहे हैं
    • मेरे लिए यह समझना सचमुच मुश्किल है कि अगर यह AI commits की वजह से है और पूरी कहानी सिर्फ़ traffic volume की है
      single-digit order की वृद्धि, यानी करीब 14 गुना load increase, से इस स्तर के outages नहीं होने चाहिए
      GitHub जो काम करता है और उसका throughput, अगर उसकी तुलना social media companies, payment companies, video platforms वगैरह से करें, तो यह मानना मुश्किल है कि यह सिर्फ़ load problem है
      यह ज़्यादा उस स्थिति जैसा लगता है जहाँ पहले से बुनियादी समस्याएँ झेल रहे platform पर बढ़ा हुआ load चढ़ गया हो और उसने सब कुछ और बढ़ा दिया हो

  • यह मज़ाक इसलिए काम करता है क्योंकि सुविधा के लिए हम सबने चुपचाप काफ़ी concentration risk स्वीकार कर लिया है

  • https://repo.autonoma.ca/treetrek
    यह मेरा बनाया हुआ free open source, minimal-feature, no-cache, no-dependency, no-authentication/no-authorization वाला शुद्ध PHP raw Git viewer है
    GitList ने cache bug की वजह से shared hosting की disk space और memory उड़ा दी थी, और मैंने इसे GitHub·BitBucket·GitLab repositories को एकीकृत करने के लिए बनाया
    self-hosting करने और किसी third party की मनमर्ज़ी के अधीन न रहने में एक संतोष है

  • यह app, जो शायद ज़्यादातर vibe coding app ही होगा, संभव है GitHub को डाउन कराने वाली vibe coding apps की लहर में अपना योगदान दे रहा हो
    डूबते जहाज़ को किसी तरह तैरता रखने की कोशिश कर रहे GitHub कर्मचारियों के लिए बुरा लगता है, और Microsoft ऐसा लगता है जैसे अपने ही जहाज़ को डुबाने के लिए हर संभव काम कर रहा हो