LLMs are us (me certainly) at our worst. I'm an LLM when I become annoyed with a problem, refuse to engage with it in earnest and just want to get it over with. I'm an LLM when I give the first answer to a non-obvious question that pops into my mind.

People say that AI-produced stuff is uninspired, generic and soulless, but this year's Grammys were a great illustration of how we don't need GenAI for this to happen, shallow consumerism is enough.

Is it possible to show that LLMs can't reason? It's easy to show that they can't reason the way we do, but hypothetically it might be possible to somehow couple its "semantics" coherently. Unless this is you however, you really should shut up about LLM intelligence though.

How to mitigate latency in a deterministic system. This is an almost entirely novel concept which has very little literature supporting it.

Gemini does a great job at summarising our paper

LLMs automated design patterns, that is: stochastic pattern-matching on signals without any consideration for semantics. Neither of them ever really worked, but both look like they do at first glance and since people don't like to think about semantics, they both took root

I'm reading @markburgessosl.bsky.social draft paper on attention in AI. Some 🤯: - LLMs are slow because of the incredibly wide context when evaluating, so that's also a boundary problem - Boundaries are the same as a rejection of a violation of an autonomy, so semantics are agentic

If you want to issue stablecoins as defined by the GENIUS Act, you need to buy treasuries in equal amount. I wonder if its goal is to bring US debt back on-shore. It's amazing how the status quo is held up by the Two Generals' Problem and how that's mostly a misunderstanding.

All clocks are wrong but some are useful. 🧵

Can someone explain to me why CAP was adopted into the canon based on a paper, but Paxos required Chubby to even be noticed?

The problem of state-management is that processes are allowed to make decisions. We project free will. It's a kind of anthropomorphisation. In fact, all their "free will" is just a byproduct of their incidental entanglement, ie: unforeseen causal relationships between them.

Whatever you might think about LLMs, it's matter of fact that they are tools of cargo-culting, meaning that they imitate the external signals without understanding the internals. How that is not considered a problem is beyond me.

If you believe the conclusions of CAP apply to all distributed systems, you believe that there's no way to not have the occasional latency spike or even node isolation event happen to your service, unless you have an incredibly well tuned network. Our next project disproves this

LLMs and Tesla's FSD are the same problem. Both can only succeed if they can consistently apply meaning and reason about it. A bush with feet is a human carrying a plant. Now do this with orders of magnitude more complexity and you see the problem. Probabilism won't save you

We're planning a new kind of service, one everyone thought impossible because of CAP, that should fix most distributed systems problems in a very simple way. If you have control-plane problems or service-integration issues, send me a DM or reply here and I'll get in touch.

I did find it amazing at the start, (but got used to by now) is how nobody refutes our innovation at its substance. People who take the time to understand it (without exception) also accept even our wildest claims. Few actually care about truth if it contradicts their beliefs

A thread about why pessimistic systems are bad at scaling.

Andras Gerlits@omniledger.io · 9mo ago

Let's analyse Spanner using the model explained here. Spanner relies on pessimistic locks, so we first need to ask the question of what it is in a distributed system. Simple: a pessimistic lock is an optimistically written record, sometimes on a remote node.

Let's analyse Spanner using the model explained here. Spanner relies on pessimistic locks, so we first need to ask the question of what it is in a distributed system. Simple: a pessimistic lock is an optimistically written record, sometimes on a remote node.

Andras Gerlits@omniledger.io · 9mo ago

Let's first reformulate Linearizability to mean that time-order should never contradict any process's observed order of events. This will help us in mapping out the ultimate limits of our semantics in space. So: clocks at different distances, measured in ms (communication time)

My goal with these threads is to outline the minimal semantics of distributed consistency in a generally accessible format. I think these questions have been mostly ignored for decades, which is a shame, since they can lead to practical results. In the last one, we'll tackle CAP

Andras Gerlits@omniledger.io · 9mo ago

Let's first reformulate Linearizability to mean that time-order should never contradict any process's observed order of events. This will help us in mapping out the ultimate limits of our semantics in space. So: clocks at different distances, measured in ms (communication time)

Let's first reformulate Linearizability to mean that time-order should never contradict any process's observed order of events. This will help us in mapping out the ultimate limits of our semantics in space. So: clocks at different distances, measured in ms (communication time)

So, when is the industry going to be ready to talk about decentralisation? I mean, you can argue that CloudFlare engineers know what they're doing, but that also means that this problem is too complex to be solved centrally.

There's a great interview with Leslie Lamport, in which he makes the point that any time-ordered system will contradict the observed (causal) order of events as seen by different processes in different places. He's clearly right about this, except for his conclusion.

Time is experiencing changes. In distributed systems, we focus on composing these changes eagerly into a unified view for any potential observer. This eagerness is the bottleneck. If you just lazily calculate each observer's current view, the known problems just don't apply.

The basic facts of physics tells us why distributing systems is hard. It's because different time-coordination systems move at different speeds. The only logical conclusion here is that these need to be calibrated to each other if we want to establish order between them.

Second outage in two weeks. I guess it's time to be educated about how nobody could do better than be down for half a day again.

The AWS outage has nominally happened because of DNS, but the root cause is that we centralise data-collection and management. If data was delivered to observers from multiple sources (with a shared timeline), central outages cannot happen. Not all reactors are Chernobyl

The consensus in IT that cloud providers failing centrally is still the best of all possible worlds is not only self-serving but also false. It leads to clients not asking questions so everything staying the same. I think the reason developers excuse this is because 1/x

People offload to cloud-providers, not because that is the technically superior thing to do, but for the same reason they hire McKinsey, to shift blame from themselves.

I love how absolute science is. It's the only area where you can be unapologetically certain about being right even if everyone else is telling you that you're wrong.

Wrt today's failure: There were two things that surprised me very much after I started working in software innovation. The first was how receptive academia was to new ideas. I'm very proud of the fact that so many took the time to understand how we solved the fundamental 1/x