> Following this logic we should then add standard libraries and the whole os into account.

I realise you're being snarky but systems and verification schemas like that do exist. The terms I most often associate with them is "high-assurance" or "critical supply chain" software. There's bound to be many others.

These requirements crop up in stuff like the firmware for ATM keypad. Or Google's source code (they vendor everything in their own trees). Or Vegas slot machines.

In an amusing twist, software supply chain assurance is such a massive problem that large security consultancies offer code escrow services. If you, as a software seller, can't guarantee that you'll be around 20 years down the line, the buyer can require you to submit your code to such a third-party service. Should you go out of business, the source code will remain accessible to the buyer for their future development needs.

I honestly wish people did do this for these sorts of posts because it opens up a lot of solution space and would lead to interesting optimizations along the entire stack. The boundaries between all levels fade, the pieces ready for creative recombination.

All that other code needs maintainers. Is it really that interesting to say "look how much I can punt to others?"

It's not as if anyone except the authors will use these micro libs, we might as well encourage metrics that produce interesting ones.

I wasn't so much disagreeing with the number, as much as it being the tag line.

Excluding ansible/chef recipe to manage the machine, I could deploy Redis and have no lines of code to maintain.