Which is the problem if you don't want to spend your days troubleshooting BS problems.
Much of the movement is for no good reason at all.
There seem to be this sentiment that maintainers owe the users nothing, but also the opposite is true.
There is no reason to give the maintainer some special status concerning "his" code.
It’s something the maintainer made and licensed in such a way that you can use it for free. The special status concerning “his” code is that it generally is in fact “his” (or her) property.
If you don’t like it you’re free in most cases to fork it and suit yourself.
Either way, it still doesn’t change the fact that there are going to be upstream bugs and vulnerabilities that remain unpatched if you’re trying to keep something frozen for 15 years.
Have you asked yourself why this is the case and why it should be the default accepted case?
> Is that a better idea than keeping up-to-date with a rolling 24/36/48 month release cycle?
There are plenty of devices out there that exist for longer than 2 or 4 years. And those "rolling upgrades", how are you going to deal with "we're dropping 32-bit support"? Or "we're dropping support for CPUs that don't support certain features". Or a hundred other deprecations and the inevitable increase in bloat of software?
Ah, but occasionally you do need something new. Well, in most cases, the LTS support won’t help you - because they just fix bugs, but do not e.g. provide TLS 1.3 to replace the aging OpenSSL 0.96 which barely supports SSLv2.
Additionally, do you have LTS hardware replacement for 15 year old hardware running Linux? Iirc Dell, HP and friends only provide a 5 yr guarantee - and that guarantee is “we’ll give you a new machine if we don’t have replacement parts” which you also have with Linux (just install the latest)
Even then, I think 15 years of support for a Linux distribution is a bad idea anyway - software just moves way faster than that. How supported is that release really going to be after 14 years, even with the best of effort?
Is every upstream package going to be version compatible with a 15 year old release with no breaking changes? And if it's not, and you patch around that or freeze those packages, is your software still "supported"? What if there are unpatched critical issues? Is that a better idea than keeping up-to-date with a rolling 24/36/48 month release cycle?
In the analogy of a roof or a basic appliance that's fine, but the long-term support equivalent of that is have a copy of the software on a couple of USB drives and disconnect the machine from the internet completely. As long as you don't do anything novel with it, it'll probably work for decades. There are still Windows 3.1 terminals in the wild somewhere.