Add acknowledgements, rebuild site and ebooks

input/6_appendix.md

@@ -4,7 +4,7 @@ If you've made it this far, thank you.
 
 If you liked the book, follow me on [Github](https://github.com/mixu/) (or [Twitter](http://twitter.com/mikitotakada)). I love seeing that I've had some kind of positive impact. "Create more value than you capture" and all that.
 
-I'd like to thank @logpath and @alexras for their comments - of course, any mistakes and omissions that remain are my fault!
+I'd like to thank @logpath, @alexras, @globalcitizen, @graue and @frankshearar for their comments and corrections - of course, any mistakes and omissions that remain are my fault!
 
 It's worth noting that my chapter on eventual consistency is fairly Berkeley-centric; I'd like to change that. I've also skipped one prominent use case for time: consistent snapshots. There are also a couple of topics which I should expand on: namely, an explicit discussion of safety and liveness properties and a more detailed discussion of consistent hashing. However, I'm off to [Strange Loop 2013](https://thestrangeloop.com/), so whatever.
 

output/abstractions.html

@@ -182,7 +182,7 @@ <h2>The CAP theorem</h2>
 <p>I&#39;ll discuss this in more detail in the chapter on replication when I discuss Paxos. The important thing is that CP systems incorporate network partitions into their failure model and distinguish between a majority partition and a minority partition using an algorithm like Paxos, Raft or viewstamped replication. CA systems are not partition-aware, and are historically more common: they often use the two-phase commit algorithm and are common in traditional distributed relational databases.</p>
 <p>Assuming that a partition occurs, the theorem reduces to a binary choice between availability and consistency.</p>
 <p class="img-container"><img src="images/CAP_choice.png" alt="Based on http://blog.mikiobraun.de/2013/03/misconceptions-about-cap-theorem.html"></p>
-<p>I think there are three conclusions that should be drawn from the CAP theorem:</p>
+<p>I think there are four conclusions that should be drawn from the CAP theorem:</p>
 <p>First, that <em>many system designs used in early distributed relational database systems did not take into account partition tolerance</em> (e.g. they were CA designs). Partition tolerance is an important property for modern systems, since network partitions become much more likely if the system is geographically distributed (as many large systems are).</p>
 <p>Second, that <em>there is a tension between strong consistency and high availability during network partitions</em>. The CAP theorem is an illustration of the tradeoffs that occur between strong guarantees and distributed computation.</p>
 <p>In some sense, it is quite crazy to promise that a distributed system consisting of independent nodes connected by an unpredictable network &quot;behaves in a way that is indistinguishable from a non-distributed system&quot;.</p>

output/appendix.html

@@ -62,7 +62,7 @@ <h1 style="color: white; background: #D82545; display: inline-block; padding: 6p
 <h1>6. Further reading and appendix</h1>
 <p>If you&#39;ve made it this far, thank you.</p>
 <p>If you liked the book, follow me on <a href="https://github.com/mixu/">Github</a> (or <a href="http://twitter.com/mikitotakada">Twitter</a>). I love seeing that I&#39;ve had some kind of positive impact. &quot;Create more value than you capture&quot; and all that.</p>
-<p>I&#39;d like to thank @logpath and @alexras for their comments - of course, any mistakes and omissions that remain are my fault!</p>
+<p>I&#39;d like to thank @logpath, @alexras, @globalcitizen, @graue and @frankshearar for their comments and corrections - of course, any mistakes and omissions that remain are my fault!</p>
 <p>It&#39;s worth noting that my chapter on eventual consistency is fairly Berkeley-centric; I&#39;d like to change that. I&#39;ve also skipped one prominent use case for time: consistent snapshots. There are also a couple of topics which I should expand on: namely, an explicit discussion of safety and liveness properties and a more detailed discussion of consistent hashing. However, I&#39;m off to <a href="https://thestrangeloop.com/">Strange Loop 2013</a>, so whatever.</p>
 <p>If this book had a chapter 6, it would probably be about the ways in which one can make use of and deal with large amounts of data. It seems that the most common type of &quot;big data&quot; computation is one in which <a href="http://en.wikipedia.org/wiki/SPMD">a large dataset is passed through a single simple program</a>. I&#39;m not sure what the subsequent chapters would be (perhaps high performance computing, given that the current focus has been on feasibility), but I&#39;ll probably know in a couple of years.</p>
 <h2>Books about distributed systems</h2>

output/ebook.html

@@ -400,7 +400,7 @@ <h2>The CAP theorem</h2>
 <p>I&#39;ll discuss this in more detail in the chapter on replication when I discuss Paxos. The important thing is that CP systems incorporate network partitions into their failure model and distinguish between a majority partition and a minority partition using an algorithm like Paxos, Raft or viewstamped replication. CA systems are not partition-aware, and are historically more common: they often use the two-phase commit algorithm and are common in traditional distributed relational databases.</p>
 <p>Assuming that a partition occurs, the theorem reduces to a binary choice between availability and consistency.</p>
 <p class="img-container"><img src="images/CAP_choice.png" alt="Based on http://blog.mikiobraun.de/2013/03/misconceptions-about-cap-theorem.html"></p>
-<p>I think there are three conclusions that should be drawn from the CAP theorem:</p>
+<p>I think there are four conclusions that should be drawn from the CAP theorem:</p>
 <p>First, that <em>many system designs used in early distributed relational database systems did not take into account partition tolerance</em> (e.g. they were CA designs). Partition tolerance is an important property for modern systems, since network partitions become much more likely if the system is geographically distributed (as many large systems are).</p>
 <p>Second, that <em>there is a tension between strong consistency and high availability during network partitions</em>. The CAP theorem is an illustration of the tradeoffs that occur between strong guarantees and distributed computation.</p>
 <p>In some sense, it is quite crazy to promise that a distributed system consisting of independent nodes connected by an unpredictable network &quot;behaves in a way that is indistinguishable from a non-distributed system&quot;.</p>
@@ -1286,7 +1286,7 @@ <h4>Dynamo; PBS; optimistic replication</h4>
 <div style="page-break-after: always;"></div><a name="appendix"></a><h1>6. Further reading and appendix</h1>
 <p>If you&#39;ve made it this far, thank you.</p>
 <p>If you liked the book, follow me on <a href="https://github.com/mixu/">Github</a> (or <a href="http://twitter.com/mikitotakada">Twitter</a>). I love seeing that I&#39;ve had some kind of positive impact. &quot;Create more value than you capture&quot; and all that.</p>
-<p>I&#39;d like to thank @logpath and @alexras for their comments - of course, any mistakes and omissions that remain are my fault!</p>
+<p>I&#39;d like to thank @logpath, @alexras, @globalcitizen, @graue and @frankshearar for their comments and corrections - of course, any mistakes and omissions that remain are my fault!</p>
 <p>It&#39;s worth noting that my chapter on eventual consistency is fairly Berkeley-centric; I&#39;d like to change that. I&#39;ve also skipped one prominent use case for time: consistent snapshots. There are also a couple of topics which I should expand on: namely, an explicit discussion of safety and liveness properties and a more detailed discussion of consistent hashing. However, I&#39;m off to <a href="https://thestrangeloop.com/">Strange Loop 2013</a>, so whatever.</p>
 <p>If this book had a chapter 6, it would probably be about the ways in which one can make use of and deal with large amounts of data. It seems that the most common type of &quot;big data&quot; computation is one in which <a href="http://en.wikipedia.org/wiki/SPMD">a large dataset is passed through a single simple program</a>. I&#39;m not sure what the subsequent chapters would be (perhaps high performance computing, given that the current focus has been on feasibility), but I&#39;ll probably know in a couple of years.</p>
 <h2>Books about distributed systems</h2>

output/single-page.html

@@ -423,7 +423,7 @@ <h2>The CAP theorem</h2>
 <p>I&#39;ll discuss this in more detail in the chapter on replication when I discuss Paxos. The important thing is that CP systems incorporate network partitions into their failure model and distinguish between a majority partition and a minority partition using an algorithm like Paxos, Raft or viewstamped replication. CA systems are not partition-aware, and are historically more common: they often use the two-phase commit algorithm and are common in traditional distributed relational databases.</p>
 <p>Assuming that a partition occurs, the theorem reduces to a binary choice between availability and consistency.</p>
 <p class="img-container"><img src="images/CAP_choice.png" alt="Based on http://blog.mikiobraun.de/2013/03/misconceptions-about-cap-theorem.html"></p>
-<p>I think there are three conclusions that should be drawn from the CAP theorem:</p>
+<p>I think there are four conclusions that should be drawn from the CAP theorem:</p>
 <p>First, that <em>many system designs used in early distributed relational database systems did not take into account partition tolerance</em> (e.g. they were CA designs). Partition tolerance is an important property for modern systems, since network partitions become much more likely if the system is geographically distributed (as many large systems are).</p>
 <p>Second, that <em>there is a tension between strong consistency and high availability during network partitions</em>. The CAP theorem is an illustration of the tradeoffs that occur between strong guarantees and distributed computation.</p>
 <p>In some sense, it is quite crazy to promise that a distributed system consisting of independent nodes connected by an unpredictable network &quot;behaves in a way that is indistinguishable from a non-distributed system&quot;.</p>
@@ -1309,7 +1309,7 @@ <h4>Dynamo; PBS; optimistic replication</h4>
 <div style="page-break-after: always;"></div><a name="appendix"></a><h1>6. Further reading and appendix</h1>
 <p>If you&#39;ve made it this far, thank you.</p>
 <p>If you liked the book, follow me on <a href="https://github.com/mixu/">Github</a> (or <a href="http://twitter.com/mikitotakada">Twitter</a>). I love seeing that I&#39;ve had some kind of positive impact. &quot;Create more value than you capture&quot; and all that.</p>
-<p>I&#39;d like to thank @logpath and @alexras for their comments - of course, any mistakes and omissions that remain are my fault!</p>
+<p>I&#39;d like to thank @logpath, @alexras, @globalcitizen, @graue and @frankshearar for their comments and corrections - of course, any mistakes and omissions that remain are my fault!</p>
 <p>It&#39;s worth noting that my chapter on eventual consistency is fairly Berkeley-centric; I&#39;d like to change that. I&#39;ve also skipped one prominent use case for time: consistent snapshots. There are also a couple of topics which I should expand on: namely, an explicit discussion of safety and liveness properties and a more detailed discussion of consistent hashing. However, I&#39;m off to <a href="https://thestrangeloop.com/">Strange Loop 2013</a>, so whatever.</p>
 <p>If this book had a chapter 6, it would probably be about the ways in which one can make use of and deal with large amounts of data. It seems that the most common type of &quot;big data&quot; computation is one in which <a href="http://en.wikipedia.org/wiki/SPMD">a large dataset is passed through a single simple program</a>. I&#39;m not sure what the subsequent chapters would be (perhaps high performance computing, given that the current focus has been on feasibility), but I&#39;ll probably know in a couple of years.</p>
 <h2>Books about distributed systems</h2>

readme.md

@@ -31,7 +31,7 @@ You need to install Calibre first for the HTML to epub/mobi conversion.
 
 # Thanks
 
-Many many thanks to logpath and alexras for their help!
+Many many thanks to logpath, alexras, globalcitizen, graue and frankshearar for their help!
 
 # Licence