GitHub से Dillo परियोजना का स्थानांतरण

 (dillo-browser.org)
2 पॉइंट द्वारा GN⁺ 2025-12-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब ब्राउज़र Dillo परियोजना को GitHub से अपने स्वयं-होस्टेड सर्वर पर स्थानांतरित किया जा रहा है।
  • GitHub की JavaScript निर्भरता, एकल नियंत्रण संरचना और धीमी परफॉर्मेंस को मुख्य कारणों में बताया गया।
  • नया सर्वर dillo-browser.org डोमेन पर चलाया जा रहा है, जिसमें cgit आधारित हल्का Git फ्रंटएंड और स्वयं निर्मित बग ट्रैकर ‘buggy’ का उपयोग होता है।
  • सभी डेटा को git रिपॉज़िटरी के रूप में प्रबंधित करके Codeberg और Sourcehut में मिरर किया जाता है, जिससे डेटा हानि का जोखिम न्यूनतम होता है।
  • OpenPGP सिग्नेचर के जरिए DNS खोने पर भी भरोसेमंदी बनी रहे, इसलिए यह डिज़ाइन किया गया है, जिससे परियोजना की स्वतंत्रता और दीर्घकालिक स्थिरता मजबूत होती है।

पृष्ठभूमि

  • पहले Dillo की मूल साइट dillo.org थी और इसमें Mercurial रिपॉज़िटरी, मेल सर्वर, बग ट्रैकर और मेलिंग लिस्ट आर्काइव शामिल थे।
    • 2022 में डोमेन खो गया और एक तीसरे पक्ष ने AI विज्ञापनों से भरी समान साइट बना दी।
    • कुछ सामग्री फिर भी वापस नहीं मिल पाई, जबकि कुछ हिस्सा पुनर्प्राप्त हुआ।
  • इसी अनुभव के कारण एक ही साइट पर निर्भरता से बचने और वितरित बैकअप संरचना बनाने का फैसला किया गया।
  • शुरुआत में कोड GitHub पर अपलोड किया गया, लेकिन लंबी अवधि के लिए इसे उपयुक्त नहीं माना गया।

GitHub की समस्याएं

  • GitHub CI workflow और रिपॉज़िटरी प्रबंधन में उपयोगी था, लेकिन इसमें कुछ सीमाएं हैं।
    • JavaScript के बिना फ्रंटएंड काम नहीं करता, इसलिए Dillo ब्राउज़र से issues या PR नहीं देखे जा सकते।
    • पेज अनावश्यक रूप से संसाधन खर्च करता है, जिससे सादा HTML rendering पर अतिरिक्त लोड आता है।
  • एकल नियंत्रण इकाई के कारण किसी खाते के ब्लॉक होने का जोखिम था, जिससे डेटा एक्सेस बंद हो सकता है।
  • प्लेटफॉर्म लगातार धीमा होता जा रहा है और तेज इंटरनेट कनेक्शन की जरूरत बढ़ा रहा है।
  • GitHub का “push model” नोटिफिकेशन तरीका ऑफलाइन-आधारित डेवलपमेंट वर्कफ़्लो से मेल नहीं खाता।
  • गैर-डेवलपर यूज़र्स का अनुपात ज्यादा होने वाली परियोजनाओं के लिए community management tools की कमी से डेवलपर थकान बढ़ती है।
  • GitHub के LLM और जनरेटिव AI की तरफ़ बढ़ते फोकस के कारण साइटें LLM crawlers को रोकने के लिए JavaScript wall या browser fingerprint tracking को सख्त कर रही हैं।
    • इससे Dillo उपयोगकर्ताओं की पहुँच पर प्रतिबंध जैसी समस्या पैदा हुई।

