Bearded gurus

75
Wisdom of the Bearded Gurus vendredi 4 octobre 2013

description

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!

Transcript of Bearded gurus

Page 1: Bearded gurus

Wisdom of the Bearded Gurus

vendredi 4 octobre 2013

Page 2: Bearded gurus

vendredi 4 octobre 2013

Page 3: Bearded gurus

vendredi 4 octobre 2013

Page 4: Bearded gurus

Wisdom of the BearrrrdedGurrrrus

vendredi 4 octobre 2013

Page 5: Bearded gurus

Me at 10

vendredi 4 octobre 2013Here’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.

Page 6: Bearded gurus

Me at 20

vendredi 4 octobre 2013Here’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.

Page 7: Bearded gurus

Feeling like a kid

vendredi 4 octobre 2013But 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?

Page 8: Bearded gurus

Arrogance

vendredi 4 octobre 2013Luckily 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.

Page 9: Bearded gurus

Crew!Boat!

vendredi 4 octobre 2013At some point I found something like a crew.Luckily for me, the Ruby crew is an awesome crew ;)

Page 10: Bearded gurus

maitre-du-monde.fr@abelar_s

vendredi 4 octobre 2013OK so now you know me, where are we going?

Page 11: Bearded gurus

Let’s gofearlessly

vendredi 4 octobre 2013Let’s unearth some old geeks’ bones.

Page 12: Bearded gurus

?

vendredi 4 octobre 2013We’re lost.And the path... wow, it’s difficult to even know where it starts.

Page 13: Bearded gurus

OH: it’s fun to see the (Node.)JS community be rocked hard each time they rediscover old things.

vendredi 4 octobre 2013This made me laugh because Ruby & Rails is not the cool kid anymore,so bashing JS guys was fun.

Page 14: Bearded gurus

Object/Relational Mapping is the Vietnam of computer science

- Ted Newark

vendredi 4 octobre 2013Or not.I’m not quoting what other, older, less fancy communities say about Ruby.

Page 15: Bearded gurus

- imperative programming- object-oriented prog.- ActiveRecord-oriented prog.

When did it go wrong?

vendredi 4 octobre 2013At least we have some healthy sense of self-derision to correct ourselves.

Page 16: Bearded gurus

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 2013Wow.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.

Page 17: Bearded gurus

vendredi 4 octobre 2013

Page 18: Bearded gurus

Books

vendredi 4 octobre 2013

Page 19: Bearded gurus

Universities

vendredi 4 octobre 2013

Page 20: Bearded gurus

Communications of the ACM

vendredi 4 octobre 2013Also, conferences like SIGGRAPH.

Page 21: Bearded gurus

In Search of an Understandable Consensus AlgorithmDiego Ongaro and John Ousterhout

Stanford University(Draft of April 7, 2013, under submission to SOSP)

AbstractRaft is a consensus algorithm for managing a replicated

log. It produces a result equivalent to Paxos, and it isas efficient as Paxos, but its structure is different fromPaxos; this makes Raft more understandable than Paxosand also provides a better foundation for building practi-cal systems. In order to enhance understandability, Raftseparates the key elements of consensus, such as leaderelection and log replication, and it enforces a stronger de-gree of coherency to reduce the number of states that mustbe considered. Raft also includes a new mechanism forchanging the cluster membership, which uses overlappingmajorities to guarantee safety. Results from a user studydemonstrate that Raft is easier for students to learn thanPaxos.

1 IntroductionConsensus algorithms allow a collection of machines

to work as a coherent group that can survive the failuresof some of its members. Because of this, they play akey role in building reliable large-scale software systems.Paxos [9, 10] has dominated the discussion of consensusalgorithms over the last decade: most implementationsof consensus are based on Paxos or influenced by it, andPaxos has become the primary vehicle used to teach stu-dents about consensus.

Unfortunately, Paxos is quite difficult to understand, inspite 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, bothsystem builders and students struggle with Paxos.

After struggling with Paxos ourselves, we set out tofind 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 anddescribe it in a way that is significantly easier to learn thanPaxos, and that facilitates the development of intuitionsthat are essential for system builders? It was importantnot just for the algorithm to work, but for it to be obvi-ous why it works. In addition, the algorithm needed to becomplete enough to cover all the major issues required foran implementation.

