Show HN：Homebrew 6.0.0

原文 ↗ Hacker News 讨论 ↗

升级行为与 casks

  • 一些用户报告说，brew upgrade 现在会更新所有 casks，包括那些标记为 auto_updates: true 的，而这些以前会被跳过。
  • 维护者表示这是预期行为：Homebrew 现在只会跳过它检测为已经自动更新的 casks，但该检测并不完美，并请求提交 bug 报告。
  • 有一个环境变量可以恢复自动更新 casks 的旧行为；有人担心禁用了提示的用户可能会“悄无声息地”遇到这一变化。
  • 几位用户不喜欢这种“过于积极的升级”或全局更新，尤其是在他们只想更新单个包时。

安全、冷却期与供应链

  • 多位评论者要求加入“冷却期”功能（延迟新版本发布），以缓解供应链攻击。
  • 维护者解释说 Homebrew 其实已经对某些生态（npm、PyPI、RubyGems 等）使用了冷却期以及人工/CI 审核，并认为按其模型来看，全局冷却期弊大于利。
  • 仍有人希望有用户侧冷却期或更慢的发布通道；也有人更偏好快速修复零日漏洞。
  • 还有人质疑“人工审核”的深度，因为大型项目的更新常常在上游发布后约 1–2 小时内就落地。

版本管理、固定版本与滚动发行

  • Homebrew 仍然是滚动发行管理器；精确版本/旧版本并不是其主要目标。
  • formula@version、brew version-install、Bundle 的 version_file 以及 brew pyenv-sync 之类工具存在，但只是部分解决方案。
  • 想要严格固定版本或长期保留旧版本的用户，往往会转向 Mise、Nix、MacPorts 或语言专用管理器。

tap 信任、签名与提示

  • 新的 tap trust 获得了一些人的欢迎，但也有人质疑它到底能在多大程度上提升安全性，还是只是增加确认步骤。
  • 讨论集中在 Homebrew 放弃未签名 casks 以及这与平台锁定和代码签名担忧之间的关系。

性能、UX 与并发

  • 许多人称赞 6.0 中明显的速度/性能提升，尤其是 brew upgrade。
  • 新的交互式提示（例如在安装复杂 formula 之前询问）受到一些人欢迎；另一些人则立刻去找环境变量/标志来关闭它们。
  • 受限网络环境下的用户希望更好地控制并行下载；并发可以通过环境变量调节，但目前没有带宽限速功能。

替代方案、生态与使用模式

  • 大型子线程将 Homebrew 与 Mise、Nix、MacPorts、pkgsrc 和 devbox 进行了比较。
  • 常见模式是：用 Homebrew 管理 GUI 应用和通用工具；用 Mise/Nix/语言管理器管理按项目或多版本运行时。
  • 一些人因为被强制升级或 macOS 支持阶段性退出而离开了 Homebrew；也有人从 Nix 回流，理由是 macOS 集成和 UX 更好。

Linux、不可变发行版与用户态包管理器

  • Homebrew 在 Linux 上的使用越来越多，尤其是在不可变/原子型发行版，以及用户没有 root 权限的企业或共享环境中。
  • 用户喜欢把系统包与较慢的发行版仓库解耦的“用户态包管理器”。
  • 对 Linux 安装前缀和非 root 安装方式仍有一些困惑；大家希望有更多文档和保证。

Intel 支持与老旧 Mac

  • Intel macOS 的弃用时间线引发争议：有人认为在 Homebrew 用户群体中，Intel 服务器/老 Mac 仍然很常见；也有人说这类用户只是很小的少数，应该改用 Linux 或其他工具。
  • 还提到 MacPorts、Nix 等替代生态，作为旧版 macOS 和 Intel 硬件的剩余选项。

治理、基础设施与 AI

  • 有人质疑 Homebrew 与 GitHub 的紧密耦合，以及自托管 taps 的难度（需要 git 服务器）。
  • 新的“Responsible AI Usage”文档被提及；有人好奇 6.0 中 AI 的使用范围，以及这些指南是否被一致遵守。
  • 几位评论者强调 Homebrew 由志愿者运营并鼓励捐赠；也有人对它竟然没有获得大型厂商资助表示惊讶。