> 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.
Having many apps will not affect battery life on Android in any meaningful way. Actively using them will. Apps can't just sit there and run in background, unless you explicitly gave them that permission.
Android also takes permissions away from apps after they haven't been used in a while anyway.
So most of the battery consumption will be from the apps that you actively need and use. Android's battery usage screen backs this up.
The metro app I installed when I was on a trip in Istanbul is still on my phone, but it's dormant. Yes, I should definitely uninstall it, but I really can't be bothered to do this all the time. On stock Android, phone takes care of this for me. On GrapheneOS, either I take that responsibility or face the consequences - which I don't really want.
> 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".
It’s not horribly broken any more than your toaster is for not needing constant updates. Though I do have such a longstanding love/hate relationship with Ubuntu because of this. It is why it runs everywhere and just works (even powers the WSL2 defaults), but everything it provides also always so very far behind I end up recompiling so much important stuff by hand.
> 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?!
The "outdated" package, probably has all these security fixes [0]. That's why it exists - to maintain something safely. You step back from latest and greatest, to not get a compromised system the next time something goes wrong.
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).
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.
Nope, I have tried. Just as suspicious to them if not moreso because it's a datacenter IP and not residential. I even have a list of sites I've tried to visit that were explicitly blocked from datacenter IPs, and that file has over a hundred hosts in it now.
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...).
Bootstrapping a modern/ up-to-date C/C++ compiler works, getting an up-do-date Python onto the system works too. No such issues with either of those. But try the same with Go or Rust and you hit nasty roadblocks (in both cases the older OS was previously supported just fine.)
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.
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.
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.
reply