स्व-होस्टिंग सेटअप

  • मौजूदा रिपॉज़िटरी सेवाएँ सिंगल फेल्योर पॉइंट हटाने और हल्का ऑपरेशन दोनों को एक साथ पूरा नहीं कर पा रही थीं।
    • इसलिए हमने खुद का सर्वर चलाने और कई मिरर रखने का निर्णय लिया।
  • हमने dillo-browser.org डोमेन खरीदा और एक छोटा VPS सर्वर सेट किया।
    • अपेक्षा से ज्यादा स्थिरता के साथ यह चल रहा है और मुख्यतः AI bot ट्रैफिक को संभाल रहा है।
  • Git फ्रंटएंड के लिए cgit चुना गया।
    • यह C भाषा में लिखा गया है, इसलिए RAM और CPU उपयोग कम है और यह JavaScript के बिना काम करता है।
    • Dillo में ठीक से दिखे इसके लिए CSS में कुछ बदलाव किए गए।
    • https://git.dillo-browser.org/ से एक्सेस किया जा सकता है।
  • बग ट्रैकर के लिए स्वयं बनाया गया ‘buggy’ इस्तेमाल होता है।
    • Markdown फाइलों को parse करके HTML पृष्ठ बनाए जाते हैं, और प्रत्येक बग git रिपॉज़िटरी में सेव होता है।
    • commit के समय git hook अपने-आप पृष्ठ अपडेट कर देता है।
    • ऑफलाइन एडिट संभव, सुरक्षा जोखिम की चिंता नहीं।
    • https://bug.dillo-browser.org/ पर उपलब्ध।
  • मेलिंग लिस्ट आर्काइव को 3 बाहरी सेवाओं में वितरित करके सहेजा गया है, आगे चलकर इसमें खुद की अतिरिक्त कॉपी जोड़ने की योजना है।

मिरर सेटअप

  • सभी मुख्य डेटा git रिपॉज़िटरी फॉर्मेट में रखे हैं और Codeberg तथा Sourcehut पर मिरर किए गए हैं।
    • अगर कोई रिपॉज़िटरी बंद हो जाए, तो कम ट्रांसिशन खर्च के साथ उसे अन्य मिरर पर शिफ्ट किया जा सकता है।
  • एकल फेल्योर पॉइंट अब DNS (dillo-browser.org) है।
    • DNS खोने पर मेलिंग लिस्ट, Fediverse और IRC के जरिए यूज़र्स को सूचित किया जा सकता है।
    • डेटा पहले से ही git में प्रतिलिपि होने के कारण गंभीर डेटा हानि नहीं होगी।

OpenPGP सिग्नेचर

  • यह पेज Rodrigo Arias Mallo के GPG key (32E65EC501A1B6FDF8190D293EE6BA977EB2A253) से साइन है।
    • यही key Dillo की latest release में भी मौजूद है और GitHub अकाउंट में भी register है।
    • signature फाइल (index.html.asc) <link rel=signature> से लिंक की गई है।
  • OpenPGP सिग्नेचर से DNS खोने पर भी ट्रस्ट बना रहता है।
    • TLS certificate chain के बजाय सिग्नेचर-आधारित ट्रस्ट से ownership प्रमाणित की जाती है।
    • सभी git मिररों में सिग्नेचर शामिल करके डेटा हानि सहनशीलता और मजबूत की गई है।

