←back to thread

264 points davidgomes | 3 comments | | HN request time: 0s | source
Show context
elric ◴[] No.41876822[source]
Lots of dogmatism in this discussion, it seems. A couple of things:

1. Most psql deployments are not exposed to the interwebz, they are typically only accessible to the applications that need them by virtue of network setup (firewalls etc). This limits the attack vector to whatever the application does. Good.

2. Distro vendors (RHEL et al) often stick to major psql release for the lifecycle of the OS version. If the OS lives longer than the psql major version, they take on the responsability of backporting critical security issues.

3. While upgrades aren't hard, they're not easy either.

4. Psql is pretty much feature complete for many workloads, and pretty stable in general. For many people, there is little need to chase the latest major version.

replies(7): >>41876901 #>>41877104 #>>41877174 #>>41877411 #>>41877438 #>>41878003 #>>41879089 #
atoav ◴[] No.41877104[source]
Also:

5. If your IT department is spread thin already and that old version is running fine, the incentive to potentially create more work for yourself is not gigantic.

replies(1): >>41877167 #
Dalewyn ◴[] No.41877167[source]
One of the first laws of the universe that a good engineer learns is: Do not fix what is not broken.

And no, being old is not broken.

replies(9): >>41877567 #>>41877619 #>>41877848 #>>41877998 #>>41878067 #>>41878190 #>>41879176 #>>41880524 #>>41880526 #
1. LaGrange ◴[] No.41878190[source]
One of the first laws of universe that an experienced engineer learns is that "do not fix what is not broken" never actually applies, and is only brought up by people invulnerable to consequences.

That doesn't mean "upgrade recklessly," but it does mean you should know _why_ you're either upgrading or _NOT_ upgrading. That's your job, much more than the act of upgrading itself.

Unpublished vulnerabilities in old software are not a hypothetical. And very old packages are usually broken, just coped with at the expense of significant lost opportunity cost - or because the failure is a combination of rare and impactful that means once it happens everyone is out of job anyway.

Seriously, I've yet have to encounter a sysadmin using that old, silly adage at me and not later have to admit I was right.

Edit: so no, you don't stay on an ancient version of the database because "it's not broken." You're staying on it because _the upgrade process itself_ is so broken you're terrified of it.

replies(1): >>41879569 #
2. kayodelycaon ◴[] No.41879569[source]
I generally follow if it’s not broken, fixes need to be carefully planned. I can’t tell you how many times I thought I’d quickly do an upgrade and things would go wrong, like all of my home automation stop working right before bed.
replies(1): >>41881851 #
3. LaGrange ◴[] No.41881851[source]
I mean, _yeah_, for anything important you should move as carefully as possible. Just, "not upgrading" ain't that.