Never Update Anything

Original Article ↗ Hacker News Discussion ↗

Frequent software updates promise security and new features but often introduce breaking changes, instability, and user-hostile “enshittification,” leading some engineers to prefer long-lived, rarely changing stacks or even air‑gapped, never‑updated systems. Commenters contrast modern continuous delivery with earlier eras of slow, expensive releases that forced much stricter QA, and highlight strategies like LTS releases, static sites, limited dependencies, and staggered rollouts as ways to balance security with reliability. Underneath is a broader concern that easy over‑the‑air updates have removed incentives to ship robust software and shifted risk onto end users and operators.

Meta about the article and “never update” irony

  • Commenters note the joke that an article titled “Never Update Anything” has multiple edits and a server overwhelmed by HN traffic.
  • Some see further irony that the blog might need migration, caching, or a new CMS to cope with load.
  • Several suggest static-site generation; examples show tiny hardware easily surviving HN with static hosting.

Update strategies and risk management

  • One camp argues for minimizing updates: run stable systems for years, preferably offline and locked down.
  • Another camp argues that avoiding updates makes them rarer and more painful; continual small updates keep deltas manageable.
  • Various strategies are proposed:
    • Run 1–2 versions behind and delay updates by days or weeks.
    • Use LTS releases and “tip & tail” models with fast-moving “tip” and minimally changed “tail.”
    • Avoid very fresh releases and randomize update schedules to reduce mass breakage risk.

Quality, QA, and the internet-era shift

  • Multiple comments lament that easy online updating normalized weak QA.
  • Older console/game workflows, with strict external QA and expensive distribution, are contrasted with today’s “ship now, patch later” culture.
  • Frequent updates are seen by some as a sign of poor quality; others note that historically bugs simply persisted for years.

Real-world legacy and long-lived systems

  • Many enterprises, governments, and hospitals still run outdated, unpatched Windows (including XP, Vista, 7, 10).
  • Some customers refuse to drop old OSes, forcing vendors to stay on old toolchains (e.g., Java 8).
  • Storage and data-center vendors historically used conservative “target code” policies, avoiding the latest release in production.

Security vs connectivity and “just security updates”

  • Several argue for “never update and never expose to the internet” as a practical compromise.
  • IoT and auto-updating appliances are criticized as vectors for enshitification and risk.
  • Others point out that separating “just security patches” from features is hard: backporting is expensive and interactions can introduce new bugs.
  • There is concern that “security updates” are sometimes vehicles for unwanted features or removals.

Languages, frameworks, and long-term stability

  • Go is repeatedly cited as a good fit for people who dislike breaking changes; Common Lisp and some ecosystems are praised for decades-long stability.
  • Java’s multi-train “tip & tail” release model is described in detail as trying to balance new features vs stability.
  • Some want 10–20 year framework lifetimes; others call this unrealistic given evolving platforms and developer churn.
  • AngularJS is held up as an example of a “never dies” legacy framework still in production years after planned migrations.

Infrastructure choices: containers, distros, and orchestration

  • Some prefer lifecycle management of entire container images over in-place updates.
  • Static sites plus simple web servers (nginx, Apache) are highlighted as extremely resilient and resource-light.
  • There is debate over Alpine vs Ubuntu LTS; some prefer “boring” stacks (Apache, Ubuntu) for predictability.
  • Docker Swarm is criticized as unreliable at scale with poor issue response; several report migrating to Kubernetes despite its complexity.
  • NixOS/Guix and “OS as code” are praised conceptually, but Nix’s language and ecosystem complexity turn some users away.

Business incentives and user manipulation

  • A recurring theme is that business incentives favor constant churn: new features, rewrites, and monetization over long-term support.
  • Engineers are seen as partly complicit, chasing high salaries and shiny projects while unglamorous LTS work is underpaid.
  • Dark patterns like paywalled “Skip this update” buttons are cited as emblematic of manipulative update practices.