Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

app.radicle.xyz

Post reply on HN
Print view View original

251–260 of 299 posts

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#251

Post by int_19h »

miohtama wrote: post #120
cloudhead wrote: post #117

Earlier quoted context omitted.

Hey there. Yes, Windows support is something we'd like to have, but focusing on less OSes is helping us ship faster. In principle, there shouldn't be any issue in porting to Windows, but since no one on the team runs Windows it would have been hard to ensure things are working smoothly. If there is demand though, we will certainly start allocating time towards it. Radicle does work on macOS as well.

Windows Subsystem for Linux should alleviate these pains a lot.

WSL is great so long as everything you need to do runs inside its VM. If you need to access things on the main Windows filesystem, you're basically accessing a networked file system at that point, with all that entails for perf.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#252

Post by anonymousDan »

cloudhead wrote: post #85
pastage wrote: post #79

Earlier quoted context omitted.

That problem is social you can never be sure of that even with hardware signing of commits. No tech can ever solve that. Just get "pull requests" from contributors you know and pull from maintainers you trust. Is the social model.

That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, which is bound to the Repository ID.

It's seems to me that for security reasons it might be a good idea to support separate signing keys for normal commits and commits that change the ownership set. This would allow you to keep the ownership change keys offline under the assumption they are rarely used. This is something PoS cryptocurrencies tend to do by having a separate withdrawal key for accessing stake to the signing key used for block proposals, attestations etc.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#253

Post by akurtzhs »

BHSPitMonkey wrote: post #249
bee_rider wrote: post #234

Earlier quoted context omitted.

It looks like there’s still an Arch Linux BitTorrent tracker; maybe I’m out of touch but I think this is not a very uncommon way of distributing distros (?).

Granted, you've found the one (and only?) notable exception to the "no legitimate torrent use cases" rule that I can think of. :) And this has a legacy roughly as long as BitTorrent itself. The fact that BT never established a footing in other use cases (even those where you would think it would be a great solution) is telling.

Blizzard used BitTorrent for distributing full games, patches and trailers for years.

https://wowpedia.fandom.com/wiki/Blizzard_Downloader

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#255

Post by bee_rider »

BHSPitMonkey wrote: post #249
bee_rider wrote: post #234

Earlier quoted context omitted.

It looks like there’s still an Arch Linux BitTorrent tracker; maybe I’m out of touch but I think this is not a very uncommon way of distributing distros (?).

Granted, you've found the one (and only?) notable exception to the "no legitimate torrent use cases" rule that I can think of. :) And this has a legacy roughly as long as BitTorrent itself. The fact that BT never established a footing in other use cases (even those where you would think it would be a great solution) is telling.

That’s fair, I never got into torrenting for illegal purposes but even I had the feeling that we were acting as the thinnest veneer of legitimacy when torrenting distros, haha.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#257

Post by saurik »

IshKebab wrote: post #177
saurik wrote: post #53

From their documentation: > It’s important to only publish repositories you own or are a maintainer of, and to communicate with the other maintainers so that they don’t initialize redundant repository identities. Based on my experience with people taking my code and shoving it onto GitHub--as well as separately in my demoralizing general experience of putting random little "please for the love of all that is holy don…

> putting random little "please for the love of all that is holy don't do X as it will cause problems for other users" notices in the documentation or even as interstitial UI (!!) of my products and watching everyone immediately do exactly that thing as no one reads or thinks (or even cares)--a large number of people aren't going to honor this request in the documentation Kind of off topic, but you shouldn't get anno…

I spoke in the past tense, and already learned this lesson back 20 years ago; you can tell that I believe software can and should be coded to avoid such issues from the position I took with my comment: that it was concerning that the software would stop working not if but when people do not read this "important" notice. Although, maybe you didn't actually bother to read the rest of my comment, and so failed to appreciate my actual point, given how you just quoted something near the beginning which was mere evidence and focused on it with what feels a bit like an axe to grind ;P.

Which, though, leads me to something I will say in response to your reframing: while I do believe that one must build systems with the understanding that people will not read any of the documentation, we should still judge people for the behavior. I am pro commingled recycling, and yet I also believe that people who don't even try to read the signs on top of a series of trash bins are shirking a duty they have to not be a jerk, the same way we should be angry at people for not knowing local laws even if we put them on giant signs on the street as they'd rather just be lazy.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#258

Post by saurik »

heybrendan wrote: post #212
always2slow wrote: post #165

>Installation > >The easiest way to install Radicle is by firing up your terminal and running the following command: > >$ curl -sSf https://radicle.xyz/install | sh Ah.. my high hopes were immediately dashed by the trash that is curl-bash. What a great signal for thoughtless development, if this project catches on I can't wait to watch the security train wreck unfold. Maybe someday we'll get an "Open-Source, Peer-to-…

This is an overreaction, almost to the point of absurdity. Risks inherent to pipe installers are well understood by many. Using your logic, we should abandon Homebrew [1] (>38k stars on GitHub), PiHole [2] (>46k stars on GitHub), Chef [3], RVM [4], and countless other open source projects that use one-step automated installers (by piping to bash). A more reasonable response would be to coordinate with the developers…

FWIW, Homebrew (no longer) deserves quite such ire as you will note that it explicitly does NOT pipe the result to a copy of bash: by downloading it first it and quoting it using a subshell it prevents the web server from being able to get interactive access.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#259

Post by saurik »

LegibleCrimson wrote: post #193
always2slow wrote: post #185

Earlier quoted context omitted.

Thanks but... no thanks, you've missed my point entirely. Why would I want to run peer to peer software built by developers whose security stance starts with curl-bash? Would you curl-bash a webserver? an email server? No? Probably even worse for your source code repository then right?

The problems with curl-bash are overblown. You are pretty much exactly as vulnerable running pip install, npm install, or cargo install. Not that curl bash is great, but it's not uniquely horrible when the goal is to run some unvetted code on your machine. If you care about security, you have to either vet the code or trust the source. When you install through your package manager, you're trusting the maintainers. Wh…

The big difference with curl|bash is that the download itself gets to execute in the context of the computer as it is downloading, which is a super power that makes it much easier to hide behaviors as you can make it extremely difficult for people to ever be able to just download a dead copy of the script to analyze it for malware.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#260

Post by mariusor »

bordumb wrote: post #230
mariusor wrote: post #127

Earlier quoted context omitted.

All good points, but now you moved the trust requirement from me having to trust the people working on the code, to me having to trust the tool that hosts the code. I'm not convinced your model is better. :P

Over time, I’d expect trusting the tool to be more and more trustworthy as more and more eyeballs can review the tool. Whereas having to trust people, especially as people cycle in and out over time can be inherently stochastic.

I don't know, for me when I get involved with a project, I'm more likely to be aware of the people involved with it than the place where they host it.

I understand that the disruption Radicle wants to bring is to divorce projects from their developers, but that sounds so foreign to me, that I can't wrap my head around it. I can see its use in some cases: abandoned projects, unethical behaviour from maintainers, but not to the extent where a new platform is required.

Maybe that's why I'm being such a Negative Nancy. I hope u/cloudhead didn't consider my replies too aggressive. :)

Post reply on HN