Went to see what this does. I think it might tell me? But it's unveiling the info as though the docs are generated in real time, one token at a time. For all I know, they might be? Anyway, I bounced. Ain't nobody got that kinda attention oh look a squirrel
The animation also shoves the mobile site down one line at a time, so if you skipped ahead because you're trying to read complete sentences, you get an unpleasant experience.
Appreciate the honest feedback on the website - hearing this loud and clear from multiple people. The Product Hunt page definitely does a better job explaining it simply.
Re: AMD - I'd love to chat about this. We're running on Modal right now which uses NVIDIA, but supporting AMD would be valuable especially as we scale. What part of the stack do you have running? Would be interested in exploring a collaboration.
We've written a cuda to amdgpu compiler. It should be possible to persuade someone like Modal that this is wonderful. So far people largely decline to believe that it can be done at all :)
If you've written vaguely reasonable cuda, feed it to our nvcc binary and away you go. It's more annoying with dependencies, e.g. first one builds cutlass with our "nvcc" and so forth. Just occurred to me while writing this that we could start hosting builds of popular libraries ourselves.
Does it help agents set up development environments?
This is confusing as mostly the problem has been solved - suboptimally but "well enough" - by a patchwork of solutions every repo builds over time:
1. README.md - which agents can read and follow just fine. And they can debug the problems and if you ask, they can update the README so the next agent (or human) can follow the README with less trouble.
2. Dependency versions can be pinned in Dockerfile to avoid dependency hell.
3. Version pinning is supported by project.toml, Gemfile, package.json etc. as well. And all the major languages offer per-directory isolated dependency environments (uv/venv, nvm, rvm, chruby, etc.) So even non-containerized dev has no dependency hell.
4. Secrets for the "dev DB" etc. can be stored in a password vault or wiki. Which agents can access via a browser or curl, given your credentials - or else you can copy-paste them over.
Most crucially, development environments are only set up once when starting work on a new codebase. As rarely as once every few years.
It doesn't really explain where the environment runs, it's not clear if I have to configure something like GCP/AWS or if GitArsenal handles all this (and how much it costs if so)
Good question, it handles all the infrastructure. GitArsenal runs on Modal's serverless platform, and we automatically provision the right machines for each repo's requirements(working on this feature btw). You don't need to configure GCP/AWS or manage any cloud resources, just point us at a GitHub repo and we handle finding the appropriate compute, spinning up environments, and running the setup
The unsolved part: reliable, automated setup that works across the long tail of repos without human intervention. Docker helps but doesn't solve it (many repos don't have working Dockerfiles, and building those is itself a setup problem).
Shame to see it's all Nvidia tech. If you want it on AMDGPU as well I've got that part of the stack running. Can probably do something collaborative.
Re: AMD - I'd love to chat about this. We're running on Modal right now which uses NVIDIA, but supporting AMD would be valuable especially as we scale. What part of the stack do you have running? Would be interested in exploring a collaboration.
Feel free to reach out at: rohan@ataraxy-labs.com
If you've written vaguely reasonable cuda, feed it to our nvcc binary and away you go. It's more annoying with dependencies, e.g. first one builds cutlass with our "nvcc" and so forth. Just occurred to me while writing this that we could start hosting builds of popular libraries ourselves.
3am here so I'll leave you with our somewhat confusing https://spectralcompute.com/ and the more useful direct link to a tarball https://docs.scale-lang.com/stable/manual/how-to-install/#__...
I've only just started thinking about how to make it easier to use the stack. Thoughts / feedback very welcome on that!
This is confusing as mostly the problem has been solved - suboptimally but "well enough" - by a patchwork of solutions every repo builds over time:
1. README.md - which agents can read and follow just fine. And they can debug the problems and if you ask, they can update the README so the next agent (or human) can follow the README with less trouble.
2. Dependency versions can be pinned in Dockerfile to avoid dependency hell.
3. Version pinning is supported by project.toml, Gemfile, package.json etc. as well. And all the major languages offer per-directory isolated dependency environments (uv/venv, nvm, rvm, chruby, etc.) So even non-containerized dev has no dependency hell.
4. Secrets for the "dev DB" etc. can be stored in a password vault or wiki. Which agents can access via a browser or curl, given your credentials - or else you can copy-paste them over.
Most crucially, development environments are only set up once when starting work on a new codebase. As rarely as once every few years.
Can you explain what's unsolved?