3 ms·

I have many recommendations of different kinds: ## Blogs: - http://muratbuffalo.blogspot.com/ http://muratbuffalo.blogspot.com/ - https://bartoszsypytkowski.

• mjb 6y ago
  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 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-clocks-ordering-events-distributed-system/ https://www.microsoft.com/en-us/research/publication/time-cl...) and distributed snapshot (https://www.microsoft.com/en-us/research/publication/distributed-snapshots-determining-global-states-distributed-system/ 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.6951&rep=rep1&type=pdf 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 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/03/30/lamport-pub.html http://brooker.co.za/blog/2014/09/21/liskov-pub.html http://brooker.co.za/blog/2014/09/21/liskov-pub.html http://brooker.co.za/blog/2014/05/10/lynch-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.
  • synctext 6y ago
    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/master/01_Intro_To_Distributed_Systems.ipynb https://github.com/grimadas/BlockchainEngineering/blob/maste... - Gossip. Convergence of the transactions, information https://github.com/grimadas/BlockchainEngineering/blob/master/02_Gossip_Services.ipynb https://github.com/grimadas/BlockchainEngineering/blob/maste... - Faults in distributed systems: crashes and disruptions https://github.com/grimadas/BlockchainEngineering/blob/master/03_Faults.ipynb https://github.com/grimadas/BlockchainEngineering/blob/maste... - Malicious nodes, adversary model https://github.com/grimadas/BlockchainEngineering/blob/master/04_Byzantine.ipynb https://github.com/grimadas/BlockchainEngineering/blob/maste... - Consensus and agreement despite malicious nodes https://github.com/grimadas/BlockchainEngineering/blob/master/05_Consensus.ipynb https://github.com/grimadas/BlockchainEngineering/blob/maste...
  • hugofirth 6y ago
    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.
  • mandeepj 6y ago
    > Another great resource there is Twitter: following distributed systems practitioners and researchers, and seeing what they tweet about. What's your twitter handle?
• Vervious 6y ago
  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!!
  • mjb 6y ago
    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-simple 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+).
    • thamer 6y ago
      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?