Except for the winter of 2022 when more than half of French reactors were not running, which was especially critical because of the Russian War against the Ukraine. Coal reactors had to be reactivated in Germany so lights didn't turn off in France.
Or summer when reactors have to be shut down because the rivers are too hot or running low.
So many reactors off was a special event of delayed maintenance, things are done so that does not usually happens.
And it's not true to say that Germany reactivated coal reactors for French lights.
Germany activated coal to reduce dependance on gas, and Germany exported energy to France because of the maintainances ; you know, the old correlation =/= causation.
That one occurence over 4 decades, I would say we can dare to call it pretty reliable
Would you tell a human that just tried doing an illegal move that they did "a really good job of playing chess"? The probability for such mistakes is greatly reduced but still far from negligible, which proves the point that guardrails are needed.
One advantage of percentages is that you can multiply them if the outages aren't related. If you rely on 10 systems with a 99% uptime each you end up with roughly 90% uptime in total.
After a merger we ended up with 2 operations systems and one of them thought the other one were clowns. But they thought everyone were clowns so it was hard for the rest of us to tell. They never actually apologized for being assholes, but their tune changed when they found they had bitten off more than they could chew later and they had to come hat in hand to a bunch of groups to delegate responsibilities back to them.
So a production outage happens, and we go to look at our runbooks to figure out what to do. The Wiki is also down, so no runbooks. What the actual fuck?
So it turns out the alleged clowns put all of our internal infrastructure onto the same SAN system in different partitions. They got a lot less judgy and the other Ops team got a lot more autonomy after that event.
Anyone with an Operational IQ above room temperature knows that you don't put offline and online resources onto the same hardware. Not only do they have separate duty cycles but also offline services can end up taking out the online services in unexpected ways, in part because they are assumed to be a bit sloppy and so they get less operational scrutiny.
I sped up the average runtime of a batch job by quite a humongous amount by throttling the request rate we made to a service that was used by user-facing services. If several unrelated batch jobs kicked off during the wrong time of day, we would start getting circuit breakers opening everywhere, including occasionally production.
I throttled us to use something like 8 or 10% of the official capacity of the service and no more. But I did it as limiting the number of in-flight requests, so that created back pressure if the servers were under heavy load and sending responses slowly, or let us go faster if the servers were returning results faster than usual. That peak shaving saved the other team a load of grief and let them push some capacity planning work down the roadmap to work on other things. And it dropped our failure rate by more than a factor of six. Low enough that we no longer had to babysit that process, which meant we started using it much, much more.
You need to get a critical mass of people to despise war so much that they are ready to have disadvantages themselves to make a war free world a reality. E.g. complete stop of trade with countries starting a war or supporting such a country.
It happened before relatively successful with slavery and is partially happening with the death penalty. For me it seems like a very long way to go though.
In which case, any country willing to fund a military and start a war would dominate the world.
Slavery and the death penalty are poor analogies, and not just because slavery was stopped through quite a bit of violence, and the death penalty/imprisonment exists as an alternative to vigilante justice only by virtue of the state's monopoly on violence.
"If everyone just ..." is always silly, but it's especially silly when it comes to the belief that order can be enforced through anything other than -- ultimately -- the threat of violence. Everyone will not "just".
So, you're saying that this requires all people of the world get along and agree with anything that might cause war? That sounds like a reasonable plan! Thanks for the response.
That is not what I'm saying. There can be a lot of disagreement about a lot of things but there needs to be widespread agreement to not start wars and to use strong non-war mechanisms to stop war mongers. I know that it is far off from where we are today, but it is not impossible like needing everyone to agree with everything.
LLMs certainly can interpolate between information found in its training set vastly faster than humans can find similar code on GitHub and stack overflow (or in math papers). It's certainly a tool that can be used when programming.
On the other hand also calculators help solve problems people have struggled with for millennia. It also doesn't mean that the end result is better than by hand. It's actually not, and that's the reason why you cannot replace programmers, because you need them to steer the LLMs for a good outcome.
And even the answer to the question, if LLMs make us more productive as programmers long-term is not really clear
The code is not better than an imaginary human paid to work on this as long as they wanted. But said human and sponsor did not seem to exist.
If not for LLMs this type of hardening would not be possible for me to justify at a startup, and I would have had to sigh and accept the huge attack surface of systemd.
I am a security engineer and there are unlimited things to harden, so LLMs let us harden a lot more in the same very limited time.
> that's only going to happen if splashed urine is the determining factor in how frequently a bathroom gets cleaned
If you believe in the broken windows theory, there's not one determining factor: Splashes of urine make the bathroom look dirtier and lead to people not taking care of the bathroom properly.
Some already developed even earlier and most ideas were already there in the 80s. The problem was just that the field was growing so fast that it was filled with people without formal training or fresh out of university. That way the knowledge did not spread.
For instance the 1986 paper „no silver bullet“ already described the need for iterative approaches later described as agile.
reply