I'm surprised the author rejected using GitLab because of its Open Core model, but decided foe using Drone CI, which appears to be following a similar model.
Evaluating new software forges
21–30 of 138 posts
Re: Evaluating new software forges
#22> Rather than needing a complicated YAML file to run a CI system, it’s just cloning Git repos and running commands. How do you define what repos you need and which commands are run? Ah, it is indeed also a YAML file: https://srht.site/automating-deployments
But is it a _complicated_ YAML file?
Re: Evaluating new software forges
#23Is not hard for me to see a case being built around the idea of finding value in having code to stay excluded from the surface exposed to AI so it becomes impossible for it to predate it. It's a type of "security" that doesn't find an answer in "better AIs" or "AIs with improved alignment". The value comes out of being safe from the risk that can come out of the humans in control of these AIs. I comes out of staying…
Does the chef not use tools?
Re: Evaluating new software forges
#24I'm surprised the author rejected using GitLab because of its Open Core model, but decided foe using Drone CI, which appears to be following a similar model.
The whole article feels really inconsistent on what the author likes and dislikes and his reasonings behind such things. Really off putting article imo.
Re: Evaluating new software forges
#25I'm surprised the author rejected using GitLab because of its Open Core model, but decided foe using Drone CI, which appears to be following a similar model.
If drone’s open core is a problem, there is always woodpecker, which was forked from the original drone before they changed their license a few years ago.
Re: Evaluating new software forges
#26> Rather than needing a complicated YAML file to run a CI system, it’s just cloning Git repos and running commands. How do you define what repos you need and which commands are run? Ah, it is indeed also a YAML file: https://srht.site/automating-deployments
But is it a _complicated_ YAML file?
it's also not "just cloning Git repos and running commands"
Re: Evaluating new software forges
#27I was hoping for an evaluation of Radicle--the only forge that seemed to be doing something exciting and "new", and one I haven't had the time to really analyze yet--but... no such luck :(.
There is also https://protocol.land and https://gitopia.com .
The layout of radicle.land is unfortunately pretty broken on mobile.
Re: Evaluating new software forges
#28> the email-based workflow was a lot clunkier than I expected
> If you want to create a repo for PR’s sake, email me at dev at notgull dot net and I can set you up.
So is there no way to allow seamless forking like on GitHub without high risks of abuse?
Re: Evaluating new software forges
#29Is not hard for me to see a case being built around the idea of finding value in having code to stay excluded from the surface exposed to AI so it becomes impossible for it to predate it. It's a type of "security" that doesn't find an answer in "better AIs" or "AIs with improved alignment". The value comes out of being safe from the risk that can come out of the humans in control of these AIs. I comes out of staying…
Does the chef not use tools?
Robot chefs are tools? Are they chefs?
Re: Evaluating new software forges
#30I also checked out SourceHut, but they're unfortunately not compatible with my email provider, and after some discussion with Drew (the founder) it started to sound like I'm not welcome unless I bring a real legal name and human identity. I understand how that type of collaboration can be valued and desired, but it excludes me, so I didn't pursue SourceHut any further. Something to think about if you ever consider it…
[dead]