Codex remote environments seem to do this, we had to add support (via two lines of code) for these proxy environment variables to our CLI to support talking to GitHub from these environments.
We see things more in the light of Heidi Howard’s recent Flexible Quorums and her comments that all these ideas can be mixed and matched.
Further, our reasons for not picking Raft are different, and have more to do with “what makes Raft Raft”, namely the concessions around view change and replacing message passing with RPC.
We’ve spoken a bit on this if you’d like to dive deeper:
Nit! It’s a bit more historically accurate to say that MultiPaxos/Raft are later variants of VSR since Brian Oki’s VSR predated Paxos by a year (‘88 vs ‘89) and Liskov and Cowling’s revision of Brian’s work in 2012 predated Raft by two years (the papers are remarkably similar, but Raft makes concessions for the sake of presentation).
I know it was published first, we’ve talked about this before :)
But, I’m not sure what was published first decide what’s a variant of what. I would say that, given the breadth of research into variants of Paxos and the ways it can be modified, it is most meaningful today to say they’re all variants of Paxos.
VSR having had little to no research or industry application until recently has a pretty weak claim. It does not appear to have influenced either Paxos or Raft. Raft was influenced by Paxos, and even VSR revisited discusses it in relation to these protocols.
In fact, the Raft paper cites that it was most influenced by VSR:
“Raft is similar in many ways to existing consensus algorithms (most notably, Oki and Liskov’s Viewstamped
Replication [29, 22])”
Happy to keep having this conversation, if only to shine a spotlight and pay tribute to some of the (lesser known but nevertheless) pioneers of our field. :)
I don’t interpret those words that way. I see that as a recognition of the VSR paper, as had been recently highlighted in VSR revisited at the time of publication. I guess you would have to ask the author if VSR had actually influenced his work, it’s certainly possible, but not the inference I would make from that snippet.
The paper references Paxos something like 100 times, versus 3 for VSR. It defines itself as a more understandable alternative to Paxos, so it was certainly influenced both by the existence and relevance of Paxos, and also in opposition to its apparent difficulty.
A good example to illustrate this perhaps is Babbage. He invented the computer first, but nobody using computers today was influenced by him, impressive though his achievements were! Nor would we say that computers are a kind of Babbage “analytical engine”. We say they are a kind of computer.
Diego there is only referring to “the VRR paper” (note the double “R”), i.e. specifically the VR “Revisited” paper of Cowling and Liskov in 2012 (not Oki and Liskov’s ‘88 work, which has a different title).
I wish I could share with you some of the anecdotes I’ve been privy to, having dived into the events and personally interviewed some of the people involved.
The history (or total order!) of consensus is fascinating here, almost like a Greek island, but only a few people will ever know it.
HTTP handlers for requests can be defined, many Convex apps define these to handle webhook notifications and some apps consist primarily of these endpoints or app-specific REST APIs. (I work at Convex)
I so appreciate these being public, see also Steve's Compose readme[1] and post-mortem[2].
I got to sit in for a day during prototyping for user 2 and was impressed but intimidated: reinventing the web stack is a lot of work! The team won me over though. If you have the chance to pair program with JP I highly recommend it, and I expect to be impressed by this team again in the future.
Note that this sentence was about browser-based integration tests. Browser automation has come a long way, but even on very frontend-fluent teams I've been on we had a few flakey tests, and browser-based integration tests are sometimes flakey in ways that are difficult and tedious to debug! Not understanding why doesn't necessarily indicate any lack of understanding of DNS.
But maybe it increases the odds of a "Let's understand Playwright!" post in the future!
A nice surprise to see this here! I did a web port of this game with Emscripten which much help from janisozaur: https://play-endless-web.com
There's an outdated post about what was hard about the port at http://ballingt.com/porting-endless-sky/ – with Emscripten as good as it is, it really wasn't bad!
Here's another implementation of what's described above, it forks on each invocation of readline to provide undo for interactive interpreters. https://github.com/thomasballinger/rlundo
OK I love this, and not just because of the calls to system(nc) :-)
Your code made me think, maybe I'm tying myself into knots... But my thing is making hundred thousands of checkpoints so I'd have to have as many forks as savespoints. No way to coalesce parents, maybe reparenting could work there...
