Post on 25-Jun-2015
description
Wisdom of the Bearded Gurus
vendredi 4 octobre 2013
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Wisdom of the BearrrrdedGurrrrus
vendredi 4 octobre 2013
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.
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.
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?
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.
Crew!Boat!
vendredi 4 octobre 2013At some point I found something like a crew.Luckily for me, the Ruby crew is an awesome crew ;)
maitre-du-monde.fr@abelar_s
vendredi 4 octobre 2013OK so now you know me, where are we going?
Let’s gofearlessly
vendredi 4 octobre 2013Let’s unearth some old geeks’ bones.
?
vendredi 4 octobre 2013We’re lost.And the path... wow, it’s difficult to even know where it starts.
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.
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.
- 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.
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.
vendredi 4 octobre 2013
Books
vendredi 4 octobre 2013
Universities
vendredi 4 octobre 2013
Communications of the ACM
vendredi 4 octobre 2013Also, conferences like SIGGRAPH.
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.
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.
Scriptless Attacksvendredi 4 octobre 2013
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
Lamport’s Paxos
vendredi 4 octobre 2013Well at least, Lamport’s has more pictures in it.
vendredi 4 octobre 2013HELP! We’re talking technical jargon here!
vendredi 4 octobre 2013Looks like it was made by a robot and we’d need some translation.z
Title
Team & uni.
Abstract intro
keywords
vendredi 4 octobre 2013Friendly Droid will help translate.They all have the same structure.
Acknowledgements
references
conclusion
related works
vendredi 4 octobre 2013Tags / abstract / introduction and conclusion are where to start for fast reading.
Title
Team
Abstract
vendredi 4 octobre 2013On the Web you can do things a bit differently.
related works
keywords
vendredi 4 octobre 2013
keywords?
Title
(Team)
Abstract?
intro
Acknowledgements
references
conclusion
vendredi 4 octobre 2013A thesis is a bit different but respects the same codes.
Here’s my proposal
vendredi 4 octobre 2013
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."
Meet, drink, talk
vendredi 4 octobre 2013
Fight!
vendredi 4 octobre 2013
Form parties
vendredi 4 octobre 2013
Set sail!
vendredi 4 octobre 2013
Adventure time!
vendredi 4 octobre 2013
Now you’re mainstream
vendredi 4 octobre 2013
Questions?
vendredi 4 octobre 2013
@abelar_smaitre-du-monde.fr Have fun!
vendredi 4 octobre 2013
A game of beards
Beard or nerd?
vendredi 4 octobre 2013
RULES:guess guru levels based on beard
vendredi 4 octobre 2013
Beware of traps!
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Alan CoxLinux Kernel
vendredi 4 octobre 2013
vendredi 4 octobre 2013
DMR & Ken ThompsonB / Unix / Plan9
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Alan KaySmalltalk
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Robert TarjanGraph Theory
vendredi 4 octobre 2013
vendredi 4 octobre 2013
EWD
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Captain Crunch
vendredi 4 octobre 2013
vendredi 4 octobre 2013
McCarthy
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Sergey Brin
vendredi 4 octobre 2013
vendredi 4 octobre 2013
John Carmack
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Don Knuth
vendredi 4 octobre 2013
vendredi 4 octobre 2013
ADA
vendredi 4 octobre 2013
vendredi 4 octobre 2013
Grace Hopper
vendredi 4 octobre 2013
?
vendredi 4 octobre 2013
?
vendredi 4 octobre 2013if you agree that Stallmann has a better beard than Bill Joyyou are forced to agree that emacs beats Vim!
?vendredi 4 octobre 2013
?vendredi 4 octobre 2013
?vendredi 4 octobre 2013
vendredi 4 octobre 2013