Homebrew 7.0.0

性能与架构

• 许多用户立刻注意到 7.0.0 的安装和升级速度大幅提升；性能优化和并发性增强被认为是主要原因。
• Homebrew 仍主要基于 Ruby；新的 GUI 则使用 Swift。
• 曾有一个 Rust 重写的原型，但由于在真实基准测试中更慢而被放弃。随后这些经验被用于优化 Ruby 实现。

语言 / DSL 演进

• 有人将其与 Gradle 逐步摆脱 Groovy 相比较。也有人担心，随着 Ruby 热度下降，长期依赖 Ruby DSL 会带来问题。
• 核心维护者表示，贡献者只需要很少的 Ruby 知识，而且该 DSL 已经被“去图灵完备化”：任意的安装后/卸载后 Ruby 逻辑正被更窄的 DSL 和 JSON API 所替代，随着时间推移，软件包定义也可能迁移到 JSON。

平台支持与 Intel Mac

• 放弃 macOS 10.15 并将 Intel Mac 降为 Tier 3（实际上等于停止支持）是最具争议的变化。
• 有人认为，对于一个志愿者项目来说，支持 Intel 6–7 年已经很合理，尤其是在 Apple 和 GitHub 都在逐步停止对 Intel macOS 的支持时。
• 也有人认为这属于过早淘汰“完全还能用”的硬件，并将 Homebrew 的政策与 MacPorts 对比，后者支持非常老的 macOS 版本和架构。
• 对 Intel 用户来说，MacPorts 和 Linux（配合 Homebrew 或原生包管理器）常被建议作为替代路径。

Linux、前缀与沙箱

• 在 Linux 上，初始设置通常仍需要 root（用于默认 prefix 和沙箱工具），不过可选使用专用用户。
• 7.0.0 引入了对任意长度小于 64 字符的前缀的实验性支持；这一限制源于倾倒 bottles 时需要重写二进制路径。
• 现在弃用 Bubblewrap 沙箱，改为 Landlock；没有 Landlock 的内核会回退到 6.0.0 之前那种安全性更低的行为。

安全与供应链

• Homebrew 强调其更强的沙箱能力和安全/漏洞公告系统。
• 一篇详细批评认为，Homebrew 的供应链模式本质上仍是“信任机制”，不适合用于有生产权限的机器，并呼吁强制签名、可复现构建以及多方验证。
• 也有人回应说，语言级包管理器同样存在风险；Homebrew 也链接了其安全文档并欢迎具体报告。
• 一些用户建议使用“冷却期”机制或外部工具，延迟采用最新的上游包。

新的 GUI 应用

• 这个新的原生 macOS 应用受到欢迎，不过：
  • 它目前需要更新的 macOS（Tahoe 26+），这让谨慎升级的用户感到不满。
  • 有人认为带有大量 emoji 的 UI 风格失当。
  • 一个反复出现的“failed to decode JSON output”错误，被追查为 shell 集成输出污染了 Homebrew 的 JSON。

开发中使用 LLM

• 维护者表示，他们在重构、性能工作、沙箱处理和变更日志撰写中大量但经审阅地使用了 LLM 辅助（包括一个自定义的 “Agent IDE”）。
• 一些用户不喜欢发布说明里那种 LLM 风格的语气，并且对在系统包管理器中引入 AI 感到不安。
• 也有人为这种工作流辩护，认为输出都经过充分审查和测试，而且整体性能和安全性比以往都更好。

替代方案与工作流

• 一些用户越来越依赖：
  • Mise，用于语言工具链和全局 CLI（有时甚至用它来引导安装 Homebrew）。
  • uv，用于 Python。
  • Nix、pkgsrc 或 MacPorts，用于开发依赖，而 Homebrew 主要只通过 Casks 负责 GUI 应用。
• 在 Linux 上，Homebrew 在不可变/原子式发行版上很受欢迎，也常被用来将系统包与用户工具解耦。

总体评价

• 许多人感谢 Homebrew 作为 macOS 和 Linux 上“关键基础设施”的角色。
• 很多人称赞它的速度和新特性；也有人因为每次大版本升级时平台下线和政策变化而感到焦虑。
• Intel 停更、 安全姿态和操作系统版本要求是主要不满来源；性能、Linux 改进和 GUI 则是主要亮点。