Radicle: Açık kaynak tabanlı eşler arası GitHub alternatifi

 (app.radicle.xyz)
2 puan yazan GN⁺ 2024-03-06 | 1 yorum | WhatsApp'ta paylaş
  • Radicle Heartwood, Radicle Protocol’ün üçüncü uygulamasıdır; merkezi bir kod forge’u olmadan eşler arası yöntemle kod işbirliği ve yayınlama yığını sunar
  • Depo, geliştiricilerin doğrudan kullandığı komut satırı aracı rad ve ağ daemon’u radicle-node içerir
  • GitHub ve GitLab gibi kod forge’larının yerini alacak şekilde tasarlanmıştır; güvenlik ve merkeziyetsizlik ile kullanıcı egemenliğini korumayı temel hedefler olarak benimser
  • Kurulum ortamı Linux veya Unix benzeri işletim sistemi, Git 2.34 veya üzeri, ssh-agent içeren OpenSSH 9.1 veya üzeri gerektirir
  • Hem ikili dosya kurulumu hem de Rust kaynak kurulumu desteklenir; ancak geri bildirim e-postaları herkese açık Zulip kanalına otomatik olarak gönderilir ve adınız ile e-posta adresiniz görünebilir

Radicle Heartwood ne sunuyor

  • Heartwood, Radicle Protocol’ün üçüncü yinelemesidir ve eşler arası kod işbirliği ile yayınlama için eksiksiz bir yığındır
  • Depo, Heartwood uygulaması için gerekli ana bileşenleri içerir
    • rad: Kullanıcı dostu komut satırı arayüzü
    • radicle-node: Ağ daemon’u
  • Radicle, GitHub ve GitLab gibi kod forge’larına alternatif olarak tasarlanmıştır
    • Hedefi güvenlik, merkeziyetsizlik, kullanıcı egemenliği ve özgürlüğünün korunmasıdır
  • Genel bilgiler Radicle home page üzerinden görülebilir
  • Proje sohbetleri Zulip chat üzerinde yapılabilir
  • Radicle’ın çalışma şekli Protocol Guide içinde ayrıntılı olarak derlenmiştir

Kurulum ve çalıştırma

  • Kurulum gereksinimleri şunlardır
    • Linux veya Unix tabanlı işletim sistemi

    • Git 2.34 veya üzeri

      • ssh-agent içeren OpenSSH 9.1 veya üzeri
      • İkili dosya kurulumu için curl ve tar gerekir; en yeni sürüm aşağıdaki komutla kurulur
curl -sSf https://radicle.dev/install | sh

