2024 年对精简软件的呼吁

简单/自托管 vs 用户友好服务

• 几条评论指出，你可以构建极其精简的工具（例如通过 Web 服务器 + SSH/FTP/NFS + 极小脚本实现基础的图片/剪贴板分享）。
• 另一些人反驳说，非技术用户几乎完全活在浏览器里；要求他们去学习 FTP/SFTP 或挂载方式，确实是个门槛。
• 对于给家人/朋友自托管的场景，有人认为与其做自定义上传前端，不如直接教他们或预装 FileZilla、SFTP 文件系统或同步工具之类的软件。

图片分享示例、性能与隐私

• 有人批评文章中的演示应用没有调整图片大小或优化图片，却提供了完整尺寸的缩略图，称这是“优化错了东西”（二进制体积 vs 带宽）。
• 关于 EXIF 的争论：一方说在很多场景下不移除元数据是严重的隐私/安全风险；另一方则认为这更多是用户责任，或者在私密分享中这甚至可能是一项功能。
• 对于这是否让文章显得“伪善”还是只是“未完成”，各方意见不一。

激励机制与臃肿成因

• 多条评论把原因归咎于组织激励：快速交付能带来晋升；谨慎、精简的工程看起来“不够高产”。
• 臃肿也来自安全性/可移植性的选择：把所有东西都带上（驱动、运行时、调试映射）比按平台逐个裁剪更容易。
• 有人认为随着能力增长，臃肿不可避免；也有人认为这主要是开发文化和优先级问题。

Electron、Web 技术栈与 GUI 工具包

• 许多人把 Electron 和“装在盒子里的 Web”视为臃肿的典型代表（简单应用却要下载巨大体积、占用大量内存/CPU）。
• 辩护者指出，Electron 大幅降低了跨平台开发成本，利用了大量 Web 开发者资源，并加快了 UI 迭代。
• 提到的替代方案包括：Qt、JavaFX、Avalonia、Tauri、Slint，以及像 Telegram 这样的原生“重型”应用。权衡包括许可（Qt）、工具成熟度和招聘难度。
• 有人认为如果没有 Electron，很多桌面应用（尤其在 Linux 上）根本不会存在；另一些人则说原生技术栈完全可行。

库、打包，以及共享 vs 静态链接

• 讨论围绕 Mesa 的体积，以及该如何“划线”区分必要复杂度与过度打包。
• 支持共享库的理由：集中管理、磁盘/RAM 更省；支持静态二进制的理由：部署更简单、隐藏依赖更少。
• 包管理器可能掩盖真实复杂度：apt install 并不会告诉你究竟拉进来的是完整浏览器引擎，还是一个小巧的静态二进制。

软件质量是否在变差？

• 一派认为现代应用（尤其是 Electron）明显更差：原本很简单的工具却占用数百 MB 内存/CPU，并且相比旧式原生界面有更糟的 UX 模式。
• 另一派认为过去的软件（例如 90 年代桌面软件）也以 bug 多、不安全而臭名昭著；怀旧可能带有偏见。
• 更细致的观点是：大约 2003–2013 年存在一个“黄金时期”，当时原生工具包扎实、工程实践更好，之后则在 Web/移动端跨平台压力推动下出现回退。

臃肿与精简的例子

• 被指出的臃肿例子：
  • Notion Calendar 约 84 MB。
  • 作为 Snap 的 Firefox，每个版本占用数百 MB。
  • ClickHouse 的“客户端”二进制约 900 MB，因为它打包了服务端/工具。
  • QGIS Windows 安装包约 1 GB，而且还在增长。
• 更精简的反例：
  • 旧版 Ventrilo 客户端只有几 MB，内存占用也很小。
  • 一些 Qt/JavaFX 桌面应用在认真优化下可控制在约 30–140 MB 以内，内存只占几十 MB。
  • 有个工具通过移除不必要部分从 33 MB 缩到 1.4 MB（细节未完整说明）。

监管、供应链与 API

• 新的安全立法和长期更新义务已经在促使一些组织重新审视依赖扩张问题。
• 有人建议借助更好的工具和轻量级形式化方法来推理庞大的依赖图，而不是指望臃肿自然消失。
• 也有人主张开放 API，让用户可以选择更精简的替代客户端，而不是被迫使用官方但臃肿的版本。

操作系统与安全模型

• 一条讨论线把责任归咎于操作系统安全模型：过去的系统（例如基于软盘的环境）隐式地强制了简单的能力边界，而现代操作系统允许任意代码获得广泛访问权限，这使今天庞大的依赖树更危险。