I had a few different issues getting the CI broker working the way I wanted to (don't even remember what the issues were, but it had to do with catching patches) so wired up my own way but simply polling via Git - using a thing I built a while back called goa (gitops agent) for another project.
The tricky part was getting the output from what ever do with the code, back into the Radicle patch. But it works.
The raw point is valid. Sure this a poorly edited article and lacks the best research - can we agree that like almost everything, we've engineered these things to be commercially short in terms of life-span, let alone not super-sustainable in terms of manufacture or maintenance? Aside from the continuously performance-oriented standardization shifts, the specialization of bicycle types is doing a disservice to sustainability. Also, the "electrification" of bicycles is a completely separate argument - from all angles: manufacture, maintenance and longevity; one that is no different that all EVs. TBH, this article reads like a ChatGPT dialog.
Unfortunate that we've missed another opportunity for healthy dialog around the benefits of the bicycle.
That exists, it is just hidden right now. If my intent was to offer this up and a for-the-public-good I'd turn it back on. But like most of the other comments here, at some point it just doesn't make sense for me to foot the bill to run it. It would be one thing if it was a simple front-end, with a simple back-end. But processing this insight is a little bit resource intensive which creates a cost burden. Academically it wasn't a big deal to run this in a true HPC, the costs have already been covered. Commercially is a different calculus.
Basic analysis of open source software's source - for things like "bus factor". Started as a research project, probably going to die as a research project.
Right, so the moral of the story centers on the target user of the CLI tool. If you're building something for the Elixir community - game on I suppose, though there is still the complexity of build-env per OS/arch.
I wonder where WASM/container enters the discussion.
But...the issue is packaging/distributing a CLI built with Elixir. Comparatively to building a CLI in something like Rust, there is a lot of overhead that comes with a VM-based language and framework. Especially if you want to target multiple OS and processor architectures (or distributions). Not to say that it is impossible, just maybe not as simple. It is one thing to run Mix tasks, or access the Owl API from REPL, it is another to run an Owl-based app on macOS, Linux and Windows and get it there.
I worked on a DARPA project a few years before this - where we were using CBE as the core for a polymorphic processor (one with an FPGA attached to every IO). We were also gutting PS3s to make mission computers for early unmanned systems - running Ubuntu on top. USAF wasn't the only one - not only were there commercial supply challenges with the PS3, various components were being horded by various nation states. We were pretty sure they didn't even no what to do with the parts, but was a basic attempt to prevent projects like this from getting off the ground.
I loved nb! Until I ran it from a top-level directory and it committed an update to every git repo within that top-level. :D. Definitely operator error, but I learned my lesson and am back to separating notes from todos.
This is awesome! Super appreciate the effort on this.
One challenge I've had is the file-based concept. And it losing "shape" quickly. I taken a few whacks at something different and have settled on a CLI-based kanban-y thing: https://github.com/kitplummer/clikan
But this lacks things like tags - which I appreciate as long as they are searchable in some form.
The tricky part was getting the output from what ever do with the code, back into the Radicle patch. But it works.
https://revolveteam.com/blog/goa-radicle-ci/
There are some caveats - mostly security related - given this is potentially executing commands on a host node.