Radicle: ทางเลือกแทน GitHub แบบเพียร์ทูเพียร์ที่ใช้โอเพนซอร์ส

 (app.radicle.xyz)
2 คะแนน โดย GN⁺ 2024-03-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Radicle Heartwood เป็นการทำงานจริงครั้งที่สามของ Radicle Protocol โดยให้สแตกสำหรับการทำงานร่วมกันและเผยแพร่โค้ดแบบเพียร์ทูเพียร์โดยไม่ต้องพึ่ง code forge แบบรวมศูนย์
  • รีโพซิทอรีนี้มีเครื่องมือบรรทัดคำสั่ง rad สำหรับนักพัฒนาใช้งานโดยตรง และเน็ตเวิร์กดีมอน radicle-node รวมอยู่ด้วย
  • ออกแบบมาเพื่อเป็นทางเลือกแทน code forge อย่าง GitHub และ GitLab โดยมีเป้าหมายหลักคือ ความปลอดภัยและการกระจายศูนย์ รวมถึงการรักษาอธิปไตยของผู้ใช้
  • สภาพแวดล้อมสำหรับติดตั้งต้องเป็น Linux หรือระบบปฏิบัติการตระกูล Unix, Git 2.34 ขึ้นไป, และ OpenSSH 9.1 ขึ้นไป ที่มี ssh-agent
  • รองรับทั้งการติดตั้งแบบไบนารีและการติดตั้งจากซอร์ส Rust แต่ฟีดแบ็กทางอีเมลจะถูก โพสต์อัตโนมัติไปยังช่อง Zulip สาธารณะ ซึ่งอาจทำให้ชื่อและที่อยู่อีเมลถูกเปิดเผย

สิ่งที่ Radicle Heartwood มีให้

  • Heartwood เป็นเวอร์ชันวนซ้ำครั้งที่สามของ Radicle Protocol และเป็นสแตกครบชุดสำหรับการทำงานร่วมกันและการเผยแพร่โค้ดแบบเพียร์ทูเพียร์
  • รีโพซิทอรีนี้มีองค์ประกอบหลักที่จำเป็นสำหรับการใช้งาน Heartwood
    • rad: อินเทอร์เฟซบรรทัดคำสั่งที่ใช้งานง่าย
    • radicle-node: เน็ตเวิร์กดีมอน
  • Radicle ถูกออกแบบมาเป็นทางเลือกแทน code forge อย่าง GitHub และ GitLab
    • เป้าหมายคือการรักษา ความปลอดภัย, การกระจายศูนย์, อธิปไตยและเสรีภาพของผู้ใช้
  • ดูข้อมูลทั่วไปได้ที่ Radicle home page
  • สนทนาเกี่ยวกับโปรเจกต์ได้ที่ Zulip chat
  • วิธีการทำงานของ Radicle อธิบายไว้อย่างละเอียดใน Protocol Guide

การติดตั้งและการใช้งาน

  • ข้อกำหนดในการติดตั้งมีดังนี้
    • ระบบปฏิบัติการ Linux หรือ Unix

    • Git 2.34 ขึ้นไป

      • OpenSSH 9.1 ขึ้นไป ที่มี ssh-agent
      • การติดตั้งแบบไบนารีต้องใช้ curl และ tar โดยติดตั้งรีลีสล่าสุดได้ด้วยคำสั่งต่อไปนี้
curl -sSf https://radicle.dev/install | sh

