Thank you. This sounds like a great approach! I’ve also been surprised at the mechanical nature that git resolves conflicts in, and the loss of intent when auto-merging.
There were unusual elements characteristic of the decay chain following a fission.
After a U-235 atom undergoes fission, one of the outcomes is it releases Barium and Krypton (and some neutrons), which then eventually decay to stable/semi-stable elements. If one of those stable elements is common in the deposit but otherwise rare naturally, it would point to a nuclear reaction having occurred.
Also note that the U-235 decay chain generally looks different from the decay chain following a fission reaction of U-235.
Yeah, I would say the y-axis range on charts should be set at "3-sigma likelihood of observation" thresholds. Not everything that's charted can be framed as sampling from a distribution, but the principle of manually setting chart ranges would nonetheless still apply.
For instance, if we're charting someone's body temperature, we would likely fix our y-axis to 80-110.
An equivalent economic policy would be if Europe and India were both allowed to buy oil, but capped at India's current amount (let's say 20% of pre-war baseline). Perhaps this can be called a "fractional" embargo.
Is this really desirable? The pain of going from 80% embargoed to 100% is much greater for Russia than 0% to 20% -- a 100% would likely cripple the war. To be fair, not saying that was a card in play due to China, Iran, etc. But arguing it's good economic/diplomatic policy is unclear since it makes the embargo weaker
Perhaps set a timeout on the operation then? Given this is kernel it's not as easy as userspace, but I'm sure you could request to set a interrupt on a timer.
> Many code bases that I've worked on suffered from too much, and badly engineered, code - not from not having enough code.
Because the projects that weren't built fast enough were eventually thrown away, meaning they never require maintenance, which is the source of the sampling bias you are observing. I've seen it happen in some cases (engineer with the wrong personality leading an R&D project).
Heap sort can sort n elements with O(1) auxiliary data while quick sort (which is what libcxx usually relies on) in its worst-case performance would require storing O(n) stack frames. Since stack sizes are usually small, an adversary making you sort a million elements would likely cause a stack overflow.
Bing has generally made money for Microsoft. Search is just so valuable -- look at Google and how it built a whole conglomerate of loss leaders around it.
But then your LB is a single point of failure! Even if you were to spin up duplicate copies of the LB that could be failed-over-to in real time, there is still the drawback that you are bounded by the number of requests you can store on a single machine.
I think what you actually built is a message queue engine that forwards the data to the consumers, not a load balancer.
I speak a Slavic language spoken by ~2 million people, and I asked GPT-4 to tell me an old fable in my language. It did so fantastically, with no grammatical errors. I tried some more things -- it speaks it fluently, though admittedly not always idiomatically.