I had started to think I was the only one saying this.
Never Update Anything
91–100 of 121 posts
Re: Never Update Anything
#92Oh hey, I was wondering why the VPS suddenly had over 100 load average, restarted Docker since the containers were struggling, now I know why (should be back now for a bit). Won't necessarily fix it, might need to migrate over to something else for the blog, with a proper cache, alongside actually writing better articles in the future. I don't think the article itself holds up that well, it's just that updates are of…
Back in 2018, I helped a startup update their AngularJS wrapped jQuery prototype to 1.6 and tried hard to separate business logic from component code so they could migrate over to vue, react or angular2 after I left.
I regularly snowboard with someone still at the company. They’re still on AngularJS.
AngularJS never dies.
AngularJS is forever.
Re: Never Update Anything
#93The world is not static and software these days is very interconnected. Dreams of not updating only work in a unchanging world. Sadly, this world is still to be found.
Re: Never Update Anything
#94The world is not static and software these days is very interconnected. Dreams of not updating only work in a unchanging world. Sadly, this world is still to be found.
Funny you're saying that. In context of the stricken crowds I've read that FedEx, UPS and SouthWest had no problems at all, because many systems run on Windows95, or even something based on Win3.1x :-) Seems they are well isolated, but networked nonetheless. Or do you think they use bush-drums and smoke signs to conduct their businesses?
Re: Never Update Anything
#95Extreme viewpoint, but agree strongly. Big reason why working in Common Lisp brings a smile to my face - it’s a standard, quicklisp works, ffi works, etc. I can run code and follow instructions written DECADES ago, it just damn works.
Re: Never Update Anything
#96I pretty much agree- most systems don't need updating. I've seen and setup OpenBSD servers that ran for a decade without issues never getting updates. I currently run some production web services on Debian where I do updates every 3 years or so, and no issues. Leaving something alone that works good is a good strategy. Most of the cars on the road are controlled by ECUs that have never had, and never will have any ty…
> Vehicles that can get remote updates like Teslas are going to be much less reliable than one not connected to anything that has a single extensively tested final version.
I don’t think it’s necessarily this, but the fact that being able to update anytime is a great source of pressure to release untested software at any cost.
Re: Never Update Anything
#97Avoid software that will need constant updates. Because that is a signal it is defective to begin with, or expected to be broken soon.
For example, I avoid graphical commercial OS, large, graphical web browsers. Especially mobile OS and "apps".
Avoidance does not have to be 100% to be useful. If it defeats reliance on such software then it pays for itself, so to speak. IMHO.
The notion of allowing RCE/OTA for "updates" might allegedly be motivated by the best of intentions.
But these companies are not known for their honesty. Nor for benevolence.
And let's be honest, allowing remote access to some company will not be utilised 100% for the computer owner's benefit. For the companies remotely installing and automatically running code on other peoples' computer, surveillance has commercial value. Allowing remote access makes surveillance easier. A cake walk.
Re: Never Update Anything
#98Avoid software that will need constant updates. Because that is a signal it is defective to begin with, or expected to be broken soon. For example, I avoid graphical commercial OS, large, graphical web browsers. Especially mobile OS and "apps". Avoidance does not have to be 100% to be useful. If it defeats reliance on such software then it pays for itself, so to speak. IMHO. The notion of allowing RCE/OTA for "update…
Exception is mobile apps
Re: Never Update Anything
#99What the article points to is that most updates are bad updates. We teach people that they should accept all updates for security reasons, but really they should only accept security updates. But they can't, because this is not a possibility that is given to them. All updates are put together, and we as an industry suck at even knowing if our change is backward compatible or not (which is actually some kind of incomp…
And you can't have _just_ security updates, because the combinational complexity of security fixes across feature versions is insane, not to mention the fact that the interaction of the security and features changes can themselves introduce bugs. There's groups that try (eg distro maintainers) but it's ultimately a losing battle. I'm convinced that patching is only a bandaid, but it's also impossible to have 100% bug-free code, so there needs to be some sort of systematic solution on top of whatever particular code is running. Behavior analysis, egress network analysis, immutable by default images with strictly defined writeable volumes and strictly defined data that's going to be written there, etc. There's not a silver bullet, but I think patching and trying to keep up with updates is, like, a gallium bullet at best
Re: Never Update Anything
#100To jump on a related article since it's linked and comments are now closed: https://blog.kronis.dev/articles/stable-software-release-sys...
The 2021/2022/2023/2024 version-numbering schemes are for applications, not libraries, because applications are essentially not ever semver-stable.
That's perfectly reasonable for them. They don't need semver. People don't build against jetbrains-2024.1, they just update their stuff when JetBrains breaks something they use (which can happen at literally any time, just ask plugin devs)... because they're fundamentally unstable products and they don't care about actual stability, they just do an okay job and call it Done™ and developers on their APIs are forced to deal with it. Users don't care 99%+ of the time because the UI doesn't change and that is honestly good enough in nearly all cases.
That isn't following semver, which is why they don't follow semver. Which is fine (because they control their ecosystem with an iron fist). It's a completely different relationship with people looking at that number.
For applications, I totally agree. Year-number your releases, it's much more useful for your customers (end-users) who care about if their habits are going to be interrupted and possibly how old it is. But don't do it with libraries, it has next to nothing to do with library customers (developers) who are looking for mechanical stability.