For lying, just as with coding, you just need to develop a ruleset that you can use as a framework that you can apply consistently depending on the person's role within your life/career. You need to divide your lies into a limited number of alternative realities that are easy to keep track of. Then depending on the role of the person you're communicating with, you adhere to one reality or another. This ensures that everyone in the same group operates within the same reality... So when people who exist in the same reality talk to each other, they will believe that you are logically consistent. The challenge is mostly about ensuring that people from different groups/realities you've crafted never meet or talk to each other. With social media filter bubbles nowadays, it barely requires any effort to do this; if the big guys manage to make it work with billions of people, surely you can do it with just your own network.<p>You could maximize your gains by having a custom-crafted reality tailored for each individual but the risks go up by an order of magnitude since it means that you have to put up and maintain more information barriers between the different participants. Also, they will never trust you fully because that requires confirmation from a third party... And you can never create that social confirmation scenario if every person who knows you has a different reality about you in their minds. It's better to forego some of the bigger potential gains of one-person-one-reality and instead go for a lower risk approach with fewer 'shared realities' with significant overlap between themselves and where the discrepancies between the different realities which you crafted is just enough to yield some benefit for you but can also provide you the social support necessary to generate a certain level of authenticity if doubts arise surrounding some of your more creative money-maker narratives.
i'm no database expert, but from what i can tell: this is a spanner-like (clock synchronized) distributed synchronization mechanism for live, high volume event streams?
>The Problem with Lying is Keeping Track of All the Lies<p>Lie consistently. Lie in the same way. Keep using the same lies. Make an alternative story in your mind and connect all lies together so they are consistent and make sense. And practice a lot. Hard work beats talent.
This article is in the context of stream processing, which is a bit of a special case, but:<p>Whenever somebody is making a lot of hot air about consistency in their chosen SQL database, they tend to conveniently sweep under the rug how common it is to use read-only replicas that are fed by asynchronous replication and caches that are updated when the programmer remembers to / that use consistency-ignoring TTLs.
In the best possible scenario, a distributed DB can be as truthful as a single DB.<p>In the best possible scenario, a DB with snapshot isolation can be as truthful as a strictly serialisable DB.<p>In both those cases, your truth is at the whim of a programmer committing buggy code.<p>When I want truth, I write append-only events and fold my view over them. TFA tried to argue a point about eventual-consistency never settling, but that's how the world works. What's the final balance of your bank account?
Note to 6 out of the 7 commenters so far: this article is about distributed systems, not lying per se. I'm hoping this is not a bellwether of how many HN readers actually <i>read</i> the article.
The promise of lies is it allows the impossible. Mutually inconsistent ideas to coexist. You don’t have to track anything. You just lie again and again. That’s the beauty of it. If you start tracking everything, you may as well tell the truth and use your brain.