Show HN: Homebrew 6.0.0 (brew.sh)
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate).
Happy to discuss any questions here!
120 comments
[ 2.8 ms ] story [ 58.9 ms ] threadI noticed that homebrew updated _all_ my casks when running 'brew upgrade' (even those with "auto_updates: true" in their Cask JSON API).
Is this intended, new default behavior? This did not use to happen...
The only people I want to trust to quickly ship new code to my machine are Apple and my browser (which handles more untrusted input than anything else).
For everything else (vscode and its extensions, npm, homebrew, and all the apps that self-update), I prefer to err on the side of waiting a few days.
Some exceptional 0days might warrant a cooldown bypass, but even in its current form users are vulnerable to 0days until they run brew upgrade.
Funnily Mise does not support dependencies, and I was quite surprised that it mostly doesn't matter, as either pnpm/uv handles that, or it's a static binary that just works. In the past, had the unfortunate experience of packaging a Python application for Homebrew (the ridiculous process involved importing around 50 dependencies as "resources", building every single one from source or manually checking if it's already on Homebrew, declaring build toolchains for 5 different programming languages as dependencies, waiting over an hour for CI to finish on every update, then an upstream update introduced a "build-time dependency loop" and the project suddenly became unpackable for Homebrew) so I totally get why Mise took the "easy way out" and just relies on language-specific package managers directly.
Only thing from my Brewfile that I couldn't replace was the Docker CLI (needed to interact with Colima). And I still use Homebrew for casks. I encourage others to experiment with their dev setups, there are some amazing new tools out there.
We are not many [1], but Homebrew has been a great way to quickly bootstrap an environment in immutable Linux distributions.
Note that certain operating systems such as Universal Blue's Bazzite (1.28%), Bluefin (0.49%) and Aurora (0.28%) default to bundling Homebrew [2].
[1] https://formulae.brew.sh/analytics/os-version/365d/
[2] https://github.com/ublue-os/brew
I don't understand how devs don't use a tool that makes multiple versions of everything possible.
I know supporting Intel is an ordeal and a choice, but I'm firmly on the camp that Homebrew should find a way to maintain Intel support as long as possible.
Homebrew will still work (increasingly poorly) on macOS Intel for a year after that, it just won’t be “supported” or tested in CI environments (where currently macOS Intel usually slows down the release of lots of software for all other platforms).
That a volunteer run project with no employees is unable to come anywhere near the support levels of the world’s second biggest, trillion dollar company should not be surprise.
We’re also limited that GitHub (part of Microsoft, 4th biggest, also trillion dollar company) will have killed all macOS Intel CI by autumn/fall 2027 too.
We are announcing this well in advance to give people migration paths to MacPorts or other hardware.
There’s nothing stopping you for doing the work to setup “Intelbrew” and support it for the community. When I started work on Homebrew it had no funding or CI or binary packages/bottles at all. I did much of that work myself. It was hard but you could do the same.
Completely reasonable to say “I don’t have time!” but: then you need to accept the decisions of those that do, sorry.
It’s taken a long time but we’re finally at the point where we do (pretty much) only upgrade the minimal software we need to actually avoid breakage rather than the previous “better safe than sorry” conservative approach. We also now tell you by default everything we’ll upgrade before we do it (unless you say “upgrade foo” and all we are gonna do is upgrade foo).
So: we’ve maybe solved this issue and maybe not. The perfect outcomes for everyone here is pretty much impossible given the original design of Homebrew. MacPorts or Nix or Mise are likely a better fit in that case.
Since everybody runs their own unique permutation of apt or dnf packages, adding as little as possible will keep you as close as possible to what distro maintainers test. There's even OSes like Fedora Silverblue or Bluefin or SteamOS that ship with a fully baked _image_ - where installing system level packages is strongly discouraged - which helps ensure predictability and stable upgradeability.
Homebrew packages also tend to be more recent (this depends on your distro of course) and don't require elevated permissions to install.
[1]: Other unprivileged package managers like Mise or Nix do the same of course
- Brew seems to have better support for the packages it has, compared to Nix where it seems a percentage of packages are not as well maintained,
- Better Mac support; some Nix packages have features disabled on macOS, I think just because the maintainers of this packages don’t have a Mac for testing,
- Better UX.
Obviously I miss the reproducibility of Nix environments and the ability to easily create my own flakes with specific packages, but on the balance, Brew has won me back. (I still like Nix, and FWIW we use Nix at work.)