- İkili dosyalar [download](https://radicle.dev/download) sayfasından da alınabilir
- Kaynaktan kurmak için **Rust toolchain** gerekir; depo içinde aşağıdaki komutlar çalıştırılır

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

- Doğrudan seed node üzerinden de kurulabilir

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

- Node için **systemd unit** dosyaları `/systemd` klasöründedir ve ek özelleştirmeler için başlangıç noktası olarak kullanılabilir
- Debug modunda çalıştırma için [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md) belgesine bakın

Geri bildirim, katkı ve lisans

  • Geri bildirim rad issue, Zulip veya feedback@radicle.dev üzerinden gönderilebilir
  • E-posta ile gönderilen geri bildirimler Zulip’teki herkese açık #feedback kanalına otomatik olarak yayınlanır
    • Yayınlama sürecinde From başlığı herkese açık olur ve genellikle ad ile e-posta adresini içerir
  • Katkı rehberi CONTRIBUTING.md ve HACKING.md içinde yer alır
  • Radicle, MIT Lisansı ve Apache License 2.0 koşullarıyla dağıtılır
  • Ayrıntılar LICENSE-APACHE ve LICENSE-MIT içinde bulunur

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-06
Hacker News yorumları

  • Radicle’ın kurucu ortağıyım. Protokolün iç işleyişini merak ediyorsanız önce belgelere bakabilirsiniz: https://docs.radicle.xyz/
    Belgeler hâlâ hazırlanıyor

    • Belgeleri okuyunca “Radicle depoları herkese açık/özel olabilir ve kaynak kodu, dokümantasyon ve rastgele veri kümeleri içerebilir” kısmı gözüme çarptı.
      Temelde bir P2P dosya paylaşım uygulaması ise, kötüye kullanım protokolün hangi bölümünde ele alınıyor merak ediyorum. Aksi hâlde film, müzik, yazılım gibi telifli içerikleri gelişigüzel paylaşan BitTorrent veya Winny gibi önceki nesil dosya paylaşım uygulamalarından farkının ne olduğunu bilmiyorum. Az sayıda kötü niyetli kullanıcının işi bozacağını düşünüyorum; ayrıca yasa dışı bir şeye katılmadığımdan emin olabilmek için “kişisel” ağları ayırmanın mümkün olup olmadığını da merak ediyorum
    • İlginç bir proje. İş modelini merak ediyorum.
      Crunchbase’te 12 milyon dolar yatırım aldığı yazıyor; dolayısıyla bir gelirleştirme planı olmalı gibi görünüyor
    • GitHub veya GitLab gibi mülkî hizmetlerin yerine aktif olarak alternatif aramıyorum, ama arada sırada alternatif soran talepler alıyorum. Dağıtık, self-hosted çözümleri seviyorum; Radicle’ın yönü de bu açıdan doğru, fakat gereksinimlerde Linux veya Unix tabanlı işletim sistemi denmesi beni düşündürüyor.
      Yardım ettiğim proje türlerinde bu ölümcül olabilir. Kod Rust gibi görünüyor; MS Windows desteği planlanıyor mu merak ediyorum. Mac OS’un Unix ailesine dahil sayıldığını varsayabiliriz, değil mi? Resmî Windows desteği olmasa bile bir MSYS2 portu mümkün mü merak ediyorum.
      Biraz arka plan eklersem, hizmet sağlayıcı seçimi gibi kararları veren konumda değilim; GitHub’da hatırı sayılır bir açık kaynak kod tabanı bulunan yarı-kamu niteliğinde bir kuruluşla bağlantılıyım. Bazen belirli fikirleri önerme fırsatım oluyor ama benim yetkimde değil. Bu kuruluş, özel tedarikçi politikalarının etkisine kapılmayacak bir dayanıklılığa sahip olma ve sürdürülebilirlik ya da geniş erişilebilirlik gibi “iyi işler” yapma konusunda güçlü motivasyona sahip. Tipik bir Avrupa kamu kuruluşu olduğu için GitHub bu tür politikalarla çelişiyor.
      Arşivleme veya ağ desteğiyle ilgilenen başka kamu kurumları da var, ancak ya kapasiteleri yetersiz ya da eski yöntemlerde takılı kalmış durumdalar; tedarikçilerin kurduğu tuzaklara da sık sık düşüyorlar. Örneğin arşiv hizmeti, DataBricks’in ticari ve kapalı kaynaklı bir ürün olduğunu bile bilmeden onu tamamen benimsedi. Bu yüzden o kuruluşun self-hosted bir çözümü iyi kullanacağına dair beklentim düşük; dağıtık bir çözüm daha iyi görünüyor. Ancak başlıca yaygın PC ortamlarında çalışmayan bir araç kullanılamaz
    • Radicle’a ne kadar bütçe ayrıldığını, kaç kişinin ne kadar süre üzerinde çalıştığını ve kimlerin kullandığını merak ediyorum
    • Web sitesinin ve uygulamanın tasarımını beğendim. Pek çok açık kaynak projesi görsel tasarımda tamamen çuvallıyor; yüzeysel bir unsur olsa bile güzel tasarım, projeyle daha fazla etkileşime girmek istememi sağlıyor.
      Ayrıca eskiden ve şimdi ayrı ayrı hangi düzeyde benimsenme beklediklerini, gerçek sonucun bu beklentilerle örtüşüp örtüşmediğini de merak ediyorum

  • Radicle’ın son yaklaşık 5 yılda nasıl evrildiğini izlemek ilginçti. Protocol Berg 2023 atölyesine katıldım; bence oldukça güçlü ve yeni bir şey ortaya koydular.
    Özellikle ilginç olan nokta, işbirliği özelliklerinin bile local-first olması. İnternet olmasa da patch ve issue gönderebiliyorsunuz; GitHub’da her sorun çıktığında tüm ekibin HN’ye yapışıp kalmasına gerek kalmıyor

  • Amacı için fena bir proje gibi görünmüyor, ama Git’in kendisinin de zaten açık kaynak ve P2P olduğunu düşünüyorum. İkili dosyaları sh <(curl) ile almaya gerek yok; başka Git sunucularına bağlanıp Git komutlarıyla kodu doğrudan çekebilir veya merge edebilirsiniz.
    Git’te olmayan şeyler kod issue’ları, wiki, tartışmalar, GitHub Pages ve her şeyden önce geliştirici profilleri ağı. Kaynak kod commit’leri wiki veya issue’larla karışmasın diye proje metaverisini .git içine koymanın bir yolu gerekiyor. git notes gibi bağımsız referanslar mümkün olabilir.
    https://git-scm.com/docs/git-notes

    • Git bir ölçüde P2P etkileşim düşünülerek tasarlandı, ancak pratikte bu şekilde dağıtıldığı bir model yok. Tüm dağıtım istemci-sunucu modelini kullanıyor; çünkü Git’in tek başına P2P ağa doğrudan dağıtım yapacak özellikleri eksik.
      Örneğin git clone ile aldığınız deponun gerçekten istediğiniz depo olduğunu doğrulamanın bir yolu yok. Bu yüzden güvendiğiniz bir kaynaktan, yani bilinen bir sunucudan klonlamanız gerekiyor. Bu, pratik P2P ile uyumlu değil.
      Radicle, yerelde doğrulanabilir kararlı depo tanımlayıcıları[0] vererek bu sorunu çözüyor ve güvenilmeyen tarafların depoyu sunabilmesini sağlıyor.
      [0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
    • Radicle issue takibi ve pull request ekliyor. Muhtemelen başka bazı özellikler de dahil olacaktır.
      Mobilde, asıl bağlantının altındaki düğmelere basarsanız issue takibi sekmesini ve pull request sekmesini vb. görebilirsiniz
    • Fossil(https://fossil-scm.org) issue’ları, wiki’yi vb. proje deposunun içine koyuyor
    • “Her şeyden önce geliştirici profilleri ağı” mı; dünya ne hâle gelmiş diye düşündürüyor.
      Gerrit’in eskiden kod incelemelerini Git’te sakladığını hatırlıyorum
    • Geleneksel Git, Nintendo ile ilgili son haberlerdeki gibi sansürden kaçamıyor. Bu fikir aklımda dönüp duruyordu; birinin zor işi yapmış olmasına gerçekten sevindim

  • Belgelerde, “yalnızca sahibi olduğunuz veya bakımcısı olduğunuz depoları yayımlamanız ve yinelenen depo tanımlayıcıları oluşturmamak için diğer bakımcılarla iletişim kurmanız önemlidir” deniyor.
    Kodumu alıp GitHub’a koyan insanlarla karşılaştım; ürün belgelerine ya da aradaki kullanıcı arayüzlerine “lütfen X yapmayın, diğer kullanıcılar için sorun çıkarır” uyarısı koysanız bile kimsenin bunu okumadan, düşünmeden ya da umursamadan doğrudan X yaptığını çok gördüm. Bu yüzden birçok kişinin belgelerdeki bu isteğe uymayacağını düşünüyorum; hatta ana sayfa yalnızca kodun nasıl push edileceğini anlatıyor, bu “önemli” istek ise insanların neredeyse hiç okumadığı kullanıcı kılavuzunda yer alıyor.
    Sonuçta ana sayfadaki yönergeleri izleyerek üzerinde çalıştığınız açık kaynak kodunu öylece push etmek gibi makul görünen bir davranışın, protokol ve depolama biçimi nedeniyle zamanla önemli bir şeyi bozabileceği veya kafa karıştırıcı hâle getirebileceği noktası epey kaygı verici.

    • Burada özel bir sorun var gibi görünmüyor. Bugün de bir deponun resmî konumu ayrı bir sosyal ağ ya da web sitesi gibi dış kanallardan bulunuyor.
      GitHub’da yıldız sayısıyla ek güven kazanılabiliyor; Radicle’da bunun karşılığı belirli bir deponun seed sayısı.
    • Belgeleri veya uyarıları görmezden geliyor diye insanlara kızılacak bir durum değil. Bu son derece mantıklı bir davranış.
      Normalde bir günlük bilgisayar kullanımında onlarca uyarı görüyoruz ve onlarca araç kullanıyoruz. Tüm bu uyarıları ve her aracın belgelerini dikkatle okumanın alacağı zamanı düşününce bu çok uzun sürer.
      Bu yüzden okumayıp heuristic kullanmak çok daha iyidir. Örneğin kaydedilmemiş değişiklikleri olan bir belgeyi kapatınca diyalog kutusunun “vazgeçilsin mi?” diye soracağını bildiğiniz için okumanıza gerek yoktur. Bu iyi bir şey.
      Sonuç olarak yazılımı, insanların böyle davrandığı gerçeğini varsayarak tasarlamak gerekir. Genelde bu mümkündür. Somut bir örnek varsa, “rica edip okunmasını ummaktan” daha iyi bir çözüm önerebilirim.
    • GitHub tarzında, kendi deponuzun orijinal olduğunu belirtmek için koda telif hakkı bildirimi koyup telif hakkı bildirimini değiştirmeyi yasa dışı hâle getirmek değil mi? Bu burada da uygulanabilir.

  • Çıkışı tebrikler. Bu projeyi takip ediyordum ve ne kadar olgunlaştığını görmek gerçekten heyecan verici. Şu anda GitHub’da olan bir projeyi taşımanın en iyi yolu nedir merak ediyorum. Denenebilecek bir mirror mode olup olmadığını da merak ediyorum.

    • Henüz yerleşik mirroring yok, ama bunu değerlendiriyoruz. Teoride her saat GitHub’dan çekip Radicle’a push eden bir cron görevi ayarlamak kadar basit olmalı.
      git pull github master
      git push rad master

  • Bu depoların sıradan kullanıcılar tarafından ne kadar keşfedilebilir olacağını merak ediyorum. https://app.radicle.xyz/robots.txt yok gibi görünüyor, yani arama motorlarının almasına izin veriliyor gibi; nitekim Google ve DDG’de site:app.radicle.xyz ile arayınca sonuçlar çıkıyor.
    Henüz site filtresi olmadan üst sıralarda görünmüyorlar, ama sıralama iyileşebilir.
    CI desteğiyle entegre olan araçlar da olsa iyi olurdu. Nihayetinde while true; do wait_repo_update; git pull && ./run_ci.sh; done gibi bir döngü olurdu, ama yalnızca güvenilen tanımlayıcılardan gelen push’larla sınırlanabilen daha iyi bir biçime ihtiyaç var.
    Son olarak artefact depoları da gerekli. Ancak Radicle’ın her şeyi çözmesi gerekmeyebilir. Özellikle büyük ikilileri paylaşan dağıtık bir ağ, oldukça hızlı biçimde istenmeyen amaçlar için kullanılacak gibi duruyor.

    • Şu anda çeşitli CI entegrasyonları üzerinde çalışıyoruz ve ihtiyaçlarımıza göre uyarlanmış kendi yerel CI’ımızı da geliştiriyoruz.
    • İyi nokta. app.radicle.xyz gibi gateway’ler, crawler’ların ağdaki tüm depo kümesini indekslemesine izin vermeli gibi görünüyor.

  • “P2P” ya da daha yaygın deyişle “dağıtık” tam olarak ne anlama geliyor, insanların bunu net biçimde tanımlamasını isterdim. Şu anda fazlasıyla muğlak bir moda sözcük hâline geldi ve her anlama gelecek şekilde kullanılabiliyor.

    • Bu terimin sıkça yanlış kullanıldığını görmedim. Radicle ve çoğu P2P sisteminde kullanılan tanım Wikipedia tanımıyla[0] aynı; özellikle de “peer’ler ağda eşit yetki ve kabiliyetlere sahip katılımcılardır” kısmı.
      Dolayısıyla P2P sistem, tüm katılımcıların “ağ içinde eşit yetkiye” sahip olduğu sistemdir. Genellikle herkesin aynı yazılımı çalıştırdığı anlamına da gelir.
      [0]: https://en.wikipedia.org/wiki/Peer-to-peer

  • Kurulum talimatı curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | sh ise, beklentim doğrudan curl-bash çöplüğüne çöktü
    Böyle bir kurulum yöntemi düşüncesiz geliştirmenin güçlü bir işareti. Bu proje tutarsa bir güvenlik felaketinin yaşandığını göreceğiz gibi geliyor. Umarım bir gün en kötü kurulum biçimiyle başlamayan bir “açık kaynak P2P GitHub alternatifi” çıkar

    • Bu neredeyse saçma denecek düzeyde bir aşırı tepki
      Pipe edilen kurulum programlarının riskleri birçok kişi tarafından iyi biliniyor. Bu mantıkla Homebrew [1](38 binden fazla GitHub yıldızı), PiHole [2](46 binden fazla), Chef [3], RVM [4] ve bash’e pipe edilen tek adımlı otomatik kurulum programı kullanan sayısız açık kaynak projeyi çöpe atmamız gerekir
      Daha makul tepki, geliştiricilerle çalışıp belgelerde alternatif kurulum yöntemleri sunmalarını ya da riskleri daha iyi açıklamalarını sağlamak olur; pire için yorgan yakmak değil
      [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
    • Biraz dramatik bir tepki değil mi?
      Aktarımın yarıda kesilmesi sorununa gelince, sisteminizde ^(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?)?) ile eşleşen tehlikeli komutlar olmadığı sürece script güvenli
      Bunu hallettikten sonra, yalnızca scripti sunup çalıştırma komutunu sunmamakla arasındaki fark ne, emin değilim. İncelemek istiyorsanız scripti indirip ayrıca çalıştırabilirsiniz. Pipe edilen script ile indirilmiş scripti algılamanın bir yolu vardı gibi hatırlıyorum ama bu tür küçük scriptlerde çalışmaz sanırım
    • Burada var [0]. Proje henüz yayımlanmadan önceki aşamada olduğu için ele alınması gereken parçalar var ve şu an odak biraz başka yerde. Rust’ın cargo’suyla kaynaktan derlemek de mümkün [1]
      [0] https://files.radicle.xyz/latest/
      [1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
    • İsterseniz kullanırsınız, istemezseniz kullanmazsınız; bakımcıya güvenip güvenmeme meselesi. Kurulum yöntemi, bakımcıya güvenilip güvenilmeyeceğini belirleyecek şey olmamalı; curl-bash olsa bile

  • Kripto para piyasası her yükseldiğinde Radicle’dan bahsedildiğini duyuyor gibiyim. Bunu ciddi olarak kullanan var mı?
    Bu bir anda downvote yemiş. Cidden soruyorum; Radicle’a ne kadar bütçe ayrıldı, kaç kişi üzerinde çalıştı ve kimler kullanıyor merak ediyorum

    • Adil bir soru
      Kripto sektöründe çalışıyorum ve bende de aynı izlenim oluştu. Radicle’ı en son önceki boğa piyasasında duymuştum, ayı piyasasında ise sessizdi. Herkes ayı piyasası inşa etme zamanıdır diyor ve Radicle açıkça bir geliştirici aracı, bu yüzden oldukça tuhaf

  • Depoları yalnızca belirli bir düğüm kümesine sunma kullanım senaryosunu destekleme planı olup olmadığını merak ediyorum. GitHub’da olmak istemeyen ama özel iş birliği yapmak isteyen insanlar olabilir

    • Var. Radicle’da buna özel depo deniyor. Ağın geri kalanına görünmez ve yalnızca güvenilen eşler arasında paylaşılır
      Ancak depolanırken şifreli olmadığı için, güven kümesine dahil olmayan aracı düğümlerde depolanamaz