Here's my product which is a leap in the same direction and will help you run any codebase on relevant machine.
Check it out on gitarsenal.dev/ and we got ranked 6th on Product Hunt as well.
Here's my product which is a leap in the same direction and will help you run any codebase on relevant machine.
Check it out on gitarsenal.dev/ and we got ranked 6th on Product Hunt as well.
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?
KomoD•2mo ago
rohan2003•2mo ago