This is a very good list. Adrian's blog is, particularly, a treasure.

I wrote this post a while ago, aiming to answer a similar question about finding paper: http://brooker.co.za/blog/2020/05/25/reading.html One key point there is that there are, in my mind, multiple 'modes' of reading, and I like to use different approaches to finding material for different modes. Those blogs you list are great for curiosity mode. Another great resource there is Twitter: following distributed systems practitioners and researchers, and seeing what they tweet about. When I read a (recent) paper I really like, I often see if the authors are active on Twitter and follow them there if they are.

It's also important not to weight too much on recency. A lot of the canon is actually more approachable than newer papers. For example, Lamport's classic "Time, Clocks" (https://www.microsoft.com/en-us/research/publication/time-cl...) and distributed snapshot (https://www.microsoft.com/en-us/research/publication/distrib...) papers, and Gilbert and Lynch's CAP paper (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67....) are approachable without deep background or systems knowledge. Similarly, John Little's " A Proof for the Queuing Formula: L = λW" (https://pubsonline.informs.org/doi/abs/10.1287/opre.9.3.383) is quite approachable if you have a math background but no systems knowledge, and is one of the foundational results behind the practice of building stable systems.

I've got some longer-form dives into researcher's work here: http://brooker.co.za/blog/2014/03/30/lamport-pub.html http://brooker.co.za/blog/2014/09/21/liskov-pub.html http://brooker.co.za/blog/2014/05/10/lynch-pub.html

Finally, books. There are a couple recommendations for Martin Kleppman's Designing Data-Intensive Applications book, which I like a whole lot. Alex Petrov's "Database Internals" is also a very approachable introduction. I wish every practitioner in the field would read Harchol-Balter's Performance Modeling and Design of Computer Systems.

More gentle introduction to timeless concepts that stood the test of times.

Material from a university master course on distributed systems engineering. We developed our own university material in .ipynb format at Github. Should give you the basics in 5 days. Applies distributed systems theory in 5 steps. Most improvements in past decade are not due to hardware improvement, but algorithm and tooling advances I believe.

- Distributed systems. Overlays and communication network. Introduction to simulation framework https://github.com/grimadas/BlockchainEngineering/blob/maste...

- Gossip. Convergence of the transactions, information https://github.com/grimadas/BlockchainEngineering/blob/maste...

- Faults in distributed systems: crashes and disruptions https://github.com/grimadas/BlockchainEngineering/blob/maste...

- Malicious nodes, adversary model https://github.com/grimadas/BlockchainEngineering/blob/maste...

- Consensus and agreement despite malicious nodes https://github.com/grimadas/BlockchainEngineering/blob/maste...

I couldn't agree more about curiosity mode (I'm going to use that phrase liberally). Despite reading papers for many years, I rarely go in cold. I browse blog posts and twitter, ask myself a series of questions, then try to find/read papers to answer them. Of course this only leads to more questions, and so the journey continues.

I also agree with the recommendations for "Designing Data-Intensive Applications" and "Database Internals". Though, having read the latter for a book club at $employer, I felt it served better as a sort of "index for the space" for people who already had some DB experience, rather a true introduction.

> Another great resource there is Twitter: following distributed systems practitioners and researchers, and seeing what they tweet about.

What's your twitter handle?

I recall paper trail had some errors in their post on paxos (iirc), which made me more skeptical of the publication in general. But these are good links!!

Well, "Paxos Made Simple" has some errors, so if you're skeptical about stuff with errors your options are rather limited.

See https://lamport.azurewebsites.net/pubs/pubs.html#paxos-simpl... Ok, might not be fair to call it an error, but it is super confusing, and a great example of Lamport's larger point that writing prose about these things is really hard, and we need better tools (like TLA+).

Interesting note: "one sentence in this paper is ambiguous [...] I am not going to remove this ambiguity or reveal where it is."

I find it surprising that he didn't actually attempt to change this problematic sentence if it was clearly shown that it leads to incorrect implementations. I get his point about prose, but a tiny footnote on a webpage doesn't feel like the best way to highlight what seems to be a common misunderstanding.

Any idea what this ambiguous sentence might be, and what is this mistake that implementers tend to make?