> GrapheneOS recommendation to this was to have fewer apps
Sounds reasonable. People tend to install way too many apps on their phones and than blame the phone about short battery life or too many notifications.
What's so hard? A developer finds a bug, fixes it, publishes a new release at some point, done. Versus someone else finds a bug, maybe opens a CVE, bug gets fixed, maintainer might notice it, backports patch and fixes (or breaks) the package. The latter CVE case is the rare case, hence all the crashes. E.g. Busybox is famous for that. They have a plethora of security issues documented in their bug tracker. Sometimes they even get fixed but most of them never get a CVE, issues stay open and you can guess if it's vulnerable or not (usually it is, don't use it).
> It’s not horribly broken any more than your toaster is for not needing constant updates.
I don't know where this sense of "stable" in the community comes from. Software isn't perfect and gets fixed all the time. Yes, there are packages with different maintained stable branches that you can pin for your LTS distribution but this is by far the minority. For the other stuff you constantly have to work around missing features or existing bugs. E.g., why do I have to compile "jq" by myself just because the outdated package crashes on certain inputs?!
> Depending on the particular distro, only certain core packages are likely to get updates on LTS releases.
All LTS distros fix only some core packages sporadically as no one is able to back port all the patches esp. since most packages do not use CVEs and just fix bugs on the go. "Stable" for non-rolling distributions simply means "horribly broken and outdated".
Oh dear, that reminds me of one of my courses I had to take where we had to memorise the WAM and execute it on paper in the exam. Most useless course ever.
I'm not sure what C/C++ compilers you have in mind but bootstrapping older GCC and LLVM versions on modern systems is far from trivial and typically requires patching (e.g. older LLVM versions do not compile with modern compilers) and pinning a whole ecosystem (cmake, C lib, autotools, ...). The same is true for the other way around, modern C compilers usually do not compile on older systems and you get lucky if you find a round trip of several versions that get you a roughly working compiler at some point.
Same for me, also the "screen" size is off (just shows window size), the location is off by hundreds of kilometres and other information is quite generic (battery level "kept back", small set of standard fonts available...).
I can recommend "The song of the cell" as a starting point. If you prefer textbooks, maybe "Life: The Science of Biology". I have a translated non-english copy and besides some math issues it's a nice overview, but I'm not a biologist.