冷血软件
能够被“冻结”多年、重启后也不会出问题的软件——所谓冷血软件——对那些厌倦了依赖和框架不断变化的开发者很有吸引力。评论者探讨了这种想法在何时现实可行，对比了能长期运行的 C、Go、Java、PHP 或静态 HTML 应用，与脆弱的移动端、Python、Node 和前端工具链，它们常常会因新的操作系统、SDK 或包版本而崩坏。许多人认为，严格控制依赖、稳定的平台和简单的架构，是实现数十年寿命的唯一方式，但也指出安全更新、不断变化的业务需求以及快速演进的生态，往往会迫使系统变成更“温血”、持续维护的形态。
长寿 vs 转瞬即逝的软件
- 许多人同意，有些软件应该被构建得能持续几十年（工具、基础设施、博客、CMS 等），但也有人指出，随着使用场景和技术栈演变，很多应用本质上就是短命的。
- 有人认为，重写代码最终可能比维护运行了几十年的旧系统更便宜；也有人强烈反对，指出触碰那些老旧但关键的系统成本极高、风险巨大。
- “Buxton 指数”/时间跨度的概念被用来解释差异：有些人或组织按年规划；另一些则只优化下个季度。
安全、生态变化与维护负担
- 一个反复出现的反对意见是：在一个在线、联网或受监管的环境里，安全更新和生态变化会迫使持续维护，使真正“冷血”的软件很少见。
- 令人痛苦的变化例子包括：移动应用（iOS/Android SDK 变化、应用商店政策）、Xcode 更新导致旧项目失效、包生态破坏（Node、Python、前端构建）。
- 也有人反驳说，经过谨慎规划（LTS 操作系统版本、无网络、有限攻击面）可以让系统多年保持可用且低维护。
依赖、工具与稳定策略
- 强调尽量减少依赖，尤其是构建工具和快速变化的框架；许多人更喜欢静态二进制、vendoring、容器，甚至冻结的虚拟机。
- 有几位提到用简单栈取得了成功：C、PHP、Go、Java、Perl、Elixir、原生 JS，以及 Make/Pandoc 这样的 Unix 工具。
- 另一些人指出，容器和 distroless 镜像可以“冻结”环境，但只是把维护转移到别处，并没有消除它。
语言、框架与平台体验
- 被赞扬稳定/向后兼容的有：Go（带 modules 和兼容性承诺）、Java（但 Java 9 之后有保留）、Perl、C、部分 PHP、Express.js、Elixir/Erlang 库、IBM 大型机、Windows、Linux 内核。
- 被批评为“温血”的有：Python（2→3 分裂、频繁弃用、依赖工具）、现代 JS 构建栈、一些 Ruby 和 Node 生态。
- 争论依然存在：有人说在严格工具约束下，Python 多年不变地运行良好；也有人则一直遭遇频繁破坏。
库的新鲜度与“完成了”的软件
- 检查“最后一次提交”被认为是一个有用但不完美的启发式：通常意味着项目被遗弃，但也可能表示某些库确实已经完成并稳定多年。
- 担忧在于：无人维护的库可能隐藏安全问题和不兼容性；但稳定、体积小、无依赖的库也可以无限期地继续有用。
哲学观点与隐喻批评
- 一些人赞成“明天用昨天的技术”和无聊工具，以最大化可预测性。
- 另一些人批评“冷血”这个生物学隐喻不准确或令人困惑，更喜欢更直白的概念，比如“外部依赖少”和清晰的威胁模型。