Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Distributed Systems Classics (2017)

nvartolomei.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Distributed Systems Classics (2017)

#41

Post by toast0 »

throwaway894345 wrote: post #31
toast0 wrote: post #22

Earlier quoted context omitted.

> the relations between events happening in a distributed system, is more fundamental than their absolute ordering The important thing in most distributed systems is having an order. Having a single observer serialize events as it receives them is so much more tractable than trying to use absolute order. Using absolute order requires very precise time synchronization which is hard; using absolute order requires knowi…

> absolute order requires very precise time synchronization which is hard Presumably relativity is the reason precise time synchronization (and thus absolute ordering) is hard.

That forms a basis for the difficulty. But then there's additional layers of difficulty in real networks where the path between nodes is often asymmetric, and you may also observe that elapsed time (A -> B -> A) is sometimes greater than elapsed time (A -> C -> B -> C -> A) or (A -> C -> B -> A) or (A -> B -> C -> A)

Re: Distributed Systems Classics (2017)

#42

Post by jasonwatkinspdx »

phtrivier wrote: post #9
nylonstrung wrote: post #4

Lamport is the author of more than half of these, it's crazy how influential he is in this space In addition to making LaTex which has almost nothing to do with it

It's the thing that baffles me the most with those people, the Knuths and Lamports and Carmarcks, and whatnot. It's not like they have light schedules - they do research, they have classes, they attendconference, and they have jobs, etc... And some benefit from tenure, which give them time to deeply focus on some topics. But I can't imagine how I would write tex in ten years in Pascal on archaic machines if I had all…

My brother was something of a prodigy. Whatever it is that people like Carmack have, he had it too (and Carmack was one of his personal heros).

I would say with my brother it wasn't just that he was analytically extremely sharp, it's that he could focus it on things in a way that bordered on unhealthy obcession.

For example during undergrad he took a semester off because he burned himself out taking an insane course load, while also working on research as an undergrad.

Anyhow he spent that semester and the following summer at my parents house, and he spent months in basically the same pattern. Work on his research topic on the family PC until he needs to read a paper or think about something, at which point he'd roll the office chair over to the nearby couch and flop onto that. Every once in a while he'd disappear to his old bedroom to sleep for a few hours or take a shower or such.

And I mean he lived basically half a year like that, just relentlessly drilling into his research topic with every waking moment.

Re: Distributed Systems Classics (2017)

#43

Post by [deleted] »

throwaway-17732 wrote: post #36
moritz wrote: post #30

Earlier quoted context omitted.

Related hot take Maybe thats why one of the not-so-bad ideas how to go about distributed systems came from a guy who was trained as a physicist and used to complain to his fellow programmers that “a lot of systems actually break the laws of physics”[1]? > In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden) where is the shared state? In the middle of the Atlantic? -…

And yet we have CRDTs.

[deleted]

Re: Distributed Systems Classics (2017)

#45

Post by NortySpock »

ksambhi wrote: post #40
mjb wrote: post #13

This is not a bad list for sure. Here are some deeper cuts for those looking for something a bit less mainstream: "The Maintenance of Duplicate Databases" https://datatracker.ietf.org/doc/html/rfc677 (AFAIK the genesis of the use of logical clocks in distributed systems). "Chain Replication for Supporting High Throughput and Availability" https://www.usenix.org/legacy/event/osdi04/tech/full_papers/... (Chain replicat…

Question from a recent CS grad here, who just learnt about CAP: what do you mean by “very poor trade-off thinking in the decade that followed”?

A Critique of the CAP theorem by Martin Kleppmann.

https://arxiv.org/abs/1509.05393

Basically naive CAP theorem assumes "no latency (delay) allowed", in which case, yeah, sure, the quorum must agree or you are writing to a split-brain quorum somehow. But what if delay sensitivity is a knob that can be tuned, and writes have conflict resolution?

Martin Kleppmann's book Designing Data-Intensive Applications is considered a useful tome for anyone who needs a insight in the complexity involved in distributed systems (hint: getting data in ram flushed to an SSD also involves multiple moving parts)

Re: Distributed Systems Classics (2017)

#46

Post by bionsystem »

phtrivier wrote: post #9
nylonstrung wrote: post #4

Lamport is the author of more than half of these, it's crazy how influential he is in this space In addition to making LaTex which has almost nothing to do with it

