mprime1
Joined 6 years ago
Joined 6 years ago
Here’s something similar-ish but using symmetric encryption (i.e. password):
I had the foolish idea of installing a Tesla charger at home to charge my Bolt. I’ve been unable to ever use it.
The wall charger works fine with Teslas. My car and adapter charge fine at Tesla superchargers.
But the home Tesla charger refuses to charge my Bolt. (Yes I disabled vehicle restrictions and tried all sorts of combinations of settings for weeks before giving up. Tesla support was useless of course)
Restriction or bug, same difference.
That's the NATS Go _client_.
The server project is https://github.com/nats-io/nats-server 17k stars, 1.5k forks, 160 contributors
IANAP but here’s my understanding.
At the end of the month you spent $2000, you’re not sure how so you track down your expenses:
- rent $500
- groceries $120
- gas $80
- …
- unknown: $123
That ‘unknown’ is dark matter. It’s a placeholder. It’s there and makes your total but you can’t explain it yet.(Russia is really good at weaponizing memes but I don’t meant to single it out, the US has also been very successfully influencing the same country for decades via Hollywood movies for example)
- There is someone else that is better at X than you are
- The person not so good at X is probably better than you at YParent was asking about deduping encrypted data.
Someone said (wrongly) it’s impossible and I shared a popular project that does exactly that.
My bookmark archive is 10TB but deduped on-disk size is 100GB because most files are the same across backups!
Water treatment is powered by the geyser and in turn the leftover brown water feeds the geyser.
Pretty neat (for sewage)!
Process 1 receives: 3:00 [1] "P1 is leader" 3:01 [2] "P2 is leader"
Process 2 receives: 3:00 [1] "P1 is leader" 4:00 [2] "P2 is leader"
This is perfectly valid Atomic Broadcast. Order is maintained.
However from 3:01 to 4:00PM you have 2 leaders (or 2 processes holding the lock).
Don't use ABCast to do locking / leader election for your "user-space" application!
Rounding down 'usually works' to 'it's not perfect and we need to handle edge cases' is how you build dependable systems.
Your first comment seemed very much in the first camp to me.
When programmers think of locks, they think of something that can be used to guarantee mutual exclusion.
Distributed locks have edge cases where mutual exclusion is violated.
Implementation does not matter.
e.g. imagine someone shows you a design for a perpetual motion machine. You don't need to know the details to know it doesn't work! It would violate the laws of physics!
Similarly, anyone telling you they created an implementation of a distributed lock that is safe, is claiming their system breaks the laws of information theory.
"Distributed locks" are at best contention-reduction mechanisms. i.e. they can keep multiple processes from piling up and slowing each other down.
[Some] Paxos for example use leader election to streamline the protocol and achieve high throughput. But Paxos safety does NOT depend on it. If there are multiple leaders active (which will inevitably happen), the protocol still guarantees its safety properties.