Kinrany

3) their big model has too many alignment issues

This implies that normally models are aligned and there is merely a number of issues to fix.

Paper records burn great and are harder to store in multiple locations

From my understanding (and I never seriously considered cryonics) all patients know very well that the likelihood of recovery is very low. Just not zero.

https://en.wikipedia.org/wiki/Larry_Johnson_(author)

From this description, the main controversy is the allegation of hastening the death of the patient. Not sure where's the scam though.

Sure, but it's better to do no domain modelling than to pretend doing it.

The solution might be to move to separate Postgres boxes everything that needs performance tuning at all.

I'm not in the "use Postgres for everything" camp, but only because I think it's too complex to be used like that. It should be replaced with a bunch of simple primitives in this role. No SQL and query planning magic please.

I'd rather take a mess of ad-hoc interfaces. Forcing people to do domain modeling does not go well.

Ignoring the singleton for now, because I don't quite see the need.

What's the alternative? Which part of this is actually caused by OOP? If you want to isolate IO, which you should, then you need to inject things that do IO and you need to specify a contract for them. And then it's nice to instantiate things or call functions without explicitly instantiating the whole tree of their dependencies.

I dislike OOP as much as the next HN commenter, but dependency injection tools are good in principle. OOP just uses them much more and for bad reasons.

I think that's unfair because most people won't run their own relays any time soon, but rather rely on a local enthusiast.

Dig tunnels under the broken roads, then remove the ceiling

Man, why'd they have to make it whitespace-sensitive.

That would make the model useless

...that's what I'm asking :)

From the same pricing page, it's all additional services: observability, relay hosting, support engineers.

I wonder if Iroh and Zenoh could/should be used together.

The fundamental component of Iroh is p2p routing by key, and the main utility provided by Zenoh is message semantics. The two seem complementary.

All of this makes perfect sense

You can have a copy of your emails for offline use in your browser.

Less so as a reliable backup.

Websites can work offline

A web UI can do that

More like implode proprietary blog hosting platforms and replace them with commodity VMs that can be used for blog hosting, among other things

So surely they volunteered it?

Books make the most sense as a guide, not a tutorial or a reference

How did the diary end up in the court files in the first place?

Why did you leave?

You can implement your own event loop within a single thread

One unique core concept per tenant, because the SaaS is nominally multi-tenant but it's really N unrelated websites for N enterprise customers in a trenchcoat

If you can solve the same problem in a simpler way without using k8s, that means k8s is not a zero cost abstraction.

It's not obligated to be, but it's also obvious why people would want it to be.

And it doesn't actually prevent concurrency.

In modern terms, it's marketing slop. It is what ChatGPT could have created at the time if it was asked to select a bunch of "best practices" and form a punchy acronym out of them.

There's no system, it's five rules selected at random.

Worse, their usefulness varies from hopelessly vague through trivial to actively confusing.