▲

GN⁺: 라디클: 오픈소스 기반의 피어투피어 GitHub 대안

 (app.radicle.xyz)
2P by neo 6달전 | favorite | 댓글 1개

Radicle Heartwood 프로토콜 & 스택

  • Radicle Heartwood는 동료 간 코드 협업 및 출판 스택인 Radicle 프로토콜의 세 번째 버전임.
  • 이 저장소에는 사용자 친화적인 커맨드 라인 인터페이스(rad)와 네트워크 데몬(radicle-node)을 포함한 Heartwood의 전체 구현이 포함되어 있음.
  • Radicle은 사용자의 주권과 자유를 보존하는 안전하고 분산된 강력한 대안으로, GitHub과 GitLab 같은 코드 포지를 대체하기 위해 설계됨.

설치 요구 사항

  • Linux 또는 Unix 기반 운영 체제 필요.
  • Git 2.34 이상 버전 필요.
  • OpenSSH 9.1 이상 버전과 ssh-agent 필요.

바이너리에서 설치

  • curl과 tar가 필요함.
  • 최신 바이너리 릴리스를 설치하려면 다음 명령어를 실행함: sh <(curl -sSf https://radicle.xyz/install)

소스에서 설치

  • Rust 툴체인이 필요함.
  • 이 저장소 내부에서 다음 명령어를 실행하여 Radicle 스택을 소스에서 설치할 수 있음: cargo install --path radicle-cli --force --locked cargo install --path radicle-node --force --locked cargo install --path radicle-remote-helper --force --locked
  • 또는 직접 시드 노드에서 설치할 수 있음: cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \ radicle-cli radicle-node radicle-remote-helper

실행

  • 시스템 데몬과 HTTP 데몬을 위한 Systemd 유닛 파일이 /systemd 폴더에 제공됨. 이는 추가 사용자 정의를 위한 출발점으로 사용될 수 있음.
  • 또한, 두 크레이트에 Dockerfile이 포함되어 있음.
  • 디버그 모드에서 실행하는 방법은 HACKING.md를 참조함.

기여하기

  • Radicle에 기여하는 방법에 대한 소개는 CONTRIBUTING.md와 HACKING.md를 참조함.

라이선스

  • Radicle은 MIT 라이선스와 Apache License (Version 2.0)의 조건 하에 배포됨.
  • 자세한 내용은 LICENSE-APACHE와 LICENSE-MIT를 참조함.

GN⁺의 의견

  • Radicle은 중앙 집중식 코드 호스팅 서비스의 대안으로, 사용자의 코드 주권을 강화하고자 하는 분산형 코드 협업 플랫폼임. 이는 개발자들에게 데이터 소유권과 프라이버시에 대한 통제를 제공함으로써 매우 중요한 가치를 지님.
  • Radicle이 제공하는 분산형 네트워크는 중앙 서버에 의존하지 않기 때문에, 서비스 중단이나 검열로부터 자유롭다는 장점이 있음. 그러나 이는 네트워크의 안정성과 속도에 영향을 줄 수 있어 사용자 경험에 부정적인 영향을 미칠 수도 있음.
  • Radicle은 오픈소스 프로젝트로, 개발자 커뮤니티의 기여를 통해 지속적으로 발전하고 있음. 이는 기술적 문제 해결이나 새로운 기능 추가에 있어 빠른 대응이 가능하다는 이점을 가지고 있음.
  • Radicle을 도입하기 전에는 기존의 중앙 집중식 서비스와의 호환성, 프로젝트의 보안 요구 사항, 그리고 팀 내에서의 채택 장벽 등을 고려해야 함.
  • 유사한 기능을 제공하는 다른 프로젝트로는 GitLab의 자체 호스팅 버전이나 Gitea와 같은 오픈소스 대안들이 있으며, 이들은 사용자가 자신의 서버에서 코드를 관리할 수 있게 해줌.
▲
neo 6달전  [-]
Hacker News 의견

  • 프로젝트 공동 창립자로부터의 인사와 프로토콜 작동 방식에 대한 설명 링크 제공. 문서는 아직 작업 중임.

    안녕하세요, 해커뉴스 여러분. 저는 이 프로젝트의 공동 창립자입니다. 프로토콜이 내부적으로 어떻게 작동하는지 궁금하시다면 여기서 시작하세요: Radicle 문서. 다만 문서는 아직 작업 중입니다.

  • 프로젝트의 목적에 적합해 보이지만, git이 이미 오픈소스이며 P2P라는 의견. git은 추가 바이너리 없이 다른 서버에 연결하여 코드를 직접 가져오거나 병합할 수 있음. git에서 부족한 것은 코드 이슈, 위키, 토론, GitHub 페이지, 그리고 가장 중요한 개발자 프로필 네트워크임. 프로젝트 메타데이터를 .git 자체에 포함시킬 방법이 필요하며, 위키와 이슈를 혼동하지 않기 위해 독립적인 참조가 필요할 수 있음.

    이 프로젝트는 목적에 맞게 잘 만들어진 것 같지만, git 자체도 이미 오픈소스이고 P2P입니다. 별도의 바이너리를 설치할 필요 없이 다른 git 서버에 연결하고 git 명령어로 코드를 직접 가져오거나 병합할 수 있죠. git에서 빠진 것은 코드 이슈, 위키, 토론, GitHub 페이지, 그리고 가장 중요한 개발자 프로필 네트워크입니다. 프로젝트 메타데이터를 .git에 포함시킬 수 있는 방법이 필요합니다. 아마도 git notes와 같은 독립적인 참조가 필요할 것입니다. git-notes 문서

  • Radicle의 발전을 지켜보는 것이 매우 흥미로움. Protocol Berg 2023에서의 워크샵 참석 후, 매우 강력하고 새로운 것을 구축했다고 생각함. 프로토콜의 협업 측면도 로컬 우선이라는 점이 가장 흥미로움. 인터넷 없이도 패치와 이슈를 제출할 수 있으며, GitHub에 문제가 있을 때 팀이 영향을 받지 않음.

    Radicle이 지난 5년 동안 발전하는 모습을 지켜보는 것은 매우 흥미로웠습니다. 2023년 Protocol Berg에서 열린 워크샵에 참석했는데, 그들이 매우 강력하고 새로운 것을 만들었다고 생각합니다. 특히 프로토콜의 협업 측면도 로컬 우선으로 설계되어 인터넷이 없어도 패치와 이슈를 제출할 수 있고, GitHub에 문제가 있을 때 팀이 영향을 받지 않는다는 점이 가장 흥미롭습니다.

  • MIT와 Apache 라이선스를 모두 사용하는 이유에 대한 궁금증. MIT 라이선스가 Apache 라이선스에서 제공하는 추가적인 책임을 우회할 수 있게 하지 않는지, 특히 특허 라이선스 부여 조항에 대한 것. MIT 라이선스는 특허에 대해 언급하지 않으므로, 그렇다면 왜 MIT 라이선스만 사용하지 않는지에 대한 의문.

    MIT와 Apache 라이선스를 모두 사용하는 이유가 궁금합니다. 비판이 아니라, 제가 틀렸을 수도 있지만, MIT 라이선스는 Apache 라이선스에서 제공하는 추가적인 책임을 우회할 수 있게 하지 않나요? 특히 특허 라이선스 부여 조항에 대해서요. MIT 라이선스는 특허에 대해 언급하지 않으니, 그렇다면 왜 MIT 라이선스만 사용하지 않는지 궁금합니다.

  • 일반인이 이러한 저장소를 얼마나 쉽게 찾을 수 있는지에 대한 의문. robots.txt 파일이 없어 검색 엔진에 의한 크롤링이 가능해 보임. Google과 DDG에서 검색 결과가 나오긴 하지만 아직 높은 순위는 아님. 순위가 개선될 수도 있음. CI(지속적 통합) 지원 통합 도구도 흥미로울 것. 신뢰할 수 있는 신원으로부터의 푸시에만 제한할 수 있는 더 나은 도구가 필요함. 마지막으로 아티팩트 저장소에 대한 언급. Radicle이 모든 것을 해결할 필요는 없으며, 특히 분산 네트워크를 통한 대용량 바이너리 공유는 빠르게 원치 않는 용도로 사용될 수 있음.

    이 저장소들이 일반인에게 얼마나 발견하기 쉬운지 궁금합니다. robots.txt 파일이 없어 보이니 검색 엔진이 크롤링할 수 있을 것 같고, 실제로 Google과 DDG에서 검색해보면 결과가 나옵니다. 아직 높은 순위는 아니지만, 사이트 필터를 사용하지 않으면 순위가 향상될 수도 있겠죠. CI(지속적 통합) 지원을 통합할 도구도 흥미로울 것입니다. 신뢰할 수 있는 신원의 푸시에만 제한할 수 있는 더 좋은 도구가 필요합니다. 그리고 마지막으로 아티팩트 저장소에 대한 언급이 있는데, Radicle이 모든 것을 해결할 필요는 없습니다. 특히 분산 네트워크를 통한 대용량 바이너리 공유는 빠르게 원치 않는 용도로 사용될 수 있습니다.

  • 프로젝트 출시를 축하하며, 프로젝트를 지켜보고 성숙해진 것을 보며 흥분함. GitHub에 있는 프로젝트를 어떻게 이전하는지, 테스트 동안 미러 모드가 있는지에 대한 질문.

    출시를 축하합니다! 이 프로젝트를 지켜보면서 얼마나 많이 성숙해졌는지 보는 것이 정말 흥미롭습니다. 현재 GitHub에 있는 프로젝트들은 어떻게 이전할 수 있나요? 테스트하는 동안 미러 모드가 있나요?

  • 문서에서는 자신이 소유하거나 관리하는 저장소만 게시하고, 다른 관리자와 소통하여 중복된 저장소 신원을 초기화하지 않도록 하는 것이 중요하다고 언급함. 하지만 사람들이 문서를 읽지 않거나 주의를 기울이지 않아 이러한 요청을 무시할 가능성이 높음. 홈페이지에서는 코드를 푸시하는 방법을 안내하지만, 이 중요한 요청은 사용자 가이드에서만 찾을 수 있어 문제가 될 수 있음.

    문서에서는 자신이 소유하거나 관리하는 저장소만 게시하고, 다른 관리자와 소통하여 중복된 저장소 신원을 초기화하지 않도록 하는 것이 중요하다고 언급합니다. 하지만 사람들이 문서를 읽지 않거나 주의를 기울이지 않아 이러한 요청을 무시할 가능성이 높습니다. 홈페이지에서는 코드를 푸시하는 방법을 안내하지만, 이 중요한 요청은 사용자 가이드에서만 찾을 수 있어 문제가 될 수 있습니다.

  • "peer to peer" 또는 "distributed"와 같은 용어의 정확한 정의를 바람. 이 용어들이 버즈워드로 사용될 때 매우 모호해질 수 있음.

    사람들이 "peer to peer" 또는 더 흔히 "distributed"라는 용어를 정확히 정의하기를 바랍니다. 이 용어들은 버즈워드로 사용될 때 매우 모호해질 수 있습니다.

  • 출시를 축하하며, git 대신 pijul을 사용하는 비슷한 프로젝트인 nest.pijul.com을 떠올림.

    출시를 축하합니다! 이것은 git 대신 pijul을 사용하는 비슷한 프로젝트인 nest.pijul.com을 생각나게 합니다.

  • 주제에서 벗어난 언급으로, NESticle을 떠올림.

    주제에서 벗어난 언급: 이것은 NESticle을 생각나게 합니다. NESticle 위키

답변달기