Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
llama
- Llama – A CLI for outsourcing computation to AWS Lambda
- llama
- Distcc: A fast, free distributed C/C++ compiler
-
Distributed Cloud Builds for Everyone
I was surprised there wasn't a more obvious link, but the implementation of the ideas in the post is in open-source CLI tool here https://github.com/nelhage/llama
- Llama: CLI for outsourcing computation to Amazon Lambda
-
Outrun: Execute local command using processing power of another Linux machine
See also llama:
https://github.com/nelhage/llama
> Llama is a tool for running UNIX commands inside of Amazon Lambda. Its goal is to make it easy to outsource compute-heavy tasks to Lambda, with its enormous available parallelism, from your shell.
recc
-
Distributed Cloud Builds for Everyone
Very nice! I really like the ease-of-use of this, as well as the scale-to-zero costs. That's a tricky thing to achieve. Seems like it could become a standard path to ease the migration from local to remote builds.
If the author is interested in standardizing the same, I'd suggest implementing the REAPI protocol (https://github.com/bazelbuild/remote-apis). It should be amenable to implementing on a Lambda-esque back-end, and is already standard amongst most tools doing Remote Execution (including Bazel! Bazel+llama could be fun). And equally, it's totally usable by a distcc-esque distribution tool (recc[1] is one example) - that's also what Android is doing before they finish migrating to Bazel ([2], sadly not yet oss'd).
The main interesting challenge I expect this project to hit is going to be worker-local caching: for compilation actions it's not too bad to skip assuming the compiler is built into the container environment, but if branching out into either hermetic toolchains or data-heavy action types (like linking), fetching all bytes to the ephemeral worker anew each time may prove to be prohibitive. On the other hand, that might be a nice transition point to switch to persistent workers: use a lambda backed solution for the scale-to-0 case, and switch execution stacks under the hood to something based on reused VMs when hitting sufficient scale that persistent executors start to win out.
(Disclaimer: I TL'd the creation of this API, and Google implementation of the same).
[1] https://gitlab.com/BuildGrid/recc
[2] https://opensource.googleblog.com/2020/11/welcome-android-op...
What are some alternatives?
bazel-buildfarm - Bazel remote caching and execution service
remote-apis - An API for caching and execution of actions on a remote system.
icecream - Distributed compiler with a central scheduler to share build load
OpenAFS - Fork of OpenAFS from git.openafs.org for visualization
cargo-mutants - :zombie: Inject bugs and see if your tests catch them!
outrun - Execute a local command using the processing power of another Linux machine.
gnu-parallel - A clone of GNU Parallel (git://git.savannah.gnu.org/parallel.git)
rffmpeg - rffmpeg: remote SSH FFmpeg wrapper tool
telepythy - Remote Python Runner
sccache - Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.