You know, it feels like some of that advice isn't entirely viable, though i support it on some level.

> * keep your phone longer. Brag about it. Find a persuasive way to _demand_ that apps, updates, etc... keep working. I don't know what difference 5 years vs 3 years do, though.

> * make fun of people who change their phone all the time. (Or for that matter, make fun of consumerism _in general_.) Assuming peer pressure stands a chance against advertising industry.

Currently i have an ulePhone Armor X7 Pro, a phone that i got because it was both affordable and relatively rugged (i've dropped it once on concrete while doing pull-ups, it didn't even have a scratch on it) as well as water/dust proof. Despite the fact that the battery is not removable (something that's an entirely different can of worms) or in a form factor that's hard to get aftermarket replacements for, it's suitable for most of my needs - probably one of the least bad choices i could have made with these constraints in mind.

That said, the kernel is from 2020, the Android security patches are from 2020 and Android 10 will hit its own EOL in a few years anyways. Not only does the software have planned obsolescence baked into it by the OS going out of support eventually, not only is it abandoned by the developers who aren't actively shipping patches, but it will also not be possible to install custom ROMs because of either the bootloaders being locked by default (which sometimes don't even have ways around this) or the drivers being oddly specific and half of the phone's functionality breaking with those, which i've experienced even back in Android 2.X days.

Of course, phones aren't the only problematic bits of software here: old hardware is basically killed due to insecure OSes like Windows XP, Windows 7 and others for certain goals like gaming (and no, Linux is not and will not be suitable for that on older hardware for numerous titles) or other pieces of software that have become increasingly bloated nowadays and require better/modern hardware to run.

Who knows, maybe we'll eventually even see x86 be retired completely, it's not like all of our software is backwards compatible even as we speak, many focusing on just x64 and not even testing their software on older architectures. Though perhaps that only applies to decades, not a few years, as far as time scales are concerned.

> * write efficient software ? (The joke is that anything that can be rewritten in Rust will be rewritten in Rust; but the jury is still out on whether the energy saved _running_ Rust code will offset the energy consumed _compiling_ it.)

> * write no software ? (especially if you're in the cat picture and fake news sharing business ?)

Maybe we should also think about how to limit what our current software can do, to prevent it from eating all of the system resources for whatever reason (it being written badly, having unreasonable demands for hardware because "RAM that's not used is wasted" and so on)?

For example, currently i run Docker Swarm on my homelab with containers, each of which has a resource limitation in place: none can use up more than 1 core of my CPU which consequently means that nothing can typically bring down the entire system by misbehaving.

I wish we'd easily be able to do the same for desktop software on all OSes, just set affinity to N core(s) by default for software that we don't want to give too much processing power and allow it to request more. Same for memory. Same for disk space. I am okay with offending packages working slowly, hitting the swap space or being OOM killed (or even them requesting more resources), i'm not okay with some software package thinking its owns my machine and slowing everything down.

In summary, however, i'll try to make my hardware and software last: Debian (community LTS)/Ubuntu LTS/Rocky Linux are all suitable for now, even on my homelab boxes with used 200GEs with just 35W TDP, and i guess my phone will also be okay until it's overcome by malware that will proceed to steal any and all of my data, should companies not get there first.