- สามารถดาวน์โหลดไบนารีได้จากหน้า [download](https://radicle.dev/download) เช่นกัน
- หากต้องการติดตั้งจากซอร์ส ต้องมี **Rust toolchain** แล้วรันคำสั่งต่อไปนี้ภายในรีโพซิทอรี

cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle

- สามารถติดตั้งโดยตรงจาก seed node ได้เช่นกัน

cargo install --force --locked --root ~/.radicle \
    --git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
    crates/radicle-cli crates/radicle-node crates/radicle-remote-helper

- ไฟล์ **systemd unit** สำหรับโหนดอยู่ในโฟลเดอร์ `/systemd` และสามารถใช้เป็นจุดเริ่มต้นสำหรับการปรับแต่งเพิ่มเติมได้
- ดูการรันในโหมดดีบักได้ที่ [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)

ฟีดแบ็ก, การมีส่วนร่วม, ใบอนุญาต

  • สามารถส่งฟีดแบ็กได้ทาง rad issue, Zulip หรือ feedback@radicle.dev
  • ฟีดแบ็กที่ส่งทางอีเมลจะถูกโพสต์อัตโนมัติไปยัง ช่อง #feedback สาธารณะ บน Zulip
    • ระหว่างการโพสต์ เฮดเดอร์ From จะถูกเปิดเผย ซึ่งโดยทั่วไปจะมีชื่อและที่อยู่อีเมลรวมอยู่ด้วย
  • แนวทางการมีส่วนร่วมอยู่ใน CONTRIBUTING.md และ HACKING.md
  • Radicle เผยแพร่ภายใต้เงื่อนไขของ MIT License และ Apache License 2.0
  • รายละเอียดอยู่ใน LICENSE-APACHE และ LICENSE-MIT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-06
ความเห็นจาก Hacker News

  • ผมเป็นผู้ร่วมก่อตั้ง Radicle เอง ถ้าอยากรู้ว่า โปรโตคอลทำงานภายในอย่างไร ให้เริ่มจากอ่านเอกสารได้เลย: https://docs.radicle.xyz/
    เอกสารยังเขียนไม่เสร็จ

    • พออ่านเอกสารแล้ว สิ่งที่สะดุดตาคือส่วนที่บอกว่า “repository ของ Radicle ตั้งเป็นสาธารณะ/ส่วนตัวได้ และเก็บซอร์สโค้ด เอกสาร หรือชุดข้อมูลตามต้องการได้”
      ถ้ามองว่าโดยพื้นฐานมันคือ แอปแชร์ไฟล์แบบ P2P ก็เลยสงสัยว่าปัญหาการใช้งานในทางที่ผิดถูกจัดการไว้ตรงไหนของโปรโตคอล ไม่อย่างนั้นก็ไม่เห็นว่ามันต่างจากแอปแชร์ไฟล์ยุคก่อนอย่าง BitTorrent หรือ Winny ที่ใช้แชร์หนัง เพลง หรือซอฟต์แวร์ละเมิดลิขสิทธิ์แบบสุ่ม ๆ อย่างไร ดูเหมือนผู้ใช้ไม่หวังดีแค่ไม่กี่คนก็อาจทำระบบเสียหายได้ และก็สงสัยด้วยว่าจะสามารถแยกเครือข่ายแบบ “ส่วนตัว” เพื่อให้มั่นใจได้หรือไม่ว่าตัวเองไม่ได้มีส่วนกับสิ่งผิดกฎหมาย
    • เป็นโปรเจ็กต์ที่น่าสนใจ อยากรู้เรื่อง โมเดลธุรกิจ
      ใน Crunchbase ระบุว่าได้รับเงินลงทุน 12 ล้านดอลลาร์ ก็น่าจะมีแผนสร้างรายได้อยู่
    • ไม่ได้กำลังพยายามหาตัวแทนบริการปิดอย่าง GitHub หรือ GitLab แบบจริงจัง แต่บางครั้งก็มีคนมาถามหาทางเลือกอยู่เหมือนกัน ผมชอบโซลูชันแบบ self-hosted ที่กระจายศูนย์ ดังนั้นทิศทางของ Radicle ถือว่าตรงมาก แต่ติดที่ข้อกำหนดระบุว่า ระบบปฏิบัติการต้องเป็น Linux หรือ Unix เป็นพื้นฐาน
      สำหรับประเภทโปรเจ็กต์ที่ผมช่วยอยู่ ตรงนี้อาจเป็นจุดตัดสินเลย โค้ดดูเหมือนเขียนด้วย Rust ก็เลยอยากรู้ว่ามีแผนรองรับ MS Windows ไหม ส่วน Mac OS ก็นับว่าอยู่ในสาย Unix ได้อยู่แล้วใช่ไหม? ต่อให้ยังไม่รองรับ Windows อย่างเป็นทางการ ก็สงสัยว่าอย่างน้อยพอร์ตไป MSYS2 ได้หรือเปล่า
      ขอเสริมบริบทนิดหนึ่ง ผมไม่ได้อยู่ในตำแหน่งที่ตัดสินใจเลือกผู้ให้บริการอะไรแบบนั้น แต่เกี่ยวข้องกับองค์กรกึ่งภาครัฐที่มีโค้ดโอเพนซอร์สจำนวนมากอยู่บน GitHub บางครั้งผมพอมีโอกาสเสนอไอเดียบางอย่างได้ แต่ไม่ได้มีอำนาจตัดสินว่าจะนำไปใช้หรือไม่ องค์กรนี้มีแรงจูงใจสูงที่จะสร้างความยืดหยุ่นไม่ให้ถูกนโยบายของผู้ให้บริการเอกชนชี้นำ และยังอยากทำ “สิ่งที่ดี” อย่างความยั่งยืนหรือการเข้าถึงอย่างกว้างขวางด้วย ในฐานะองค์กรภาครัฐแบบยุโรปทั่วไป GitHub จึงค่อนข้างขัดกับนโยบายเหล่านั้น
      ยังมีหน่วยงานรัฐอื่นที่ดูแลงานเก็บรักษาข้อมูลหรือสนับสนุนเครือข่ายอยู่ด้วย แต่ขีดความสามารถไม่พอหรือยังติดวิธีคิดแบบเก่า และก็มักตกหลุมพรางที่ผู้ขายวางไว้ ตัวอย่างเช่น มีบริการด้านการเก็บรักษาที่นำ DataBricks ไปใช้ทั้งระบบโดยไม่รู้ด้วยซ้ำว่ามันเป็นผลิตภัณฑ์เชิงพาณิชย์แบบปิดซอร์ส ดังนั้นผมจึงไม่ค่อยคาดหวังว่าองค์กรนั้นจะใช้โซลูชัน self-hosted ได้ดีนัก และโซลูชันแบบกระจายศูนย์ก็ดูน่าสนใจกว่า เพียงแต่เครื่องมือที่ไม่ทำงานบนสภาพแวดล้อมพีซีหลักของผู้ใช้ทั่วไปนั้นใช้ไม่ได้
    • อยากรู้ว่า Radicle ใช้ งบประมาณเท่าไร มีคนทำกี่คน ทำมานานแค่ไหน และตอนนี้มีใครใช้อยู่บ้าง
    • ผมชอบดีไซน์ของเว็บไซต์และแอป หลายโปรเจ็กต์โอเพนซอร์สมักพังในเรื่อง งานภาพและการออกแบบ แบบหมดรูป ซึ่งถึงจะเป็นแค่หน้าตาภายนอก แต่ดีไซน์ที่สวยก็ทำให้อยากมีปฏิสัมพันธ์กับโปรเจ็กต์มากขึ้น
      แล้วก็อยากรู้ด้วยว่าแต่ก่อนกับตอนนี้คาดหวังการยอมรับในระดับไหนไว้ และผลลัพธ์จริงออกมาตรงกับความคาดหวังหรือไม่

  • น่าสนใจมากที่ได้ดูว่า Radicle ค่อย ๆ พัฒนามาตลอดราว 5 ปีที่ผ่านมา ผมไปร่วมเวิร์กช็อปที่ Protocol Berg 2023 และคิดว่าพวกเขาสร้างสิ่งใหม่ที่ทรงพลังพอสมควร
    จุดที่น่าสนใจมากเป็นพิเศษคือ แม้แต่ ฟีเจอร์สำหรับการทำงานร่วมกันก็ยังเป็น local-first ต่อให้ไม่มีอินเทอร์เน็ตก็ยังส่ง patch กับ issue ได้ และเวลาที่ GitHub มีปัญหา ทั้งทีมก็ไม่จำเป็นต้องไปเฝ้า HN กันหมด

  • ถ้ามองตามวัตถุประสงค์ก็ดูเป็นโปรเจ็กต์ที่ใช้ได้ แต่ผมคิดว่า Git เองก็เป็น โอเพนซอร์สและ P2P อยู่แล้ว สามารถต่อไปยัง Git server อื่นแล้วดึงหรือ merge โค้ดด้วยคำสั่ง Git ได้ตรง ๆ โดยไม่ต้องมารับไบนารีผ่าน sh <(curl)
    สิ่งที่ Git ไม่มีคือ issue ของโค้ด, wiki, การสนทนา, GitHub Pages และที่สำคัญที่สุดคือเครือข่ายโปรไฟล์นักพัฒนา ต้องมีวิธีใส่ metadata ของโปรเจ็กต์ลงไปใน .git เอง เพื่อไม่ให้ source code commit ปะปนกับ wiki หรือ issue อาจใช้ reference แยกอิสระแบบ git notes ได้ก็ได้
    https://git-scm.com/docs/git-notes

    • Git ถูกออกแบบมาโดยคำนึงถึงการโต้ตอบแบบ P2P อยู่ในระดับหนึ่ง แต่ในทางปฏิบัติกลับไม่มีการกระจายใช้งานแบบนั้นเลย การใช้งานทั้งหมดอาศัย โมเดล client-server เพราะ Git เพียงอย่างเดียวยังขาดความสามารถที่จะนำไปใช้บนเครือข่าย P2P ได้ตรง ๆ
      ตัวอย่างเช่น ไม่มีวิธีตรวจสอบได้เลยว่า repository ที่ได้จาก git clone คือ repository ที่ผมร้องขอจริง ๆ ดังนั้นจึงต้อง clone จากแหล่งที่เชื่อถือได้ หรือก็คือ server ที่รู้จัก ซึ่งไม่สอดคล้องกับ P2P ที่ใช้งานได้จริง
      Radicle แก้ปัญหานี้ด้วยการให้ ตัวระบุ repository ที่เสถียร[0] ซึ่งตรวจสอบได้ในเครื่อง ทำให้หน่วยงานที่เราไม่จำเป็นต้องเชื่อถือสามารถเป็นผู้ให้ repository ได้
      [0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
    • Radicle เพิ่ม การติดตาม issue และ pull request เข้ามา น่าจะมีฟีเจอร์อื่นเพิ่มมาบางส่วนด้วย
      บนมือถือ ถ้ากดปุ่มใต้ลิงก์ต้นฉบับ ก็จะเห็นแท็บ issue tracker, แท็บ pull request และอื่น ๆ
    • Fossil(https://fossil-scm.org) เก็บ issue, wiki และอย่างอื่นไว้ใน repository ของโปรเจ็กต์
    • “ที่สำคัญที่สุดคือเครือข่ายโปรไฟล์นักพัฒนา” ฟังแล้วชวนให้คิดว่าโลกเรามาถึงจุดนี้ได้ยังไง
      ถ้าจำไม่ผิด Gerrit เคยเก็บ code review ไว้ใน Git มาก่อน
    • Git แบบดั้งเดิมหลีกเลี่ยง การเซ็นเซอร์ ไม่ได้ อย่างข่าวที่เกี่ยวกับ Nintendo ช่วงหลัง ๆ ไอเดียแบบนี้ติดอยู่ในหัวผมมาพักหนึ่งแล้ว จึงดีใจมากที่มีคนลงมือทำงานยากส่วนนี้จนสำเร็จ

  • ในเอกสารระบุว่า “สิ่งสำคัญคือต้องเผยแพร่เฉพาะรีโพซิทอรีที่คุณเป็นเจ้าของหรือเป็นผู้ดูแล และควรสื่อสารกับผู้ดูแลคนอื่นเพื่อหลีกเลี่ยงการสร้างตัวระบุรีโพซิทอรีที่ซ้ำกัน”
    ผมเคยเจอคนเอาโค้ดของผมไปลงบน GitHub แล้ว และก็เห็นมาหลายครั้งว่าต่อให้ใส่ข้อความในเอกสารผลิตภัณฑ์หรือ UI ระหว่างทางว่า “ได้โปรดอย่าทำ X เพราะมันจะทำให้ผู้ใช้อื่นมีปัญหา” ก็ไม่มีใครอ่าน คิด หรือใส่ใจ แล้วทำ X ทันทีอยู่ดี ดังนั้นเลยคิดว่าคนจำนวนมากคงไม่ทำตามคำขอนี้ในเอกสาร แถมหน้าโฮมเพจก็บอกแค่วิธี push โค้ด ส่วนคำขอที่ว่า “สำคัญ” นี้กลับอยู่ในคู่มือผู้ใช้ที่แทบไม่มีใครอ่าน
    สุดท้ายแล้ว การแค่ push โค้ดโอเพนซอร์สที่กำลังทำอยู่ตามคำแนะนำบนหน้าโฮมเพจ ซึ่งเป็นการกระทำที่ ดูสมเหตุสมผล อาจทำให้บางสิ่งสำคัญถูกรบกวนหรือทำให้สับสนเมื่อเวลาผ่านไปจากลักษณะของโปรโตคอลและวิธีการจัดเก็บข้อมูล ซึ่งค่อนข้างน่ากังวล

    • ดูเหมือนจะไม่มีปัญหาพิเศษอะไรตรงนี้ ตอนนี้เอง ตำแหน่งทางการ ของรีโพซิทอรีก็มักถูกค้นหาผ่านช่องทางภายนอกอย่างโซเชียลเน็ตเวิร์กหรือเว็บไซต์อยู่แล้ว
      บน GitHub คุณได้ความน่าเชื่อถือเพิ่มจากจำนวนดาว และบน Radicle สิ่งที่เทียบกันได้ก็คือจำนวน seed ของรีโพซิทอรีนั้น
    • ไม่ใช่เรื่องที่จะไปหงุดหงิดใส่คนที่มองข้ามเอกสารหรือคำแนะนำ เพราะนั่นเป็นพฤติกรรมที่มีเหตุผลมาก
      โดยทั่วไปในแต่ละวันคนเราจะเห็นข้อความแนะนำเป็นสิบ ๆ ข้อระหว่างใช้งานคอมพิวเตอร์ และใช้เครื่องมือเป็นสิบ ๆ ตัว ถ้าจะต้องอ่านคำแนะนำทุกอันและอ่านเอกสารของทุกเครื่องมืออย่างละเอียด เวลาที่ต้องใช้มันมากเกินไป
      เพราะแบบนั้นการไม่อ่านแล้วใช้ heuristic จึงดีกว่ามาก เช่น ถ้าปิดเอกสารที่มีการแก้ไขที่ยังไม่ได้บันทึก เราก็รู้อยู่แล้วว่ากล่องโต้ตอบน่าจะถามว่า “จะทิ้งไหม?” เลยไม่จำเป็นต้องอ่าน นี่เป็นเรื่องที่ดี
      สรุปคือควรออกแบบซอฟต์แวร์โดยตั้งต้นจากข้อเท็จจริงที่ว่าผู้คนมีพฤติกรรมแบบนี้ ซึ่งโดยมากก็ทำได้ ถ้ามีตัวอย่างที่เป็นรูปธรรม ก็น่าจะเสนอทางแก้ที่ดีกว่าวิธี “ขอร้องและหวังว่าคนจะอ่าน” ได้
    • แบบ GitHub คือใส่ ประกาศลิขสิทธิ์ ไว้ในโค้ดเพื่อระบุว่ารีโพของตัวเองเป็นต้นฉบับ และทำให้การแก้ไขประกาศลิขสิทธิ์เป็นเรื่องผิดกฎหมาย ไม่ใช่หรือ? ตรงนี้ก็น่าจะใช้ได้เหมือนกัน

  • ขอแสดงความยินดีกับการเปิดตัว ติดตามโปรเจ็กต์นี้มาสักพักแล้ว และตื่นเต้นมากที่เห็นว่ามันโตและสุกงอมขึ้นมาก อยากรู้ว่าสำหรับโปรเจ็กต์ที่ตอนนี้อยู่บน GitHub ควรย้ายอย่างไรถึงจะดีที่สุด และก็สงสัยว่ามี โหมดมิเรอร์ ให้ลองใช้ไหม

    • ตอนนี้ยังไม่มีการทำ mirroring ในตัว แต่กำลังพิจารณาอยู่ ในทางทฤษฎีมันควรจะง่ายพอ ๆ กับตั้งงาน cron ให้ดึงจาก GitHub ทุกชั่วโมงแล้ว push ไปยัง Radicle
      git pull github master
      git push rad master

  • สงสัยว่าระดับ การค้นพบได้ ของรีโพซิทอรีเหล่านี้สำหรับผู้ใช้ทั่วไปจะเป็นอย่างไร https://app.radicle.xyz/robots.txt เหมือนจะไม่มี ดังนั้นน่าจะอยู่ในสถานะที่เสิร์ชเอนจินเข้ามาเก็บข้อมูลได้ และถ้าลองค้น site:app.radicle.xyz บน Google กับ DDG ก็มีผลลัพธ์ออกมาจริง
    ตอนนี้ยังไม่ขึ้นสูงถ้าไม่ใส่ตัวกรองไซต์ แต่อันดับอาจดีขึ้นได้
    นอกจากนี้ก็น่าจะดีถ้ามีเครื่องมือสำหรับเชื่อมกับการรองรับ CI ด้วย สุดท้ายอาจเป็นแค่ลูปประมาณ while true; do wait_repo_update; git pull && ./run_ci.sh; done แต่ก็น่าจะต้องมีรูปแบบที่ดีกว่านี้ซึ่งจำกัดให้ทำงานเฉพาะกับ push จากตัวระบุที่เชื่อถือได้
    สุดท้ายยังต้องมีรีโพซิทอรีสำหรับเก็บ artifacts ด้วย แต่บางที Radicle ก็อาจไม่จำเป็นต้องแก้ทุกอย่าง โดยเฉพาะเครือข่ายแบบกระจายศูนย์ที่ใช้แชร์ไบนารีขนาดใหญ่ ดูเหมือนจะถูกนำไปใช้ในทางที่ไม่พึงประสงค์ได้ค่อนข้างเร็ว

    • ตอนนี้เรากำลังทำ CI integration หลายแบบอยู่ และกำลังสร้าง native CI ของเราเองที่ออกแบบให้เหมาะกับความต้องการของเรา
    • เป็นประเด็นที่ดี ดูเหมือนว่า gateway อย่าง app.radicle.xyz ควรอนุญาตให้ crawler ทำดัชนีชุดรีโพซิทอรีทั้งหมดของเครือข่ายได้

  • อยากให้ผู้คนกำหนดให้ชัดเจนว่า “P2P” หรือที่เรียกกันบ่อยกว่าว่า “distributed” จริง ๆ แล้วหมายถึงอะไร เพราะตอนนี้มันกลายเป็น คำฮิตที่คลุมเครือ มากเกินไปจนจะใช้ในความหมายอะไรก็ได้

    • ไม่ค่อยเห็นว่าคำนี้ถูกใช้ผิดบ่อยนัก นิยามที่ใช้กับ Radicle และระบบ P2P ส่วนใหญ่ก็เหมือนกับนิยามใน Wikipedia[0] โดยเฉพาะส่วนที่ว่า “peer คือผู้เข้าร่วมที่มีสิทธิและความสามารถเท่าเทียมกันในเครือข่าย”
      ดังนั้นระบบ P2P ก็คือระบบที่ผู้เข้าร่วมทุกคนมี “สิทธิเท่าเทียมกันภายในเครือข่าย” และโดยทั่วไปก็มักหมายถึงทุกคนรันซอฟต์แวร์ตัวเดียวกันด้วย
      [0]: https://en.wikipedia.org/wiki/Peer-to-peer

  • คำแนะนำการติดตั้งดันเป็น curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | sh ซะงั้น ความคาดหวังเลยพังทลายทันทีเพราะขยะ curl-bash
    วิธีติดตั้งแบบนี้เป็นสัญญาณแรงมากของการพัฒนาแบบไม่คิดหน้าคิดหลัง ถ้าโปรเจ็กต์นี้ดังขึ้นก็คงได้เห็นหายนะด้านความปลอดภัยแน่ ๆ หวังว่าสักวันจะมี “ทางเลือก GitHub แบบ P2P โอเพนซอร์ส” ที่ไม่ได้เริ่มต้นด้วยวิธีติดตั้งที่แย่ที่สุดออกมาซะที

    • นี่แทบจะเป็นการ react เกินเหตุ แบบไม่น่าเชื่อเลย
      หลายคนก็รู้กันดีอยู่แล้วว่าตัวติดตั้งแบบ pipe มีความเสี่ยง ถ้าจะใช้ตรรกะนั้น ก็ต้องเลิกใช้ Homebrew [1](GitHub ดาวมากกว่า 3.8 หมื่น), PiHole [2](4.6 หมื่นกว่า), Chef [3], RVM [4] และโปรเจ็กต์โอเพนซอร์สอีกมากมายที่ใช้ตัวติดตั้งอัตโนมัติแบบขั้นตอนเดียวผ่าน bash
      การตอบสนองที่สมเหตุสมผลกว่าคือร่วมมือกับนักพัฒนาให้มีวิธีติดตั้งทางเลือกในเอกสาร หรืออธิบายความเสี่ยงให้ชัดขึ้น ไม่ใช่ทำลายทุกอย่างเพราะเรื่องเล็กน้อย
      [1] https://brew.sh/
      [2] https://github.com/pi-hole/pi-hole
      [3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
      [4] https://rvm.io/rvm/install
    • นี่ไม่ดราม่าไปหน่อยเหรอ?
      เรื่องปัญหาการส่งข้อมูลถูกขัดจังหวะนั้น ตราบใดที่ในระบบไม่มีคำสั่งอันตรายที่ตรงกับ ^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?) สคริปต์นี้ก็ปลอดภัย
      พอจัดการประเด็นนั้นแล้ว ก็ไม่แน่ใจว่ามันต่างอะไรกับการแจกแค่สคริปต์โดยไม่ให้คำสั่งรัน ถ้าอยากตรวจสอบก็โหลดสคริปต์มารันแยกเองได้ เหมือนเคยมีวิธีตรวจจับว่าสคริปต์ถูก pipe มาหรือถูกดาวน์โหลดมา แต่คงใช้ไม่ได้กับสคริปต์เล็ก ๆ แบบนี้
    • อยู่ตรงนี้ [0] โปรเจ็กต์ยังไม่เปิดตัวอย่างเป็นทางการเลยยังมีชิ้นส่วนที่ต้องจัดการ และตอนนี้โฟกัสก็อยู่คนละจุดนิดหน่อย นอกจากนี้ยัง build from source ด้วย cargo ของ Rust ได้ด้วย [1]
      [0] https://files.radicle.xyz/latest/
      [1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
    • จะโหลดหรือไม่โหลด จะเชื่อผู้ดูแลหรือไม่เชื่อผู้ดูแล สุดท้ายก็เป็นเรื่องของความไว้ใจ วิธีติดตั้ง ไม่ใช่สิ่งที่จะมาตัดสินว่าควรเชื่อผู้ดูแลหรือไม่ และแม้จะเป็น curl-bash ก็เหมือนกัน

  • รู้สึกว่าได้ยินชื่อ Radicle ทุกครั้งที่ตลาดคริปโตขึ้น มีใครใช้งานมันแบบจริงจังไหม?
    อันนี้โดนดาวน์โหวตทันทีเลย ฉันถามจริงจังนะ อยากรู้ว่า Radicle ใช้งบไปเท่าไร มีคนทำกี่คน และมีใครใช้อยู่บ้าง

    • เป็นคำถามที่ยุติธรรมดี
      ฉันทำงานในวงการคริปโตและก็รู้สึกแบบเดียวกัน ครั้งล่าสุดที่ได้ยินเรื่อง Radicle คือช่วงตลาดขาขึ้นรอบก่อน ส่วนช่วงขาลงกลับเงียบไป ทุกคนชอบพูดกันว่า ตลาดขาลงคือเวลาสำหรับการสร้าง และ Radicle ก็เป็นเครื่องมือสำหรับนักพัฒนาชัด ๆ เลยยิ่งดูแปลกพอสมควร

  • สงสัยว่ามีแผนจะรองรับกรณีใช้งานที่ให้บริการ repository เฉพาะกับชุดของโหนดบางชุดไหม น่าจะมีคนที่ไม่อยากอยู่บน GitHub แต่ก็ยังอยาก ทำงานร่วมกันแบบปิด

    • มี ใน Radicle เรียกสิ่งนี้ว่า private repository มันจะไม่ปรากฏต่อส่วนที่เหลือของเครือข่าย และแชร์กันเฉพาะระหว่างเพียร์ที่เชื่อถือกันเท่านั้น
      อย่างไรก็ตาม ตอนจัดเก็บข้อมูลมันไม่ได้ถูกเข้ารหัส จึงไม่สามารถเก็บไว้บนโหนดตัวกลางที่ไม่ได้อยู่ในชุดความเชื่อถือได้