131–140 of 176 posts
Curious about the differences between content on aphyr.com/tags/jepsen and jepsen.io/analyses. I recently discovered aphyr.com and was excited about the potential insights!
Jepsen started as a personal blog series in nights and weekends; jepsen.io is when I started doing it professionally, about ten years ago.
Earlier quoted context omitted.
> Blockchains are still a scam Did you actually look at the blockchain nodes implementation as of 2025 and what's in the roadmap? Ethereum nodes/L2s with optimistic or zk-proofs are probably the most advanced distributed databases that actually work. (not talking about "coins" and stuff obviously, another debate)
> Ethereum nodes/L2s with optimistic or zk-proofs are probably the most advanced distributed databases that actually work. What are you comparing against? Aren't they slower, less convenient, and less available than, say, DynamoDB or Spanner, both of which have been in full-service, reliable operation since 2012?
https://github.com/williamstein/nats-bugs
For example, https://github.com/williamstein/nats-bugs/issues/5 links to a discussion I have with them about data loss, where they fundamentally don't understand that their incorrect defaults lead to data loss on the application side. It's weird. I got very deep into using NATS last year, and then realized the choices it makes for persistence are really surprising. Another horrible example if that server startup time…
https://github.com/nats-io/nats.rs/issues/1253#issuecomment-...
If you are looking for a serverless alternative to JetStream, check out https://s2.dev Pros: unlimited streams with the durability of object storage – JetStream can only do a few K topics Cons: no consumer groups yet, it's on the agenda
I understand that you need to make money. But you'll have to have a proper self-hosting offering with paid support as well before you're considered, at least by me.
I'm not looking to have even more stuff in the cloud.
NATS be trippin, no CAP.
https://github.com/nats-io/nats-server/discussions/3312#disc...
(I opened this discussion 2.5 years ago and get an email from github every once in a while ever since. I had given up hope TBH)
Earlier quoted context omitted.
certainly a narrative that is popular among the grey beard crowd, yes. in pretty much every field i've worked on, the opposite problem has been much much more common.
What fields? Cargo culting is annoying and definitely leads to suboptimal solutions and sometimes total misses, but I’ve rarely found that simply reading literature on a thorny topic prevents you from thinking outside the box. Most people I’ve seen work who were actually innovating (as in novel solutions and/or execution) understood the current SOTA of what they were working on inside and out.
I was engaged after one of the worlds biggest data leaks. The Security org was hyper worried about the cloud environment, which was in its infancy, despite the fact their data leak was from on-prem mainframe style system and they hadn't really improved their posture in any significant way despite spending £40m.
As an aside, I use NATs for some workloads where I've obviously spent low effort validating whether it's a great idea, and I'm pretty horrified with the report. (=
Earlier quoted context omitted.
> Blockchains are still a scam Did you actually look at the blockchain nodes implementation as of 2025 and what's in the roadmap? Ethereum nodes/L2s with optimistic or zk-proofs are probably the most advanced distributed databases that actually work. (not talking about "coins" and stuff obviously, another debate)
> Ethereum nodes/L2s with optimistic or zk-proofs are probably the most advanced distributed databases that actually work. What are you comparing against? Aren't they slower, less convenient, and less available than, say, DynamoDB or Spanner, both of which have been in full-service, reliable operation since 2012?
DynamoDB and Spanner are both great, but they're meant to be run by a single admin. It's a considerably simpler problem to solve.
Every time someone builds one of these things and skips over "overcomplicated theory", aphyr destroys them. At this point, I wonder if we could train an AI to look over a project's documentation, and predict whether it's likely to lose commmitted writes just based on the marketing / technical claims. We probably can.
You can have DeepWiki literally scan the source code and tell you: > 2. Delayed Sync Mode (Default) > In the default mode, writes are batched and marked with needSync = true for later synchronization filestore.go:7093-7097 . The actual sync happens during the next syncBlocks() execution. However, if you read DeepWiki's conclusion, it is far more optimistic than what Aphyr uncovered in real-world testing. > Durability…
Well, its an LLM ... of course its going to be optimistic. ;-)