https://hackerpaper.kaipfister.de/p/2006.00064/Collected HN comments and submissions linking this paper.enMon, 02 Nov 2026 11:16:22 GMThttps://news.ycombinator.com/item?id=28181343urn:hackerpapers:mention:2006.00064:28181343Sat, 14 Aug 2021 15:22:09 GMT<p>This is the approach I take when I write, so this is how I try to write. I hope it is reflected in my first-author papers. Three papers from the past several years: https://www.scott-a-s.com/files/middleware2016_loadbalancing..., https://www.scott-a-s.com/files/pldi2017_lf_elastic_scheduli..., https://arxiv.org/pdf/2006.00064.pdf.</p><p><a href="https://hackerpaper.kaipfister.de/p/2006.00064/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.DChttps://news.ycombinator.com/item?id=25245145urn:hackerpapers:mention:2006.00064:25245145Sun, 29 Nov 2020 14:04:08 GMT<p>Me and my colleagues came up with an abstraction called conductors for the orchestration problem. Short version is that when you have some dependence on multiple resources being in a particular state before creating or updating yet another resource, use a conductor. They observe multiple resource kinds, and operate a FSM internally. State transitions happen upon receiving an event from an observed resource. The logs of the conductor make it easy to debug dependency problems, because you can easily see that your conductor’s FSM is in a particular state, waiting to see some number of a…</p><p><a href="https://hackerpaper.kaipfister.de/p/2006.00064/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.DC