cloudhead's comments

On: Rust needs an extended standard library

[cloudhead]

This doesn’t solve the supply chain security issue mentioned.

[spease → cloudhead]

Maybe, but it’s kind of half-assed to just figure out a solution that only works for stdx and then leave every other library out to hang.

Supporting tools like cargo audit would be a better choice for the entire ecosystem, not just things that are appropriate to have in stdx.

On: Rust needs an extended standard library

[cloudhead]

Even better would be to have some of the basics in the standard library, like Go and Zig.

On: Boeing to plead guilty to criminal fraud charge st...

[cloudhead]

So are people going to jail?

On: Dangers of “decentralized” ID systems

[cloudhead]

Low quality post that doesn’t understand how DIDs work.

[justinko → cloudhead]

That's because it was clearly very heavily assisted by AI.

On: Radicle: Open-Source, Peer-to-Peer, GitHub Alterna...

[cloudhead]

No plans to do so - firstly we’d have to rewrite it in C, and second it would be a big amount of code for the Git project to merge.

On: Radicle: Open-Source, Peer-to-Peer, GitHub Alterna...

[cloudhead]

We tried. At first we built it on top of IPFS. It was much too slow. BitTorrent is interesting but we need a way to have mutability (repos change all the time). So we built the networking layer ourselves and the forge on top of that.

[contrarian1234 → cloudhead]

If you built a mutable bittorrent layer yourself (like ipfs but better), then why not make it its own separate thing?

If that's what you've managed to pull off, that's like a way bigger deal than a p2p gitforge (not that that isn't super cool in itself)

I guess architecturally why does it need to be coupled to git and a git forge?

[cloudhead → contrarian1234]

It's optimized for certain workloads around code collab, so for now we don't want to oversell it. It doesn't have to be coupled with Git, though Git is very efficient at synchronizing changes. The protocol currently can be used for other things than a forge, but having an application influence protocol development is very helpful.

On: Radicle: Open-Source, Peer-to-Peer, GitHub Alterna...

[cloudhead]

Contributions to the repo have to abide to both licenses, derivative work gets to choose only one.

[20after4 → cloudhead]

That explains it perfectly, thank you!

On: Radicle: Open-Source, Peer-to-Peer, GitHub Alterna...

[cloudhead]

It’s simple: I don’t want my code and code collaborators to be using a platform owned and controlled by a third party. Just like I don’t want my OS or text editor, kitchen, furniture, clothing, books or music to be controlled by a third party that can decide to take it away whenever they see fit. Code and open source are integral to my life, as are the other things cited above, and therefore I’m uncomfortable with the idea of using github for the forseable future.

As it happens there are many others like me, and this helps fuel our excitement and drive to get this out there.

On: Radicle: Open-Source, Peer-to-Peer, GitHub Alterna...

[cloudhead]

Understandably! We are working on packages for Linux and macOS.

On: Radicle: Open-Source, Peer-to-Peer, GitHub Alterna...

[cloudhead]

It's a good question, I don't know why you're downvoted.

Because the synchronization protocol (backed by Git) is operating in the background, web frontends are always just querying local data, so it's actually quite fast. You can try browsing the linked repository and see for yourself.

[throwaway220033 → cloudhead]

Even a slightly critical comment gets downvoted instantly in this thread, I wonder why ;)