The Wisdom of Bearded Gurus

The Wisdom of Bearded Gurus

Disclaimer: I will rework this. I had too much to say and had to cut to fit in 40mn. Actually I spoke so fast that I spent only 20. So I will add some content soon.

Abstract:
In the good ol' times, when Computer Science was young and open like the ocean, brave captains were more mathematicians than developers. Also, they had great beards.

They opened routes, fought monsters, discovered unknown lands, and we had fun on this ever since. As time goes by, we seem to forget some of their warnings and wisdom.

It's time to roll the treasure map and find the buried chests of pure gold advice!

1c737f6bf76c2f983c77446629a188d8?s=128

Sylvain Abélard

October 04, 2013
Tweet

Transcript

  1. Wisdom of the Bearded Gurus vendredi 4 octobre 2013

  2. vendredi 4 octobre 2013

  3. vendredi 4 octobre 2013

  4. Wisdom of the Bearrrrded Gurrrrus vendredi 4 octobre 2013

  5. Me at 10 vendredi 4 octobre 2013 Here’s me at

    10. Young, foolish and frankly? Underwater. Culture, films, comics: ancient is good. Well OK but why didn’t it win? Unless of course it’s... secret. You noticed that game BTW? Guess what: people are often slowed down because of idolizing things.
  6. Me at 20 vendredi 4 octobre 2013 Here’s me at

    18~23. Why the pain? Well I’m in an association and it seems we never learn. Why don’t we learn? Maybe it’s just hard. Note that, if it’s secret it’s not my fault I don’t know. I have excuses.
  7. Feeling like a kid vendredi 4 octobre 2013 But I

    don’t like excuses, or rather, I’d like to find the secret to beat people. Then I started looking, and I felt like a kid again. Afraid of the big guys. How to stand proud when you only have just a pack of menthol sweets?
  8. Arrogance vendredi 4 octobre 2013 Luckily for me, arrogance came

    back. I felt like I knew everything. Then I know I don’t. Then I try to bluff people in thinking I do.
  9. Crew! Boat! vendredi 4 octobre 2013 At some point I

    found something like a crew. Luckily for me, the Ruby crew is an awesome crew ;)
  10. maitre-du-monde.fr @abelar_s vendredi 4 octobre 2013 OK so now you

    know me, where are we going?
  11. Let’s go fearlessly vendredi 4 octobre 2013 Let’s unearth some

    old geeks’ bones.
  12. ? vendredi 4 octobre 2013 We’re lost. And the path...

    wow, it’s difficult to even know where it starts.
  13. OH: it’s fun to see the (Node.)JS community be rocked

    hard each time they rediscover old things. vendredi 4 octobre 2013 This made me laugh because Ruby & Rails is not the cool kid anymore, so bashing JS guys was fun.
  14. Object/Relational Mapping is the Vietnam of computer science - Ted

    Newark vendredi 4 octobre 2013 Or not. I’m not quoting what other, older, less fancy communities say about Ruby.
  15. - imperative programming - object-oriented prog. - ActiveRecord-oriented prog. When

    did it go wrong? vendredi 4 octobre 2013 At least we have some healthy sense of self-derision to correct ourselves.
  16. I would advise students to pay more attention to the

    fundamental ideas rather than the latest technology. The technology will be out- of-date before they graduate. Fundamental ideas never get out of date. -- David Parnas vendredi 4 octobre 2013 Wow. How about human stuff? Tech changed every 10 years (now rather every 2 years) but humans evolved in millenia so that’s not going anytime soon.
  17. vendredi 4 octobre 2013

  18. Books vendredi 4 octobre 2013

  19. Universities vendredi 4 octobre 2013

  20. Communications of the ACM vendredi 4 octobre 2013 Also, conferences

    like SIGGRAPH.
  21. In Search of an Understandable Consensus Algorithm Diego Ongaro and

    John Ousterhout Stanford University (Draft of April 7, 2013, under submission to SOSP) Abstract Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to Paxos, and it is as efficient as Paxos, but its structure is different from Paxos; this makes Raft more understandable than Paxos and also provides a better foundation for building practi- cal systems. In order to enhance understandability, Raft separates the key elements of consensus, such as leader election and log replication, and it enforces a stronger de- gree of coherency to reduce the number of states that must be considered. Raft also includes a new mechanism for changing the cluster membership, which uses overlapping majorities to guarantee safety. Results from a user study demonstrate that Raft is easier for students to learn than Paxos. 1 Introduction Consensus algorithms allow a collection of machines to work as a coherent group that can survive the failures of some of its members. Because of this, they play a key role in building reliable large-scale software systems. Paxos [9, 10] has dominated the discussion of consensus algorithms over the last decade: most implementations of consensus are based on Paxos or influenced by it, and Paxos has become the primary vehicle used to teach stu- dents about consensus. Unfortunately, Paxos is quite difficult to understand, in spite of numerous attempts to make it more approach- able. Furthermore, its architecture is unsuitable for build- ing practical systems, requiring complex changes to cre- ate an efficient and complete solution. As a result, both system builders and students struggle with Paxos. After struggling with Paxos ourselves, we set out to find a new consensus algorithm that could provide a bet- ter foundation for system building and education. Our ap- proach was unusual in that our primary goal was under- standability: could we define a consensus algorithm and describe it in a way that is significantly easier to learn than Paxos, and that facilitates the development of intuitions that are essential for system builders? It was important not just for the algorithm to work, but for it to be obvi- ous why it works. In addition, the algorithm needed to be complete enough to cover all the major issues required for an implementation. The result of our effort is a consensus algorithm called Raft. Raft is similar in many ways to existing consensus algorithms (most notably, Oki and Liskov’s Viewstamped Replication [17]), but it has several novel aspects: • Design for understandability: understandability was our most important criterion in evaluating de- sign alternatives. We applied specific techniques to improve understandability, including decomposition (Raft separates leader election, log replication, and safety so that they can be understood relatively in- dependently) and state space reduction (Raft reduces the degree of nondeterminism and the ways servers can be inconsistent with each other, in order to make it easier to reason about the system). • Strong leader: Raft differs from other consensus al- gorithms in that it employs a strong form of leader- ship where only leaders (or would-be leaders) issue requests; other servers are completely passive. This makes Raft easier to understand and also simplifies the implementation. • Membership changes: Raft’s mechanism for changing the set of servers in the cluster uses a sim- ple joint consensus approach where the majorities of two different configurations overlap during tran- sitions. We performed a user study with 43 graduate students at two universities to test our hypothesis that Raft is more understandable than Paxos. After learning both algo- rithms, students were able to answer questions about Raft 23% better than questions about Paxos. We have implemented Raft in about 1500 lines of C++ code, and the implementation is used as part of RAMCloud [18]. We have also proven the correctness of the Raft algorithm. The remainder of the paper introduces the replicated state machine problem (Section 2), discusses the strengths and weaknesses of Paxos (Section 3), describes our gen- eral approach to understandability (Section 4), presents the Raft consensus algorithm (Sections 5-7), evaluates Raft (Section 8), and discusses related work (Section 9). 2 Achieving fault-tolerance with replicated state machines Consensus algorithms typically arise in the context of replicated state machines [20]. In this approach, state ma- chines on a collection of servers compute identical copies of the same state and can continue operating even if some of the servers are down. Replicated state machines are used to solve a variety of fault-tolerance problems in dis- tributed systems. For example, large-scale systems that have a single cluster leader, such as GFS [4], HDFS [21], and RAMCloud [18], typically use a separate replicated state machine to manage leader election and store config- 1 vendredi 4 octobre 2013 So now you’ve found some papers.
  22. In Search of an Understandable Consensus Algorithm Diego Ongaro and

    John Ousterhout Stanford University (Draft of April 7, 2013, under submission to SOSP) Abstract Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to Paxos, and it is as efficient as Paxos, but its structure is different from Paxos; this makes Raft more understandable than Paxos and also provides a better foundation for building practi- cal systems. In order to enhance understandability, Raft separates the key elements of consensus, such as leader election and log replication, and it enforces a stronger de- gree of coherency to reduce the number of states that must be considered. Raft also includes a new mechanism for changing the cluster membership, which uses overlapping majorities to guarantee safety. Results from a user study demonstrate that Raft is easier for students to learn than Paxos. 1 Introduction Consensus algorithms allow a collection of machines to work as a coherent group that can survive the failures of some of its members. Because of this, they play a key role in building reliable large-scale software systems. Paxos [9, 10] has dominated the discussion of consensus algorithms over the last decade: most implementations of consensus are based on Paxos or influenced by it, and Paxos has become the primary vehicle used to teach stu- dents about consensus. Unfortunately, Paxos is quite difficult to understand, in spite of numerous attempts to make it more approach- able. Furthermore, its architecture is unsuitable for build- ing practical systems, requiring complex changes to cre- ate an efficient and complete solution. As a result, both system builders and students struggle with Paxos. After struggling with Paxos ourselves, we set out to find a new consensus algorithm that could provide a bet- ter foundation for system building and education. Our ap- proach was unusual in that our primary goal was under- standability: could we define a consensus algorithm and describe it in a way that is significantly easier to learn than Paxos, and that facilitates the development of intuitions that are essential for system builders? It was important not just for the algorithm to work, but for it to be obvi- ous why it works. In addition, the algorithm needed to be complete enough to cover all the major issues required for an implementation. The result of our effort is a consensus algorithm called Raft. Raft is similar in many ways to existing consensus algorithms (most notably, Oki and Liskov’s Viewstamped Replication [17]), but it has several novel aspects: • Design for understandability: understandability was our most important criterion in evaluating de- sign alternatives. We applied specific techniques to improve understandability, including decomposition (Raft separates leader election, log replication, and safety so that they can be understood relatively in- dependently) and state space reduction (Raft reduces the degree of nondeterminism and the ways servers can be inconsistent with each other, in order to make it easier to reason about the system). • Strong leader: Raft differs from other consensus al- gorithms in that it employs a strong form of leader- ship where only leaders (or would-be leaders) issue requests; other servers are completely passive. This makes Raft easier to understand and also simplifies the implementation. • Membership changes: Raft’s mechanism for changing the set of servers in the cluster uses a sim- ple joint consensus approach where the majorities of two different configurations overlap during tran- sitions. We performed a user study with 43 graduate students at two universities to test our hypothesis that Raft is more understandable than Paxos. After learning both algo- rithms, students were able to answer questions about Raft 23% better than questions about Paxos. We have implemented Raft in about 1500 lines of C++ code, and the implementation is used as part of RAMCloud [18]. We have also proven the correctness of the Raft algorithm. The remainder of the paper introduces the replicated state machine problem (Section 2), discusses the strengths and weaknesses of Paxos (Section 3), describes our gen- eral approach to understandability (Section 4), presents the Raft consensus algorithm (Sections 5-7), evaluates Raft (Section 8), and discusses related work (Section 9). 2 Achieving fault-tolerance with replicated state machines Consensus algorithms typically arise in the context of replicated state machines [20]. In this approach, state ma- chines on a collection of servers compute identical copies of the same state and can continue operating even if some of the servers are down. Replicated state machines are used to solve a variety of fault-tolerance problems in dis- tributed systems. For example, large-scale systems that have a single cluster leader, such as GFS [4], HDFS [21], and RAMCloud [18], typically use a separate replicated state machine to manage leader election and store config- 1 Scriptless Attacks Lamport’s Paxos vendredi 4 octobre 2013 These are pretty different papers by the way.
  23. Scriptless Attacks vendredi 4 octobre 2013

  24. In Search of an Understandable Consensus Algorithm Diego Ongaro and

    John Ousterhout Stanford University (Draft of April 7, 2013, under submission to SOSP) Abstract Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to Paxos, and it is as efficient as Paxos, but its structure is different from Paxos; this makes Raft more understandable than Paxos and also provides a better foundation for building practi- cal systems. In order to enhance understandability, Raft separates the key elements of consensus, such as leader election and log replication, and it enforces a stronger de- gree of coherency to reduce the number of states that must be considered. Raft also includes a new mechanism for changing the cluster membership, which uses overlapping majorities to guarantee safety. Results from a user study demonstrate that Raft is easier for students to learn than Paxos. 1 Introduction Consensus algorithms allow a collection of machines to work as a coherent group that can survive the failures of some of its members. Because of this, they play a key role in building reliable large-scale software systems. Paxos [9, 10] has dominated the discussion of consensus algorithms over the last decade: most implementations of consensus are based on Paxos or influenced by it, and Paxos has become the primary vehicle used to teach stu- dents about consensus. Unfortunately, Paxos is quite difficult to understand, in spite of numerous attempts to make it more approach- able. Furthermore, its architecture is unsuitable for build- ing practical systems, requiring complex changes to cre- ate an efficient and complete solution. As a result, both was our most important criterion in evaluating de- sign alternatives. We applied specific techniques to improve understandability, including decomposition (Raft separates leader election, log replication, and safety so that they can be understood relatively in- dependently) and state space reduction (Raft reduces the degree of nondeterminism and the ways servers can be inconsistent with each other, in order to make it easier to reason about the system). • Strong leader: Raft differs from other consensus al- gorithms in that it employs a strong form of leader- ship where only leaders (or would-be leaders) issue requests; other servers are completely passive. This makes Raft easier to understand and also simplifies the implementation. • Membership changes: Raft’s mechanism for changing the set of servers in the cluster uses a sim- ple joint consensus approach where the majorities of two different configurations overlap during tran- sitions. We performed a user study with 43 graduate students at two universities to test our hypothesis that Raft is more understandable than Paxos. After learning both algo- rithms, students were able to answer questions about Raft 23% better than questions about Paxos. We have implemented Raft in about 1500 lines of C++ code, and the implementation is used as part of RAMCloud [18]. We have also proven the correctness of the Raft algorithm. The remainder of the paper introduces the replicated Lamport’s Paxos vendredi 4 octobre 2013
  25. Lamport’s Paxos vendredi 4 octobre 2013 Well at least, Lamport’s

    has more pictures in it.
  26. vendredi 4 octobre 2013 HELP! We’re talking technical jargon here!

  27. vendredi 4 octobre 2013 Looks like it was made by

    a robot and we’d need some translation.z
  28. Title Team & uni. Abstract intro keywords vendredi 4 octobre

    2013 Friendly Droid will help translate. They all have the same structure.
  29. Acknowledg ements references conclusion related works vendredi 4 octobre 2013

    Tags / abstract / introduction and conclusion are where to start for fast reading.
  30. Title Team Abstract vendredi 4 octobre 2013 On the Web

    you can do things a bit differently.
  31. related works keywords vendredi 4 octobre 2013

  32. keywords? Title (Team) Abstract? intro Acknowledgements references conclusion vendredi 4

    octobre 2013 A thesis is a bit different but respects the same codes.
  33. Here’s my proposal vendredi 4 octobre 2013

  34. Find nuggets vendredi 4 octobre 2013 "When you want to

    do something differently from the rest of the world, it's a good idea to look into whether the rest of the world knows something you don't."
  35. Meet, drink, talk vendredi 4 octobre 2013

  36. Fight! vendredi 4 octobre 2013

  37. Form parties vendredi 4 octobre 2013

  38. Set sail! vendredi 4 octobre 2013

  39. Adventure time! vendredi 4 octobre 2013

  40. Now you’re mainstream vendredi 4 octobre 2013

  41. Questions? vendredi 4 octobre 2013

  42. @abelar_s maitre-du-monde.fr Have fun! vendredi 4 octobre 2013

  43. A game of beards Beard or nerd? vendredi 4 octobre

    2013
  44. RULES: guess guru levels based on beard vendredi 4 octobre

    2013
  45. Beware of traps! vendredi 4 octobre 2013

  46. vendredi 4 octobre 2013

  47. Alan Cox Linux Kernel vendredi 4 octobre 2013

  48. vendredi 4 octobre 2013

  49. DMR & Ken Thompson B / Unix / Plan9 vendredi

    4 octobre 2013
  50. vendredi 4 octobre 2013

  51. Alan Kay Smalltalk vendredi 4 octobre 2013

  52. vendredi 4 octobre 2013

  53. Robert Tarjan Graph Theory vendredi 4 octobre 2013

  54. vendredi 4 octobre 2013

  55. EWD vendredi 4 octobre 2013

  56. vendredi 4 octobre 2013

  57. Captain Crunch vendredi 4 octobre 2013

  58. vendredi 4 octobre 2013

  59. McCarthy vendredi 4 octobre 2013

  60. vendredi 4 octobre 2013

  61. Sergey Brin vendredi 4 octobre 2013

  62. vendredi 4 octobre 2013

  63. John Carmack vendredi 4 octobre 2013

  64. vendredi 4 octobre 2013

  65. Don Knuth vendredi 4 octobre 2013

  66. vendredi 4 octobre 2013

  67. ADA vendredi 4 octobre 2013

  68. vendredi 4 octobre 2013

  69. Grace Hopper vendredi 4 octobre 2013

  70. ? vendredi 4 octobre 2013

  71. ? vendredi 4 octobre 2013 if you agree that Stallmann

    has a better beard than Bill Joy you are forced to agree that emacs beats Vim!
  72. ? vendredi 4 octobre 2013

  73. ? vendredi 4 octobre 2013

  74. ? vendredi 4 octobre 2013

  75. vendredi 4 octobre 2013