And in 2005, if the Apple Calculator had leaked arbitrary amounts of memory... it just would have been a bug report in a queue. Because it's just a little utility, not an emergency.
He inadvertently disproves his own thesis by linking to the Spotify bug. It's from 2020, when his chart was still in the green, though it's likely there are multiple different memory leak bugs discussed in the thread.
It's true that in the much-further distant past there were fewer bugs of this nature. Or at least fewer that made it to production. That's partly because when you have 64K of memory and no memory protection, these bugs become very apparent very quickly. And partly because software was operating in a much simpler environment -- one application running at a time, not much of an OS at all. There were still plenty of bugs though!
Most of his examples don't support his thesis at all
Todayâ(TM)s real chain: React â' Electron â' Chromium â' Docker â' Kubernetes â' VM â' managed DB â' API gateways.
Each layer adds âoeonly 20â"30%.â Compound a handful and youâ(TM)re at 2â"6Ã-- overhead for the same behavior.
That's how a Calculator ends up leaking 32GB. Not because someone wanted it toâ"but because nobody noticed the cumulative cost until users started complaining.
Apple Calculator uses exactly none of those.
Then he talks about AI models and software inefficiency. No; AI uses a lot of power but it's highly optimized. Because unlike a Calculator utility people care a LOT about the efficiency of AI training and inference.
He's noted a real problem (that a lot of people also have) but his detailed diagnoses are nonsense, and therefore his solutions are unlikely to work.