It's the thing that baffles me the most with those people, the Knuths and Lamports and Carmarcks, and whatnot. It's not like they have light schedules - they do research, they have classes, they attendconference, and they have jobs, etc... And some benefit from tenure, which give them time to deeply focus on some topics. But I can't imagine how I would write tex in ten years in Pascal on archaic machines if I had all…

I'll add my stories to the 2 brother comments, in my prepa my best friend was by far the best in class. He did the 2 year program in chemistry in the first 2 months by himself. He arrived once in exams after a full night of re-reading the 3 LOTR books and still nailed the best grade effortlessly. And to his own admission, he was far from the most productive / smarter guys he knew.

I remember listening to him and a teacher, the teacher would give some anecdotes on what he's seen at the ENS. People reciting world chess championship games at night to fall asleep. Reading massive math books (1000+ pages) in an afternoon. Another story I heard in a different context from another teacher, math students were assigned a python project, after an introductory course. They never did any programming before. One student wrote 300 LoC in a single function and showed it to the teacher. It didn't have a main function, so the teacher asked him how he tested it. The student didn't know what he was talking about. They added what's needed to run the function and it worked.

Re: Distributed Systems Classics (2017)

#47

Post by prydt »

Some of these probably aren't exactly classics but I do love:

- rendezvous hashing / consistent hashing

- Hybrid logical clocks

- "Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS"

- "Scaling Replicated State Machines with Compartmentalization" (much more recent but really one of my favorite papers)

Re: Distributed Systems Classics (2017)

#48

Post by mjb »

ksambhi wrote: post #40
mjb wrote: post #13

This is not a bad list for sure. Here are some deeper cuts for those looking for something a bit less mainstream: "The Maintenance of Duplicate Databases" https://datatracker.ietf.org/doc/html/rfc677 (AFAIK the genesis of the use of logical clocks in distributed systems). "Chain Replication for Supporting High Throughput and Availability" https://www.usenix.org/legacy/event/osdi04/tech/full_papers/... (Chain replicat…

Question from a recent CS grad here, who just learnt about CAP: what do you mean by “very poor trade-off thinking in the decade that followed”?

Basically, many people convinced themselves that the formalization of CAP means that systems need to choose between highly available and strongly consistent, and hence chose eventual consistency. This is, partially, because Gilbert and Lynch define "availability" to mean "available to all clients, even those on a minority side of a partition". The much more useful "available to a majority of clients" is achievable at the same time as strong consistency in presence of a single partition, and this is the common cloud failure mode.

See https://brooker.co.za/blog/2024/07/25/cap-again.html for a longer take.

Other, much more reasonable trade-offs, lead to eventual consistency too. Mostly latency optimizations, but many of those also lead to non-zero RPO and so are undesirable for multiple reasons. We discuss some of this in section 8 of the DSQL paper: https://arxiv.org/pdf/2607.13276

Re: Distributed Systems Classics (2017)

#49

Post by jeremyjh »

toast0 wrote: post #41
throwaway894345 wrote: post #31

Earlier quoted context omitted.

> absolute order requires very precise time synchronization which is hard Presumably relativity is the reason precise time synchronization (and thus absolute ordering) is hard.

That forms a basis for the difficulty. But then there's additional layers of difficulty in real networks where the path between nodes is often asymmetric, and you may also observe that elapsed time (A -> B -> A) is sometimes greater than elapsed time (A -> C -> B -> C -> A) or (A -> C -> B -> A) or (A -> B -> C -> A)

Doesn't each node just need to know its exact path (or latency of same) to the time source each is synchronizing from? The path from node to node doesn't matter because we're ordering log entries from the timestamp of the receiving node.

Imagine you take three atomic clocks, synchronize them, and move each within exactly 1 meter of one of those nodes, directly connected in an identical manner. Relativistic effects are constant. If there are elevation differences, you factor it once and done. The problem with this setup is not relativity. It is quantum uncertainty (and various interference sources, thermal radiation, etc).

Re: Distributed Systems Classics (2017)

#50

Post by brcmthrowaway »

Joel_Mckay wrote: post #33
brcmthrowaway wrote: post #10

Earlier quoted context omitted.

Does anyone use Elixir/Erlang anymore?

Yes, but it is boring telecom projects... so most people aren't interested. Scala is kind of a more modern alternative. If doing a twitter like platform, elixir with Phoenix channels could handle around >20k users per host. Very few other options work for that use case. =3

goroutines?
Post reply on HN