Ask HN: What is your favorite CS paper? - <AUTHOR> <comment><USER2> "Reflections on Trusting Trust" by Ken Thompson is one of my favorites.

Most papers by Jon Bentley (e.g. A Sample of Brilliance) are also great reads.

I'm a frequent contributor to Fermat's Library, which posts an annotated paper (CS, Math and Physics mainly) every week. If you are looking for interesting papers to read, I would strongly recommend checking it out - [http://fermatslibrary.com/](http://fermatslibrary.com/)

\- Reflections on Trusting Trust (Annotated Version) - [http://fermatslibrary.com/s/reflections-on-trusting- trust](http://fermatslibrary.com/s/reflections-on-trusting-trust)

\- A Sample of Brilliance (Annotated Version) - [http://fermatslibrary.com/s/a-sample-of- brilliance](http://fermatslibrary.com/s/a-sample-of-brilliance)

<comment><USER3> The Ken Thompson Hack is a haunting idea. The intelligence agencies almost certainly would've tried to implement it at some point.

<comment><USER4> They have -- this is basically what Stuxnet did. Some of the equation group leaks were even further advanced -- they installed themselves in the hard drive firmware, then hid the sectors where the exploit code was stored _even from the BIOS_.

So point is, it's been done. That's why the Equation Group malware operated undetected for almost a decade (and maybe longer than that). Never underestimate the power of a government -- they can afford to hire and train an army of Ken Thompsons for the price of an aircraft carrier.

<comment><USER5> > they installed themselves in the hard drive firmware, then hid the sectors > where the exploit code was stored even from the _BIOS._

Where can I read more technical details (such as code analysis) about this?

I've never heard of anything like this hiding for _10 years_ before.

<comment><USER6> [https://www.symantec.com/content/en/us/enterprise/media/secu...](https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf)

<comment><USER5> Okay, that was interesting reading. Now I actually know what Stuxnet did and how it worked.

The un-named _nls_933w.dll_ responsible for modifying firmware on "over a dozen" HDDs is only termed as Stuxnet- _like_ however: [https://securelist.com/equation-the-death-star-of-malware- ga...](https://securelist.com/equation-the-death-star-of-malware- galaxy/68750/)

That's remarkably impressive though.

HDDs aren't impenetrable walls - [http://spritesmods.com/?art=hddhack](http://spritesmods.com/?art=hddhack) \- but reflashing firmware on over a dozen disks, presumably from Windows... nice.

<comment><USER4> Yeah; that's what you get with nation-state resources. How long does it really take to reverse-engineer a target like HDD firmware? Give a good hacker a month and they could probably figure it out for one HDD -- now realize the government can hire, train and supply hundreds of people like this.

Sure, it costs billions. But to a nation-state, billions are easy to find.

This is why modern security tools and practices are really only going to be capable of keeping out criminal organizations and mass-hacks. If a nation- state decides to target you, there is really no way you can defend against it. Often they are able to undermine the trust mechanisms in place through sheer resource asymmetry (they have the compute resources to brute-force SSL key collisions -- they did this with Stuxnet to fake a Microsoft signing cert to push the payload via a MITMed Windows Update).

There are even reports of three-letter-agencies intercepting routers during shipment, desolderig chips from the board, and replacing them with "bugged" chips containing back doors in hardware; then packaging it all up and getting it delivered on-time.

You just can't fight that kind of power; even as a company as large as Google or Apple. Nation states will always be able to probe and exploit the edge cases in your security model. In general, you can't make anything totally secure, but you can try to make it cost enough to break into that it will deter anyone who can't justify the cost.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I would never call it my "all-time favorite" (no paper qualifies for that title in my book), but Satoshi Nakamoto's paper, "Bitcoin: A Peer-to-Peer Electronic Cash System" deserves a mention here, because it proposed the first-known solution to the double-spending problem in a masterless peer-to- peer network, with Byzantine fault tolerance (i.e., in a manner resistant to fraudulent nodes attempting to game the rules), via a clever application of proof-of-work:

[https://bitcoin.org/bitcoin.pdf](https://bitcoin.org/bitcoin.pdf)

Others in this thread have already mentioned papers or opinionated essays that quickly came to mind, including "Reflections on Trusting Trust" by Ken Thompson, "A Mathematical Theory of Communication" by Claude Shannon (incredibly well-written and easy-to-follow given the subject matter), and "Recursive Functions of Symbolic Expressions and Their Computation by Machine" by John McCarthy.

I would also mention "On Computable Numbers, with an Application to the Entscheidungsproblem" by Alan Turing, "On Formally Undecidable Propositions of Principia Mathematica And Related Systems" by Kurt Gödel, and "The Complexity of Theorem Proving Procedures" by Stephen Cook, but in my view these papers are 'unnecessarily' challenging or time-consuming to read, to the point that I think it's better to read textbooks (or popular works like "Gödel, Escher, and Bach" by Douglas Hofstadter) covering the same topics instead of the original papers. Still, these papers are foundational.

Finally, I think "The Mythical Man-Month" by Fred Brooks, and "Worse is Better" by Richard Gabriel merit inclusion here, given their influence.

This is by no means an exhaustive list. Many -- _many_ \-- other worthy papers will surely come to mind over the course of the day that I won't have a chance to mention here.

There are many other good recommendations elsewhere in this thread, including papers/essays I have not yet read :-)

<comment><USER8> maybe i'm a little stringent but if if isn't peer reviewed and in a journal, i don't consider it a paper.

<comment><USER9> I guess that, given its impact, it's more peer-reviewed than most published papers.

<comment><USER10> I think that this is an important point: that just because something isn't in a journal, doesn't mean that it hasn't been peer reviewed!

<comment><USER11> see: arXiv

</comment></comment></comment></comment></comment><comment><USER12> Without a doubt.

Time, Clocks, and the Ordering of Events in a Distributed System. Leslie Lamport.

[http://amturing.acm.org/p558-lamport.pdf](http://amturing.acm.org/p558-lamport.pdf)

My first introduction to time scales as a partial ordering. Very mind opening.

<comment><USER13> Your link is throwing a 404 for me. I found it here: [https://www.ics.uci.edu/~cs230/reading/time.pdf](https://www.ics.uci.edu/~cs230/reading/time.pdf)

<comment><USER12> That is not the paper. It appears to be a summary.

</comment></comment></comment><comment><USER14> "A Mathematical Theory of Communication" \- Claude E. Shannon

[http://math.harvard.edu/~ctm/home/text/others/shannon/entrop...](http://math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf)

<comment><USER15> All time hit paper

<comment><USER16> I like the papers that describe the OOPS and the Gödel Machine :)

</comment></comment></comment><comment><USER17> Out Of The Tarpit, by Moseley and Marks

[https://github.com/papers-we-love/papers-we- love/blob/master...](https://github.com/papers-we-love/papers-we- love/blob/master/design/out-of-the-tar-pit.pdf)

The first half of the paper is a spot-on critique of so many things that go wrong in the process of designing and implementing large-scale software systems. The second half, where the authors propose a solution, kind of goes off the rails a bit into impracticality... but they definitely point in a promising direction, even if nobody ever uses their concrete suggestions.

<comment><USER18> Project:M36 is an implementation of the proposed design from the "Out of the Tarpit" paper.

[https://github.com/agentm/project-m36](https://github.com/agentm/project-m36)

</comment></comment><comment><USER19> Peter Naur, _" Programming as theory building."_ (1985)

"…programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts."

[http://pages.cs.wisc.edu/~remzi/Naur.pdf](http://pages.cs.wisc.edu/~remzi/Naur.pdf) [https://news.ycombinator.com/item?id=10833278](https://news.ycombinator.com/item?id=10833278) [https://news.ycombinator.com/item?id=7491661](https://news.ycombinator.com/item?id=7491661)

<comment><USER20> This really is a paper with deep implications.

One of them, as I understand it, is that in any significant software project, regardless of the volume and quality of the documentation, or quality of the code base, maintainers not involved in building the original project will not be able to build the "theory" correctly in their minds, and will consequently make changes that are clumsy or detrimental. (I'm summarizing, so some important aspects have been skipped).

I see this aspect of the paper as related to the "conceptual integrity" discussed in the Mythical Man-Month.

This paper has long been one of my favorites, and was first brought to my attention when I was reading (IIRC) one of Alistair Cockburn's books. Sadly, few of the people I shared it with found it interesting.

<comment><USER19> It's at the core of my software life for several years now: [http://akkartik.name/about](http://akkartik.name/about)

</comment></comment></comment><comment><USER21> I've been trying to get it frontpaged because, despite it's length, it's perhaps one of the most startling papers of this decade. Sadly, it seems like the HN voting gestalt hasn't decided to upvote a paper that's the CS equivalent of breaking the speed of light:

"Generic Top-down Discrimination for Sorting and Partitioning in Linear Time" ->

[http://www.diku.dk/hjemmesider/ansatte/henglein/papers/hengl...](http://www.diku.dk/hjemmesider/ansatte/henglein/papers/henglein2011a.pdf)

(if you're daunted by an 80 page paper as I am, there is also a talk on it: [https://www.youtube.com/watch?v=sz9ZlZIRDAg](https://www.youtube.com/watch?v=sz9ZlZIRDAg))

It is possible, with some proper insight and approaches, to sort general datastructures in linear time on modern computing hardware. The speed limit of sort is O(n) with some extra constant cost (often accrued by allocation). It works by decomposing and generalizing something akin to radix sort, leveraging a composable pass of linear discriminators to do the work.

There's a followup paper using this to make a very efficient in-memory database that one could easily generalize under something like kademelia and with care I suspect could make something like a better spark core.

[http://www.diku.dk/hjemmesider/ansatte/henglein/papers/hengl...](http://www.diku.dk/hjemmesider/ansatte/henglein/papers/henglein2011c.pdf)

I keep submitting and talking about this but no one seems to pick up on it. This paper is crazy important and every runtime environment SHOULD be scrambling to get this entire approach well-integrated into their stdlib.

Unsurprisingly, Kmett has already implemented it in Haskell (it generalized neatly under the dual of the applicative+alternative functor): [https://hackage.haskell.org/package/discrimination](https://hackage.haskell.org/package/discrimination)

<comment><USER22> >It is possible, with some proper insight and approaches, to sort general datastructures in linear time on modern computing hardware. The speed limit of sort is O(n) with some extra constant cost (often accrued by allocation).

There is a well-known proof from information theory that the problem of sorting _n_ distinct items has a worst-case time complexity of Ω( _n_ log _n_ ) fixed-bitwidth operations: (1) Since each of the _n_ items is distinct, the average number of bits needed to encode each item is Ω(log _n_ ). (2) In the worst case, in order to correctly sort the items, each bit of each item needs to be read. (3) Therefore, sorting the list requires reading Ω( _n_ log _n_ ) bits.

So, I'm not sure how to understand the claim that their algorithm operates in "linear time". Are they saying O(n) operations where each operation operates on O(log n) bits?

[Edit: See below response from kraghen: The time is linear in the total size of the data, not in the number of items. I'll leave this comment up in case anyone has the same misunderstanding that I had.]

<comment><USER23> Discrimination runs in linear time not in the number of items but in the total size of the data. If you have n items each of size k it takes O(kn). Conventional sorting often assumes that you can compare keys of size k in constant time and therefore gets O(n lg n) but a more honest analysis would yield O(kn log n) for (say) merge sort.

<comment><USER24> The bound on string sorting is typically written as O(n log n + D), where D is the sum of distinguishing prefixes, ie input length minus some fluff. Since D >= n log n we already have linearity on input length.

<comment><USER23> Are you saying that you can sort strings in O(n log n + D) using a conventional sorting algorithm such as merge sort? If so, I don't understand why D would be an additive factor implying that each string is only involved in a constant number of comparisons.

(I wasn't, by the way, only considering strings when discussing variable sized keys -- the beauty of discrimination is that we essentially reduce all sorting problems to string sorting.)

<comment><USER24> A conventional sorting algorithm such as Multikey Quicksort.

[http://people.mpi- inf.mpg.de/~sanders/courses/algdat03/salgd...](http://people.mpi- inf.mpg.de/~sanders/courses/algdat03/salgdat.pdf)

<comment><USER21> When people say "conventional" sorting algorithms, they're usually talking about sorting algorithms based around pairwise comparison functions.

I note on slide 14 of this presentation, it looks like this is sort of the discriminator for selecting a better partitioning scheme. So it looks to me like this actually leverages a similar principle?

As we've seen in this thread and others, there are some other ways to measure and/or process that have different characteristics. Surely all of these deserve attention! So, thanks very much for sharing this.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Automated Distributed Execution of LLVM code using SQL JIT Compilation

As collected by the SIGBOVIK group:

[http://sigbovik.org/2017/proceedings.pdf](http://sigbovik.org/2017/proceedings.pdf)

Quote:

"Following the popularity of MapReduce, a whole ecosystem of Apache Incubator Projects has emerged that all solve the same problem. Famous examples include Apache Hadoop, Apache Spark, Apache Pikachu, Apache Pig, German Spark and Apache Hive [1]. However, these have proven to be unusable because they require the user to write code in Java. Another solution to distributed programming has been proposed by Microsoft with their innovative Excel system. In large companies, distributed execution can be achieved using Microsoft Excel by having hundreds of people all sitting on their own machine working with Excel spreadsheets. These hundreds of people e combined can easily do the work of a single database server."

PS: This thread is great, i'm bookmarking because here there are good (serious) papers.

<comment><USER26> Apache Pikachu got me

<comment><USER16> The alliteration is real

</comment></comment></comment><comment><USER27> I'll take a broad interpretation of 'CS' and throw out a couple of personal highlights.

C. Shannon, "A Symbolic Analysis of Relay and Switching Circuits" (1940): [https://dspace.mit.edu/bitstream/handle/1721.1/11173/3454142...](https://dspace.mit.edu/bitstream/handle/1721.1/11173/34541425-MIT.pdf?sequence=2)

Shannon's master's thesis, which introduces boolean algebra to the field of digital circuit design.

R.W. Hamming, "Error Detecting and Error Correcting Codes" (1950): [https://ia801903.us.archive.org/1/items/bstj29-2-147/bstj29-...](https://ia801903.us.archive.org/1/items/bstj29-2-147/bstj29-2-147.pdf)

In Hamming's own words: "Damn it, if the machine can detect an error, why can't it locate the position of the error and correct it?"

J.T. Kajiya, "The Rendering Equation" (1986): [http://cseweb.ucsd.edu/~ravir/274/15/papers/p143-kajiya.pdf](http://cseweb.ucsd.edu/~ravir/274/15/papers/p143-kajiya.pdf)

Kajiya introduces the integral rendering equation, which is the basis for most current techniques of physically based rendering.

</comment><comment><USER28> "The Limits of Correctness" (1985) by Bryan Cantwell Smith: [https://www.student.cs.uwaterloo.ca/~cs492/11public_html/p18...](https://www.student.cs.uwaterloo.ca/~cs492/11public_html/p18-smith.pdf)

I know Thompson's "Reflections on Trust" and Shannon's "Communication" papers are more famous but I believe BCS's "Correctness" paper has more immediate relevance to a wider population of programmers.

For example, I don't believe Ethereum's creator, Vitalik Buterin, is familiar with it because if he was, he would have realized that _" code is law"_ is not possible and therefore he would have predicted the DAO hack and subsequent fork/reversal to undo the code.

Seriously, if you read BCS's paper _and generalize its lessons learned_ , you will see that the DAO hack and its reversal as _inevitable_.

<comment><USER29> > you will see that the DAO hack and its reversal as inevitable.

Honest naïve question. What's the proof?

<comment><USER30> FWIW I think this is a very fair question. Parent's post veers a bit further toward defeatism than I think Smith's paper advocates for or justifies. In particular, _of course_ the DAO hack wasn't inevitable -- a more careful programmer could've foreseen and prevented that attack and whole other classes of attack.

<comment><USER31> Part of the linked paper's point is that because computer systems involve many "levels of failure", even a more careful programmer cannot usually rule out every class of programs. The DAO hack, yes, possibly.

But, for example, people have also lost money due to bugs in the Solidity compiler: [https://np.reddit.com/r/ethtrader/comments/5foa5p/daily_disc...](https://np.reddit.com/r/ethtrader/comments/5foa5p/daily_discussion_30nov2016/dalxys1/) How many "more careful" Ethereum programmers _also_ check the compiler for correctness?

Another paper in this vein is James Fetzer's "Program Verification: The Very Idea". [http://lore.ua.ac.be/Teaching/SSPEC2LIC/critique2.pdf](http://lore.ua.ac.be/Teaching/SSPEC2LIC/critique2.pdf)

<comment><USER30> _> Part of the linked paper's point is that because computer systems involve many "levels of failure", even a more careful programmer cannot usually rule out every class of programs._

But -- and this is the crucial point -- that doesn't mean we shouldn't strive to be better than we are now.

The impossibility of perfectly modeling the world hasn't prevented us from making enormous progress on software safety and security over the past 30 odd years. Today, if you care to, you can easily write code that is free of buffer overflows and command injection attacks. In the 00's SQL injection attacks were extremely easy to find; now they're comparatively rare.

Smith's paper tells us that code-as-law is probably a bad idea. But it is not -- and wasn't intended to be -- an indict of static analysis or model-based engineering more generally. Every structural engineer knows the difference between a bridge and a model of a bridge; a paper pointing out the difference without substantively critiquing the practical usefulness of a particular type of model would probably elicit eye-rolls. I'm not sure why these mundane observations receive such attention in computer science. Maybe because with software the model and the system look so similar.

But to be sure, the impossibility of codifying human morality is a pretty lame excuse for failing to use static analysis tools or better languages or quality frameworks to prevent known classes of attacks. So I doubt that's what Smith is advocating.

 _> How many "more careful" Ethereum programmers also check the compiler for correctness?_

Yes, we should _obviously_ check compilers for correctness, and we're making slow but sure progress toward a world where our critical infrastructure comes with strong -- of course, never perfect -- correctness guarantees.

<comment><USER31> > But -- and this is the crucial point -- that doesn't mean we shouldn't > strive to be better than we are now.

Agreed! And I also agree that we are really making progress. But we're far from a world where people can crank out provably correct code (let alone the _proofs_ ).

> I'm not sure why these mundane observations receive such attention in > computer science. Maybe because with software the model and the system look > so similar.

Excellent point, and yes, I think that is the problem. Modeling the world in code is not much different from... er... modeling the world in code :-)

</comment></comment></comment></comment></comment></comment><comment><USER32> "Reflections on Trusting Trust" \- Ken Thompson

[https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...](https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)

<comment><USER33> Seconded.

</comment></comment><comment><USER34> Most of my favourites have already been listed but one I found particularly interesting was Von Neumann's _Theory of Self-Reproducing Automata_ [0].

[0] [http://cba.mit.edu/events/03.11.ASE/docs/VonNeumann.pdf](http://cba.mit.edu/events/03.11.ASE/docs/VonNeumann.pdf)

<comment><USER35> +1 to this. Von Neumann was well ahead of his time with his automata ideas. I found in interesting how both Von Neumann and Turing turned to analyse biological systems later in their careers.

<comment><USER36> Some of you might be interested in an essay I wrote about von Neumann and Norbert Wiener that gives some of the background and context of this work.

[http://www.ehudlamm.com/outsiders.pdf](http://www.ehudlamm.com/outsiders.pdf)

</comment></comment></comment><comment><USER37> Purely Functional Data Structures by Chris Okasaki - [https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf](https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf)

Can programming be liberated from the von Neumann style? - John Backus's Turing lecture - [http://dl.acm.org/citation.cfm?id=1283933](http://dl.acm.org/citation.cfm?id=1283933)

</comment><comment><USER38> Diego Ongaro's Raft paper[1]. Perhaps this only speaks to my experience as a student but having surveyed some of the other papers in the domain (paxos[2] in its many variants: generalized paxos[3], fpaxos[4], epaxos[5], qleases[6]), I'm glad the author expended the effort he did in making Raft as understandable (relatively) as it is.

[1]: [https://raft.github.io/raft.pdf](https://raft.github.io/raft.pdf)

[2]: [https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/12/paxos-simple-Copy.pdf)

[3]: [https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/tr-2005-33.pdf)

[4]: [https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/tr-2005-112.pdf)

[5]: [https://www.cs.cmu.edu/~dga/papers/epaxos- sosp2013.pdf](https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf)

[6]: [https://www.cs.cmu.edu/~dga/papers/leases- socc2014.pdf](https://www.cs.cmu.edu/~dga/papers/leases-socc2014.pdf)

</comment><comment><USER39> A bit cliche for HN, but I really enjoyed _RECURSIVE FUNCTIONS OF SYMBOLIC EXPRESSIONS AND THEIR COMPUTATION BY MACHINE (Part I)_ by John McCarthy[0]. It was accessible to someone whose background at the time was not CS and convinced me of the beauty of CS -- and lisp.

[0] - [http://www-formal.stanford.edu/jmc/recursive.html](http://www- formal.stanford.edu/jmc/recursive.html)

</comment><comment><USER40> It might be a cliche one to pick, but I really really really enjoy Alan Turing's "Computing Machinery and Intelligence"[1]. This paper straddles the line between CS and philosophy, but I think it's an important read for anyone in either field. And a bonus is that it's very well-written and readable.

[1] [https://www.csee.umbc.edu/courses/471/papers/turing.pdf](https://www.csee.umbc.edu/courses/471/papers/turing.pdf)

<comment><USER41> Given the far reaching importance of the Turing test, it's amazing how readable and understandable the paper is.

<comment><USER42> I really don't see how anyone would take that as a given.

</comment></comment></comment><comment><USER43> Cheating a little, but the collected Self papers are what I'd bring to a desert island:

[https://www.cs.ucsb.edu/~urs/oocsb/self/papers/papers.html](https://www.cs.ucsb.edu/~urs/oocsb/self/papers/papers.html)

<comment><USER44> "Self: the power of simplicity" really lives up to its name!

</comment></comment><comment><USER45> Yao's minimax principle. It's not a very exciting read or a very exciting conclusion compared to some of these other papers, but it's still interesting, and the conclusion has been practically useful to me a small handful of times.

It concerns randomized algorithms, which are algorithms that try to overcome worst case performance by randomizing their behavior, so that a malicious user can't know which input will be the worst case input this time.

The principle states that the expected cost of a randomized algorithm on a single input is no better or worse than the cost of a deterministic algorithm with random input.

Yao proves this is the case by constructing two zero sum games based around the algorithms' running times and then using game theory (specifically von Neumann's minimax theorem) to show that the two approaches are equivalent. It's a really neat approach!

</comment><comment><USER46> The Anatomy of a Large-Scale Hypertextual Web Search Engine, by Brin and Page.

Not only for the historical value of changing the world, and for the fact that it's very interesting and readable; It has personal value to me: the first CS paper I've ever read and it inspired me and changed the course of my life, literally.

Also, it has some very amusingly naive (in hindsight) stuff in it, like: "Google does not have any optimizations such as query caching, subindices on common terms, and other common optimizations. We intend to speed up Google considerably through distribution and hardware, software, and algorithmic improvements. Our target is to be able to handle several hundred queries per second"

[http://infolab.stanford.edu/~backrub/google.html](http://infolab.stanford.edu/~backrub/google.html)

<comment><USER47> I was hoping this one would show up. It's a startlingly simple paper, which both made the idea easy to implement (PageRank algorithm can be implemented in around 10 lines of Python, give or take), and easy to game ( _viz._ the rise of link farms). Recommended for anyone with the prerequisite 1 semester of linear algebra or equivalent.

</comment></comment><comment><USER48> Kademlia, a P2P distributed hash table. DHTs are very complex from the outside but very simple once you understand the building blocks.

[https://pdos.csail.mit.edu/~petar/papers/maymounkov- kademlia...](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia- lncs.pdf)

<comment><USER49> Hmm, I think it's important to understand Chord DHT first and only after that move on to Kademlia, then S/Kademlia and so on.

</comment></comment><comment><USER50> There are a ton of fantastic Haskell papers, but if I had to pick one this would be it. It reconciles the pure and lazy functional nature of Haskell with the strict and often messy demands of the real world:

State in Haskell. John Launchbury and Simon L. Peyton Jones

[https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/07/state-lasc.pdf)

<comment><USER51> I like Haskell papers and books but they often reference the "Core" language, for which an accessible implementation seems to be lacking, which is a missed opportunity, imho. Yes, I know it is part of GHC, but it is buried under several layers of undocumented code. GHC could have been much more open to research if they modularized and documented everything more thoroughly.

<comment><USER50> I think SPJ would agree with you. Have you seen [https://www.youtube.com/watch?v=uR_VzYxvbxg](https://www.youtube.com/watch?v=uR_VzYxvbxg)?

</comment></comment></comment><comment><USER49> Worth mentioning Joe Armstrong's "Making reliable distributed systems in the presence of sodware errors" [1].

[1] [http://erlang.org/download/armstrong_thesis_2003.pdf](http://erlang.org/download/armstrong_thesis_2003.pdf)

<comment><USER52> I was hoping your title wasn't a typo

</comment></comment><comment> bra-ket Kanerva's Sparse Distributed Memory is quite remarkable: [https://en.wikipedia.org/wiki/Sparse_distributed_memory](https://en.wikipedia.org/wiki/Sparse_distributed_memory)

it's a book though: [https://www.amazon.com/Sparse-Distributed-Memory-MIT- Press/d...](https://www.amazon.com/Sparse-Distributed-Memory-MIT- Press/dp/0262514699)

</comment><comment><USER53> "Communicating Sequential Processes" by Tony Hoare

[http://www.usingcsp.com/](http://www.usingcsp.com/)

I read it multiple times and still don't quite understand it all.

There are more great papers i read but this one comes back to mind more often then others.

</comment><comment><USER54> _As We May Think_ [https://www.theatlantic.com/magazine/archive/1945/07/as- we-m...](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may- think/303881/)

This paper, written during WW II (!) by someone who had around to 20 years of computing experience at that time (!!) introduced the world to the ideas like hypertext, and citation indexes. Google's PageRank algorithm can be seen as a recombining of ideas from this paper.

This is worth reading to see how much was understood how early.

</comment><comment><USER55> I don't have a favorite research paper, but there is a long Ph.D. thesis I've recently read in its entirety and found a lot of interesting ideas:

Programming with Agents: [http://alumni.media.mit.edu/~mt/thesis/mt-thesis- Contents.ht...](http://alumni.media.mit.edu/~mt/thesis/mt-thesis- Contents.html)

Here is a short paper with a clear description of an ingenious idea.

Engineered Robustness by Controlled Hallucination: [http://web.mit.edu/jakebeal/www/Publications/NIAI-2008.pdf](http://web.mit.edu/jakebeal/www/Publications/NIAI-2008.pdf)

I like the simplicity of it. Most CS researches seem to be afraid of describing things that are simple, even if those things are non-obviosu and valuable.

</comment><comment><USER56> Dijkstra's shortest path algorithm in "A Note on Two Problems in Connexion with Graphs" [http://www-m3.ma.tum.de/foswiki/pub/MN0506/WebHome/dijkstra....](http://www-m3.ma.tum.de/foswiki/pub/MN0506/WebHome/dijkstra.pdf) Pure, mathematical and a great impact on both how to prove and define algorithms as well as the problem itself.

</comment><comment><USER57> Why Pascal Is Not My Favorite Programming Language, by Brian Kernighan [http://www.cs.virginia.edu/~cs655/readings/bwk-on- pascal.htm...](http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html)

No Silver Bullet, by Fred Brooks [http://worrydream.com/refs/Brooks- NoSilverBullet.pdf](http://worrydream.com/refs/Brooks-NoSilverBullet.pdf)

The original STL documentation [https://www.sgi.com/tech/stl/table_of_contents.html](https://www.sgi.com/tech/stl/table_of_contents.html)

</comment><comment><USER4> The Mythical Man-Month

[https://www.cs.drexel.edu/~yfcai/CS451/RequiredReadings/Myth...](https://www.cs.drexel.edu/~yfcai/CS451/RequiredReadings/MythicalManMonth.pdf)

<comment><USER58> And the paper that inspired it, Melvin Conway's "How Do Committees Invent?"

[http://www.melconway.com/Home/Committees_Paper.html](http://www.melconway.com/Home/Committees_Paper.html)

<comment><USER4> This is great -- I never knew about this paper but it reinforces a lot of things I learned. Namely, if you want to know how a company _really_ works, ignore the org charts and map the systems architecture (a corollary to the author's thesis).

That it still holds true almost 50 years later is pretty amazing.

</comment></comment></comment><comment><USER59> New Directions in Cryptography - Diffie + Hellman

[https://www-ee.stanford.edu/~hellman/publications/24.pdf](https://www- ee.stanford.edu/~hellman/publications/24.pdf)

</comment><comment><USER60> Some old ones:

Jeffrey Ullman & John Hopcroft: Formal languages and their relation to automata [0]

Ted Codd: A relational model of data for large shared data banks [1]

C.A.R Hoare: Communicating Sequential Processes [2]

[0][http://dl.acm.org/citation.cfm?id=1096945](http://dl.acm.org/citation.cfm?id=1096945)

[1][http://dl.acm.org/citation.cfm?id=362685](http://dl.acm.org/citation.cfm?id=362685)

[2][http://www.usingcsp.com/cspbook.pdf](http://www.usingcsp.com/cspbook.pdf)

</comment><comment><USER61> Cheney on the MTA [http://home.pipeline.com/~hbaker1/CheneyMTA.html](http://home.pipeline.com/~hbaker1/CheneyMTA.html)

Full tail recursion scheme implementation by never "return" in C

<comment><USER43> Such a great hack. Not only tail recursion but a complete GC implementation in (almost) platform-independent generated C code.

</comment></comment><comment><USER62> The Night Watch by James Mickens is always a good read:

[https://www.usenix.org/system/files/1311_05-08_mickens.pdf](https://www.usenix.org/system/files/1311_05-08_mickens.pdf)

<comment><USER63> That's a good one, but I think "This World of Ours", Mickens' treatise on the practical realities of operational security (specifically keying material handling), should take the top spot:

[https://www.usenix.org/system/files/1401_08-12_mickens.pdf](https://www.usenix.org/system/files/1401_08-12_mickens.pdf)

<comment><USER64> The nice thing about this one is that it actually does have some important kernels of truth amid all the hilarity. Especially this bit about threat models:

> Basically, you're either dealing with Mossad or not-Mossad. If your > adversary is not-Mossad, then you'll probably be fine if you pick a good > password and don't respond to emails from ChEaPestPAiNPi11s@ virus- > basket.biz.ru. If your adversary is the Mossad, YOU'RE GONNA DIE AND THERE'S > NOTHING THAT YOU CAN DO ABOUT IT

More security researchers need to learn about that.

</comment></comment></comment><comment><USER65> I've always enjoyed Finseth's Thesis on text editing, "A cookbook for an EMACS", which he turned into a book: [https://www.finseth.com/craft/](https://www.finseth.com/craft/) and is available in epub form for free.

</comment><comment><USER66> The Flajolet-Martin paper on counting unique items in an infinite stream with constant space [1]: a great, well-written introduction to streaming algorithms that triggered my first "aha" moment in the field. You never forget your first.

[1] [http://algo.inria.fr/flajolet/Publications/FlMa85.pdf](http://algo.inria.fr/flajolet/Publications/FlMa85.pdf)

</comment><comment><USER67> Andrew Tridgell's PhD Thesis: [https://www.samba.org/~tridge/phd_thesis.pdf](https://www.samba.org/~tridge/phd_thesis.pdf)

Which documents the invention of rsync, it's a good read.

<comment><USER68> His KnightCap papers are also cool, .e.g [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.6321&rep=rep1&type=pdf)

AlphaGo learning from self-play? Tridgell did it in 1998.

</comment></comment><comment><USER69> "On the criteria to be used in decomposing systems into modules" by David Parnas, 1972, the seminal paper where he brings forward the key ideas that would later be called cohesion and coupling.

[https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit...](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)

Why it was important: you can't build big complex systems without these principles.

Some people say he was instrumental in stopping the Star Wars program, he argued it would be impossible to test outside of war (and therefore doomed).

</comment><comment><USER70> Not a single paper but Eric Veach's Ph.D. thesis 'Robust Monte Carlo Methods for Light Transport Simulation' \- [http://graphics.stanford.edu/papers/veach_thesis/](http://graphics.stanford.edu/papers/veach_thesis/)

</comment><comment><USER71> I haven't read a ton of academic research in general, but in trying to understand CRDTs and concurrency, gritzko's paper on "Causal Trees"[1] struck me as incredibly smart and clear in its thinking. Many of the other CRDT papers I read (even influential ones) were flawed in a number of respects: blurred lines between design and implementation, blatant mistakes and typos, hasty and unconvincing conclusions, an overabundance of newly-minted terms and acronyms, dense proofs lacking any concrete examples, unintuitive divisions between operation history and state mutation. The Causal Trees paper is also dense and also invents a bunch of new vocabulary, but the logic is completely consistent (to the point of being unified under a single metaphor) and clearly explained every step of the way. The data format is also very clever, and the paper spends a good amount of time following the practical consequences of those design decisions, e.g. the ease of displaying inline changes, or of generating a particular revision of the document.

Weirdly, the paper isn't much discussed alongside the usual contenders. (WOOT, Logoot, RGA, LSEQ, etc.)

[1]: [https://ai2-s2-pdfs.s3.amazonaws.com/6534/c371ef78979d7ed84b...](https://ai2-s2-pdfs.s3.amazonaws.com/6534/c371ef78979d7ed84b6dc19f4fd529caab43.pdf)

</comment><comment><USER72> Mine is "Image Quilting for Texture Synthesis and Transfer" by Efros and Freeman. It's simple enough to implement as a personal project and has some nice visual output. Plus, Wang tiles are cool and it's fun to learn more about them.

[https://www2.eecs.berkeley.edu/Research/Projects/CS/vision/p...](https://www2.eecs.berkeley.edu/Research/Projects/CS/vision/papers/efros- siggraph01.pdf)

<comment><USER73> On the same subject, I prefer the concurrently published "Image Analogies" paper ( [http://www.mrl.nyu.edu/projects/image- analogies/](http://www.mrl.nyu.edu/projects/image-analogies/) ) because their described technique, while slow, just makes so much sense.

</comment></comment><comment><USER74> Notation as a Tool of Thought, Kenneth E. Iverson

[http://www.jsoftware.com/papers/tot.htm](http://www.jsoftware.com/papers/tot.htm)

<comment><USER75> Also along those lines: Two notes on notation, Knuth, [https://arxiv.org/abs/math/9205211](https://arxiv.org/abs/math/9205211)

</comment></comment><comment><USER76> Depixelizing Pixel Art

[http://johanneskopf.de/publications/pixelart/paper/pixel.pdf](http://johanneskopf.de/publications/pixelart/paper/pixel.pdf)

I think this paper is very cute and also technically interesting.

</comment><comment><USER77> An Algorithm for the Machine Calculation of Complex Fourier Series

James W. Cooley and John W. Tukey

Mathematics of Computation Vol. 19, No. 90 (Apr., 1965), pp. 297-301

[https://www.jstor.org/stable/2003354](https://www.jstor.org/stable/2003354)

<comment><USER78> Apparently this FFT was first discovered by Gauss (1805). [http://www.cis.rit.edu/class/simg716/Gauss_History_FFT.pdf](http://www.cis.rit.edu/class/simg716/Gauss_History_FFT.pdf)

As a follow-up, let me recommend Püschel & Moura (2006) "Algebraic Signal Processing Theory", [https://arxiv.org/pdf/cs/0612077.pdf](https://arxiv.org/pdf/cs/0612077.pdf) and Püschel's other papers about similar topics.

Or in a different direction, DJB (2008), "Fast multiplication and its applications", [http://cr.yp.to/lineartime/multapps-20080515.pdf](http://cr.yp.to/lineartime/multapps-20080515.pdf)

<comment><USER27> Interesting to note that Fourier's two works were published in 1807 and 1822, so that work by Gauss also predates Fourier.

</comment></comment></comment><comment><USER79> "A Method for the Construction of Minimum-Redundancy Codes"

[https://www.ic.tu-berlin.de/fileadmin/fg121/Source- Coding_WS...](https://www.ic.tu-berlin.de/fileadmin/fg121/Source- Coding_WS12/selected-readings/10_04051119.pdf)

I'm not sure if it was the fact that I was just a kid when I read it, but it was just so obvious and simple but so complicated and amazing at the same time.

</comment><comment><USER80> End-To-End Arguments in System Design

[http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...](http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf)

</comment><comment><USER19> Hofstadter, D. R. and Mitchell, M. (1995). _" The Copycat project: A model of mental fluidity and analogy-making."_ Chapter 5 in D. R. Hofstadter, Fluid Concepts and Creative Analogies.

[http://web.cecs.pdx.edu/~mm/CopycatChapter.html](http://web.cecs.pdx.edu/~mm/CopycatChapter.html)

"Copycat is a model of analogy making and human cognition based on the concept of the parallel terraced scan, developed in 1988 by Douglas Hofstadter, Melanie Mitchell, and others at the Center for Research on Concepts and Cognition, Indiana University Bloomington. Copycat produces answers to such problems as "abc is to abd as ijk is to what?" (abc:abd :: ijk:?). Hofstadter and Mitchell consider analogy making as the core of high-level cognition, or high-level perception, as Hofstadter calls it, basic to recognition and categorization. High-level perception emerges from the spreading activity of many independent processes, called codelets, running in parallel, competing or cooperating. They create and destroy temporary perceptual constructs, probabilistically trying out variations to eventually produce an answer. The codelets rely on an associative network, slipnet, built on pre-programmed concepts and their associations (a long-term memory). The changing activation levels of the concepts make a conceptual overlap with neighboring concepts." \-- [https://en.wikipedia.org/wiki/Copycat_(software)](https://en.wikipedia.org/wiki/Copycat_\(software\))

[https://cogsci.indiana.edu/copycat.html](https://cogsci.indiana.edu/copycat.html)

</comment><comment><USER81> Bitcoin: A Peer-to-Peer Electronic Cash System

[https://www.bitcoin.com/bitcoin.pdf](https://www.bitcoin.com/bitcoin.pdf)

</comment><comment><USER82> "Dancing Links" by Knuth ([http://www-cs- faculty.stanford.edu/~knuth/papers/dancing-col...](http://www-cs- faculty.stanford.edu/~knuth/papers/dancing-color.ps.gz)) is still one of my favorites for my actually having understood it. :) I wish I had found it back in grade school. (Though I suspect I wouldn't have understood it, then.)

</comment><comment><USER83> All of the classic papers I can think of have already been mentioned, but even though it's too recent to pass judgment a new contender may well be "Deep Learning and Quantum Entanglement: Fundamental Connections with Implications to Network Design" \- [https://arxiv.org/abs/1704.01552](https://arxiv.org/abs/1704.01552)

<comment><USER84> Damn, did not expect to see this paper on here. When I read it, I wasn't thinking it could be listed under the "all-time favorite CS papers", but the connections are quite interesting and (retrospectively) intuitive.

I'll be interested to see where/(if) it gets published.

</comment></comment><comment><USER85> Alexia Massalin's 1992 PhD thesis describing the Synthesis Operating System.

      http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.4871&rep=rep1&type=pdf

Here's Valerie Aurora's description of Synthesis:

... a completely lock-free operating system optimized using run-time code generation, written from scratch in assembly running on a homemade two-CPU SMP with a two-word compare-and-swap instruction — you know, nothing fancy.

Which (necessarily) undersells by a very large margin just how impressive, innovative, and interesting this thesis is.

If you're interested in operating systems, or compilers, or concurrency, or data structures, or real-time programming, or benchmarking, or optimization, you should read this thesis. Twenty-five years after it was published, it still provides a wealth of general inspiration and specific food for thought. It's also clearly and elegantly written. And, as a final bonus, it's a snapshot from an era in which Sony made workstations and shipped its own, proprietary, version of Unix. Good times.

</comment><comment><USER86> Admittedly a good portion of my appreciation is due to the title alone, but the paper and contents itself are very good as well:

'The Geometry of Innocent Flesh on the Bone: Return-into-libc without function calls' by Hovav Shacham

[http://cseweb.ucsd.edu/~hovav/dist/geometry.pdf](http://cseweb.ucsd.edu/~hovav/dist/geometry.pdf)

</comment><comment><USER87> Not exactly CS, but the Unreasonable Effectiveness of Mathematics in the Natural Sciences is one of my favourites.

</comment><comment><USER88> I would say An Agent-Oriented Programming by Yoav Shoham. It certainly set my mind going and made me think about how programs could be organized. I still think, agents, systems of agents, and mobile agent code has a place in computing. Even though some form of RPC over HTTP won over mobile code, I look at the spinning up of VMs and cannot help but think that agents have a place. Combined with the tuple space stuff from Yale, I still see a powerful way to go forward.

1) 1990 [http://cife.stanford.edu/node/599](http://cife.stanford.edu/node/599)

2) 1993 [http://faculty.cs.tamu.edu/ioerger/cs631-fall05/AOP.pdf](http://faculty.cs.tamu.edu/ioerger/cs631-fall05/AOP.pdf)

</comment><comment><USER89> Backus - A Functional Style and Its Algebra of Programs

[https://www.cs.ucf.edu/~dcm/Teaching/COT4810-Fall%202012/Lit...](https://www.cs.ucf.edu/~dcm/Teaching/COT4810-Fall%202012/Literature/Backus.pdf)

</comment><comment><USER90> Worse is Better [http://wiki.c2.com/?WorseIsBetter](http://wiki.c2.com/?WorseIsBetter)

</comment><comment><USER91> How to share a secret by Adi Shamir. Simple, elegant, short and highly impactful.

<comment><USER92> [http://cs.jhu.edu/~sdoshi/crypto/papers/shamirturing.pdf](http://cs.jhu.edu/~sdoshi/crypto/papers/shamirturing.pdf)

</comment></comment><comment><USER93> Producing Wrong Data without Doing Anything Obviously Wrong.

Immediately useful for anyone measuring compiler transformations performance!

<comment><USER31> Great paper, yes. Immediately useful? More like disheartening, because it doesn't really tell you how to be sure your measurements are OK.

<comment><USER94> Our lab addressed some of the issues with Stabilizer [0], which "eliminates measurement bias by comprehensively and repeatedly randomizing the placement of functions, stack frames, and heap objects in memory".

[0] [http://plasma.cs.umass.edu/emery/stabilizer.html](http://plasma.cs.umass.edu/emery/stabilizer.html) "Stabilizer: Statistically Sound Performance Evaluation" by Charlie Curtsinger and Emery Berger, ASPLOS 2013

</comment></comment></comment><comment><USER95> The Essence of the Iterator Pattern, by Gibbons and Oliveira.

This paper develops a precise model for internal iteration of a data structure, such that exactly the necessary information is exposed and no more.

It's a fantastic exploration of improving a well-known design space with justified removal of details. I keep its lessons in mind whenever I am facing code that seems to have a lot of incidental complexity.

[https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator...](https://www.cs.ox.ac.uk/jeremy.gibbons/publications/iterator.pdf)

</comment><comment><USER96> One of my all time favorites has been the Jefferey Mogul paper on Receive Livelock: [https://pdos.csail.mit.edu/6.828/2008/readings/mogul96usenix...](https://pdos.csail.mit.edu/6.828/2008/readings/mogul96usenix.pdf)

I read it first as a normal CS paper, but later started seeing it as a commentary on an extremely busy work life.

Right there in the first paragraph: "... receive livelock, in which the system spends all its time processing interrupts, to the exclusion of other tasks..."

Does this remind you of anything?

</comment><comment><USER97> My favourite is "Targeting Safety-Related Errors During Software Requirements Analysis" by Robyn Lutz at the Jet Propulsion Laboratory. It's available at [https://trs.jpl.nasa.gov/bitstream/handle/2014/35179/93-0749...](https://trs.jpl.nasa.gov/bitstream/handle/2014/35179/93-0749.pdf)

The article provides a safety checklist for use during the analysis of software requirements for spacecraft and other safety-critical, embedded systems.

</comment><comment><USER98> It's not exactly a paper but I really liked "The Limits of Mathematics" by Chaitin. I wrote a blogpost about it a few years back ([https://shebang.ws/the-limits-of-mathematics.html](https://shebang.ws/the- limits-of-mathematics.html)), I already submitted it to HN ([https://news.ycombinator.com/item?id=1725936](https://news.ycombinator.com/item?id=1725936)).

</comment><comment><USER99> "The Derivative of a Regular Type is its Type of One-Hole Contexts" \- Conor McBride, [http://strictlypositive.org/diff.pdf](http://strictlypositive.org/diff.pdf)

This shows how you end up "differentiating" datatypes in the context of strict functional programming, in order to do things like "mutate" lists. It is essentially the same as what mathematicians call "combinatorial species".

</comment><comment><USER100> My favorite paper in computer systems is "Memory Resource Management in VMware ESX Server". It identifies a problem and devises several clever solutions to the problem. I love papers that make your go "AHA!".

[http://web.eecs.umich.edu/~mosharaf/Readings/ESX- Memory.pdf](http://web.eecs.umich.edu/~mosharaf/Readings/ESX-Memory.pdf)

</comment><comment><USER101> Deepmind's first paper on deep reinforcement learning. The beginning of a new era towards AGI : )

Human-level control through deep reinforcement learning [http://www.nature.com/nature/journal/v518/n7540/full/nature1...](http://www.nature.com/nature/journal/v518/n7540/full/nature14236.html?foxtrotcallback=true)

</comment><comment><USER102> Type Systems as Macros

[http://www.ccs.neu.edu/home/stchang/popl2017/](http://www.ccs.neu.edu/home/stchang/popl2017/)

It's not world-changing or even particularly novel, but it's such a simple concept explained very well that really changes how you see the typed/dynamic language divide, as well as language design in general.

</comment><comment><USER103> Trading Group Theory for Randomness by Laci Babai ([http://dl.acm.org/citation.cfm?id=22192](http://dl.acm.org/citation.cfm?id=22192)) -- this beautiful paper introduced algorithmic group theory & interactive proofs (in the form of Arthur-Merlin games) to study the Graph Isomorphism problem, and introduced several groundbreaking new results. Perhaps a more approachable (and funny) version of this would be Babai's humorous essay detailing the flurry of work that broke out after his results introducing AM/MA...it's the closest thing I've seen to making theoretical CS exhilarating :P ([http://www.cs.princeton.edu/courses/archive/spr09/cos522/Bab...](http://www.cs.princeton.edu/courses/archive/spr09/cos522/BabaiEmail.pdf))

</comment><comment><USER104> The Scheme papers are great [http://library.readscheme.org/page1.html](http://library.readscheme.org/page1.html)

"On the Translation of Languages from Left to Right", by Knuth, I found much clearer and more illuminating than any of the secondary literature on LR(k) parsing.

<comment><USER43> I recall finding "Lambda: The Ultimate GOTO" to be mind-bending.

</comment></comment><comment><USER105> Not a paper, and not strictly CS, but _Mythical Man-Month_ by Brooks. It solidified the connection in my mind between systems engineering and software engineering. Other readings since then have extended and changed this understanding, but this is where my approach to software development started to mature.

<comment><USER58> And I'd add the paper that inspired Brooks, Melvin Conway's "How Do Committees Invent?".

[http://www.melconway.com/Home/Committees_Paper.html](http://www.melconway.com/Home/Committees_Paper.html)

</comment></comment><comment><USER106> "The Moral Character of Cryptographic Work" by Phillip Rogaway

Background: [http://web.cs.ucdavis.edu/~rogaway/papers/moral.html](http://web.cs.ucdavis.edu/~rogaway/papers/moral.html)

Paper: web.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf

</comment><comment><USER107> "Hints for Computer System Design" by Butler Lampson

[https://www.microsoft.com/en-us/research/wp- content/uploads/...](https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/acrobat-17.pdf)

</comment><comment><USER108> "NP-complete Problems and Physical Reality" by Scott Aaronson. It relates NP- complete problems to examples in nature. Excellent paper and a fun read.

[https://arxiv.org/abs/quant-ph/0502072](https://arxiv.org/abs/quant- ph/0502072)

</comment><comment><USER109> A play on regular expressions: [https://sebfisch.github.io/haskell- regexp/regexp-play.pdf](https://sebfisch.github.io/haskell-regexp/regexp- play.pdf)

This paper explains a beautiful algorithm for matching regular expressions with a Socratic dialogue.

</comment><comment><USER110> From the perspective of - 'take a fresh look at something we take for granted' \- "A Preliminary Architecture for a Basic Data-Flow Processor" (Dennis & Misunas 1975)

Focusing on the flow of data between operators and greedily executing a linear program is what an out-of-order processor is.

</comment><comment><USER111> Since I just love the impracticality of it, Bernard Chazelle's linear time triangulation is my fave.

[https://www.cs.princeton.edu/~chazelle/pubs/polygon- triang.p...](https://www.cs.princeton.edu/~chazelle/pubs/polygon-triang.pdf)

</comment><comment><USER112> "Collaborative creation of communal hierarchical taxonomies in social tagging systems"

[http://ilpubs.stanford.edu:8090/775/1/2006-10.pdf](http://ilpubs.stanford.edu:8090/775/1/2006-10.pdf)

</comment><comment><USER113> "Interactive Indirect Illumination Using Voxel Cone Tracing" by Crassin et al.

As an architectural lighting guy, seeing realtime global illumination look this good in a game engine was fantastic. Parts of the algorithm I can understand, parts go over my head still, but the results are amazing.

A big part of what I do at work is radiosity simulations in AGI32 which is of course more accurate (because it's trying to accurately simulate real world lighting results) but much much slower.

[http://research.nvidia.com/publication/interactive- indirect-...](http://research.nvidia.com/publication/interactive-indirect- illumination-using-voxel-cone-tracing)

<comment><USER114> That link doesn't work for me, even though the same link is presented in a Google search. Also, for some reason I can't find it via search by DOI.

[http://research.nvidia.com/publication/interactive- indirect-...](http://research.nvidia.com/publication/interactive-indirect- illumination-using-voxel-cone-tracing) has the paper plus presentation available, plus abstract and other links.

<comment><USER113> Thanks! I've replaced it with your working nvidia link.

I got the citeseerx.ist.psu.edu link off google and it worked for me the first time. I'm an alum but not logged into anything, so either it was a bypass via google referrer (not sure why they'd do that, it's not looking for advertising clicks) or some usage limit.

</comment></comment></comment><comment><USER115> _Growing a Language_

<comment><USER27> Guy L. Steele.

[https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf](https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)

</comment></comment><comment><USER116> Scott Aaronson's "Why Philosophers Should Care About Computational Complexity"

[https://www.scottaaronson.com/papers/philos.pdf](https://www.scottaaronson.com/papers/philos.pdf)

</comment><comment> alok-g Automated Theorem Proving, David Plaisted

[http://onlinelibrary.wiley.com/doi/10.1002/wcs.1269/full](http://onlinelibrary.wiley.com/doi/10.1002/wcs.1269/full)

</comment><comment><USER117> Royce 1970 of course: [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf) wherein he did not introduce Waterfall, but for some reason the negative aspects of his article became the basis for Waterfall. The article for 1970 is surprisingly relevant although archaic in language. It's worth reading to the end. He wrote this describing leading teams in the 1960s do what I assume was actual "rocket" science.

</comment><comment><USER118> Probabilistic Topic Models [http://www.cs.columbia.edu/~blei/papers/Blei2012.pdf](http://www.cs.columbia.edu/~blei/papers/Blei2012.pdf)

</comment><comment><USER119> [http://www.scs.stanford.edu/~dm/home/papers/remove.pdf](http://www.scs.stanford.edu/~dm/home/papers/remove.pdf)

<comment><USER120> Love the figures and references.

</comment></comment><comment><USER121> "Programming with Abstract Data Types", B Liskov and S Zilles

</comment><comment><USER122> Back To The Future (Squeak). [http://ftp.squeak.org/docs/OOPSLA.Squeak.html](http://ftp.squeak.org/docs/OOPSLA.Squeak.html)

</comment><comment><USER14> The Applications of Probability to Cryptography - Alan M. Turing

[https://arxiv.org/abs/1505.04714](https://arxiv.org/abs/1505.04714)

</comment><comment><USER123> Oh man... I don't know. There's so many.

I'll need to go with

Gilbert, E., & Karahalios, K. (2009, April). Predicting tie strength with social media. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 211-220). ACM.

In grad school, it was the paper that kept on giving. I think I cited it every semester for a paper or project. There's a lot of other papers and books that really inspired me, but this one was magic.

</comment><comment><USER124> Anything dealing w/ "reversible computing", makes you ask "what-if" ...

[http://cqi.inf.usi.ch/qic/80_Toffoli.pdf](http://cqi.inf.usi.ch/qic/80_Toffoli.pdf)

[https://www.eng.famu.fsu.edu/~mpf/Frank-99-PhD- bookmarked.pd...](https://www.eng.famu.fsu.edu/~mpf/Frank-99-PhD- bookmarked.pdf)

</comment><comment><USER125> I see some of my favourites among other replies. I don't think I see these:

[http://aegis.sourceforge.net/auug97.pdf](http://aegis.sourceforge.net/auug97.pdf)

[http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf](http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)

</comment><comment><USER126> ImageNet Classification with Deep Convolutional Neural Networks [https://papers.nips.cc/paper/4824-imagenet-classification- wi...](https://papers.nips.cc/paper/4824-imagenet-classification-with-deep- convolutional-neural-networks.pdf) If not evident already, time will tell that this paper brought us to a new era.

</comment><comment><USER127> The splay trees paper by Sleator and Tarjan (1985) [https://www.cs.cmu.edu/~sleator/papers/self- adjusting.pdf](https://www.cs.cmu.edu/~sleator/papers/self-adjusting.pdf)

It's just such a cool result and the paper is very well written. Further, the dynamic optimality conjecture at the end is still an open problem.

</comment><comment><USER128> Paxos made simple. It's a very beautiful paper.

</comment><comment><USER129> Not CS, but control theory: "Guaranteed Margins for LQG Regulators" by John C. Doyle. The abstract is just three words: "There are none."

[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.362...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.362.8807&rep=rep1&type=pdf)

</comment><comment><USER130> "Cache-Conscious Collision Resolution in String Hash Tables" Nikolas Askitis and Justin Zobel, SPIRE 2005

The most simple and most effective hash table scheme, and nobody is using it, or even knows about it. Fastest and least memory, but not thread-safe. After 12 years there's still nothing better on the horizon.

Though the CheneyMTA paper is also brilliant, a typical Baker paper.

</comment><comment><USER131> "On non-computable functions" \- Tibor Rado.

Proof that the busy beaver function is not computable.

[http://computation4cognitivescientists.weebly.com/uploads/6/...](http://computation4cognitivescientists.weebly.com/uploads/6/2/8/3/6283774/rado- on_non-computable_functions.pdf)

</comment><comment><USER132> The Dynamo Paper. [http://www.allthingsdistributed.com/files/amazon-dynamo- sosp...](http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf)

One of the best practical "How can this improve our business?" technical papers, and an excellent introduction to reading papers.

</comment><comment><USER133> Not hardcore CS as some of the other papers on here, but I really enjoyed the BigTable paper [https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable- osdi06.pdf)

</comment><comment><USER134> I'll go with an unconventional choice: Michael Kleber's _The Best Card Trick_: [http://www.northeastern.edu/seigen/11Magic/Articles/Best%20C...](http://www.northeastern.edu/seigen/11Magic/Articles/Best%20Card%20Trick.pdf)

</comment><comment><USER135> I know this doesn't really count, but the "Get me off your fucking mailing list" one made me giggle - [http://www.scs.stanford.edu/~dm/home/papers/remove.pdf](http://www.scs.stanford.edu/~dm/home/papers/remove.pdf)

</comment><comment><USER136> I sill find this interesting, if you are familiar with Dijkstra Algorithm.

Finding the k Shortest Paths by D. Eppstein [https://www.ics.uci.edu/~eppstein/pubs/Epp- SJC-98.pdf](https://www.ics.uci.edu/~eppstein/pubs/Epp-SJC-98.pdf)

</comment><comment><USER44> Olin Shivers's work on various control flow analyses, in particular the paper "CFA2: a context-free approach to control-flow analysis", is a really cool static analysis via abstract interpretation. Matt Might had a bunch of papers in a similar vein.

<comment><USER109> I wonder if it is possible to express this analysis as a datalog program.

</comment></comment><comment><USER137> Why it is Important that Software Projects Fail

[http://berglas.org/Articles/ImportantThatSoftwareFails/Impor...](http://berglas.org/Articles/ImportantThatSoftwareFails/ImportantThatSoftwareFails.html)

</comment><comment><USER138> PCP theorem as explained by Bernard Chazelle , 2001 [https://www.cs.princeton.edu/~chazelle/pubs/bourbaki.pdf](https://www.cs.princeton.edu/~chazelle/pubs/bourbaki.pdf)

Great writing style!

</comment><comment><USER139> Knuth vs Email:

[http://www-cs-faculty.stanford.edu/~knuth/email.html](http://www-cs- faculty.stanford.edu/~knuth/email.html)

It's not technically a CS paper, but well worth the (very short) read regardless.

</comment><comment><USER140> Intelligence without representation, by Rodney Brooks.

[http://people.csail.mit.edu/brooks/papers/representation.pdf](http://people.csail.mit.edu/brooks/papers/representation.pdf)

</comment><comment><USER141> the report on the Therac-25. a good warning that bugs can have very real consequences.

[http://sunnyday.mit.edu/papers/therac.pdf](http://sunnyday.mit.edu/papers/therac.pdf)

</comment><comment><USER142> The Byzantine Generals Problem by Lamport et al is a must read for anyone interested in distributed systems.

Some of the others that have already been mentioned on this thread:

\- Time, Clocks, and the Ordering of Events in a Distributed System

\- Paxos Made Simple

</comment><comment><USER143> Seam Carving!

[http://perso.crans.org/frenoy/matlab2012/seamcarving.pdf](http://perso.crans.org/frenoy/matlab2012/seamcarving.pdf)

</comment><comment><USER144> Scalability of Collaborative Environments [https://sci- hub.ac/10.1109/C5.2006.32#](https://sci-hub.ac/10.1109/C5.2006.32#)

</comment><comment><USER145> Smashing the stack for fun adn profit [http://insecure.org/stf/smashstack.html](http://insecure.org/stf/smashstack.html)

</comment><comment><USER146> "Bitcoin: A Peer-to-Peer Electronic Cash System" [https://bitcoin.org/bitcoin.pdf](https://bitcoin.org/bitcoin.pdf)

</comment><comment><USER147> Real programmers don't use Pascal The rise of worse is better

</comment><comment><USER148> Delegation is Inheritance

[http://wiki.c2.com/?DelegationIsInheritance](http://wiki.c2.com/?DelegationIsInheritance)

</comment><comment><USER149> On Formally Undecidable Propositions... by Kurt Godel.

One might argue this is not CS, but it's something everyone should read and understand.

</comment><comment><USER150> Communicating Sequential Processes C. A. R. Hoare [http://www.usingcsp.com/cspbook.pdf](http://www.usingcsp.com/cspbook.pdf)

</comment><comment><USER151> Relevance Vector Machines by Tipping

or

Homomorphic Encryption over the Integers

</comment><comment><USER145> [http://insecure.org/stf/smashstack.html](http://insecure.org/stf/smashstack.html)

</comment><comment><USER152> The original GAN paper was pretty big for me. [https://arxiv.org/pdf/1406.2661.pdf](https://arxiv.org/pdf/1406.2661.pdf)

</comment><comment><USER153> Not a paper, but one of my favorite talks

[https://www.youtube.com/watch?v=_ahvzDzKdB0&t=642s](https://www.youtube.com/watch?v=_ahvzDzKdB0&t=642s)

Growing a Language by Guy Steele (co-inventory of Scheme). Brilliant speech about how to grow languages and why it's necessary. Languages that can be grown by the programmer, like Lisp or Smalltalk are better than languages that fixed like most others, this is why.

</comment><comment><USER154> My favorite topic was from an advanced user interfaces class. Describe 3 example of a bad user experience where the input in to the system does not give you the expected output. My poor example was a Kleenex box, I try to pull on one Kleenex and it tears or two come out at a time.

</comment><comment><USER155> The bitcoin whitepaper.

[https://bitcoin.org/bitcoin.pdf](https://bitcoin.org/bitcoin.pdf)

</comment><comment><USER156> I'm surprised no one has mentioned "The Cathedral and the Bazaar" yet. Admittedly is more essay, less paper.

[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)</comment>


Elon Musk: Just walk out of bad meetings - <AUTHOR> http://www.bbc.co.uk/news/business-43809674 <comment><USER2> That's not actually what he said - the article cuts his quote in half, and seems to attribute sentiment that's not there:

"Walk out of a meeting or drop off a call as soon as it is obvious you aren't adding value. It is not rude to leave, it is rude to make someone stay and waste their time."

This is a weird, and somewhat sensational, interpretation of that line in the memo. It is clear that the mandate is to only hold useful meetings, only as often, and for as long as they're necessary. Nothing strange about that kind of mentality...

<comment><USER3> Could you explain what the massive implication difference between the quote and the paraphrase is? I'm not seeing it for some reason.

<comment><USER4> I think the big difference is in the actual quote, he's not saying walk in to a meeting and say "this is dumb" and leave. He's saying the meeting might start out being useful, but then end up slowing down or going into a tangent, and when it just becomes corporate speak and the topic doesn't actually interest you, you should leave or the meeting should probably end there.

<comment><USER5> Not only that - the meeting might be highly useful and productive, but not to _everyone_ summoned.

i.e. those that find themselves in a meeting where they are not needed or have nothing to contribute should leave - however that isn't saying anything about the actual meeting being good or bad.

</comment></comment></comment></comment><comment><USER6> I hate time wasting meetings, I was on a conference call one time that had gone on for over 90 minutes over a completely inane decision. At one point I got up from my desk, left the building and went and bought a box of doughnuts from a store five minutes from office. I came back a d had missed nothing and no one had noticed I was gone. utterly pointless.

I'm sure the majority of these pointless meetings are just organised by "business" people to justify their jobs. If they aren't in meetings what would they actually do with their day...

The meeting was a discussion for what limit to put on number of items for a proposed new kanban column. 90 minutes to discuss if it should be zero or one, they couldn't agree so ditched the entire column proposal altogether.. Sigh.

Thus was at a time where we already I think 13 columns on our kanban because of someone spending all day seemingly working on dev process and i guess columns were there way to show they had done somethinf....

</comment><comment><USER7> says the guy who still has a few millions on the bank when he drops all his jobs. This is really the kind of stuff where an entrepreneur who never really worked a real job to pay rent (i.e. because he has no alternative) is a really bad manager. The advise sounds reasonable on paper, but that's simply not how people work.

<comment><USER8> Eh, I don't think that's fair. You're talking about someone who used to budget $1/day for food and showered at the YMCA.

<comment><USER9> Completely different. It isn't about being wealthy or not. Musk has never had a 9 to 5 job so he doesn't understand how that world works. Nobody just walks out of meetings like that.

<comment><USER7> I agree, however I don't think it's "just" the 9-5 job. If you had a big safety net and could move into your moms big house when sh*t hits the fan, even then having a 9-5 job you would still not follow some rules. But when you are so poor (like most people) that you really require not to lose your job, then is when you really have to do things you don't like just so your manager doesn't get pissed about you.

<comment><USER10> Yup, that's why Elon is making a company rule to leave a meeting when you think you don't contribute to anymore.

</comment></comment></comment></comment></comment><comment><USER11> I shudder to think how much more I could have accomplished if I'd worked for a CEO who had my back like that! I've had jobs where half my time was coding and the other half was in meetings. When all I wanted to do was code. Guess that might be why I was attracted to startups in the first place!

<comment><USER3> He didn't say walk out of meetings if you like to code instead; he said walk out of unproductive meetings, if they're wasting people's time. There's a fine line there...

<comment><USER12> The point the parent comment is trying to make is that meetings _are_ a waste of people's time. Most software engineers will agree that the majority of meetings are unproductive.

<comment><USER13> Most software engineers often fail to see value in things that aren't of immediate interest to them. That doesn't mean meetings are a waste of people's time.

<comment><USER3> I'm actually worried this is going to backfire massively precisely because people interpret it so liberally. I hope he realizes what judgment calls he's asking everyone to make.

<comment><USER14> It will be a test of whether he's hired good people.

</comment></comment></comment></comment></comment></comment><comment><USER15> It must be hard to manage a company in the age of online outrage and excessive media attention. I imagine people will censor themselves in meetings/emails for fear of it getting 'leaked'. A bit similar to the kind of self-censoring people will do in authoritarian governments.

<comment><USER9> This email was meant to leak.

</comment></comment><comment><USER16> The actual quote has a slightly different meaning than what many are assuming - as far as I understand the actual quote was this:

> "Walk out of a meeting or drop off a call as soon as it is obvious you > aren't adding value. It is not rude to leave, it is rude to make someone > stay and waste their time," Musk writes.

from [http://www.businessinsider.com/elon-musk-productivity-tip- le...](http://www.businessinsider.com/elon-musk-productivity-tip-leave- meetings-if-theyre-not-productive-2018-4)

</comment><comment><USER17> _" In general, always pick common sense as your guide. If following a "company rule" is obviously ridiculous in a particular situation, such that it would make for a great Dilbert cartoon, then the rule should change."_

The entire memo: [https://electrek.co/2018/04/17/tesla-model-3-production- goal...](https://electrek.co/2018/04/17/tesla-model-3-production- goal-6000-units-per-week/)

</comment><comment><USER18> Come on, would it really be the end of the world, if they got another small round of investment just until they hit that 6000 a week mark?

If tesla really is as good of an investment as they say it is, then the situation is nowhere near that dire. From the sounds of it, they're going to make their 6K per week, it's just a question of when. By all means, be efficient and cancel those meetings. But you don't need to push employees to the brink of failure.

</comment><comment><USER19> _A leaked email outlined other ways staff could help streamline operations.

These include walking out of meetings, sidestepping the chain of command and ignoring company rules on occasion._

Thought experiment: Imagine you were reading this about Uber, not Tesla. Why would you feel differently? How about back when Kalanick was CEO?

<comment><USER20> I'd imagine at a large enough company there are bound to be obviously dumb rules that some low-level manager invented to power-trip ("All employees must walk on the right-hand side to walk to the left-most bathroom past 3pm").

My only concern is that it will be less "ignore obviously dumb rules" and more "ignore safety precautions".

</comment></comment><comment><USER21> Elon Musk always has advice for other people that we can't follow because we're not also rich. Just walk out of meetings. OK.</comment>


What if We Replaced iTunes With the Cloud? - <AUTHOR> http://www.nytimes.com/external/readwriteweb/2008/12/16/16readwriteweb-what_if_we_replaced_itunes_with_the_cloud.html <comment><USER2> "These days, everybody's talking about cloud computing - the notion that computing's future lies in web-based applications and services and not in software tied to the desktop ... Yet still, some programs remained tied to the desktop with seemingly no plans to move elsewhere. iTunes is one of those programs."

Rather than examining the reasons that iTunes has stayed out of the 'cloud', the author is assuming the cloud is always a Good Thing.

I wonder how long it would take to sync your 160GB iPod from 'the cloud'.

</comment><comment><USER3> Go for it, anything that benefits the consumer benefits the economy.</comment>


Work Policies May Be Kinder, but Brutal Competition Isn't - <AUTHOR> http://www.nytimes.com/2015/08/18/business/work-policies-may-be-kinder-but-brutal-competition-isnt.html

<comment><USER2> Funny that this article is hardly getting any attention, even though it highlights major problems with America's workplace culture (as opposed to a single company). I guess this article is too nuanced for any visceral reactions?</comment>


Hungarian PM: no tax for Hungarian women with four or more children - <AUTHOR> https://www.theguardian.com/world/2019/feb/10/viktor-orban-no-tax-for-hungarian-women-with-four-or-more-children <comment><USER2> His coalition is going to be ever so pleased when they realize how many Roma families will benefit from this tax break: [https://en.wikipedia.org/wiki/Romani_people_in_Hungary#Demog...](https://en.wikipedia.org/wiki/Romani_people_in_Hungary#Demographics)

</comment><comment><USER3> this is part of a wider effort across South-East Europe:

"Hungary, like its central and eastern European neighbours Slovenia, Croatia, Slovakia and Serbia, have some of the lowest fertility rates in the world, while many educated workers have sought higher salaries further west. According to the United Nations, almost all of the countries with the fastest shrinking populations are in eastern Europe. Hungary's population is projected to decline 15 per cent by 2050, from 9.7m in 2017 to 8.3m."

"Other countries in the region have also offered incentives to raise the birth rate. In Poland, the conservative Law and Justice party rose to power in 2015 with an expensive pledge giving 500 zlotys (£100) a month, about one-third of the net minimum wage, for every second and subsequent child. The initiative costs more than 1 per cent of Poland's GDP

Last spring, Serbia, which loses 30,000 people annually, introduced a 500m dinar (£3m) fund to provide payments worth 12,000 dinar for families with three children and 18,000 dinar for the fourth."

from: [https://www.ft.com/content/56a5c36a-2d68-11e9-8744-e7016697f...](https://www.ft.com/content/56a5c36a-2d68-11e9-8744-e7016697f225)

</comment><comment><USER4> With the level of education and the reasons most women in a country like Hungary do not have a lot of children, i doubt this amount would make any dent. Although i am unaware of local complexities such amounts only encourage breeding amongst the poorer sections which should not be encouraged.

At the risk of being flagged, it true though that a certain religion has much higher fertility rate than the others and have observed it in very high population countries in South Asia. One, if not the main reason for poverty

</comment><comment><USER5> Even though Hungary has a great, safe, fun culture, young people who can are running away to Western Europe because of the huge corruption that's going on in Hungary compared to the size of the country.

Don't let the strongly manipulated voting system that favors villages instead of representation in the number of people make you think that Orban is popular. Many people outside Budapest still like him, but more and more people come to realize that power concentrated in one hand is dangerous.

As for me I'm a big believer in decentralization (Bitcoin) helping to solve some of the political problems, but of course there's still a lot to do to undo the centralization that's going on in the judicial system and the media.

</comment><comment><USER6> I have not been following any news related to Hungary or really anything going on in Eastern Europe, so when I saw the headline I did not understand the motivating factors. I thought that this might be a progressive policy to help out women with a high number of children (and it is), but it is not motivated through benevolence as I thought rather it is a protectionist policy aimed at increasing their population. I was very surprised.

<comment><USER7> thank you for providing your judgement on benevolence of policies in countries and regions you admit not following. At least you're "morally right"...</comment></comment>


Ask HN: What's the purpose of the "payload" in SSL TLS/DTLS Heartbeat anyway? - <AUTHOR>

Having read through RFC 6520, I don't understand why the payload is necessary. Neither the server nor the client appears to be using it for anything?
Wouldn't it have been simpler and more secure to skip the payload altogether?
In a security protocol it seems strange the designers of the protocol opted for a more complex protocol than necessary. <comment><USER2> > Having read through RFC 6520, I don't understand why the payload is > necessary. Neither the server nor the client appears to be using it for > anything?

RFC 6520:

      "To perform PMTU discovery, HeartbeatRequest messages
       containing padding can be used as probe packets, as described in
       [RFC4821]."

      "In particular, after a number of retransmissions without
       receiving a corresponding HeartbeatResponse message having the
       expected payload, the DTLS connection SHOULD be terminated. "

      "When a HeartbeatRequest message is received and sending a
       HeartbeatResponse is not prohibited as described elsewhere in this
       document, the receiver MUST send a corresponding HeartbeatResponse
       message carrying an exact copy of the payload of the received
       HeartbeatRequest.

       If a received HeartbeatResponse message does not contain the expected
       payload, the message MUST be discarded silently.  If it does contain
       the expected payload, the retransmission timer MUST be stopped."

The "use" of the payload is in the RFC. What the RFC omits is the "why" for why the payload exists in the first place. Omission of this "why" is likely because the authors expected that their readers would inherently understand why given that the RFC is for network protocols and meant to be read by those understanding network protocols.

The "why" is that networks are subject to packet loss, and to timing delays. If you send out two heartbeats 10s apart, and only receive one reply back, then is the reply responsive to the first heartbeat, or to the second 10s later? Without some unique data in each of the packets you send, which is echoed by the other end, you can not disambiguate this question.

Now, one could argue that a simple sequence counter defined by the protocol would suffice. But that is open to exploit by a misbehaving server because once the server recognizes your heartbeat counter pattern, it can issue anticipatory heartbeat replies with the proper sequence number that you will accept as valid. By making the payload arbitrary bytes, then you have the option of sending a sequence number, or generating random data (and tracking it yourself), or both. The random data aspect thwarts misbehaving servers from determining your pattern and replying with the right data without ever receiving your requests. The arbitrary sized payload also makes the packet useful for path MTU discovery as the first paragraph I quoted from the RFC indicates.

<comment><USER3> For TLS, which runs on top of TCP, this is a non-issue, as TCP enforces complete, in-order delivery of the data.

However:

       This document describes the Heartbeat Extension for the Transport
       Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
       protocols [...] DTLS is designed to secure traffic running on top
       of unreliable transport protocols.

The payload is necessary because this extension can be used with DTLS, which runs on top of UDP, which does not enforce complete or in-order delivery.

I wonder if the payload should have been specified only for use with DTLS, not TLS.

<comment><USER4> The whole extension was originally specified only for DTLS. Then the working group started suggesting reasons that an app-layer liveness check would be useful in TLS. At some point, it became easier simply to add the feature in both places than to hash out the argument. That's how standards processes work: it's easier to say "yes" to a new feature than "no".

</comment></comment></comment><comment><USER5> All protocols are full of cruft like that. It's not that different from the Bitcoin "malleability" attack which also originated in a feature that has no practical use but the protocol designers thought might be handy to have in the future. Many people think it is a good idea to build extension points into your systems because that increases the flexibility of it. In reality it just makes the system harder to use and more prone to bugs.

<comment><USER6> to quote from [0,p67], which is the dissertation of the guy writing it:

The HeartbeatResponse must contain the same payload as the request it answers, which allows the requesting peer to verify it. This is necessary to distinguish expected responses from delayed ones of previous requests, which can occur because of the unreliable transport.

[0] [http://duepublico.uni-duisburg- essen.de/servlets/DerivateSer...](http://duepublico.uni-duisburg- essen.de/servlets/DerivateServlet/Derivate-31696/dissertation.pdf)

<comment><USER5> Ok but is there any evidence that anyone has a practical use for distinguishing the order of received heartbeat response packets? Otherwise it is still a complete YAGNI feature. And if so, why wouldn't a simple 32 bit sequence number suffice?

<comment><USER7> Having studied this for many hours now... and also having read part of that dissertation... and knowing something about block ciphers...

I don't think it is probable that any peer will want to know the order of the "ping" replies. A heartbeat is not used to diagnose anything. Any heartbeat response will suffice to keep the connection alive.

The need for a payload/sequence number is presented as a "truth" of networking but it seems to be invalid here.

A 32 bit sequence number would suffice, except for the fact that DTLS also uses this packet for path MTU discovery. Strangely, an IP packet cannot exceed the ethernet MTU of 1500 bytes anyway and at present I have no idea how this DTLS MTU discovery is supposed to work. Supposedly, the only way to check for MTU limits on routers is to set a bit in the IP header that says "do not fragment" and then wait for possible ICMP replies. This should work for UDP as well. But perhaps you can also discover UDP fragmentation at the receiving end since UDP might not automatically recombine the fragments. Then, any protocol on top of UDP would be able to do this as well. It was introduced in DTLS so that any applications using DTLS wouldn't need to do it themselves.

Whatever the case may be, and however useful or stupid the design, these messages could not exceed 1500 bytes. So why 64k? Probably just because a byte is max 255 which is too low, a word (2 bytes) is max 65535 which is enough. I don't know what features UDP/DTLS have for reassembling packets, but apparently they thought it easier to make $FFFF the max value than to impose a better limit on this number.

Also the padding is required just in case some peer sends simple sequence numbers as payload. A 32-bit sequence number + 3 bytes of header would be 7 bytes. Adding a 16 byte padding of random data would scramble the plaintext so the plaintext of the encryption (all of this is encrypted) could not be guessed.

In the unlikely case that some implementation uses 13 bytes of payload with 16 bytes of padding, and the block cipher uses 128-bit blocks, which is 16 bytes, then this whole security measure is voided since the block cipher simply encrypts bocks of 128 bits in serial.

All in all it doesn't sound like it's very well thought out.

</comment></comment></comment></comment><comment><USER8> When you're paying your 107,000 workers $53bn to insert backdoors into everything, finding new and interesting ways to hide exploits in source code becomes an art form. Of course you can't find any reason why a payload for a "keepalive" was necessary... because it simply wasn't, but absent some data, you can't insert the exploit.</comment>


ISPs ask lawmakers to kill privacy rules, and they're happily obliging - <AUTHOR> https://arstechnica.com/tech-policy/2017/02/isps-wont-have-to-follow-privacy-rules-if-gop-lawmakers-get-their-way/ <comment><USER2>
       > "Further, the Order would also result in consumers being bombarded
       > with trivial data breach notifications. The FCC greatly expands the
       > category of information for which a breach notification would be necessary,
       > even if the consumer is not harmed."

Can't have those damned consumers knowing just how far we spread their data around, nor the negligence with which our partners handle their data. That just won't do.

</comment><comment><USER3> USA should be considered a corporate oligarchy at this point. It's clear that, with gerrymandering, our FPTP voting system, and the fact that corporations are people and money is speech, the citizens of the country hold no real power anymore.

<comment><USER4> Encrypt. EVERYTHING. It's the power we _do_ have, and it might be the only power.

<comment><USER5> Yep, I pretty much already do exactly that. Cheap VPS provider + VPN for a good fraction of my home network traffic.

If my ISP wants to pay me in the form of a discounted price in exchange for my browsing data then I'll reconsider my position.

<comment><USER3> A problem there is that many VPNs sell our data as well. Even if they say they don't sell it, we have no way of proving they don't.

<comment><USER5> In my mind, a commercial VPS provider has little incentive to perform data mining of a particular customer's traffic vs a residential ISP.

Could AWS, Digital Ocean, Linode, <insert other low end hosts> all be trying to? Sure, I guess? Is it really central to their business model? I think that is a bit of a stretch so I'm comfortable trusting my tunneled traffic to them.

<comment><USER4> They have a lot to lose, considering how much anyone in that space would love to snap up market share.</comment></comment></comment></comment></comment></comment>


Gogo is getting sued by American Airlines over its in-flight Wi-Fi - <AUTHOR> http://www.theverge.com/2016/2/16/11021738/american-airlines-gogo-internet-speed-lawsuit <comment><USER2> Purely anecdotal - but Goto has been sucking more and more over the years I've been using it. Maybe it's speed creep - everything else gets faster - but Goto st</comment>


Dreamers - <AUTHOR> http://tom.posterous.com/dreamers

<comment><USER2> "Now class, today we will talk about what you want to be when you grow up. Isn't that fun?" The teacher looks around and spots the child, silent, apart from the others and deep in thought. "Jonny, why don't you start?" she encourages him.

Jonny looks around, confused, his train of thought disrupted. He collects himself, and stares at the teacher with a steady eye. "I want to code demos," he says, his words becoming stronger and more confidant as he speaks. "I want to write something that will change peoples perception of reality. I want them to walk away from the computer dazed, unsure of their footing and eyesight. I want to write something that will reach out of the screen and grab them, making heartbeats and breathing slow to almost a halt. I want to write something that, when it is finished, they are reluctant to leave, knowing that nothing they experience that day will be quite as real, as insightful, as good. I want to write demos." Silence. The class and the teacher stare at Jonny, stunned. It is the teachers turn to be confused. Jonny blushes, feeling that something more is required. "Either that or I want to be a fireman." --Grant Smith

<comment><USER3> The funny thing is that with all the talk of "dreamers" and "aiming high" on HN, there's a horrible horrible groupthink that goes on here. An obsession with the latest fad, to the complete disregard of substance. Buzzwords over basic utility, lists over productivity,

I would argue that demosceners (like little Johnny) are the dreamers while much of HN consists of internet hucksters. Back when I was writing demoscene code I bent my computer over my knee and made it beg (Wrote a flat real mode extension for borland pascal). Phong shading on a 486? Check. realtime raytracing on that same 486, in the same demo? Check. (10fps btw).

These days people struggle to handle a few thousand users of a text based website on a quad core system with gigabytes of ram.

PS: Sorry this was a little off topic. Follow your dreams, don't let the man get you down!

N.B. Although the S/N here is often quite poor, it is at least an order of magnitude better than other places I know about. At least once a day I read an article that is very much worth my time.

<comment><USER4> In the web hucksters' defense (not that I am one, mind you), fitting a few thousand users onto a quad core system (as opposed to a few million) improves maintainability, reliability, recoverability, and a multitude of other things that simply aren't major concerns in the demo scene.

The guys building big rigs care about performance - but never to the same tune as the guys designing F-1 racing cars. Different goals demand different approaches.

If you want to design jet fighters, go do that - and push the hardware to the absolute limits of human ability, but there is a glory in designing commuter jets too, you know.

<comment><USER3> That was part of my point. I don't see why we can't have a fast and good in the same piece of software. I've written software like that before, it's not difficult at all. Just keep your CS knowledge in the back of your mind and be a little pragmatic.

This is something that bothers me a lot. We've made huge, massive, spectacular progress in hardware. We know what the characteristics of our problems are (usually they're quite simple like CRM), yet software seems to ge slower, and more complex. With more layers of added complexity.

I simply do not see why continue to produce such bad software as a society. We continue to build on quicksand when a few hundred yards to the side is solid bedrock (lisps, ada, smalltalk, erlang, etc).

Back in the 50's we had teahouses in england [1] that fully automated their accounting/payroll system. On 50's hardware. Yet today we still need quad xeons to do even a fraction of that. It makes me very very angry to throw more hardware at a problem that has already been solved with orders of magnitude less.

1\. <http://www.kzwp.com/lyons/leo.htm>

</comment></comment></comment></comment><comment><USER5> Depending on what you've lived through, what that snippet derides might not sound too bad. I mean, for those from war torn places, immigrants who worked hard, a secure job to take care of your family and see your children grow up isn't a bad dream at all. We simply have the luxury of making that our baseline.

If anything, my take-away is to recognize that those things aren't bad in it of themselves, but just don't mistake the dreams of others for your own.

<comment><USER6> Right, so I wasn't saying that having a "normal job" is objectively bad, merely that in certain circumstances people have a tendency to "settle" for their lives and mistake rationalized contentment for happiness. I used it as an example since it's something many people in this particular country (U.S.) can relate to -- or could, if they took the time to look at their lives.

</comment></comment><comment><USER7> "When I was six, I wanted to create twitter apps and new ways to manage your to-do list!"

(No one looks on the flip-side..)

<comment><USER4> There is truth here - there is a large, unspoken sector of the internet startup world that is consisted of poor ideas with equally poor implementations whose sole purpose of existence is to flip to someone equally clueless for a profit.

There is nothing glorious in this, though entrepreneurs you will still be.

"When I grow up, I want to create failing businesses that I can convince people to pay me tens of millions of dollars to buy!"

</comment></comment><comment><USER8> I didn't realize that the best course of action in life is to follow the dreams you had as a 9 year old. While the idea might sound romantic, by age 10, these kids realized that they didn't actually want to be president.

I think its a little more apt to figure out what you want to do with your life when you're 18, 21, 30, 40, 50, etc.

</comment><comment><USER9> I like this post. I'm not sure it's as much about what you want to do, or be, as opposed to what you don't want to do. I believe that figuring out what you want to do with your life is much more difficult than figuring out what you definitely don't want. The problem is that nobody ever asks you, "What is it that you don't want to do when you grow up?". I think that question, presented to us when we were younger, would give far more direction to our lives.

</comment><comment><USER10> Well presumably you still have the ability to dream. For myself, I asked myself "what would you do if you had no fear" and I find that process useful. George Patton says " ... When you have collected all the facts and fears and made your decision, turn off all your fears and go ahead!"

</comment><comment><USER11> Profound

<comment><USER11> Wow downvoted here heavily too, I wonder if this is because the comment added little value (other than a recommendation to check out his thought which i thought had clarity) or because people disliked the article.

</comment></comment><comment><USER11> I had a similar thought recently - conservatives are motivated by fear, idealists by hope.

<comment><USER11> Er wow I got downvoted here heavily. I was just making the point that he talks about some people being happy with stability (avoiding fear) and some happy with chasing the ideal (hope).</comment></comment>