Never Update Anything

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.