The result of our effort is a consensus algorithm calledRaft. Raft is similar in many ways to existing consensusalgorithms (most notably, Oki and Liskov’s ViewstampedReplication [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 toimprove understandability, including decomposition(Raft separates leader election, log replication, andsafety so that they can be understood relatively in-dependently) and state space reduction (Raft reducesthe degree of nondeterminism and the ways serverscan be inconsistent with each other, in order to makeit 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) issuerequests; other servers are completely passive. Thismakes Raft easier to understand and also simplifiesthe implementation.

• Membership changes: Raft’s mechanism forchanging the set of servers in the cluster uses a sim-ple joint consensus approach where the majoritiesof two different configurations overlap during tran-sitions.

We performed a user study with 43 graduate studentsat two universities to test our hypothesis that Raft is moreunderstandable than Paxos. After learning both algo-rithms, students were able to answer questions about Raft23% better than questions about Paxos.

We have implemented Raft in about 1500 lines ofC++ code, and the implementation is used as part ofRAMCloud [18]. We have also proven the correctnessof the Raft algorithm.

The remainder of the paper introduces the replicatedstate machine problem (Section 2), discusses the strengthsand weaknesses of Paxos (Section 3), describes our gen-eral approach to understandability (Section 4), presentsthe Raft consensus algorithm (Sections 5-7), evaluatesRaft (Section 8), and discusses related work (Section 9).

2 Achieving fault-tolerance with replicatedstate machines

Consensus algorithms typically arise in the context ofreplicated state machines [20]. In this approach, state ma-chines on a collection of servers compute identical copiesof the same state and can continue operating even if someof the servers are down. Replicated state machines areused to solve a variety of fault-tolerance problems in dis-tributed systems. For example, large-scale systems thathave a single cluster leader, such as GFS [4], HDFS [21],and RAMCloud [18], typically use a separate replicatedstate machine to manage leader election and store config-

1

vendredi 4 octobre 2013So now you’ve found some papers.

Page 22: Bearded gurus

In Search of an Understandable Consensus AlgorithmDiego Ongaro and John Ousterhout

Stanford University(Draft of April 7, 2013, under submission to SOSP)

AbstractRaft is a consensus algorithm for managing a replicated

log. It produces a result equivalent to Paxos, and it isas efficient as Paxos, but its structure is different fromPaxos; this makes Raft more understandable than Paxosand also provides a better foundation for building practi-cal systems. In order to enhance understandability, Raftseparates the key elements of consensus, such as leaderelection and log replication, and it enforces a stronger de-gree of coherency to reduce the number of states that mustbe considered. Raft also includes a new mechanism forchanging the cluster membership, which uses overlappingmajorities to guarantee safety. Results from a user studydemonstrate that Raft is easier for students to learn thanPaxos.

1 IntroductionConsensus algorithms allow a collection of machines

to work as a coherent group that can survive the failuresof some of its members. Because of this, they play akey role in building reliable large-scale software systems.Paxos [9, 10] has dominated the discussion of consensusalgorithms over the last decade: most implementationsof consensus are based on Paxos or influenced by it, andPaxos has become the primary vehicle used to teach stu-dents about consensus.

Unfortunately, Paxos is quite difficult to understand, inspite 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, bothsystem builders and students struggle with Paxos.

After struggling with Paxos ourselves, we set out tofind 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 anddescribe it in a way that is significantly easier to learn thanPaxos, and that facilitates the development of intuitionsthat are essential for system builders? It was importantnot just for the algorithm to work, but for it to be obvi-ous why it works. In addition, the algorithm needed to becomplete enough to cover all the major issues required foran implementation.

The result of our effort is a consensus algorithm calledRaft. Raft is similar in many ways to existing consensusalgorithms (most notably, Oki and Liskov’s ViewstampedReplication [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 toimprove understandability, including decomposition(Raft separates leader election, log replication, andsafety so that they can be understood relatively in-dependently) and state space reduction (Raft reducesthe degree of nondeterminism and the ways serverscan be inconsistent with each other, in order to makeit 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) issuerequests; other servers are completely passive. Thismakes Raft easier to understand and also simplifiesthe implementation.

• Membership changes: Raft’s mechanism forchanging the set of servers in the cluster uses a sim-ple joint consensus approach where the majoritiesof two different configurations overlap during tran-sitions.

We performed a user study with 43 graduate studentsat two universities to test our hypothesis that Raft is moreunderstandable than Paxos. After learning both algo-rithms, students were able to answer questions about Raft23% better than questions about Paxos.

We have implemented Raft in about 1500 lines ofC++ code, and the implementation is used as part ofRAMCloud [18]. We have also proven the correctnessof the Raft algorithm.

The remainder of the paper introduces the replicatedstate machine problem (Section 2), discusses the strengthsand weaknesses of Paxos (Section 3), describes our gen-eral approach to understandability (Section 4), presentsthe Raft consensus algorithm (Sections 5-7), evaluatesRaft (Section 8), and discusses related work (Section 9).

2 Achieving fault-tolerance with replicatedstate machines

Consensus algorithms typically arise in the context ofreplicated state machines [20]. In this approach, state ma-chines on a collection of servers compute identical copiesof the same state and can continue operating even if someof the servers are down. Replicated state machines areused to solve a variety of fault-tolerance problems in dis-tributed systems. For example, large-scale systems thathave a single cluster leader, such as GFS [4], HDFS [21],and RAMCloud [18], typically use a separate replicatedstate machine to manage leader election and store config-

1

Scriptless Attacks

Lamport’sPaxos

vendredi 4 octobre 2013These are pretty different papers by the way.

Page 23: Bearded gurus

Scriptless Attacksvendredi 4 octobre 2013

Page 24: Bearded gurus

In Search of an Understandable Consensus AlgorithmDiego Ongaro and John Ousterhout

Stanford University(Draft of April 7, 2013, under submission to SOSP)

AbstractRaft is a consensus algorithm for managing a replicated

log. It produces a result equivalent to Paxos, and it isas efficient as Paxos, but its structure is different fromPaxos; this makes Raft more understandable than Paxosand also provides a better foundation for building practi-cal systems. In order to enhance understandability, Raftseparates the key elements of consensus, such as leaderelection and log replication, and it enforces a stronger de-gree of coherency to reduce the number of states that mustbe considered. Raft also includes a new mechanism forchanging the cluster membership, which uses overlappingmajorities to guarantee safety. Results from a user studydemonstrate that Raft is easier for students to learn thanPaxos.

1 IntroductionConsensus algorithms allow a collection of machines

to work as a coherent group that can survive the failuresof some of its members. Because of this, they play akey role in building reliable large-scale software systems.Paxos [9, 10] has dominated the discussion of consensusalgorithms over the last decade: most implementationsof consensus are based on Paxos or influenced by it, andPaxos has become the primary vehicle used to teach stu-dents about consensus.

Unfortunately, Paxos is quite difficult to understand, inspite 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, bothsystem builders and students struggle with Paxos.

After struggling with Paxos ourselves, we set out tofind 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 anddescribe it in a way that is significantly easier to learn thanPaxos, and that facilitates the development of intuitionsthat are essential for system builders? It was importantnot just for the algorithm to work, but for it to be obvi-ous why it works. In addition, the algorithm needed to becomplete enough to cover all the major issues required foran implementation.

The result of our effort is a consensus algorithm calledRaft. Raft is similar in many ways to existing consensusalgorithms (most notably, Oki and Liskov’s ViewstampedReplication [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 toimprove understandability, including decomposition(Raft separates leader election, log replication, andsafety so that they can be understood relatively in-dependently) and state space reduction (Raft reducesthe degree of nondeterminism and the ways serverscan be inconsistent with each other, in order to makeit 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) issuerequests; other servers are completely passive. Thismakes Raft easier to understand and also simplifiesthe implementation.

• Membership changes: Raft’s mechanism forchanging the set of servers in the cluster uses a sim-ple joint consensus approach where the majoritiesof two different configurations overlap during tran-sitions.

We performed a user study with 43 graduate studentsat two universities to test our hypothesis that Raft is moreunderstandable than Paxos. After learning both algo-rithms, students were able to answer questions about Raft23% better than questions about Paxos.

We have implemented Raft in about 1500 lines ofC++ code, and the implementation is used as part ofRAMCloud [18]. We have also proven the correctnessof the Raft algorithm.

The remainder of the paper introduces the replicatedstate machine problem (Section 2), discusses the strengthsand weaknesses of Paxos (Section 3), describes our gen-eral approach to understandability (Section 4), presentsthe Raft consensus algorithm (Sections 5-7), evaluatesRaft (Section 8), and discusses related work (Section 9).

2 Achieving fault-tolerance with replicatedstate machines

Consensus algorithms typically arise in the context ofreplicated state machines [20]. In this approach, state ma-chines on a collection of servers compute identical copiesof the same state and can continue operating even if someof the servers are down. Replicated state machines areused to solve a variety of fault-tolerance problems in dis-tributed systems. For example, large-scale systems thathave a single cluster leader, such as GFS [4], HDFS [21],and RAMCloud [18], typically use a separate replicatedstate machine to manage leader election and store config-

1

Lamport’s Paxosvendredi 4 octobre 2013

Page 25: Bearded gurus

Lamport’s Paxos

vendredi 4 octobre 2013Well at least, Lamport’s has more pictures in it.

Page 26: Bearded gurus

vendredi 4 octobre 2013HELP! We’re talking technical jargon here!

Page 27: Bearded gurus

vendredi 4 octobre 2013Looks like it was made by a robot and we’d need some translation.z

Page 28: Bearded gurus

Title

Team & uni.

Abstract intro

keywords

vendredi 4 octobre 2013Friendly Droid will help translate.They all have the same structure.

Page 29: Bearded gurus

Acknowledgements

references

conclusion

related works

vendredi 4 octobre 2013Tags / abstract / introduction and conclusion are where to start for fast reading.

Page 30: Bearded gurus

Title

Team

Abstract

vendredi 4 octobre 2013On the Web you can do things a bit differently.

Page 31: Bearded gurus

related works

keywords

vendredi 4 octobre 2013

Page 32: Bearded gurus

keywords?

Title

(Team)

Abstract?

intro

Acknowledgements

references

conclusion

vendredi 4 octobre 2013A thesis is a bit different but respects the same codes.

Page 33: Bearded gurus

Here’s my proposal

vendredi 4 octobre 2013

Page 34: Bearded gurus

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 knowssomething you don't."

Page 35: Bearded gurus

Meet, drink, talk

vendredi 4 octobre 2013

Page 36: Bearded gurus

Fight!

vendredi 4 octobre 2013

Page 37: Bearded gurus

Form parties

vendredi 4 octobre 2013

Page 38: Bearded gurus

Set sail!

vendredi 4 octobre 2013

Page 39: Bearded gurus

Adventure time!

vendredi 4 octobre 2013

Page 40: Bearded gurus

Now you’re mainstream

vendredi 4 octobre 2013

Page 41: Bearded gurus

Questions?

vendredi 4 octobre 2013

Page 42: Bearded gurus

@abelar_smaitre-du-monde.fr Have fun!

vendredi 4 octobre 2013

Page 43: Bearded gurus

A game of beards

Beard or nerd?

vendredi 4 octobre 2013

Page 44: Bearded gurus

RULES:guess guru levels based on beard

vendredi 4 octobre 2013

Page 45: Bearded gurus

Beware of traps!

vendredi 4 octobre 2013

Page 46: Bearded gurus

vendredi 4 octobre 2013

Page 47: Bearded gurus

Alan CoxLinux Kernel

vendredi 4 octobre 2013

Page 48: Bearded gurus

vendredi 4 octobre 2013

Page 49: Bearded gurus

DMR & Ken ThompsonB / Unix / Plan9

vendredi 4 octobre 2013

Page 50: Bearded gurus

vendredi 4 octobre 2013

Page 51: Bearded gurus

Alan KaySmalltalk

vendredi 4 octobre 2013

Page 52: Bearded gurus

vendredi 4 octobre 2013

Page 53: Bearded gurus

Robert TarjanGraph Theory

vendredi 4 octobre 2013

Page 54: Bearded gurus

vendredi 4 octobre 2013

Page 55: Bearded gurus

EWD

vendredi 4 octobre 2013

Page 56: Bearded gurus

vendredi 4 octobre 2013

Page 57: Bearded gurus

Captain Crunch

vendredi 4 octobre 2013

Page 58: Bearded gurus

vendredi 4 octobre 2013

Page 59: Bearded gurus

McCarthy

vendredi 4 octobre 2013

Page 60: Bearded gurus

vendredi 4 octobre 2013

Page 61: Bearded gurus

Sergey Brin

vendredi 4 octobre 2013

Page 62: Bearded gurus

vendredi 4 octobre 2013

Page 63: Bearded gurus

John Carmack

vendredi 4 octobre 2013

Page 64: Bearded gurus

vendredi 4 octobre 2013

Page 65: Bearded gurus

Don Knuth

vendredi 4 octobre 2013

Page 66: Bearded gurus

vendredi 4 octobre 2013

Page 67: Bearded gurus

ADA

vendredi 4 octobre 2013

Page 68: Bearded gurus

vendredi 4 octobre 2013

Page 69: Bearded gurus

Grace Hopper

vendredi 4 octobre 2013

Page 70: Bearded gurus

?

vendredi 4 octobre 2013

Page 71: Bearded gurus

?

vendredi 4 octobre 2013if you agree that Stallmann has a better beard than Bill Joyyou are forced to agree that emacs beats Vim!

Page 72: Bearded gurus

?vendredi 4 octobre 2013

Page 73: Bearded gurus

?vendredi 4 octobre 2013

Page 74: Bearded gurus

?vendredi 4 octobre 2013

Page 75: Bearded gurus

vendredi 4 octobre 2013