

Dude, you need to figure out a way to automate that. It’s no way to live.


Dude, you need to figure out a way to automate that. It’s no way to live.


Make no mistake: this is an improvement.
There are substantial unsolvable issues with long lived certificates, and automatic deployment of very short lived certificates is the way to solve them.
Plan for certificate validity of six days in a few years.


YES! Keep cutting it down!
Revocation is a lost cause and if you don’t automate you deserve what you get.

I love it how basically your only retort is “but we think really hard about it and are very careful”. Which is exactly what I just said.

That’s grade A horse cap.
The only tool we have to guarantee the software works according to the specification is formal verification, and formal methods are a PAIN to use and are extremely limited in scope.
For the rest, the best we can do is “hope you thought of everything” (aka manual and automated testing) and “have a colleague look it over” (aka code reviews).
And that does not even start to tackle the issue that is making sure the spec solves the problem in the first place.
Yes, all the other things you mention are true too. But you were set up for failure from the start by the gods of intractable complexity first.

The main issue is that software quality was generally pretty dodgy to start off with. There just isn’t any headroom to trade off.
We’re just don’t know how to reliably write reliable software. We have developed practices to cover risks we deem unacceptable, but things like the halting problem make software verification fundamentally an intractable problem.


An important part of the effort is culture and esthetics. “ICE SUCKS DONKEY BALLS AND YOU SHOULD AVOID THEM LIKE THE PLAGUE INFESTED RAT FASCISTS THEY ARE” is a message worth amplifying, even if the tool to actually do the avoidance is flawed.
Yes, it’s theater. But theater is praxis too.
I picked up timberborn again to check out the changes in the 1.0-experimental versions. I love playing this game.