Performance and optimization is one of many pieces, but yes, it's a meme to render 500k lines.
That said though, and maybe I didn't say it well in the post, the more performant and optimized your tool is, the less burden you put on developers and users.
Sure you won't review 100k lines, but maybe the diff includes a ton of testing snapshots, or maybe it's a long running feature branch and you need to just quickly jump in and look at a specific change from a specific file. The less the developer or the user needs to think about `how` to render the diff or `how to navigate the diff`, the better we did our job.
2. Raspberry pi as a forge for a long time: also check, the git server shim is super lightweight, its just an XRPC layer over git repositories + an sqlite3 database. there are folks running it on a riscv board with 512 megs of RAM.
3. Actions are critical and they should be runnable on my local machine: IMO this ask is slightly misplaced. it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc. it would be really cool to "promote" results of such builds to the forge itself.
Surprised to see raspberry pi for hosting data that's supposed to be integral to a workflow. I've been burned too many times by SD card corruption in the past. Do you use NVME drives nowadays, just curious.
I use RPi 4 with a cheap SSD connected via USB-to-SATA connector as a tiny home server for a year already and it works without issues.
I know that not all USB-to-SATA connectors are compatible with RPi – I got lucky with the first connector I tried (Unitek). Not sure if RPi 5 has a wider compatibility.
A year isn't much. I changed I four ssds,sata,sata,nvme,nvme, about every other year, while the data store at some cheap wdc spinning rust still spins and won't stop for some years.
Raspi5 has a pci connection for ssd hardware add-ons, I use one and it runs fine with a 2 TB one, I just let it on forever. This has been on for almost a year currently without issues.
It is the job of the build system, yes. In most cases the problems people want to solve with locally runnable Actions aren't the build not working, it's the whole integration of the thing; all the YAML definition, secrets, exactly what commands it runs, how it restores tools and caches (which your build system _might_ take care of but the available primitives for that in GHA are very poor), etc.
I do think it's just an awkward problem to solve though, because it essentially devolves to needing to run the entire system somewhere else, which is why every system I've seen like this ends up being trial-and-error.
>it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc.
yes, and... the idea here is that it would be neat to extend the hermetic builds idea such that this can be run locally / anywhere where there's compute easily. The root problem that's being called out here is that idea of running something until the CI says it's green when there's a change, commit, network call, in the cycle is a pain in the ass. (The best way to avoid this churncycle is to just never write bugs! TFIC ;P)
Both Radicle and Tangled miss the point; these are all for public collaborative work, but what about private repos? Many users work on side projects; they use GitHub private for this. Once you learn GitHub, then you also start public projects on GitHub.
The point I am trying to make is, until you offer a user the ability to make a private repo for side projects, it's unlikely to take off.
What people want is the ability to make a private repo, go away for a few months and come back to find their repos right there waiting for them.
Private repos provide nothing to the site by definition. The value model here is, you must pay for private repos, either by paying a subscription or hosting your own node and bearing the related costs.
A remote execution cluster and CAS for build artifacts is a good way to avoid duplicate work on local vs CI, and avoid the problem of needing to trust local builds.
Between Radicle, Tangled and Grasp, Radicle feels the coolest to me, emotionally, local first, p2p, for whatever reason it feels kind of nostalgic.
Grasp is actually pretty cool too, built on nostr, which is maybe a stronger platform in the end? I dont really know enough about it. Stronger as in, you're maybe opening up more interoperablity by putting your stuff on a "anything network" vs Radicles "p2p git data network".
To be honest they're all cool ideas, Tangled feels some how corporate though.
Graps seems neat in the way it forces you to sign your commits (which should really be standard practice) but I think Github itself has proven that interoperability is not that important.
I can understand that. It's a difficult problem design-wise and needs someone that knows crypto, so I won't hold it against software that labels itself as alpha.
i am unable to access any repository on that website. for some, it complains that ssh or https URLs are not supported by my browser? and for others its just loading indefinitely with `Failed to load file tree`. maybe its not fairly mature.
> how would you build a social graph of follows/stars and what not using user-owned git repos as a backing store?
I'm just spitballing and depending on how you want to display it, you may need more - but if I want to "follow" you I submit a signed commit to your "follow" repository, similar if I'm staring a repo; and then your system issues a signed commit back to my "followed" repo.
its linked in the original post as well, but here is an explanation of why activitypub is not a good fit for this problem, by the authors of ForgeFed themselves: https://forgefed.org/blog/actor-programming/
Reading that - I'm really not sure that AT Protocol has a much better story there either.
(as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.
Yeah the problems they seemed to have were over collaborative data structures with permissions. You’re right about how atproto solves that, which means you’re using CRDTs if you need to collaborate. If that’s a fit mismatch, I’d tell people to just appoint api servers which wrap a repo and provide the needed semantics.
maybe, but tangled knots actually federate. you could contribute to repos on knot.ghostty.org and knot.tangled.org with the same account. no other platform permits one identity across instances.
I think the key point is that it's one atproto login/did to many forges 1:N in tangled.org's "knots" network without the reliance on a single host provider/instance like GitHub/GitLab/whatever as a single point of failure.
have a longer write up here: https://blog.tangled.org/stacking but we have "interdiffs", to view a delta from previous review. pull-requests advance in the form of immutable rounds much like the patch workflow on email.
reply