Thanks!
171 karma · joined May 5, 2012
But why do all of this piecemeal? Our philosophy is to create a controlled test sandbox environment that makes all these aspects (including concurrency) reproducible:
https://www.cloudseal.io/blog/2018-04-06-intro-to-fixing-fla...
The idea is to guarantee that any flake is easy to reproduce. If people have objections to that approach, we'd love to hear them. Conversely, if you would be willing to test out our early prototype, get in touch.
First, we'd love it if you would try our early container prototype on your build. Contact us and we'll add you to our closed alpha test. Also, we can send you the full paper (preprint) on the Debian case study, with the gory details.
I would never argue against patching tool chains to make them deterministic. If I were the maintainer I would always accept these patches! (And the GHC community we're part of has made some efforts on that front.)
You raise an interesting question regarding bootstrapping which I believe is similar to the good old Ken Thompson "Trusting Trust" attack: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
Well, there's always some trusted code base (even with Coq), but I would argue that it would be harder for us to execute the trusting-trust attack in a container than in a compiler like Ken Thompson's original. The compiler can inject malware when it recognizes that its compiling itself, but we run arbitrary build systems, compiler tool chains, JITs. On top of that, one can build the container itself without ever using the container, so we wouldn't have an opportunity to inject.
Any containers or VMs that we use in binary form need to be trusted for the same reasons. And Debian Reproducible Builds still has the original trusting-trust approach to contend with as well: i.e. they could bootstrap with a previously-corrupted gcc binary. The DRB website lists a Ph.D. dissertation on improving this situation, but I haven't read it, and I don't think it's been implemented in DRB: https://dwheeler.com/trusting-trust/
Regarding "topologically static", the system doesn't assume a fixed set of communicating endpoints (like MPI ranks). It will all you to dynamically add new participants to the network.
Why is the gRPC comparison not fair? Shouldn't they do dynamic batching also? It can be done without unduly affecting latency. (I did my phd in stream processing studying this proposition, and Jonathan Goldstein and others have demonstrated the same thing in Trill.) In the case of AMBROSIA, our latency increase vs gRPC is not because of batching, but is because on waiting for the log to persist in georeplicated storage.
Nevertheless, please give it a try and help us out by filing issues for anything you run into. You can get off the ground by simply running `Scripts/run_*_ci.sh` (which will need you to set up your Azure storage connection string for pushing service metadata to Azure).
This Thursday, December 13th, you can find us from 8-noon at the AKS KubeCon booth. https://events.linuxfoundation.org/events/kubecon-cloudnativ...
And as far as I can tell it does take a supercomputer to run Aperture.
* https://github.com/HIPERFIT/accelerate-opencl
Either OpenCL, or a freely available x86 CUDA, would really make CPU/GPU programming more useful in this case. We might already have what we need re: CUDA x86. On our TODO list is trying PGI Accelerator and GPU Ocelot for this purpose: