Why do you need to clean your house every week/couple of weeks ?
Why not clean only once a year ?
Keeping your infrastructure/code somehow uptodate ensures:
- each time you have to upgrade, this is not a big deal
- you have less breaking changes at each iteration, thus less work to do
- when you must upgrade for some reasons, the step is, again, not so big
- you are sure you own the infrastructure. That current people owns it (versus people who left the company 8 years ago)
- you benefits from innovation (yes, there is) and/or performance improvements (yes, there is)
Keeping your stuff rotting in a dark room brings nothing good
Why not think of it a different way; why do we need to put up with breaking changes at all?
I'd much rather stand up a replacement system adjacent to the current one, and then switch over, than run the headache of debugging breaking changes every single release.
To me, this is the difference between an update and an upgrade. An update just fixes things that are broken. And upgrade adds/removes/changes features from how they were before.
I'm all for keeping things up to date. And software vendors should support that as much as possible. But forcing me to deal with a new set of challenges every few weeks is ridiculous.
This idea of rapid releases with continuous development is great when that's the fundamental point of the product. But stability is a feature too, and a far more important one in my opinion. I'd much rather a stable platform to build upon, than a rickety one that keeps changing shape every other week that I need to figure out what changed and how that impacts my system, because it means I can spend all of my time _using_ the platform rather than fixing it.
This is why bleeding edge releases exist. For people who want the latest and greatest, and are willing to deal with the instability issues and want to help find and squash bugs. For the rest of us, we just want to use the system, not help develop it. Give me a stable system, ship me bug fixes that don't fundamentally break how anything works, and let me focus on my specific task. If that costs money, so be it, but I don't want to have to take one day per week running updates to find something else is broken and have to debug and fix it. That's not what I'm here to do.
And as for cleaning the house - we always have the option of hiring a cleaner. That costs us money, but they keep the house cleanliness stable whilst we focus on something else to make enough money to cover the cleaner's cost plus some profit.
I assume the cost of duplicating every piece of infra we have to create a suitable 'replacement system' would cost more than the impact the few times we have had downtime due to breaking changes in updates. Ymmv ofc
And also because, for the others, you have to migrate everybody from the "old" to the "new"; Large project, low value, nobody cares, "just to your job and don't bother us with your shit"
Considering "upgrading" to be "cleaning" is very odd. Same with "rotting".
Perhaps this is a side effect of dealing with software development ecosystems with huge dependency trees?
There's a lot of software not like that at all. No dependencies. No internet connection. No multi kilobyte lock files detailing long lists of continual software churn and bug fixes.
> Why do you need to clean your house every week/couple of weeks ? Why not clean only once a year ?
OS is not a physical house with life waste.
Rest of your message doesn’t make any sense for majority of industry. For anything dealing with manufacturing stability is much more important that marginal performance gains. Any downtime is losing money.
Why would the same exact software be considered “unclean” or “rotten” a few years down the line when it previously wasn’t? What has changed? Did it need to?
I've lost count of how many Ubuntu upgrades resulted in some weird problem (network interfaces renamed, lost default route, systemd timeouts taking 5 minutes, etc.)
There is an argument for staying on the latest stable version.
I think you are talking about an upgrade install. Those have a long history of breaking things. You would have to be crazy to attempt one of those on a critical production system.
What you would do for anything important is build a new separate system and then migrate to that once it is working. You can then migrate back if you discover issues too.
Unfortunately Debian wouldn't be exempt from "network interfaces renamed, lost default route, systemd timeouts taking 5 minutes, etc." because systemd is systemd (and Debian systemd maintainers just go along with upstream and do nothing to mitigate it)
I think interface names changed like at least 2 times in the last 4 releases.
I bought a hammer 2 decades ago and it still works flawlessly without me performing any maintenance. One day, the idiots in software engineering will realize that this is how tools are supposed to behave.
Keeping your infrastructure/code somehow uptodate ensures: - each time you have to upgrade, this is not a big deal - you have less breaking changes at each iteration, thus less work to do - when you must upgrade for some reasons, the step is, again, not so big - you are sure you own the infrastructure. That current people owns it (versus people who left the company 8 years ago) - you benefits from innovation (yes, there is) and/or performance improvements (yes, there is)
Keeping your stuff rotting in a dark room brings nothing good