Bad take - the actual problem is that there was a trusted network in the first place. This kind of network access control is trivial to bypass, and trusted devices can get compromised.
8,865 karma · joined May 17, 2016
Bad take - the actual problem is that there was a trusted network in the first place. This kind of network access control is trivial to bypass, and trusted devices can get compromised.
Something like Restate actually implements distributed transactions.
GitHub's PR review workflow is archaic in comparison, especially now that every page takes 2-3 seconds to load.
There are some variations, but this is generally the same with all open source projects which live in their internal monorepo, such as gVisor or Bazel.
I don't think it mentions sharing the data with third parties such as Anthropic?
They're closely related, ECC and RSA are both instances of the hidden subgroup problem.
You can't, but given that it's a previously unsolved problem, it doesn't seem relevant? (nor are the author's potential biases - the claims are easily verified independently)
Any tips?
There are lots of people who are very fond of Gerrit, and if anything, upstream development has picked up recently. Google has an increasing amount of production code that lives outside of their monorepo, and all of those teams use Gerrit. They have a few internal plugins, but most improvements are released as part of the upstream project.
My company has been using it for years, it's a big and sustained productivity win once everyone is past the learning curve.
Gerritforge[0] offers commercial support and runs a very stable public instance, GerritHub. I'm not affiliated with them and not a customer, but I talk to them a lot on the Gerrit Discord server and they're awesome.
> If your network is down, your clients can't connect DB too, and nothing works
This sounds simple, but can only be achieved with high certainty using distributed consensus.
That might be great for accessibility, though.
Clearly, it's possible to reduce the risk to the point where many companies are willing to accept it, but it's still a problem and comes with high operational costs. And for some use cases (like finance), even a small risk of undefined database behavior or lost writes is unacceptable.
The future are distributed databases with consensus, and unfortunately, Postgres isn't there yet.
Same with MySQL and many other "traditional" databases. It tends to work out because these failures are rare and you can get pretty close with external leader election and fencing, but Postgres is NOT easy (likely impossible) to operate as a CP system according to the CAP theorem.
There are various attempts at fixing this (Yugabyte, Neon, Cockroach, TiDB, ...) which all come with various downsides.
[1]: Someone tried it with Patroni and failed miserably, https://www.binwang.me/2024-12-02-PostgreSQL-High-Availabili...
This is very hard to fix and requires significant architectural changes (like Yugabyte or Neon have done).
They have coexisted with humans just fine over the past couple years.