There is a fundraiser for his family here: https://www.gofundme.com/f/honor-mikeal-rogers-by-supporting...

The word “just” in your comment disgusts me

Real innovators can’t stand this sort of noise and so it is a direct shot against their bow

The real judge will be survivorship bias and as a betting man, I might think product owners are the ones with the entrepreneurial spirit to make it to the other side.

Love your perspective. It reminds me of this argument I’m working on about Turing machine qualia. Maybe my argument is just Searle in disguise? https://x.com/jchris/status/1815379571736551923?s=46&t=8A60w...

This has always felt to me like evidence of a sort of computationalism. I am not a computationalist, but the thought is the "universal CPU" needs cycles for each particle. Mass is what takes time to process, so the voids experience no/less computational delay. This reads like the simulation author is messy and constrained, not godlike.

I came here to say the same thing. When you’re selling cloud services, the hardest thing to do is segment your customers by willingness to pay.

Cross AZ traffic is exactly the sort of thing companies with budgets need, that small projects don’t.

I had the pleasure of reading Montaigne before blogs were invented.

When I started reading blogs, the format reminded me of his essays.

I’m impressed by how easy it was, for someone new to all parts of the stack.

I agree MCP isn’t a big change, but that is a good thing. It’s more about making the implicit interface into something portable and reusable.

Most posix commands aren’t impressive in their own right, it’s the composability that gives them power. MCP plus data sync is similar.

This is just the first step in a bunch of cool stuff you can do. Now that the data is in a syncing database you can have models across multiple vendors and backends all working with the data locally while collaborating on changes. This means you can use the right model for the job without worrying about tracking where the data needs to go, instead each model can react to the appropriate fields and update types.

This is a super simple codebase so if you fork it and make something real, please share it with us.

Thanks y'all -- feedback taken. If I were saying it again I'd say something like:

Merkle proofs are rad b/c they build causal consistency into the protocol. But there are lots of ways to find agreement about the latest operation in distributed systems. I've built an engine using deterministic merge -- if anyone wants to help with lowest common ancestor algorithms it's all Apache/MIT.

While deterministic merge with an immutable storage medium is compelling, it doesn't solve the finality problem -- when is an offline peer too out-of-date to reconcile? This mirrors the transaction problem -- we all need to agree. This brings the question I'm curious about to the forefront: can a Merkle CRDT use a Calvin/Raft-like agreement protocol to provide strong finality guarantees and the ability to commit snapshots globally?

Apologies for the noise.