> It doesn't mmatter if there are security updates, some people have the updates == bad mentality. I think that this point of view is an unfortunate reality du

> It doesn't mmatter if there are security updates, some people have the updates == bad mentality. I think that this point of view is an unfortunate reality due to the world that we live in. Everyone would like security updates, but only as long as they're guaranteed not to actually break anything else. I've had regular Debian updates break GRUB and prevent a server from rebooting: https://blog.kronis.dev/everything%20is%20broken/debian-and-grub-are-broken https://blog.kronis.dev/everything%20is%20broken/debian-and-... (admittedly, i think i had the full unattended upgrades enabled, not just the security ones, but that's still a pretty catastrophic failure) Similarly, when i finally wanted to upgrade my install of GitLab to a newer version, it also failed spectacularly rendering the whole instance inoperable: https://blog.kronis.dev/everything%20is%20broken/gitlab-updates-are-broken https://blog.kronis.dev/everything%20is%20broken/gitlab-upda... (there is no option to get "just" the security updates, you need a new major version once the old one is EOL) I actually did a writeup since, where i migrated over to Gitea, Nexus and Drone, because even if future updates will break them, the scope will be much more manageable: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... My takeaway there was pretty similar to what you're alluding to: > Also, something else that i just now realized was that my GitLab instance was so out of date, because updating it was a painful process - the data directories that i'd need to manually back up (in addition to automated backups which are done every other day) before an update would take a lot of space, the container images are large and download slowly, the changelogs are long and configuration changes plentiful (the Unicorn to Puma migration comes to mind) and as my other post shows, a lot can go wrong and it be a very frustrating process. > In short: if you want your users to update more often and stay safe, make updating an easier and less scary process. Of course, in the case of GitLab, i don't think that's something that's necessarily easy to do, since their Omnibus install is about as close as you can get to that, but even that had problems, at least in my particular case. Sometimes you just need an alternative or a few other pieces of software to do more or less the same thing, and that's okay. I've actually written about the difficulties with updates and how problematic they become when running a non-trivial amount of software before as well, in a slightly tongue in cheek manner: https://blog.kronis.dev/articles/never-update-anything https://blog.kronis.dev/articles/never-update-anything Apologies if that's quite a few links, it's just that i think that you're offering only a part of the argument and it should be expanded to better reflect the reality for some people. Updates are feared because in practice they absolutely do bring problems and you cannot expect that ahead of time and will have to deal with it sooner or later, so not only do you need to evaluate how to upgrade everything (including configuration and other possibly breaking changes), but also have your backups and failover systems ready ahead of time. With how much software out there doesn't have proper test or staging environments and how often it's not easy to spin up a new environment, it's completely understandable that people are going to hold out for as long as they can, which leads to some pretty bad situations in practice. Of course, the need for any sort of a SLA and uptime only makes this much worse.