Weirdly this reminds me of the Raft consensus protocol: two nodes cancel each other when failing consensus as you can't tell which is the valid one, three gives you better chances, if one fails you have the other two that can get consensus. Of course in the off chance you have two failures you cannot get consensus with the only living node. Adding another two nodes make you robust to two failures.

Now replace fail with lying and you have the exact same problem.

though why treat booleans as special case and keep timestamps for them when you don’t for integers with this pattern:

isDarkTheme: {timestamped} paginationItems: 50

I can see when dark theme was activated but not when pagination was set to 50.

also, i can’t see when dark theme is being deactivated either.

seems like a poor-man changelog. there maybe use cases for it but i can’t think of anything tbh.

this. Let’s not confuse meanings. There are multiple ways to improve quality of code. Testing is one, code review is another. this belongs to the latter

I'm located in Barcelona, and yesterday lot of transactions on mini markets / pharmacies were not possible because the item prices were unknown, adding to the fact there was no phone lines available to reach out.

This reminds me of https://news.ycombinator.com/item?id=42342382 on the blog https://eieio.games/blog/writing-down-every-uuid/ they mention how they tackled various challenges such as rendering.

seems to me a survival bias.

That's because by definition it is not going to be "major" problem since the unit test acted as gateway before it got pushed to production, instead you'll probably be 'meh' and fix it once the unit test fails.

This reminds me the saying of a manager arguing why do we need so many SREs since the system is working fine.

I’ve actually talked with ChatGPT and asked it both to output mairmaid diagrams of discussed architecture (context was kubernetes clusters, namespaces and Pods) and also read diagrams and convert them correctly to kubectl commands to build the diagram.

That would be a great, and terrifying at the same time, first contact response message to us.

proof-of-superiority if you will.

I had an understanding that quantum entanglement can be used to for encryption and guaranty there are no man-in-the-middle attacks by making sure the entanglement is not broken. if we can’t know the collapse happened how can we make such claim (mitm can meassure stolen briefcase put it back and no one would know)

This is incorrect. Quantum key distribution ("quantum cryptography" is a misnomer) is vulnerable to man-in-the-middle attacks. Security relies on having a pre-shared key which makes it essentially useless in practice (just use AES if you have a PSK).

AES 256 only requires millions of qubits to crack. What do we do once we think that's attainable behind close doors? It'd be better to be prepared.

https://www.fierceelectronics.com/electronics/aes-256-joins-...

This is a wildly optimistic estimate. Even if we had an error corrected quantum computer that could evaluate an AES key (complete science fiction for the forseeable future), running Grover's algorithm would take millenia assuming extremely fast gate times (1 ps).

In any case, doubling the key length would be infinitely simpler than using QKD.