2 पॉइंट द्वारा GN⁺ 2024-03-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Radicle Heartwood प्रोटोकॉल & स्टैक

  • Radicle Heartwood, Radicle प्रोटोकॉल का तीसरा संस्करण है, जो peers के बीच code collaboration और publishing stack प्रदान करता है.
  • इस repository में Heartwood का पूरा implementation शामिल है, जिसमें user-friendly command line interface (rad) और network daemon (radicle-node) शामिल हैं.
  • Radicle को GitHub और GitLab जैसे code forge का विकल्प बनने के लिए डिज़ाइन किया गया है, और यह user sovereignty और freedom को सुरक्षित रखने वाला एक सुरक्षित, distributed और मजबूत विकल्प है.

इंस्टॉलेशन आवश्यकताएँ

  • Linux या Unix-आधारित operating system आवश्यक है.
  • Git 2.34 या उससे ऊपर का version आवश्यक है.
  • OpenSSH 9.1 या उससे ऊपर का version और ssh-agent आवश्यक हैं.

बाइनरी से इंस्टॉल करना

  • curl और tar आवश्यक हैं.
  • नवीनतम binary release इंस्टॉल करने के लिए निम्न command चलाएँ: sh <(curl -sSf https://radicle.xyz/install)

सोर्स से इंस्टॉल करना

  • Rust toolchain आवश्यक है.
  • इस repository के भीतर निम्न commands चलाकर आप Radicle stack को source से इंस्टॉल कर सकते हैं: cargo install --path radicle-cli --force --locked cargo install --path radicle-node --force --locked cargo install --path radicle-remote-helper --force --locked
  • या seed node से सीधे इंस्टॉल कर सकते हैं: cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \ radicle-cli radicle-node radicle-remote-helper

चलाना

  • system daemon और HTTP daemon के लिए Systemd unit files /systemd फ़ोल्डर में दी गई हैं. इन्हें अतिरिक्त customization के लिए शुरुआती बिंदु के रूप में उपयोग किया जा सकता है.
  • इसके अलावा, दोनों crates में Dockerfile शामिल है.
  • debug mode में चलाने का तरीका HACKING.md में देखें.

योगदान करना

  • Radicle में योगदान करने के तरीके का परिचय CONTRIBUTING.md और HACKING.md में देखें.

लाइसेंस

  • Radicle, MIT License और Apache License (Version 2.0) की शर्तों के तहत वितरित किया जाता है.
  • अधिक जानकारी के लिए LICENSE-APACHE और LICENSE-MIT देखें.

GN⁺ की राय

  • Radicle, centralized code hosting services का एक विकल्प है और user code sovereignty को मजबूत करने वाला distributed code collaboration platform है. यह developers को data ownership और privacy पर नियंत्रण देकर बहुत महत्वपूर्ण मूल्य प्रदान करता है.
  • Radicle द्वारा प्रदान किया गया distributed network किसी central server पर निर्भर नहीं करता, इसलिए इसमें service outage या censorship से मुक्त रहने का लाभ है. हालांकि, इसका असर network stability और speed पर पड़ सकता है, जिससे user experience पर नकारात्मक प्रभाव भी हो सकता है.
  • Radicle एक open source project है, जो developer community के योगदान से लगातार विकसित हो रहा है. इससे technical issues के समाधान या नई features जोड़ने में तेज़ प्रतिक्रिया संभव होती है.
  • Radicle अपनाने से पहले मौजूदा centralized services के साथ compatibility, project की security requirements, और team के भीतर adoption barriers जैसे पहलुओं पर विचार करना चाहिए.
  • समान functionality देने वाले अन्य projects में GitLab का self-hosted version या Gitea जैसे open source alternatives शामिल हैं, जो users को अपने server पर code manage करने की सुविधा देते हैं.

1 टिप्पणियां

 
GN⁺ 2024-03-06
Hacker News की राय
  • प्रोजेक्ट के सह-संस्थापक की ओर से अभिवादन और प्रोटोकॉल अंदरूनी तौर पर कैसे काम करता है, इसका विवरण देने वाले लिंक की साझा की गई है। दस्तावेज़ अभी भी तैयार किया जा रहा है।

    नमस्ते, Hacker News के सभी लोगों। मैं इस प्रोजेक्ट का सह-संस्थापक हूँ। अगर आप जानना चाहते हैं कि प्रोटोकॉल अंदर से कैसे काम करता है, तो यहाँ से शुरू करें: Radicle docs. हालांकि, docs अभी भी तैयार किए जा रहे हैं.

  • राय है कि यह प्रोजेक्ट अपने उद्देश्य के लिए उपयुक्त लगता है, लेकिन git खुद पहले से ही open source और P2P है। git बिना किसी अतिरिक्त binary के दूसरे server से जुड़कर सीधे code fetch या merge कर सकता है। git में जो कमी है, वह है code issues, wiki, discussions, GitHub Pages, और सबसे महत्वपूर्ण developer profile network। प्रोजेक्ट metadata को .git में ही शामिल करने का तरीका चाहिए, और wiki व issues में भ्रम से बचने के लिए स्वतंत्र references की ज़रूरत हो सकती है।

    यह प्रोजेक्ट अपने उद्देश्य के हिसाब से अच्छी तरह बना हुआ लगता है, लेकिन git खुद भी पहले से open source और P2P है। अलग binary इंस्टॉल किए बिना आप किसी दूसरे git server से कनेक्ट कर सकते हैं और git commands से सीधे code fetch या merge कर सकते हैं। git में जो नहीं है, वह है code issues, wiki, discussions, GitHub Pages, और सबसे महत्वपूर्ण developer profile network। प्रोजेक्ट metadata को .git में शामिल करने का कोई तरीका होना चाहिए। शायद git notes जैसी स्वतंत्र references की ज़रूरत होगी। git-notes docs

  • Radicle के विकास को देखना बेहद दिलचस्प रहा है। Protocol Berg 2023 में workshop में शामिल होने के बाद, राय है कि उन्होंने बहुत शक्तिशाली और नया कुछ बनाया है। प्रोटोकॉल का collaborative पहलू भी local-first होना सबसे दिलचस्प है। इंटरनेट के बिना भी patches और issues सबमिट किए जा सकते हैं, और GitHub में समस्या होने पर टीम प्रभावित नहीं होती।

    पिछले 5 वर्षों में Radicle को विकसित होते देखना बहुत दिलचस्प रहा है। मैं 2023 के Protocol Berg workshop में शामिल हुआ था, और मुझे लगता है कि उन्होंने कुछ बहुत शक्तिशाली और नया बनाया है। खास तौर पर प्रोटोकॉल का collaborative पहलू भी local-first तरीके से डिज़ाइन किया गया है, इसलिए इंटरनेट न होने पर भी patches और issues सबमिट किए जा सकते हैं, और जब GitHub में समस्या हो तो टीम प्रभावित नहीं होती।

  • MIT और Apache दोनों लाइसेंस इस्तेमाल करने की वजह को लेकर जिज्ञासा। सवाल है कि क्या MIT license, Apache license द्वारा दी गई अतिरिक्त ज़िम्मेदारियों को बायपास करने की अनुमति नहीं दे देता, खासकर patent license grant clause के मामले में। MIT license patents का उल्लेख नहीं करता, तो फिर सिर्फ MIT license ही क्यों न इस्तेमाल किया जाए?

    मैं जानना चाहता हूँ कि MIT और Apache दोनों licenses क्यों इस्तेमाल किए जा रहे हैं। यह आलोचना नहीं है, मैं गलत भी हो सकता हूँ, लेकिन क्या MIT license, Apache license से आने वाली अतिरिक्त ज़िम्मेदारियों को बायपास करने की अनुमति नहीं देता? खासकर patent license grant clause के संदर्भ में। MIT license patents का ज़िक्र नहीं करता, तो फिर सिर्फ MIT license ही क्यों न इस्तेमाल किया जाए?

  • सवाल है कि आम लोग ऐसी repositories को कितनी आसानी से खोज सकते हैं। robots.txt फ़ाइल नहीं दिखती, इसलिए search engines द्वारा crawling संभव लगता है। Google और DDG में search results आते हैं, लेकिन अभी ऊँची ranking नहीं है। ranking बेहतर हो सकती है। CI (continuous integration) support को integrate करने वाले tools भी दिलचस्प होंगे। ऐसे बेहतर tools चाहिए जो pushes को सिर्फ trusted identities तक सीमित कर सकें। अंत में artifact repositories का भी ज़िक्र है। Radicle को सब कुछ हल करने की ज़रूरत नहीं है, खासकर distributed network के ज़रिए बड़े binaries साझा करना जल्दी अवांछित इस्तेमाल में बदल सकता है।

    मैं सोच रहा हूँ कि आम लोगों के लिए इन repositories को ढूँढना कितना आसान है। कोई robots.txt फ़ाइल दिखाई नहीं देती, इसलिए search engines इन्हें crawl कर सकते हैं, और वास्तव में Google और DDG पर खोजने पर results मिलते हैं। अभी वे ऊँची ranking पर नहीं हैं, लेकिन site filters का इस्तेमाल न करने पर ranking सुधर सकती है। CI (continuous integration) support को integrate करने वाले tools भी दिलचस्प होंगे। ऐसे बेहतर tools की ज़रूरत है जो pushes को सिर्फ trusted identities तक सीमित कर सकें। और अंत में artifact repositories का ज़िक्र है, लेकिन Radicle को हर समस्या हल करने की ज़रूरत नहीं है। खासकर distributed network पर बड़े binaries साझा करना जल्दी अवांछित उपयोग में बदल सकता है।

  • प्रोजेक्ट की रिलीज़ पर बधाई, और इसे परिपक्व होते देख उत्साह। सवाल है कि GitHub पर मौजूद projects को कैसे migrate किया जाए, और testing के दौरान क्या mirror mode उपलब्ध है।

    रिलीज़ के लिए बधाई! इस प्रोजेक्ट को देखते रहना और यह देखना कि यह कितना mature हो गया है, वास्तव में बहुत रोमांचक है। GitHub पर मौजूद मौजूदा projects को कैसे migrate किया जा सकता है? क्या testing के दौरान कोई mirror mode है?

  • docs में कहा गया है कि केवल वही repositories publish करें जिनके आप मालिक हैं या जिन्हें आप manage करते हैं, और duplicate repository identities initialize न हों इसके लिए अन्य maintainers से संवाद करना महत्वपूर्ण है। लेकिन संभावना है कि लोग docs न पढ़ें या ध्यान न दें और ऐसे अनुरोधों को नज़रअंदाज़ कर दें। homepage पर code push करने का तरीका बताया गया है, लेकिन यह महत्वपूर्ण अनुरोध केवल user guide में मिलता है, जो समस्या बन सकता है।

    docs में उल्लेख है कि केवल वही repositories publish करना महत्वपूर्ण है जिनके आप owner हैं या जिन्हें आप manage करते हैं, और duplicate repository identities initialize न हों इसके लिए अन्य maintainers से संवाद करना चाहिए। लेकिन लोग docs नहीं पढ़ते या ध्यान नहीं देते, इसलिए वे ऐसे अनुरोधों को अनदेखा कर सकते हैं। homepage पर code push करने के निर्देश दिए गए हैं, लेकिन यह महत्वपूर्ण अनुरोध सिर्फ user guide में मिलता है, जो समस्या बन सकता है।

  • इच्छा है कि लोग "peer to peer" या अधिक प्रचलित "distributed" जैसे शब्दों को सटीक रूप से परिभाषित करें। जब ये शब्द buzzwords की तरह इस्तेमाल होते हैं, तो बहुत अस्पष्ट हो सकते हैं।

    काश लोग "peer to peer" या ज़्यादा आम तौर पर "distributed" जैसे शब्दों को ठीक से परिभाषित करें। ये शब्द जब buzzwords की तरह इस्तेमाल होते हैं, तो बहुत अस्पष्ट हो सकते हैं।

  • रिलीज़ पर बधाई, और यह git की जगह pijul इस्तेमाल करने वाले समान प्रोजेक्ट nest.pijul.com की याद दिलाता है।

    रिलीज़ के लिए बधाई! यह मुझे git की जगह pijul इस्तेमाल करने वाले एक समान प्रोजेक्ट, nest.pijul.com, की याद दिलाता है।

  • विषय से हटकर एक टिप्पणी के रूप में, यह NESticle की याद दिलाता है।

    विषय से हटकर टिप्पणी: यह मुझे NESticle की याद दिलाता है। NESticle wiki