Do they upgrade to the new LTS the day it is released?

▲ sakjur 9 hours ago | parent | next [-]

Ubuntu's upgrade tools wait until the .1 release for LTSes, so your typical installation would wait at least half a year.

▲ crcastle 14 hours ago | parent | prev [-]

Not historically.

▲ rvnx 14 hours ago | parent [-]

and they are right, this is because a lot of junior sysadmins believe that newer = better.

But the reality:

  a) may get irreversible upgrades (e.g. new underlying database structure) 
  b) permanent worse performance / regression (e.g. iOS 26)
  c) added instability
  d) new security issues (litellm)
  e) time wasted migrating / debugging
  f) may need rewrite of consumers / users of APIs / sys calls
  g) potential new IP or licensing issues

etc.

A couple of the few reasons to upgrade something is:

  a) new features provide genuine comfort or performance upgrade (or... some revert)
  b) there is an extremely critical security issue
  c) you do not care about stability because reverting is uneventful and production impact is nil (e.g. Claude Code)

but 99% of the time, if ain't broke, don't fix it.

https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

	▲	miki123211 11 hours ago \| parent \| next [-]
		On the other hand, I suspect LLMs will dramatically decrease the window between a vulnerability being discovered and that vulnerability being exploited in the wild, especially for open-source projects. Even if the vulnerability itself is discovered through other means than by an LLM, it's trivial to ask a SOTA model to "monitor all new commits to project X and decide which ones are likely patching an exploitable vulnerability, and then write a PoC." That's a lot easier than finding the vulnerable itself. I won't be surprised if update windows (for open source networked services) shrink to ~10 minutes within a year or two. It's going to be a brutal world.
	▲	mr_toad 7 hours ago \| parent \| prev \| next [-]
		Too often I see IT departments use this as an excuse to only upgrade when they absolutely have to, usually with little to no testing in advance, which leaves them constantly being back-footed by incompatibility issues. The idea of advanced testing of new versions of software (that they’ll be forced to use eventually) never seems to occur, or they spend so much time fighting fires they never get around to it.
	▲	gjvc 9 hours ago \| parent \| prev [-]
		all fair points, on the other hand, as a general rule, isn't it important to stay on currently-supported versions of pieces of software that you run? ymmv, but in my experience projects like postgresql which have been reliable, tend to continue to be so.