माइग्रेशन की प्रगति और भविष्य

  • GitHub repo तुरंत हटाया नहीं जाएगा, माइग्रेशन समाप्त होने तक अपडेट मिलते रहेंगे।
    • समाप्ति के बाद रिपॉज़िटरी को ‘archived’ स्थिति में बदलकर ऑफिशियल साइट पर घोषणा करने की योजना है।
    • पुराने कमिट और रिलीज़ फाइलें backward compatibility के लिए रखी जाएंगी।
  • नया इंफ्रास्ट्रक्चर कम खर्च और कम ऊर्जा खपत पर स्वतंत्र रूप से चल सकता है।
    • वर्तमान दान और server खर्च के आधार पर इसे कम से कम 3 साल तक चलाने की संभावना है।
    • सहायता करना चाहें तो Liberapay के जरिए योगदान दे सकते हैं (https://liberapay.com/dillo/)

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

1 टिप्पणियां

 
GN⁺ 2025-12-01
Hacker News राय

  • मैं कई सालों से GitLab को self-hosting विकल्प के रूप में इस्तेमाल कर रहा हूँ। पसंद है, लेकिन resource usage काफ़ी ज़्यादा है
    हाल में Codeberg टीम द्वारा बनाया गया Forgejo टेस्ट कर रहा हूँ, और यह सचमुच शानदार है
    सबसे बड़ा फ़र्क memory usage में है। GitLab, Ruby on Rails पर आधारित है, इसलिए कई services एक साथ चलती हैं, जबकि Forgejo, Go में लिखा गया single-binary structure है
    GitLab, 16GB VM की memory धीरे-धीरे पूरी खा जाता है, लेकिन Forgejo server और runner को साथ चलाने पर भी लगभग 300MB ही इस्तेमाल करता है
    GraphQL नहीं है, लेकिन REST API काफ़ी ठीक लगती है
    मुझे gitea और forgejo के बीच का फ़र्क ठीक से नहीं पता, लेकिन Forgejo के comparison docs देखकर लगता है कि 2022 में governance issue की वजह से soft fork हुआ था

    • हमारे स्टूडियो में करीब 50 users रोज़ git इस्तेमाल करते हैं, और हमने 2 साल पहले Forgejo पर पूरी तरह migration कर लिया था
      Go-आधारित simple structure होने की वजह से maintenance और cost बहुत कम है। हमने internal tools भी सीधे Forgejo के ऊपर बनाए हैं
      on-premise hosting होने से internet बंद हो जाए तब भी development और CI रुकते नहीं हैं। package manager cache भी support करता है, इसलिए dependency management आसान हो जाता है
    • maintenance convenience के मामले में gitea बहुत आगे है। 5 साल से ज़्यादा समय से इस्तेमाल कर रहा हूँ, और upgrade बस नई version pull करके daemon restart करने भर से हो जाता है
      GitHub की तुलना में downtime 10 गुना कम रहा है, और वह भी ज़्यादातर planned maintenance था
      जब कोई लिखता है कि GitHub की availability बेहतर है, तो हँसी आती है
    • अगर personal project है, तो मेरे हिसाब से सिर्फ़ SSH server और file system ही काफ़ी हैं
      नया repository बनाना git init --bare से हो जाता है, और backup भी अपने-आप चलते रहते हैं
      अगर अकेले development कर रहे हों, तो UI की खास ज़रूरत महसूस नहीं होती
    • Forgejo Actions basic concepts docs देखें तो CI system काफ़ी अच्छी तरह व्यवस्थित है
      मुझे लगता है GitLab-style CI, GitHub Actions से काफ़ी बेहतर है। GitHub popularity की वजह से standard बन गया, लेकिन design थोड़ा निराशाजनक है
    • अगर और minimal विकल्प चाहिए, तो Gerrit भी है। यह Java app है, किसी external DB dependency के बिना, और config व runtime information को git repo में store करता है
      सिर्फ़ shared filesystem से भी scaling और backup आसान हो जाते हैं

  • मैं अपने इलाके में एक math club चलाता हूँ, और बच्चे LaTeX और Python assignments जमा करने के लिए Forgejo इस्तेमाल करते हैं
    login management और password reset आसान होने की वजह से यह education use के लिए भी बहुत उपयोगी है

  • GitHub के push notification model से चिढ़ होने और सिर्फ़ खुद check करने पर ही updates देखना चाहने वाली बात से मैं सहमत हूँ
    email filtering का इस्तेमाल करके push notifications को pull model जैसा बनाया जा सकता है। notifications को एक dedicated folder में जमा कर दें और ज़रूरत पड़ने पर ही देखें

    • फिर भी अगर संतोष न हो, तो GitHub UI का built-in notification feature इस्तेमाल किया जा सकता है। सच कहूँ तो यह समस्या ढूँढ़ने के लिए समस्या बनाने जैसा लगता है

  • साधारण bug tracker buggy खुद बनाने वाले व्यक्ति की कहानी दिलचस्प लगी। कहा गया कि यह एक C tool है जो Markdown parse करके HTML pages बनाता है
    hacker spirit ज़िंदा है

    • लेकिन ऐसा approach शायद ही कोई अपनाएगा। मैं होता तो मुझे लगता कि इससे समस्याएँ ही बढ़ेंगी
    • यह ऐसा approach है जिसमें फायदे और नुकसान दोनों हैं

  • “push model” और “pull model” के फ़र्क के बारे में एक सवाल था

    • शायद Source Hut या Linux kernel जैसे email-based workflow की बात हो रही है। IMAP से patches को local में लाकर offline भी काम किया जा सकता है
    • push में ‘अभी तुरंत करो’ वाला समय का दबाव होता है, जबकि pull में मैं अपने तय schedule के मुताबिक check करता हूँ — यानी यह time management style का फ़र्क है

  • मुझे लगता है कि अभी कई GitHub alternatives एक साथ उभर रहे हैं, यानी यह dispersion (diaspora) phase है
    हो सकता है कुछ महीनों में main options में से एक प्रमुख बन जाए। अगर कोई बड़ी company या मशहूर व्यक्ति नया platform लाए, तो वह market lead भी कर सकता है

    • ऐसा रुझान 10 साल पहले से है। पहले GitLab पर जाने का दौर था, और आज भी GitHub की discoverability अब भी बेजोड़ है
      GitHub छोड़ने वाले projects बहुत कम हैं, इसलिए अभी कहना जल्दबाज़ी होगी
    • हर developer का collaboration style अलग होता है, इसलिए एक ही solution पर convergence होना मुश्किल है
      बल्कि re-decentralization हो रहा है। अब हर कोई अपने control, jurisdiction और workflow के हिसाब से forge चुन रहा है
    • आगे का लक्ष्य GitHub जैसी centralized structure नहीं, बल्कि federation की ओर जाना है। यानी किसी एक entity पर निर्भर न रहना
    • असली सवाल यह है कि क्या हम ‘एक replacement’ चाहते हैं, या 5 साल बाद फिर यही स्थिति दोहराना चाहते हैं
    • हम अभी ठीक वही कोशिश कर रहे हैं। Tangled नाम का एक indie-focused collaboration platform तैयार कर रहे हैं, और जल्द बड़ी घोषणा होगी

  • मैं Dillo project को Tangled पर आमंत्रित करना चाहूँगा → tangled.org

    • यह बिना JavaScript के भी अच्छी तरह काम करता है, यह बात प्रभावशाली लगी
    • अच्छा होगा अगर यह Git के अलावा दूसरे version control systems भी support करे

  • मुझे लगता है GitHub की सबसे बड़ी समस्या इसकी धीमी होती usability है

    • “more and more slow” अभिव्यक्ति स्वाभाविक है या नहीं, यह जानना चाहता हूँ। “slower and slower” ज़्यादा सामान्य है क्या?
    • पहले ठीक था, लेकिन हाल में page loading बहुत धीमी हो गई है। शायद सिर्फ़ React की वजह से नहीं है
      code navigation के लिए github.dev काम आता है, लेकिन PR और Actions अब भी धीमे और परेशान करने वाले हैं

  • अगर आप VM पर Forgejo install करना चाहते हैं, तो मैंने एक script बनाई है जो server और runner को एक साथ set up कर देती है → easyforgejo

  • इस विषय में मैं विशेषज्ञ नहीं हूँ, लेकिन इसे पढ़ना दिलचस्प लगा
    यह देखकर हैरानी हुई कि सिर्फ़ एक version control system set up करने में इतने सारे factors होते हैं
    मैं Fossil इस्तेमाल करता हूँ, और छोटी organizations में जहाँ developer, system administrator और support person की ज़िम्मेदारी अकेले निभानी हो, वहाँ यह काफ़ी सरल है
    GitHub की deploy key restrictions भी असुविधाजनक हैं। कई apps और servers चलाते समय हर key को अलग-अलग सेट करना पड़ता है, जो काफ़ी झंझट भरा है