Hi Mike, I’m @bfontaine on GitHub (I helped maintain Homebrew in ~2014-2016). I’m always impressed at your longevity as a maintainer; it’s been like what, 16+ years you’ve been maintaining Homebrew and you’re still here, still shipping new features! Thank you for everything!
just updated to 6.0.0. already loving `brew trust <tap>` thank you for all the years of work! practically a required macos experience for me these days!
as far as cli utilities go the ux of homebrew has always been so easy to use, honestly kind of a personal benchmark for me on how repeatedly approachable it is, all commands are for whatever reason so painless to remember. i remember when apple silicon dropped and you guys followed shortly with support and the ability to switch arches, like really killer stuff so impressed with homebrew! always a treat when something im interested in tinkering with has a homebrew formula available
At the off chance that you'll see and reply to my message, I have a question
I saw a tweet by someone many years ago before I knew Homebrew was a thing. The tweet basically said "Google rejected me for not being able to invert a binary tree when 80% of Google engg use Homebrew"
Ostensibly it did. But worth noting that despite many people still thinking of Max Howell when they think of Homebrew, he hasn’t been there for a long long time. Pretty sure he wasn’t there at the time of that Google interview, even. Mike and all the other contributors deserve much more credit for Homebrew. There are even contributors who since left who were there for longer and had a bigger impact than Max. And he had nothing to do with the Cask part.
Unfortunately, Max still clings to having created Homebrew as his greatest achievement, despite being so uninvolved for so long that just about the only thing that remains of his is the name and the beer nomenclature often confusing for newcomers. Since then, he’s been aggressively chasing whatever is popular at the time. When blockchain was all the rage, the made a package manager that leveraged it. Now he’s into AI stuff. But always, still at the top of his website and plastered everywhere whenever he pursues a project, he mentions he created Homebrew.
Yeah, I guess it's not being a native English speaker, so one just accept most of the words almost as names without thinking about any other meaning the word might have.
Homebrew is so good that I use it on Linux whenever possible.
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
> Most Linux package managers cannot separate user-installed packages from system packages.
And because of pinning versions to LTS releases on certain Linux distributions many times those packages stay out of date for years. Which is quite annoying.
This gets thrown around a lot, but it's not entirely true. Depending on the particular distro, only certain core packages are likely to get updates on LTS releases. Non-core packages may just get left to rot until the next LTS release. Specifically Ubuntu follows this. A lot of their non-core packages just get imported from Debian and then just sit unmaintained until next release (this goes doubly if not using Ubuntu Pro).
Especially frightening when you look at how much everyday stuff is actually in the Universe repo in Ubuntu. Without Ubuntu Pro, your LTS system can sit in a very insecure state for a long time as patching Universe is "best effort" from the community.
Most popular GUI stuff is from universe, as are quite a few dev tools. Some examples: Gimp, Inkscape, pip (and a ton of python packages), most of gnome, a big chunk of KDE, htop, mariadb, etc.
See for yourself grep -h "^Package:" /var/lib/apt/lists/_universe__Packages | awk '{print $2}' | sort -u
Or to see only what you have installed from Universe: comm -12 <(dpkg-query -f '${Package}\n' -W | sort) <(grep -h "^Package:" /var/lib/apt/lists/_universe__Packages | awk '{print $2}' | sort -u)
> Depending on the particular distro, only certain core packages are likely to get updates on LTS releases.
All LTS distros fix only some core packages sporadically as no one is able to back port all the patches esp. since most packages do not use CVEs and just fix bugs on the go. "Stable" for non-rolling distributions simply means "horribly broken and outdated".
It’s not horribly broken any more than your toaster is for not needing constant updates. Though I do have such a longstanding love/hate relationship with Ubuntu because of this. It is why it runs everywhere and just works (even powers the WSL2 defaults), but everything it provides also always so very far behind I end up recompiling so much important stuff by hand.
> It’s not horribly broken any more than your toaster is for not needing constant updates.
I don't know where this sense of "stable" in the community comes from. Software isn't perfect and gets fixed all the time. Yes, there are packages with different maintained stable branches that you can pin for your LTS distribution but this is by far the minority. For the other stuff you constantly have to work around missing features or existing bugs. E.g., why do I have to compile "jq" by myself just because the outdated package crashes on certain inputs?!
The "outdated" package, probably has all these security fixes [0]. That's why it exists - to maintain something safely. You step back from latest and greatest, to not get a compromised system the next time something goes wrong.
My personal solution for this is to install a simpler distro in chroot, alpine, and install dev newer apps in to it. Additionally, I run chroot via bwrap sandbox and have been doing this for quite some time now before flatpak became famous.
> Most Linux package managers cannot separate user-installed packages from system packages.
What is the use case when someone would want to differentiate system/user installed package? Isn't it good things that they are the same - meaning once something is install - it is there regardless of how it got here.
1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone who just wants to run a program (again a great example being Python venvs, which at this point have decades of tooling built up around trying to make it less annoying to deal with).
2. For "cattle" systems having everything installed at the system level is generally not too much of an issue, but for "pet" systems where the user might be experimenting with things it's really nice to be able to install stuff in a way that doesn't affect anything outside of your user account even if it's also available at the system level. The computers that I personally operate from on a daily basis tend to build up a lot of crap I used once over time and removing it without just backing up my stuff and nuking it all can be a major pain.
The last-millennium solution to me-only installs is to put stuff in $HOME/bin, $HOME/lib, and $HOME/etc, and put those in the appropriate paths. Build the package with e.g. CMAKE_INSTALL_PREFIX=$HOME. At some point I switched to putting those dirs all in $HOME/opt for tidiness.
It's worked for me since workstations were shaped like pizza boxes.
I'm sure there are some things it can't do, but it goes a long way. When you're installing distributed binary packages you have less ability to control the baked-in install dirs, but if the package honors the conventional $(env) it can work.
I had this exact situation with Citrix workspace refusing to install after my upgrading to the latest Fedora. I had to force install and things did work but I would have preferred to not having to do that. I don't know enough about Homebrew to know if it would have helped (Citrix distributes .deb and .rpm files).
Honestly for python just using uv is enough, not only does it handle virtualenv for you, it will also install the necessary python version you need locally.
That’s entirely a user package manager though and is GPs point: what uv does cannot be done in a package manager like apt which sees itself as only doing system package management.
In my current use case I'm setting up a new Ubuntu server for hosting LLMs. I didn't take notes when setting it up last time around but want to document exactly what was required to pass on to coworkers trying something similar. I don't know what packages I installed to get the minimalist setup working vs what is installed by default. I'm tempted to nuke and redo with notes but I'm sure there is a better method of tracking down what I deployed to get to the current state.
...or not, and this is why HomeBrew exists and I need to learn it or ansible/etc.
Yeah I tried nix about 8 months ago. Not really as simple as homebrew. Even the detereminate nix tutorial though nice felt too much of a hassle. I feel homebrew really is a nice interface which is pretty close to conventional package manager, while nix even though the concept is revolutionary, felt lacking in user experience. Hope the documentation improves.
I have switched my full OS-level dev env to https://mise.jdx.dev/ from Homebrew+pipx+npm, initially as an experiment but found out that it actually works amazingly well. Many things get installed directly from GitHub releases or a corresponding package manager (uv, pnpm, go get ...), zero glue code to "repackage", zero version lag. You can install any arbitrary version of a package, even multiple ones at once, and dynamically adjust which ones are active per working folder or explicitly through environments.
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.
Mise does seem to be in a class of its own. As mentioned elsewhere, it does rely on other registries such as aqua and obviously asdf. For people who want to use Mise for brew packages, there's https://github.com/kennyg/mise-zerobrew.
Glad you're having a good experience, but I personally switched from Mise back to Brew. I don't know if it was just my skill issue, but there were too many packages which found Mise to be problematic.
I've been using it lightly as a "better nvm" for a longer time, but only switched to it as a primary "tool installer" a few months ago. I've seen it improve quite a lot over the time, you could give it another try!
As a PHP developer, I found mise's support to be pretty sub-par compared to Shivam Mathur's packaging work for homebrew. Most of my projects are using Docker anyway, the local PHP is for stuff like static analysis that doesn't need it. And I've got a couple using Nix, which laughs at everything else (but damn, the overall UX is still even more hostile than git).
mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools")
This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.
I like mise a lot, but only use it for project specific tool management, JDK versions, etc.
I tried to use it for system wide things, but found it didn't work as well for me with things that I wanted to just be tools where I didn't care what specific version it was as long as it was more or less current, Helix, NeoVim, RipGrep, etc.
I recently found mise and have become a fan as well. I have used asdf for about a decade and it supports the same .tool-versions files so initially I used it for those exact same things.
But I use four different computers for development regularly and sometimes use Codespaces as well. While syncing dotfiles handles most of my setup, it doesn't handle binary dependencies of my dotfiles - my neovim setup wants fd & rg etc. So now those go in the mise global config. I also have a global node & python along with uv@latest which pretty much covers every tool I might want to install.
I have never cared for the fact that homebrew tries to maintain shared dependencies and several upgrades have broken stuff for me.
For system-wide things I usually use "latest" but it's nice being able to downgrade and/or stick to a working version using lockfiles. I remember back when I used Homebrew, Teleport shipped a bug that prevented me from accessing our servers and downgrading was a pain.
Mise’s refusal to make global packages globally available is off-putting. I keep using it for specific Node versions and the integration with fnox.
The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.
What do you mean by that? If you have mise activate set up correctly in your shell rc file, globally installed tools are available in every shell. There’s also shim mode [1].
I use Claude on a mise-powered project daily without any issues
Not an expert, but Claude doesn’t seem to be running with my ZSH profile? Really, anything that isn’t a terminal and tries to use global commands, such as utilities that expect Node to be available and so on. I always have to prefix commands, unless using the terminal myself.
Mise actually does support a primitive dependency system, you can specify package deps in your config, so, for example, you can ensure erlangs are installed before elixirs (bad example, elixir is already internally dependent on erlangs, but you get the idea)
Hmm, `mise use -g docker-cli` works for me. `docker compose` is a bit trickier – it gets installed as `docker-cli-plugin-docker-compose`, but docker-cli doesn’t seem to pick it up. I’ve added a symlink as `docker-compose` for the time being.
Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).
Mise also has a task runner which automatically uses correct tools. Onboarding a new team member is super easy now, they just need Mise, "mise install" and they're up.
Mise installs itself as a static binary actually (but it's of course packaged in many registries), and while there are some third party registries it delegates to for some packages (aqua, asfd), most stuff I have installed is either built-in, or from PyPI, npm or GitHub, i.e. directly published by the upstream maintainers. More info: https://mise.jdx.dev/dev-tools/backends/
There's always the chicken/egg problem of which dependency manager to install first, though. AFAIK there's no "trusted" installed for Homebrew on macOS though I might be wrong.
We're discussing Homebrew now, which includes discussing alternatives, and I'm telling my story of switching to a tool that I found better for my purposes. I'm not affiliated or anything. I agree this comment would be weird e.g. on the official Homebrew blog.
I agree, but HN doesn't like metacomments that just complain on how an article/comment is being upvoted, hence you being downvoted. See guidelines: https://news.ycombinator.com/newsguidelines.html
The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago. It's ridiculous that the usual situation for non-root users is "you can't install XY but feel free to build from source". Homebrew, Mise and Nix are filling that hole now. (Flatpak is more oriented towards GUI apps, and Snap... exists.)
At the very least, Linux package managers should have some concept of different layers of packages.
For example, there might be layers for “system” (core components), “environment” (display manager, DE, etc), and “user”, each of which are maintained fully separately so they can’t ever step on each others’ toes and break things. Yes, it means there will be some redundancy but for all the trouble and complexity it’s saving I think it’s a worthwhile tradeoff.
Most "immutable" distro flavors do something like this. Back when I ran Aurora, it was rpm-ostree for the core system packages and homebrew in a devbox container for the rest. One incentive for maintaining the layer separation was that rpm-ostree was slow.
I've since moved my desktop box to NixOS, where everything is just flakes, but my mac runs circles around it so it's just there for Steam nowadays.
I love brew but it was decades of tradition to download source and compile as non-root on shared Unix systems. Not only were the sysadmins skilled at saying no, they were not always available at 2 am, but installing some random code, after editing the Makefile to reflect some oddity of something, was 24x7. And then when we got better offers than shared dial up hosting, it was root or nothing.
To be sure it is ridiculous, but it is also traditional.
One of the frustrating limits historically with some of these is that when you're already an unprivileged user it's been difficult or impossible to get to a sandboxed environment to perform hermetic or untrusted builds. So like with nix for example you could do a user install and then builds would build as your user, but if you installed as root, then builds would delegate out properly to nixbld users.
This has gotten better in recent years with user namespaces but it takes time for it to be adopted and achieve parity with what used to be just jumping to a user who can only write to a newly created dir in tmp.
In Debian-Ubuntu it's become a standard pattern to use `curl` or `wget` to add a third-party `deb` repo with keychain integration, because for whatever reason there's still no `apt` command for this obvious scenario. Really grinds my gears.
For whatever reason, nobody seems to use it. It must be a good reason or else they would. [PS: It's because it doesn't add the signing keys and maybe also because it's too associated with Ubuntu.] This, for example, is the official way to add Mozilla's repo:
echo "deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main" | sudo tee -a /etc/apt/sources.list.d/mozilla.list > /dev/null
And here's Signal's instructions:
# 1. Install our official public software signing key:
wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg; cat signal-desktop-keyring.gpg | sudo tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
# 2. Add our repository to your list of repositories:
wget -O signal-desktop.sources https://updates.signal.org/static/desktop/apt/signal-desktop.sources; cat signal-desktop.sources | sudo tee /etc/apt/sources.list.d/signal-desktop.sources > /dev/null
# 3. Update your package database and install Signal:
sudo apt update && sudo apt install signal-desktop
I believe apt-add-repository started out as Ubuntu specific for their PPA system, didn't it? It's part of the software-properties-common package.
When using it without a PPA (just giving in the repo URL) it won't add the key by default, so you have to follow it up with the wget -qO- https:/mykey.asc | sudo apt-key add - (<< don't to this, apt-key add will add the key to the global trust)
early days apt-add-repository also didn't support signed-by for the signing keys. Very early on when you added some PPA, it'd add the repo's GPG key to the global keyring, so you were better off not using it anyway.
There is also the possibility of using Toolbx (formerly [Fedora] Toolbox), distrobox or a container, and the underlying container's package manager. The issue then ends up being about how ergonomic it is to manage a separate guest system (and have to drop into it anytime we wish to use a binary that is unavailable in the host).
Stow only symlinks. That's even one layer below GoboLinux, and GoboLinux is not extremely active either (it is not dead, but kind of semi-dormant, that is sometimes a few changes and improvements are added, then it goes back to hibernation again).
I'm a total noob in this space but I'm using pacman, paru, yay, shelly. Are those different than "userspace package manager" or are these not relevant because it's Arch?
I haven't looked much into snap but it seems very heavyweight from the few things I've tried, which downloaded what looked like an entire OS and filled up my disk and RAM. And the fact that you run `snapd` to install a package is just... odd.
> The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago.
Each one uses their own package manager right?
What I hate is that e. g. debian puts me to conform to their FHS. I want things installed into versioned AppDirs. GoboLinux allows that; NixOS to some extent too (though they used hashed directory names). Debian does not allow me to do that. I don't want to conform to what others wrote; I want software that adjusts to my wants.
> Flatpak is more oriented towards GUI apps
Have they not recently added a mandatory systemd dependency? I can't use software that things it must force software I don't need or use onto me.
Homebrew is a non-profit project run entirely by volunteers, not employees. We need your funds to pay for software, hardware and hosting around continuous integration and future improvements to the project. Every donation will be spent on making Homebrew better for our users. Please consider a regular donation through GitHub Sponsors, OpenCollective and Patreon.
I donate to a lot of open source projects that I benefit from, but I’ve never really thought about Homebrew. I will get onto it.
Apple employees did. Not Apple themselves. As for hosting, it was hosted on an equivalent of SourceForge, where many other opensource projects unaffiliated with Apple were.
And we all know how MacPorts failed to actually gain any significant momentum.
Thanks for the update. Is there any chance we can get some kind of cooldown mechanism in Homebrew?
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.
Also, where we package things from NPM/PyPi/RubyGems that have been subject to these attacks: we already apply cooldowns for you both when packaging and when creating PRs to update to new versions.
That doc is very useful and confidence inspiring in terms of being mainly about people and process, rather than about one single technical solution.
Relevant parts for those who have cool-downs at the top of mind:
> Across Homebrew’s history far more users have been protected by shipping zero-day fixes quickly than have been exposed to npm-style token-theft or crypto-mining attacks, so a global cooldown would be a net negative for most users’ security. The deeper reason Homebrew does not need a general cooldown is that, unlike language package managers, it already separates publishing from distribution: an upstream release does not reach users until it has passed human review, CI and checksum verification, which is the very review window that language-ecosystem cooldowns are trying to recreate.
[...]
> For ecosystems with a track record of fast-moving supply-side attacks, Homebrew applies a download cooldown: a freshly-published upstream version is not adopted immediately, giving the wider community time to detect and report a malicious release before Homebrew users are exposed. Cooldowns have been added for:
Bundler
RubyGems livecheck
npm and pip defaults
PyPI resource resolution
npm and PyPI in bump
Glad to see that Homebrew is taking security seriously. Still, I want to minimize the number of parties who can quickly get new code onto my machine.
Your doc says "Human review of each release." What does that actually entail?
uv had a release at 10:21am yesterday with 7,060 additions and 2,409 deletions. The new release was available in homebrew at 11:46am. What human review happened there?
I don't know of any other OS package manager that ships code this quickly to users. Arch Linux has not pushed the new release of uv yet, for example.
Our automation or a human submitted a PR, it was built and tested in our sandboxed ephemeral CI environments, a human Homebrew maintainer reviewed the CI results and PR diff and approved it for merge which happened automatically if so.
If the ask is "who reviewed the diff": yes, a human didn't do that. That's not actually happening for all packages in any meaningful large ecosystem. I'm still unconvinced a cooldown solves that until e.g. we have an open source security scanner that runs on all Homebrew packages and requires a cooldown. Even in that case, my suggestion would be that we just run it in our own CI and block package release.
For those who don't know what broxit is talking about, they're referring to something like --minimum-release-age/minimumReleaseAge in many pieces of software and package managers to reduce vulnerability to supply chain attacks. Often times, such attacks are detected within a few days of compromise.
Most handle this by having release channels. You would `brew set-channel stable/edge`.
It annoyed me this week because I only had a few minutes to try elixir 1.20 after the announcement, and brew lagged behind. You can install erl and elixir by other means (I prefer to run my own toolchains) but it wasn’t worth doing in that moment.
Brew has or used to have a source option for some recipes and that basicallllly solves it too, if you squint.
That's only for upstream packages, i.e. what the CI pulls in when building bottles. Homebrew itself is a rolling package manager, essentially only supporting the "latest" version for each package, which doesn't work well with the usual "only install packages older than X" concept.
It's all rolling release, but Homebrew maintainers have to bump the version, not the software author (unless they put in a PR to Homebrew core or publish their own Tap). What does Arch do here?
That’s not quite true. A recipe can specify a URL to check for a new version, and the homebrew automation will periodically check it. If there’s a new version, it automates the version bump.
I used that for a package my company publishes, and neither we nor any other human AFAIK ever manually update it in homebrew, yet the newest version is always installable there.
I recently switched back to Homebrew from Nix, and the three big factors in that switch are:
- 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.)
I’m not sure what I would get out of nix-Darwin. It looks like it does not solve any of the problems I am trying to solve? I don’t need or want configuration management on my personal systems, except for the web servers, which I manage using Terraform and Ansible (I am happy with these).
We use Nix at work for all sorts of stuff. Binaries run in production from Nix paths. Software we build has dependencies in Nix. People on workstations run commands from Nix paths. The OS is not Nix, but the Nix package manager looks like it’s on its way to consuming most of our dependencies. It is not used for building or deploying our code, though.
I was interested in Nix because it could automate setup and configuration of macOS features. But all it does is usually run defaults or some intermediatary. In the end I stuck with brew and wrote an idempotent setupmac() function in my bash_profile (I use bash 5) with the aid of chatgpt since it knows all the cool defaults commands, and it’s pretty much solved setting up a new account or mac (alongside a Brewfile I maintain in my dotfiles). I don’t need any of those highfalutin tools.
I am, like, two minutes away from getting my configuration back on a fresh Mac or Linux system without Nix, so configuration management is just irrelevant to me. I am evaluating it as a package manager and a way to setup development environments.
Personally I stopped using Homebrew after I got screwed too many times on mandatory upgrades that I couldn't pin. I use a combination of Mise and MacPorts now so I don't get any more surprise breakage and forced obsolescence. Plus Mise allows me to upgrade to any new version, whereas with Homebrew you have to wait for whenever the tap feels like upgrading (llama.cpp tap skips every 10 releases)
I've moved over to MacPorts due to Homebrew's aggressive support phase-out schedule[1]. My daily driver iMac is now in the Tier-3 "go away" bucket. Absolutely loved Homebrew for the short period of time I could use it, but I'm not going to get on the hardware update treadmill just to keep using it.
I was going to ask about others having this experience. I've been using MacPorts for a couple years to install developer tooling because it's far more consistent and doesn't surprise me with new major versions of Python at random. I only use Homebrew for application installation (i.e. Firefox, Slack, Spotify, etc.) that are not available in MacPorts.
Of course, I've also made a concerted effort over the years to migrate everything to uv for Python, pnpm for nodejs, etc. so maybe it's not an issue for me anymore?
Glad you've found a workflow that works for you, genuinely.
For others still using Homebrew: a lot of work has gone into upgrading only when we absolutely have to and showing these upgrades to the user before we do them, including in this release.
I switched to MacPorts because of permission issues with brew, used it for years, then switched back after MacPorts inexplicably started wanting to install like 9000 packages just to install something small-ish like wget. Which is probably just as likely to happen with any other package manager but whatever.
Nix is also worth checking out, even if the Darwin packaging is a bit flaky. I really appreciate having cross-platform devshells when I have to alternate between Mac and Linux on a regular basis.
Mise is also cross-platform, we actually use it at work for projects we develop locally on macOS, then build in CI on Linux -- it even supports multiplatform lockfiles. I had a few tries with Nix but it's a lot to wrap your head around, Mise is simple to "just try".
The deprecation of Intel support is agressive! Every Mac enthusiast I know who uses a Mac as a server uses their old machines, which are pretty much all Intel. We'll lose support from you guys a year before Apple!
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.
> We'll lose support from you guys a year before Apple!
If only Apple put a fraction of its resources towards maintaining something like homebrew (or paying the people who do), maybe the situation would be different.
That's impressive, but I'd be reluctant to criticize one open source maintained effort for not having parity with another when it's all volunteer-driven. My point was that Apple is an insanely profitable company with resources that are effectively unlimited compared to what Homebrew has (and presumably likewise when compared to Macports), so the initial framing of "this will stop being supported before Apple" seemed pretty silly to me.
If anything, the overwhelming majority of Apple enthusiasts have gone all-in on Apple Silicon. I sincerely doubt those using old Macs as servers are anything but a rounding error.
Maybe among the general mac population they are a rounding error. But among the mac population who actually peeks behind the curtain and uses homebrew?
If your clients are all macs it is just nicer keeping the server on macos imo. mac os is unix after all so you don't have any software incompatibilities for tools you'd probably run on the server. Time machine support on the server is built in, instead of being a sort of hack with samba if you wanted to try and run it on a linux server. I haven't messed with it much but there might be some clever stuff you could do with applescript and triggered actions, maybe schedule your compute jobs from your calendar app for example.
I held onto a 2010 Mac mini server for like 11 years before retiring it due to hardware problems (blame the hot room). Time Machine is the only thing I can think of that was still relevant at the end, and even that you can do with any NAS supposedly. The macOS Server stuff was way eol, and anything worth keeping had better Linux equivalents.
Yes, to such a stunning degree that I’m having a hard time believing you’re serious. The M1 was utterly transformative. The install base of homebrew is enormous. The proportion who are keeping old Mac hardware around as home servers is minuscule. The proportion of those who are keeping old Intel Macs are a fraction of that, and the ones who aren’t just running Linux on them are yet another fraction.
That’s not to say you’re crazy or anything. You do you. But do understand that you almost certainly constitute a nearly irrelevant minority of users of homebrew.
Intel homebrew is larger than Linuxbrew, yet I think it'd be shocking if they dropped support for Linuxbrew.
Old machines still work. They're still deeply useful. I'm still using daily an Intel Macbook with homebrew on it. When I no longer use it daily in some years more, it'll still make a perfect server.
At this point that would be a 2018 Mac mini, which can only run Sequoia (which will be out-of-support at the same time as Homebrew drops Intel support).
If you want Intel support, MacPorts still runs back to Leopard.
> We'll lose support from you guys a year before Apple!
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.
Yeah they also removed support for --no-quarantine flag :/ I only use it for a few casks nowadays and try to avoid Homebrew as much as possible. For CLI stuff I use Nix, Home-Manager and Nix-Darwin.
Is there any good reason for Homebrew to keep its .tar.gz files around, even after packages are installed?
I'd personally love a "Homebrew light", compatible with most of the ecosystem (sans git taps, Ruby formulas and binary packages), written in a language with fast startup times, not keeping unnecessary files on disk, with support for parallel downloads, and terminology that is much easier for the newcomers to remember and keep straight.
Thank you for your work on Homebrew, I use it every day. On the matter of speed and parallel downloads, how does this release compare to Zerobrew [0]?
On another note, to commenters here, I've been using brew bundle with the Brewfile more and more these days as a declarative list of all user packages installed, should I just move to Mise or Nix instead? What are the benefits and drawbacks? Last time I used Nix on my MacBook a few years ago it seemed to brick my whole system so not sure what that was about.
Is Homebrew still tied to GitHub or has there been any move to provide redundancy across multiple providers?
Also coming from what I consider traditional package managers such as apt, rpm, emerge, pkg, etc. I am still confused on cans, taps, kegs, formulas, etc. Does anyone have a good and concise guide to what all these features are?
Homebrew 6.0.0 seems to be the first major version of brew that is heavily written using AI. There’s new document at https://docs.brew.sh/Responsible-AI-Usage that was added 11 hours ago. Do you think that these guidelines have been followed consistently since 5.0.0?
I would say I’ve embraced AI most heavily and I wrote this document so: yes.
I review AI written code on Homebrew the same way I review code from a no avatar GitHub user with no previous contributions.
The experimental and abandoned brew-rs frontend was more “vibe coded” using my knowledge of how to benchmark and test homebrew accurately and with a shitload of manual testing. Maybe that’s why the performance wasn’t as good as expected, who knows.
Homebrew is so good that I use it on Linux whenever possible.
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
> since you can't tell what should be removed, or more importantly, what can be removed
Isn't that what dependency detection does? Whenever I'm not sure if something can be removed, I just try to remove it, and if it would break something else, the package manager tells me. I can broaden my scope and see if that's also an unnecessary dependency for something and follow the chain, with it eventually ending up with a set of packages where I actually get the prompt to proceed or not (meaning nothing in it is a required dependency for anything remaining), or I see a package I definitely want to keep around and stop. If I'm interested in what's part of the base system, I just check the metapackage for the base system.
This doesn't sound like something that's a problem with package managers in general compared to maybe some distros just using them poorly.
Curious about this. Usually I try to get an Apt source (I use Ubuntu). Why would I want to use brew on Linux? I stopped using Macs and brew around 2018 when Apple started closing down it's macOS for a few years and got sick of it. Thanks!
I love using Homebrew but I wish there was more support for pinning. I recently setup a new remote VM and tried to use a Brewfile for my setup. Turns out I cannot pin Neovim and so had to force upgrade my setup to 0.12.
How do you square advocating for the "Open Source Resistance" which touts "stop asking for permission" to do software and then saying "we need everything on MacOS to be signed and will be dropping packages that don't get Apple's permission"?
I'd consider donating, but I find that behavior to be part of squeezing free computing and participating in and advocating for the corporate erosion of ownership of one's hardware environment.
OSS Resistance is about not asking for time to do something yourself while removal of unsigned casks is about what they host in the official Homebrew/cask repo. You're free to make & use your own tap to use with Homebrew without asking, so there's not really anything to square between the two stances - any conflict all comes purely from your 3rd stance about signing in general.
I just threw them a small donation for supporting this software for so long, even if it's only 98% how I'd want the project to be run all these years myself.
I square them because both of them allow me to do lots of open source work and enjoy it.
Your signing point is not accurate. It doesn’t apply to all packages, only casks in the official tap. With casks the trust model, particularly on things that auto-update and don’t expose versions or checksums on download URLs, heavily relies on Apple’s security guardrails. We pushed against them for a while but Apple’s direction of travel made it clear that it was a waste of our energy and that we were at risk of compromising our users through doing so.
You can still automatically remove quarantine in third-party taps as desired, we’re just making it less easy to do so because we consider it a security feature that should require a deliberate bypass.
I don’t think anyone is obliged to donate to Homebrew but this sort of framing, assuming you use Homebrew, isn’t great. If you find what we do morally distasteful: go use something else. MacPorts, Mise and Nix are all good. This will be better for everyone than using us begrudgingly.
Ah, I was excited by 'sandboxing on Linux', but it's only for build.
How many more supply chain attacks will it take for someone to build a really great sandboxing/permissioning system, that's easy enough to use that we actually use it?
Say I install an `ls` alternative (because it's on the HN front page as 'ls but in lang du jour' or whatever) – it should be really simple for me to allow it read-only access to only the passed directory. I don't think firejail or apparmour even supports that, and it'd probably take me half a day to figure it out in bubblewrap.
I just want a mobile-OS style pop-up the first time programs try to do something for me to deny, approve always, approve this time, approve by dir, or custom thing matching on the args.
It wasn't a criticism, I was just excited for a second thinking "Homebrew's doing this, I trust that it's probably doing it well, I definitely want to check this out".
You need to rethink about this tierings https://docs.brew.sh/Support-Tiers many teams have old MacOS versions for build and other purposes and they face issues when they need to use packages for old versions. For example I use fully automated machine creation (packer, tart, vmware, etc.) and when we need to update let's say Monterey image it require to compile bunch of packages which is real headache.
Thank you. It is just funny and interesting to note people seeing Homebrew as their choice of default package manager on linux! It shows that people clearly care about the technically better solution which has a very good UX over the native choices that linux distros made over years, be it apt or yum or something else.
I install homebrew as a first thing on my corporate amazon linux too as many system packages are lacking, and I couldn't get neovim in a different way.
You need to set HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS to 1, as alluded to by a hint when it (first?) occurs. This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning which is a bummer.
Ah, I suppose I did word that poorly—I more mean that a significant breaking change (Casks that previously were documented as being excluded from auto-updating suddenly being auto-updated) which can occur silently is a rough end-user experience, even if the user explicitly opted into hiding hints.
Yes this is intended. We skip those that seem to have already auto-updated underneath. Our code for this is not yet rock solid so please file issues for those you notice are not doing the right thing here.
This sort of overly eager upgrading has caused me a lot of problems over the years. I really wish it didn't default to updating the entire world just because you want to update one package.
Interesting that the `brew-rs` experiment has concluded and didn't find much of a performance increase. I suppose that is expected though with a lot of the bottleneck being network IO?
Well, I might as well ask my tech support question here :)
I just ran the upgrade to 6.0.0, and it downloaded so many things concurrently that it killed my wifi (old router). Is there a way to cap bandwidth or maximum concurrent connections? (this is something I have to do in many download heavy apps, e.g., steam)
I don't think homebrew allows throttling bandwidth but it does let you set maximum concurrent downloads though. I believe the default is twice number of cores; you must have quite a few :) Set this to your preference:
Thanks for all the work you put into this over the years. Homebrew became my go-to solution for installing software on my Macs (after MacPorts) and I just realized that someone has been doing all that work for me for so long. Much appreciated!
> The master to main migration begun in 4.6.0 continues: more repositories no longer update master, GitHub Actions warn @master users to migrate to @main and the sync-default-branches workflows are removed
I noticed the change to trust already in the previous release. To uninstall something from a not yet trusted tap, I first have to trust it, then uninstall, and then untrust it. This feels a bit weird, but maybe it makes total sense...
Just want to thank you, Mike. I love Homebrew and wouldn't know what to do without it. My company sponsor's the project on github and I recommend that everyone consider helping out.
Trying to understand if nix/nix-darwin is an alternative here. I just switched over my work machine to NixOS and I'm totally loving it. So far I've only used nix on Mac to install Wezterm, because I need the Linux and Mac versions to be exactly the same and the normal Mac downloader and Nix don't have matching versions, and that worked well.
To brew? Sort of. I use nix-darwin for everything. However, some things don’t play nice with nix. In that case you can use nix-darwin to manage brew. Basically you give it all the packages you want, and it generates a brew file and uses it.
For those of us who use homebrew today, how do we get the new cool benefits ? Is there a command to upgrade (like ```brew upgrade```) everything to the new hotness, do we need to uninstall everything and reinstall ?
It's probably discussed somewhere but didn't find when glancing at the OP.
I tried brew upgrade on my setup, got a bunch of warnings about untrusted taps, and it upgraded what it could, and updated itself to homebrew 6.0.0. So I guess, yay ?
Could really use a good rollback mechanism, is there one in the works perchance? I have broken my home server multiple times with bad InfluxDB and Grafana updates, and rollback was a huge pain. I’ve now disabled cleanup so old versions of packages are kept, but there must be a better way.
I discovered Homebrew now sometimes asks whether I actually want to install a formula (e.g. `brew install ffmpeg` asks whether I want to install it because it has dependencies). Is there a way to disable this behavior and revert to the previous one?
I know this runs on Linux too. As a Linux user, I'm unclear on why I might use this instead of apt or dnf, for example. Any Linux users out there have experience with both Homebrew and one of these?
It's for predictability in upgrades. Homebrew allows you to separate system packages (from apt or dnf) from user packages (from homebrew) [1]. Running apt upgrade or dnf upgrade can render your system unbootable if you're unlucky (or unstable or degraded if you're less unlucky). Running brew upgrade can at worst break some of your own user's setup or tools.
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
Yes. I daily drive pop os now. Hate to use flatpak for anything. Only install core packages, google chrome and vscode using apt. Almost everything else is installed using homebrew. The idea is have a base stable system for UI and basic shell. Usually get the latest packages from brew. Earlier same base system but had distrobox with arch toolbox. Planning on using this scheme going forward, especially since while I love rolling release, they sometimes might have regressions which I don’t want to deal with right away. And these regressions can be both at system level or user packages level. Having a stable base helps significantly in daily driving linux in real world.
You can have multiple versions of tools installed. But overall, homebrew plays well with atomic distros. They are thing in itself, yet getting more popular lately. Im using them at home and on the server, and it feels calmer, because I can't fuck up whole system easily. Considering I'm using llms without sandbox often, this is pure gold.
Homebrew provides access to a massive catalog of software, including many tools that are not packaged for Fedora, Debian, or Ubuntu. Homebrew relies on a high level of automation in GitHub actions, which ensures users get the latest versions of tools quickly, rather than waiting for distribution-specific repositories. The Homebrew approach also decouples the underlying system from what you choose to install in user-space.
Small note: You need admin privileges only once for the first install which creates a new user `linuxbrew` and everything is based around `/home/linuxbrew` prefix. The issue is on systems where getting an admin access is not possible, you cannot ‘reliably’ install to a different prefix. It is currently unsupported.
Honestly, I would settle for a custom prefix if it tells me exactly what packages will break and what won’t without having to read each and every formula recipe.
That’s one thing that bothered me for a while and I did not have the willpower to explore that direction without having community support.
I have been used Homebrew for years, the first choice to install an App is using the `brew install --cask` command.
But can you please support old Mac too? As you upgrade brew, many brew break for old Mac since the old library/framework. And in this situation, i had to switch from brew to macports plus brew. It's a pain for old Mac to using brew.
Does anyone know of a good comparison of the process to add a package to the system? I've used multiples of these sorts of user-land package managers and always find tools that aren't in the repositories that I have to install manually. It'd be great to just add these tools to an existing package manager but I've never seen this aspect of these package managers compared.
Adding package to homebrew is straightforward, except that it has a lot of (reasonable?) requirements to make it right. Basically, you make a PR with a "formula" to their main repo from your branch. Formulas are ruby programs. LLM can do it easily, and such code is accepted if correct.
Homebrew, mise, flox, devenv are the first ones I can think of.. Arch Linux's AURs get an honorary mention as they are used in the similar way on that distro and Arch + distrobox gets the same results. A quick search shows there are many others but it doesn't look like a comparison exists for this area and I'm getting OK results out of AI comparisons. I'll just dig into it that way.
Does this fix the issue why the aws session-manager-plugin has to be removed?
Also, what about installation directories? I always install homebrew to ~/.brew since I know I’ll always have access to my home directory without sudo.
Thanks for producing such an amazing piece of software. Most of my Mac installations are based on Homebrew, but I have to rely on version management tools like Pyenv or nvm for Python and Node. Wish there was some standard 'Homebrew' way to install multiple versions of node, php and Python
I assume this trust issue is related to the not-infrequent MacOS notifications asking for permission to run Ruby in the background or when the machine starts. It says nothing about Homebrew though.
macOS Permission Management regarding shell scripts is so bad. For example they show you a list of software thats allowed to access the full disk - but I have like 8 "sh" or "bash" in there and some random scripts with no way to open the enclosing directory in Finder making it basically impossible to see what it is and if its legit…
I will try this new release of brew but I have been extremely satisfied with determinate nix so far. It completely changed my confidence in installing new stuff
Slightly tangential, but I went to set up Homebrew today on a new Mac. Stupidly clicked the top link in Google (which was sponsored but not obviously so). Took me to a spoof Homebrew page. I ran the script. Typed in my Mac password like a fool when prompted, and nothing happened. Then I realised what an idiot I’d been.
Claude found evidence of an exfiltration malware on my laptop and I inmediately wiped the device and started again. Revoked all my keys, rotated all my passwords. And now I pray the damage is contained.
I can’t believe that Google would have let this slip through. I probably wasn't the only one that got caught out.
We’ve complained about this to Google many times to no avail. It’s very frustrating. They are literally paid money to let people install malware on your machine. Please direct all annoyance and resentment to them (we share it).
Firstly, Mike, thank you for all you've done with HomeBrew - an amazing product. None of my ire was directed at you or HomeBrew.
I am so frustrated at Google, not just for this incident, but for many reasons (like their inexplicable shutdown of my own Adsense account years ago, and their neglect of several products I'd built against or bought). When they act, they leave us with no recourse. I feel anxious being dependent on them, even for simple stuff like my email account.
They are sufficiently big that they no longer care about the little guy anymore. They are only interested in swallowing up all the World's data and cashing in on Workspace.
I've heard of that but never experienced it on my Google. Weird. I just retried that now and it's giving the correct link. Maybe that's why it's not being fixed.
I reported the ad to Google immediately, and when I checked back an hour later the search results were clear. But I suspect it's only a matter of time before another one slips through the net.
I think what happens is a legitimate business with a history of legit Google advertising gets compromised by malware, and then their Google adverts are flipped.
With NetBSD and Macports, when I need to find a file I can predict where it is almost every time. With FreeBSD, Linux, and Brew, it feels like “here we go” while I guess. Since tools in categories like this are similar, things like this end up being tie breakers for me.
Back in the day, pkgsrc was a thing (cross-platform; originally from NetBSD). Source based package distribution, it explicitly allowed for unprivileged installation to a prefix of your choice. I became very familiar with it as an ordinary Solaris user 20 years ago.
I don't understand how the tap trust improves security at all. If I'm installing something from a third-party tap, instead of running tap + install, I now run tap + trust + install? How does this protect me against compromised taps?
You can now trust individual files inside taps. It was not clear to all users before now that some commands (before —-eval-all, a mess this replaces) would evaluate all packages Ruby code from all taps). This cleans that up and some other security degrading edge cases I won’t bore you with here.
Trust is also user specific now.
It’s not a silver bullet but it does help address some potential attacks and gives us a foundation to improve on over time.
brew as-console-user may help here. We don’t support a multiuser setup so there may be some limitations but we try our best to address problems as they come up.
> Run a Homebrew command as the active macOS console user.
> This is intended for MDM, Munki and Jamf workflows where brew is invoked as root but Homebrew operations should run as the logged-in console user. The nested command is always dispatched through HOMEBREW_BREW_FILE.
This isn’t very informative. Is there more documentation somewhere else that I’m missing? Google search doesn’t really find much.
I currently have a dedicated `homebrew` user that I access with `alias brew='sudo --set-home --user=homebrew --chdir /Users/homebrew -- brew' but it’s got a number of shortcomings. What will as-console-user do differently to this?
I'll second the recommendation for `mise`, and add: I typically use Homebrew for things I want everywhere, and if I want something everywhere then the latest version is _probably_ OK. I typically use mise en place for versions which are project-specific.
So I have a system Python (largely unused), a Homebrew python (pulled in as a dependency, I won't use it), and as many different mise/uv Pythons as I need for different projects. Similarly NodeJS and Java. I'd given up on nvm a while back, no longer use pyenv, and mise and uv work together really nicely.
I tried hosting a homebrew tap, after hosting apt and yum repositories.
That was when I realized Homebrew is much, much harder.
Your server needs to implement the git protocol. You can't just stick it on some server with a CDN in front of it, you need to run and fortify a git server.
Homebrew is the first thing I install on a new Mac. I love it. Thank you everyone for all the work. Looking forward to 6.0 and all the security stuff yay. I hope the apps I use that their maintainers adopt the changes.
Dependency management is still one of the hardest jobs in systems (languages, Operating systems, distributed applications, etc) - hat's off to you and your team for the hard work keeping everything together
Has anyone tried it on Linux? It has been several months
since I last tried it on Linux. I found some things worked
but others did not. Has anyone more recent experiences here,
say, within the last 6 months, on Linux specifically?
I am using my own custom "package" manager in ruby, but
naturally it is nowhere near as sophisticated as homebrew.
I am looking more towards complementing this, but these days
I also lack time for more thorough testing, so I try to
minimize pain points (and thus also less frequently use
software written by others for the most part, unless it
is a key project such as libreoffice and what not).
There are many thousands of users of Linux homebrew, mostly users of atomic distros. I am one of them. I was so happy using homebrew that I've added new formula to its repo, far2l-tty
Does homebrew still do that insane thing when you want to upgrade a single package it tell you "hold my beer" and starts installing postgres and some obscure python version?
This behaviour came about because, before we did that we ended up upgrading just what you wanted and breaking other packages by mistake.
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.
Why is this not the default? I removed homebrew years ago, because it was just full of nasty surprises like this. Does homebrew still share dependencies? Previously you could not have package A with a transitive dependency of lib-X = v1.2 and B that requires lib-X = v.0.7.
I don't think any software has ever wasted as much of my time as Brew. I can't think of a single positive experience I have had with it. I now absolutely refuse to use it for any reason.
Hi Mike, I’m @bfontaine on GitHub (I helped maintain Homebrew in ~2014-2016). I’m always impressed at your longevity as a maintainer; it’s been like what, 16+ years you’ve been maintaining Homebrew and you’re still here, still shipping new features! Thank you for everything!
17 in September. Thanks for all your great work at the time! Hope you’re well <3
just updated to 6.0.0. already loving `brew trust <tap>` thank you for all the years of work! practically a required macos experience for me these days!
as far as cli utilities go the ux of homebrew has always been so easy to use, honestly kind of a personal benchmark for me on how repeatedly approachable it is, all commands are for whatever reason so painless to remember. i remember when apple silicon dropped and you guys followed shortly with support and the ability to switch arches, like really killer stuff so impressed with homebrew! always a treat when something im interested in tinkering with has a homebrew formula available
Goat
At the off chance that you'll see and reply to my message, I have a question
I saw a tweet by someone many years ago before I knew Homebrew was a thing. The tweet basically said "Google rejected me for not being able to invert a binary tree when 80% of Google engg use Homebrew"
Was that true?
That would be Max Howell @mxcl who started Homebrew: https://x.com/mxcl/status/608682016205344768
So the incident really happened lol
Ostensibly it did. But worth noting that despite many people still thinking of Max Howell when they think of Homebrew, he hasn’t been there for a long long time. Pretty sure he wasn’t there at the time of that Google interview, even. Mike and all the other contributors deserve much more credit for Homebrew. There are even contributors who since left who were there for longer and had a bigger impact than Max. And he had nothing to do with the Cask part.
Unfortunately, Max still clings to having created Homebrew as his greatest achievement, despite being so uninvolved for so long that just about the only thing that remains of his is the name and the beer nomenclature often confusing for newcomers. Since then, he’s been aggressively chasing whatever is popular at the time. When blockchain was all the rage, the made a package manager that leveraged it. Now he’s into AI stuff. But always, still at the top of his website and plastered everywhere whenever he pursues a project, he mentions he created Homebrew.
https://mxcl.dev/
Seventeen mentions of Homebrew on the homepage alone.
This page is kind of mad. https://mxcl.dev/homebrew/
So much repetition. I'm guessing it's targeting AI training sets? The guy really wants you to know he created Homebrew!
That page is insane
Gotten so used to brew, tap, etc never even thought how unintuitive that might be for newcomers.
Huh, I've never even considered that those words had anything to do with beer. I've just accepted them at face value, same as any other tech jargon.
The whole concept comes from homebrewing.
https://en.wikipedia.org/wiki/Homebrewing
Yeah, I guess it's not being a native English speaker, so one just accept most of the words almost as names without thinking about any other meaning the word might have.
Thank you mike!
Thank you Mike!
Thank you!
thank you mike
Homebrew is so good that I use it on Linux whenever possible.
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
> Most Linux package managers cannot separate user-installed packages from system packages.
And because of pinning versions to LTS releases on certain Linux distributions many times those packages stay out of date for years. Which is quite annoying.
> quite annoying
It's also quite stable, which you'd think more people would prize given the recent and on-going supply chain attacks.
Stable as in unchanging, sure.
Stable can also mean "you get to keep all the bugs present in this version for the next 4+ years"
Or worse, the kernel moves beyond the package in the repo so a year and a half later it doesn't even work anymore.
VirtualBox is really bad about this.
Given the recent dramatic uptick in vulnerability discoveries, it's also prone to being quite insecure...
LTS still typically get security updates. That's what the support in long term support means.
This gets thrown around a lot, but it's not entirely true. Depending on the particular distro, only certain core packages are likely to get updates on LTS releases. Non-core packages may just get left to rot until the next LTS release. Specifically Ubuntu follows this. A lot of their non-core packages just get imported from Debian and then just sit unmaintained until next release (this goes doubly if not using Ubuntu Pro).
Especially frightening when you look at how much everyday stuff is actually in the Universe repo in Ubuntu. Without Ubuntu Pro, your LTS system can sit in a very insecure state for a long time as patching Universe is "best effort" from the community.
Most popular GUI stuff is from universe, as are quite a few dev tools. Some examples: Gimp, Inkscape, pip (and a ton of python packages), most of gnome, a big chunk of KDE, htop, mariadb, etc.
See for yourself grep -h "^Package:" /var/lib/apt/lists/_universe__Packages | awk '{print $2}' | sort -u
Or to see only what you have installed from Universe: comm -12 <(dpkg-query -f '${Package}\n' -W | sort) <(grep -h "^Package:" /var/lib/apt/lists/_universe__Packages | awk '{print $2}' | sort -u)
A big repo isn't always better.
> Depending on the particular distro, only certain core packages are likely to get updates on LTS releases.
All LTS distros fix only some core packages sporadically as no one is able to back port all the patches esp. since most packages do not use CVEs and just fix bugs on the go. "Stable" for non-rolling distributions simply means "horribly broken and outdated".
It’s not horribly broken any more than your toaster is for not needing constant updates. Though I do have such a longstanding love/hate relationship with Ubuntu because of this. It is why it runs everywhere and just works (even powers the WSL2 defaults), but everything it provides also always so very far behind I end up recompiling so much important stuff by hand.
> It’s not horribly broken any more than your toaster is for not needing constant updates.
I don't know where this sense of "stable" in the community comes from. Software isn't perfect and gets fixed all the time. Yes, there are packages with different maintained stable branches that you can pin for your LTS distribution but this is by far the minority. For the other stuff you constantly have to work around missing features or existing bugs. E.g., why do I have to compile "jq" by myself just because the outdated package crashes on certain inputs?!
The "outdated" package, probably has all these security fixes [0]. That's why it exists - to maintain something safely. You step back from latest and greatest, to not get a compromised system the next time something goes wrong.
[0] https://sources.debian.org/patches/jq/1.7.1-6+deb13u2/
My personal solution for this is to install a simpler distro in chroot, alpine, and install dev newer apps in to it. Additionally, I run chroot via bwrap sandbox and have been doing this for quite some time now before flatpak became famous.
> Most Linux package managers cannot separate user-installed packages from system packages.
What is the use case when someone would want to differentiate system/user installed package? Isn't it good things that they are the same - meaning once something is install - it is there regardless of how it got here.
Two reasons come to mind for me:
1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone who just wants to run a program (again a great example being Python venvs, which at this point have decades of tooling built up around trying to make it less annoying to deal with).
2. For "cattle" systems having everything installed at the system level is generally not too much of an issue, but for "pet" systems where the user might be experimenting with things it's really nice to be able to install stuff in a way that doesn't affect anything outside of your user account even if it's also available at the system level. The computers that I personally operate from on a daily basis tend to build up a lot of crap I used once over time and removing it without just backing up my stuff and nuking it all can be a major pain.
The last-millennium solution to me-only installs is to put stuff in $HOME/bin, $HOME/lib, and $HOME/etc, and put those in the appropriate paths. Build the package with e.g. CMAKE_INSTALL_PREFIX=$HOME. At some point I switched to putting those dirs all in $HOME/opt for tidiness.
It's worked for me since workstations were shaped like pizza boxes.
I'm sure there are some things it can't do, but it goes a long way. When you're installing distributed binary packages you have less ability to control the baked-in install dirs, but if the package honors the conventional $(env) it can work.
I had this exact situation with Citrix workspace refusing to install after my upgrading to the latest Fedora. I had to force install and things did work but I would have preferred to not having to do that. I don't know enough about Homebrew to know if it would have helped (Citrix distributes .deb and .rpm files).
Honestly for python just using uv is enough, not only does it handle virtualenv for you, it will also install the necessary python version you need locally.
That’s entirely a user package manager though and is GPs point: what uv does cannot be done in a package manager like apt which sees itself as only doing system package management.
Devs shouldn't need root access to install tooling or dependencies for a project.
Mixing user and system software is like having Photoshop and all of your games install their files directly into the Windows directory.
In my current use case I'm setting up a new Ubuntu server for hosting LLMs. I didn't take notes when setting it up last time around but want to document exactly what was required to pass on to coworkers trying something similar. I don't know what packages I installed to get the minimalist setup working vs what is installed by default. I'm tempted to nuke and redo with notes but I'm sure there is a better method of tracking down what I deployed to get to the current state.
...or not, and this is why HomeBrew exists and I need to learn it or ansible/etc.
You can try this command. But I doubt it will work as intended if you have ever upgraded Ubuntu versions.
https://askubuntu.com/a/492343/1056703NixOS seems ideal for this.
Homebrew is the default on Bluefin Linux since most of the system is immutable. I like it since I’m so used to it on my Mac.
Yep homebrew on an LTS distro is pro.
Huh, didn't know you can use Homebrew on Linux
Even has Linux aarch64 bottles!
Brew is probably serving your needs, but you might also want to look into Nix/NixOS, which takes what you are talking about to the next level.
Yeah I tried nix about 8 months ago. Not really as simple as homebrew. Even the detereminate nix tutorial though nice felt too much of a hassle. I feel homebrew really is a nice interface which is pretty close to conventional package manager, while nix even though the concept is revolutionary, felt lacking in user experience. Hope the documentation improves.
I have switched my full OS-level dev env to https://mise.jdx.dev/ from Homebrew+pipx+npm, initially as an experiment but found out that it actually works amazingly well. Many things get installed directly from GitHub releases or a corresponding package manager (uv, pnpm, go get ...), zero glue code to "repackage", zero version lag. You can install any arbitrary version of a package, even multiple ones at once, and dynamically adjust which ones are active per working folder or explicitly through environments.
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.
Mise does seem to be in a class of its own. As mentioned elsewhere, it does rely on other registries such as aqua and obviously asdf. For people who want to use Mise for brew packages, there's https://github.com/kennyg/mise-zerobrew.
Glad you're having a good experience, but I personally switched from Mise back to Brew. I don't know if it was just my skill issue, but there were too many packages which found Mise to be problematic.
Haven't had any serious problems so far!
When did you start using Mise? Maybe it's because I was a sort of early adopter.
I've been using it lightly as a "better nvm" for a longer time, but only switched to it as a primary "tool installer" a few months ago. I've seen it improve quite a lot over the time, you could give it another try!
As a PHP developer, I found mise's support to be pretty sub-par compared to Shivam Mathur's packaging work for homebrew. Most of my projects are using Docker anyway, the local PHP is for stuff like static analysis that doesn't need it. And I've got a couple using Nix, which laughs at everything else (but damn, the overall UX is still even more hostile than git).
Yeah same issue with haskell. Apparently not many languages are supported by mise.
mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools")
This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.
Thank you for making Mise!
I like mise a lot, but only use it for project specific tool management, JDK versions, etc.
I tried to use it for system wide things, but found it didn't work as well for me with things that I wanted to just be tools where I didn't care what specific version it was as long as it was more or less current, Helix, NeoVim, RipGrep, etc.
mise use -g ripgrep@latest
I recently found mise and have become a fan as well. I have used asdf for about a decade and it supports the same .tool-versions files so initially I used it for those exact same things.
But I use four different computers for development regularly and sometimes use Codespaces as well. While syncing dotfiles handles most of my setup, it doesn't handle binary dependencies of my dotfiles - my neovim setup wants fd & rg etc. So now those go in the mise global config. I also have a global node & python along with uv@latest which pretty much covers every tool I might want to install.
I have never cared for the fact that homebrew tries to maintain shared dependencies and several upgrades have broken stuff for me.
For system-wide things I usually use "latest" but it's nice being able to downgrade and/or stick to a working version using lockfiles. I remember back when I used Homebrew, Teleport shipped a bug that prevented me from accessing our servers and downgrading was a pain.
I did the same but with Nix.
Me too, but it definitely doesn't qualify as "zero glue code."
me too but feels like bringing bazooka to a watergun fight. might go back to brew
Mise’s refusal to make global packages globally available is off-putting. I keep using it for specific Node versions and the integration with fnox.
The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.
What do you mean by that? If you have mise activate set up correctly in your shell rc file, globally installed tools are available in every shell. There’s also shim mode [1].
I use Claude on a mise-powered project daily without any issues
[1] https://mise.jdx.dev/dev-tools/shims.html
Not an expert, but Claude doesn’t seem to be running with my ZSH profile? Really, anything that isn’t a terminal and tries to use global commands, such as utilities that expect Node to be available and so on. I always have to prefix commands, unless using the terminal myself.
Mise does support docker cli - that’s how I use it with Colima - what’s not working for you?
Last time I used it it was missing some features (like compose for example), but nothing a LLM can't fix (needed just some symlinking).
But it's not "it just works" yet.
Mise actually does support a primitive dependency system, you can specify package deps in your config, so, for example, you can ensure erlangs are installed before elixirs (bad example, elixir is already internally dependent on erlangs, but you get the idea)
https://mise.jdx.dev/dev-tools/#tool-dependencies
Hmm, `mise use -g docker-cli` works for me. `docker compose` is a bit trickier – it gets installed as `docker-cli-plugin-docker-compose`, but docker-cli doesn’t seem to pick it up. I’ve added a symlink as `docker-compose` for the time being.
Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).
FWIW you can replace pngpaste with a simple script: https://til.simonwillison.net/macos/impaste
Zbar seems to provide prebuilt binaries here https://linuxtv.org/downloads/zbar/binaries/ (haven't checked it myself)
Thanks for the docker tip!
> FWIW you can replace pngpaste with a simple script
Neat! Got curious if you can do that without a temp file, turns out you can:
---Edit:
> `docker compose` is a bit trickier
I’ve tweaked my setup a bit. This installs it as `docker-compose` without symlinking required:
And also you can manually symlink it to the Docker plugins dir so `docker compose` works as well:I really like mise but I don’t think it’s an adequate homebrew replacement. I use it more for project management dependencies and tasks.
Do you have an example? Sounds interesting.
Here's my modest collection of global tools I install in my dotfiles: https://github.com/JanPokorny/dotfiles/blob/master/dot_confi...
Projects then have their own dependencies, e.g. https://github.com/i-am-bee/agentstack/blob/main/mise.toml
Mise also has a task runner which automatically uses correct tools. Onboarding a new team member is super easy now, they just need Mise, "mise install" and they're up.
I really prefer to lock the version numbers instead:
I can commit/rollback to known good versions. To upgrade: Not so long ago, I was outspoken against mise. I've since come around. It truly is a fantastic tool.Mise now has lockfiles as a stable feature, which has the benefit of hash checking if you use Mise in a CI environment!
What were your criticisms, and what changed?
I've been using mise as a pure version manager for a pretty long time, and I had no idea you could use it for general tools like this.
Same
How does this even work? How does mise know how to install these things?
Mise has many backends. A lot comes from Aqua / asdf, but there's others like GitHub, npm, cargo, http, etc.
It's all fairly well documented here: https://mise.jdx.dev/dev-tools/backends/
Don't forget that mise depends on package registries, to install itself as well as its tools.
Mise installs itself as a static binary actually (but it's of course packaged in many registries), and while there are some third party registries it delegates to for some packages (aqua, asfd), most stuff I have installed is either built-in, or from PyPI, npm or GitHub, i.e. directly published by the upstream maintainers. More info: https://mise.jdx.dev/dev-tools/backends/
You'll see that mise recommends installing itself exclusively through package registries: https://mise.jdx.dev/installing-mise.html
pypi, npm, and even github (through releases) are registries.
curl | sh is an anti-pattern. It passes no security check.
There's always the chicken/egg problem of which dependency manager to install first, though. AFAIK there's no "trusted" installed for Homebrew on macOS though I might be wrong.
Exclusively? No, the very first option is the install script, which downloads and unpacks the correct binary for your OS from the Mise website:
curl https://mise.run | sh
...which is the same way Homebrew is installed too.
That's kind of weird that you're using this announcement to steer people to another project.
Or am I missing something..?
We're discussing Homebrew now, which includes discussing alternatives, and I'm telling my story of switching to a tool that I found better for my purposes. I'm not affiliated or anything. I agree this comment would be weird e.g. on the official Homebrew blog.
I agree, but HN doesn't like metacomments that just complain on how an article/comment is being upvoted, hence you being downvoted. See guidelines: https://news.ycombinator.com/newsguidelines.html
Just downvote and move on.
I see. OK, I'll do that next time, thanks.
Thanks for all the hard work.
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
The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago. It's ridiculous that the usual situation for non-root users is "you can't install XY but feel free to build from source". Homebrew, Mise and Nix are filling that hole now. (Flatpak is more oriented towards GUI apps, and Snap... exists.)
At the very least, Linux package managers should have some concept of different layers of packages.
For example, there might be layers for “system” (core components), “environment” (display manager, DE, etc), and “user”, each of which are maintained fully separately so they can’t ever step on each others’ toes and break things. Yes, it means there will be some redundancy but for all the trouble and complexity it’s saving I think it’s a worthwhile tradeoff.
Most "immutable" distro flavors do something like this. Back when I ran Aurora, it was rpm-ostree for the core system packages and homebrew in a devbox container for the rest. One incentive for maintaining the layer separation was that rpm-ostree was slow.
I've since moved my desktop box to NixOS, where everything is just flakes, but my mac runs circles around it so it's just there for Steam nowadays.
I love brew but it was decades of tradition to download source and compile as non-root on shared Unix systems. Not only were the sysadmins skilled at saying no, they were not always available at 2 am, but installing some random code, after editing the Makefile to reflect some oddity of something, was 24x7. And then when we got better offers than shared dial up hosting, it was root or nothing.
To be sure it is ridiculous, but it is also traditional.
One of the frustrating limits historically with some of these is that when you're already an unprivileged user it's been difficult or impossible to get to a sandboxed environment to perform hermetic or untrusted builds. So like with nix for example you could do a user install and then builds would build as your user, but if you installed as root, then builds would delegate out properly to nixbld users.
This has gotten better in recent years with user namespaces but it takes time for it to be adopted and achieve parity with what used to be just jumping to a user who can only write to a newly created dir in tmp.
In Debian-Ubuntu it's become a standard pattern to use `curl` or `wget` to add a third-party `deb` repo with keychain integration, because for whatever reason there's still no `apt` command for this obvious scenario. Really grinds my gears.
That is not a "userspace package manager" though. That still requires root.
Doesn't apt-add-repository do all that?
For whatever reason, nobody seems to use it. It must be a good reason or else they would. [PS: It's because it doesn't add the signing keys and maybe also because it's too associated with Ubuntu.] This, for example, is the official way to add Mozilla's repo:
And here's Signal's instructions: Bonkers.I believe apt-add-repository started out as Ubuntu specific for their PPA system, didn't it? It's part of the software-properties-common package.
When using it without a PPA (just giving in the repo URL) it won't add the key by default, so you have to follow it up with the wget -qO- https:/mykey.asc | sudo apt-key add - (<< don't to this, apt-key add will add the key to the global trust)
early days apt-add-repository also didn't support signed-by for the signing keys. Very early on when you added some PPA, it'd add the repo's GPG key to the global keyring, so you were better off not using it anyway.
There is also the possibility of using Toolbx (formerly [Fedora] Toolbox), distrobox or a container, and the underlying container's package manager. The issue then ends up being about how ergonomic it is to manage a separate guest system (and have to drop into it anytime we wish to use a binary that is unavailable in the host).
Well, there was stow/xstow...
https://www.gnu.org/software/stow/
https://xstow.sourceforge.net/
Stow only symlinks. That's even one layer below GoboLinux, and GoboLinux is not extremely active either (it is not dead, but kind of semi-dormant, that is sometimes a few changes and improvements are added, then it goes back to hibernation again).
I'm a total noob in this space but I'm using pacman, paru, yay, shelly. Are those different than "userspace package manager" or are these not relevant because it's Arch?
User, as in non-root/non-admin. Pacman, paru, yay, shelly ask for root permissions.
I looked around and found this fun project -- basically "Arch Linux in userspace on top of any other Linux": https://github.com/fsquillace/junest
I haven't looked much into snap but it seems very heavyweight from the few things I've tried, which downloaded what looked like an entire OS and filled up my disk and RAM. And the fact that you run `snapd` to install a package is just... odd.
PufPufPuf wrote:
> The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago.
Each one uses their own package manager right?
What I hate is that e. g. debian puts me to conform to their FHS. I want things installed into versioned AppDirs. GoboLinux allows that; NixOS to some extent too (though they used hashed directory names). Debian does not allow me to do that. I don't want to conform to what others wrote; I want software that adjusts to my wants.
> Flatpak is more oriented towards GUI apps
Have they not recently added a mandatory systemd dependency? I can't use software that things it must force software I don't need or use onto me.
I've been using it under linux and have been very (surprisingly?) happy with how it runs especially when compared with current package managers.
I'm using nix on Bazzite, with home-manager
Homebrew is a non-profit project run entirely by volunteers, not employees. We need your funds to pay for software, hardware and hosting around continuous integration and future improvements to the project. Every donation will be spent on making Homebrew better for our users. Please consider a regular donation through GitHub Sponsors, OpenCollective and Patreon.
I donate to a lot of open source projects that I benefit from, but I’ve never really thought about Homebrew. I will get onto it.
I'm amazed they're not sponsored by Apple themselves, or at the very least major mac-forward Dev houses.
If it wasn't for Brew, macOS would have no chance against Linux as a dev platform.
I think you're right - it's one of the reasons I prefer a mac as a dev platform.
Apple developed — and for many years afterwards, hosted —- MacPorts.
Apple employees did. Not Apple themselves. As for hosting, it was hosted on an equivalent of SourceForge, where many other opensource projects unaffiliated with Apple were.
And we all know how MacPorts failed to actually gain any significant momentum.
No, Apple employees originally authored the project on Apple’s time.
And it was first hosted at OpenDarwin — which was Apple-run and not available for arbitrary public hosting.
It was then hosted at OpenDarwin’s successor — Mac OS Forge. That was also Apple-run and not available for arbitrary project hosting.
MacPorts was an Apple-authored and ultimately Apple-supported project for ~15 years.
As for momentum, the project is still going strong 25 years later, so I’m not really sure what you’re referring to.
> As for momentum, the project is still going strong 25 years later, so I’m not really sure what you’re referring to.
I am referring to a significant momentum. You know, like the momentum Brew has.
Thanks for the update. Is there any chance we can get some kind of cooldown mechanism in Homebrew?
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.
https://docs.brew.sh/Supply-Chain-Security details how we’re handling cooldowns and why we have a very different risk profile to e.g. NPM.
Also, where we package things from NPM/PyPi/RubyGems that have been subject to these attacks: we already apply cooldowns for you both when packaging and when creating PRs to update to new versions.
That doc is very useful and confidence inspiring in terms of being mainly about people and process, rather than about one single technical solution.
Relevant parts for those who have cool-downs at the top of mind:
> Across Homebrew’s history far more users have been protected by shipping zero-day fixes quickly than have been exposed to npm-style token-theft or crypto-mining attacks, so a global cooldown would be a net negative for most users’ security. The deeper reason Homebrew does not need a general cooldown is that, unlike language package managers, it already separates publishing from distribution: an upstream release does not reach users until it has passed human review, CI and checksum verification, which is the very review window that language-ecosystem cooldowns are trying to recreate.
[...]
> For ecosystems with a track record of fast-moving supply-side attacks, Homebrew applies a download cooldown: a freshly-published upstream version is not adopted immediately, giving the wider community time to detect and report a malicious release before Homebrew users are exposed. Cooldowns have been added for:
Just a FYI: Bundler now supports cooldown [1].
[1]: "Cool down before you install: give new gems a few days to be vetted" - https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-b...
Glad to see that Homebrew is taking security seriously. Still, I want to minimize the number of parties who can quickly get new code onto my machine.
Your doc says "Human review of each release." What does that actually entail?
uv had a release at 10:21am yesterday with 7,060 additions and 2,409 deletions. The new release was available in homebrew at 11:46am. What human review happened there?
I don't know of any other OS package manager that ships code this quickly to users. Arch Linux has not pushed the new release of uv yet, for example.
Our automation or a human submitted a PR, it was built and tested in our sandboxed ephemeral CI environments, a human Homebrew maintainer reviewed the CI results and PR diff and approved it for merge which happened automatically if so.
If the ask is "who reviewed the diff": yes, a human didn't do that. That's not actually happening for all packages in any meaningful large ecosystem. I'm still unconvinced a cooldown solves that until e.g. we have an open source security scanner that runs on all Homebrew packages and requires a cooldown. Even in that case, my suggestion would be that we just run it in our own CI and block package release.
> Even in that case, my suggestion would be that we just run it in our own CI and block package release.
I agree.
> open source security scanner that runs on all Homebrew packages and requires a cooldown.
I think that is where all this is going in the longterm.
Until then, any upstream shenanigans are more likely to surface in hours 0-48 after a new release than hours 0-4.
+1
For those who don't know what broxit is talking about, they're referring to something like --minimum-release-age/minimumReleaseAge in many pieces of software and package managers to reduce vulnerability to supply chain attacks. Often times, such attacks are detected within a few days of compromise.
Here's Bun's, as an example: https://bun.com/docs/pm/cli/install#minimum-release-age
Most handle this by having release channels. You would `brew set-channel stable/edge`.
It annoyed me this week because I only had a few minutes to try elixir 1.20 after the announcement, and brew lagged behind. You can install erl and elixir by other means (I prefer to run my own toolchains) but it wasn’t worth doing in that moment.
Brew has or used to have a source option for some recipes and that basicallllly solves it too, if you squint.
It's in this release, see this section:
> Cooldowns, livecheck and bumping
That's only for upstream packages, i.e. what the CI pulls in when building bottles. Homebrew itself is a rolling package manager, essentially only supporting the "latest" version for each package, which doesn't work well with the usual "only install packages older than X" concept.
It's all rolling release, but Homebrew maintainers have to bump the version, not the software author (unless they put in a PR to Homebrew core or publish their own Tap). What does Arch do here?
That’s not quite true. A recipe can specify a URL to check for a new version, and the homebrew automation will periodically check it. If there’s a new version, it automates the version bump.
I used that for a package my company publishes, and neither we nor any other human AFAIK ever manually update it in homebrew, yet the newest version is always installable there.
100% need this.
I recently switched back to Homebrew from Nix, and the three big factors in that switch are:
- 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.)
I use nix-darwin and also manage my homebrew packages with it. Maybe you can take a look at that.
May I ask for what do you use it at work? I have a few places I think nix might suit but I can’t really put my finger on it.
I’m not sure what I would get out of nix-Darwin. It looks like it does not solve any of the problems I am trying to solve? I don’t need or want configuration management on my personal systems, except for the web servers, which I manage using Terraform and Ansible (I am happy with these).
We use Nix at work for all sorts of stuff. Binaries run in production from Nix paths. Software we build has dependencies in Nix. People on workstations run commands from Nix paths. The OS is not Nix, but the Nix package manager looks like it’s on its way to consuming most of our dependencies. It is not used for building or deploying our code, though.
I was interested in Nix because it could automate setup and configuration of macOS features. But all it does is usually run defaults or some intermediatary. In the end I stuck with brew and wrote an idempotent setupmac() function in my bash_profile (I use bash 5) with the aid of chatgpt since it knows all the cool defaults commands, and it’s pretty much solved setting up a new account or mac (alongside a Brewfile I maintain in my dotfiles). I don’t need any of those highfalutin tools.
I am, like, two minutes away from getting my configuration back on a fresh Mac or Linux system without Nix, so configuration management is just irrelevant to me. I am evaluating it as a package manager and a way to setup development environments.
Very glad to hear this, thanks for posting.
Personally I stopped using Homebrew after I got screwed too many times on mandatory upgrades that I couldn't pin. I use a combination of Mise and MacPorts now so I don't get any more surprise breakage and forced obsolescence. Plus Mise allows me to upgrade to any new version, whereas with Homebrew you have to wait for whenever the tap feels like upgrading (llama.cpp tap skips every 10 releases)
I've moved over to MacPorts due to Homebrew's aggressive support phase-out schedule[1]. My daily driver iMac is now in the Tier-3 "go away" bucket. Absolutely loved Homebrew for the short period of time I could use it, but I'm not going to get on the hardware update treadmill just to keep using it.
1: https://docs.brew.sh/Support-Tiers
I was going to ask about others having this experience. I've been using MacPorts for a couple years to install developer tooling because it's far more consistent and doesn't surprise me with new major versions of Python at random. I only use Homebrew for application installation (i.e. Firefox, Slack, Spotify, etc.) that are not available in MacPorts.
Of course, I've also made a concerted effort over the years to migrate everything to uv for Python, pnpm for nodejs, etc. so maybe it's not an issue for me anymore?
Glad you've found a workflow that works for you, genuinely.
For others still using Homebrew: a lot of work has gone into upgrading only when we absolutely have to and showing these upgrades to the user before we do them, including in this release.
and i `brew update && brew upgrade --greedy` every morning with my first cup of coffee because i like to live on the edge like that
thanks for all your work!
I'm in the "switched most to Mise" stage, might look into MacPorts for the remaining stuff, thanks for the tip!
I switched to MacPorts because of permission issues with brew, used it for years, then switched back after MacPorts inexplicably started wanting to install like 9000 packages just to install something small-ish like wget. Which is probably just as likely to happen with any other package manager but whatever.
Nix is also worth checking out, even if the Darwin packaging is a bit flaky. I really appreciate having cross-platform devshells when I have to alternate between Mac and Linux on a regular basis.
Mise is also cross-platform, we actually use it at work for projects we develop locally on macOS, then build in CI on Linux -- it even supports multiplatform lockfiles. I had a few tries with Nix but it's a lot to wrap your head around, Mise is simple to "just try".
Nix has a high learning curve. I now use Devbox [0] as it hides all the complexity of Nix while still giving all the benefits.
Now I install far more packages via devbox (or devbox global) than I do via HomeBrew (on osx) or pacman (on arch).
[0] - https://www.jetify.com/devbox
This is somewhat impressive, but can you reverse a binary tree?!
https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
Yeah, I remember this story too. Crazy, it most definitely feels like the organization missed an opportunity.
The deprecation of Intel support is agressive! Every Mac enthusiast I know who uses a Mac as a server uses their old machines, which are pretty much all Intel. We'll lose support from you guys a year before Apple!
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.
> We'll lose support from you guys a year before Apple!
If only Apple put a fraction of its resources towards maintaining something like homebrew (or paying the people who do), maybe the situation would be different.
MacPorts supports everything all the way back to 10.5/powerpc.
That's impressive, but I'd be reluctant to criticize one open source maintained effort for not having parity with another when it's all volunteer-driven. My point was that Apple is an insanely profitable company with resources that are effectively unlimited compared to what Homebrew has (and presumably likewise when compared to Macports), so the initial framing of "this will stop being supported before Apple" seemed pretty silly to me.
If anything, the overwhelming majority of Apple enthusiasts have gone all-in on Apple Silicon. I sincerely doubt those using old Macs as servers are anything but a rounding error.
Maybe among the general mac population they are a rounding error. But among the mac population who actually peeks behind the curtain and uses homebrew?
Maybe I’m just biased because it’s what I’ve done personally, but almost everyone using an old Intel Mac as a server is surely running Linux?
If your clients are all macs it is just nicer keeping the server on macos imo. mac os is unix after all so you don't have any software incompatibilities for tools you'd probably run on the server. Time machine support on the server is built in, instead of being a sort of hack with samba if you wanted to try and run it on a linux server. I haven't messed with it much but there might be some clever stuff you could do with applescript and triggered actions, maybe schedule your compute jobs from your calendar app for example.
I held onto a 2010 Mac mini server for like 11 years before retiring it due to hardware problems (blame the hot room). Time Machine is the only thing I can think of that was still relevant at the end, and even that you can do with any NAS supposedly. The macOS Server stuff was way eol, and anything worth keeping had better Linux equivalents.
Which Linux are you using for that?
Yes, to such a stunning degree that I’m having a hard time believing you’re serious. The M1 was utterly transformative. The install base of homebrew is enormous. The proportion who are keeping old Mac hardware around as home servers is minuscule. The proportion of those who are keeping old Intel Macs are a fraction of that, and the ones who aren’t just running Linux on them are yet another fraction.
That’s not to say you’re crazy or anything. You do you. But do understand that you almost certainly constitute a nearly irrelevant minority of users of homebrew.
From elsewhere in the thread, some hard numbers on the topic. https://formulae.brew.sh/analytics/homebrew-os-arch-ci/30d/
Intel homebrew is larger than Linuxbrew, yet I think it'd be shocking if they dropped support for Linuxbrew.
Old machines still work. They're still deeply useful. I'm still using daily an Intel Macbook with homebrew on it. When I no longer use it daily in some years more, it'll still make a perfect server.
At this point that would be a 2018 Mac mini, which can only run Sequoia (which will be out-of-support at the same time as Homebrew drops Intel support).
If you want Intel support, MacPorts still runs back to Leopard.
And all 27" iMacs.
My server is an old mac we've upgraded. My home server is an iMac.
> We'll lose support from you guys a year before Apple!
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.
Yeah they also removed support for --no-quarantine flag :/ I only use it for a few casks nowadays and try to avoid Homebrew as much as possible. For CLI stuff I use Nix, Home-Manager and Nix-Darwin.
Well nix and devenv are also dropping intel mac support due to apple cutting off support : (
AFAIK, github action runner for intel will be deprecated at similar period, maybe that is major reason.
A saving grace is they're perfect for linux distros.
Does brew gather statistics that could show what portion of users is on Intel vs Apple Silicon?
https://formulae.brew.sh/analytics/homebrew-os-arch-ci/30d/
From people who haven’t disabled analytics.
Is there any good reason for Homebrew to keep its .tar.gz files around, even after packages are installed?
I'd personally love a "Homebrew light", compatible with most of the ecosystem (sans git taps, Ruby formulas and binary packages), written in a language with fast startup times, not keeping unnecessary files on disk, with support for parallel downloads, and terminology that is much easier for the newcomers to remember and keep straight.
Thank you for your work on Homebrew, I use it every day. On the matter of speed and parallel downloads, how does this release compare to Zerobrew [0]?
On another note, to commenters here, I've been using brew bundle with the Brewfile more and more these days as a declarative list of all user packages installed, should I just move to Mise or Nix instead? What are the benefits and drawbacks? Last time I used Nix on my MacBook a few years ago it seemed to brick my whole system so not sure what that was about.
[0] https://github.com/lucasgelfond/zerobrew
Most nix users still use brew for casks on mac. Using brew bundle as your interface to it makes things almost seamless, so its not too icky overall.
eg I manage my Brewfile declaratively with home-manager, and then run this on file change
Shoutout to all the people making Homebrew possible! You rock! Everyone should consider donating to the project: https://opencollective.com/homebrew
Is Homebrew still tied to GitHub or has there been any move to provide redundancy across multiple providers?
Also coming from what I consider traditional package managers such as apt, rpm, emerge, pkg, etc. I am still confused on cans, taps, kegs, formulas, etc. Does anyone have a good and concise guide to what all these features are?
Homebrew 6.0.0 seems to be the first major version of brew that is heavily written using AI. There’s new document at https://docs.brew.sh/Responsible-AI-Usage that was added 11 hours ago. Do you think that these guidelines have been followed consistently since 5.0.0?
I would say I’ve embraced AI most heavily and I wrote this document so: yes.
I review AI written code on Homebrew the same way I review code from a no avatar GitHub user with no previous contributions.
The experimental and abandoned brew-rs frontend was more “vibe coded” using my knowledge of how to benchmark and test homebrew accurately and with a shitload of manual testing. Maybe that’s why the performance wasn’t as good as expected, who knows.
I totally missed the memo that Homebrew has supported Linux since 2019.
https://brew.sh/2019/02/02/homebrew-2.0.0/
Is it true that contributors to homebrew need to know how to invert a binary tree?
Not sure if everyone is going to get your joke, but it's a very good one.
Can you explain the joke?
https://news.ycombinator.com/item?id=9695102
Homebrew is so good that I use it on Linux whenever possible.
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
> since you can't tell what should be removed, or more importantly, what can be removed
Isn't that what dependency detection does? Whenever I'm not sure if something can be removed, I just try to remove it, and if it would break something else, the package manager tells me. I can broaden my scope and see if that's also an unnecessary dependency for something and follow the chain, with it eventually ending up with a set of packages where I actually get the prompt to proceed or not (meaning nothing in it is a required dependency for anything remaining), or I see a package I definitely want to keep around and stop. If I'm interested in what's part of the base system, I just check the metapackage for the base system.
This doesn't sound like something that's a problem with package managers in general compared to maybe some distros just using them poorly.
Curious about this. Usually I try to get an Apt source (I use Ubuntu). Why would I want to use brew on Linux? I stopped using Macs and brew around 2018 when Apple started closing down it's macOS for a few years and got sick of it. Thanks!
> around 2018 when Apple started closing down it's macOS
Did I miss the memo?
I love using Homebrew but I wish there was more support for pinning. I recently setup a new remote VM and tried to use a Brewfile for my setup. Turns out I cannot pin Neovim and so had to force upgrade my setup to 0.12.
Forced upgrades are not nice.
Try `brew version-install` (which uses `brew extract` and `brew tap-new` under the hood)
How do you square advocating for the "Open Source Resistance" which touts "stop asking for permission" to do software and then saying "we need everything on MacOS to be signed and will be dropping packages that don't get Apple's permission"?
I'd consider donating, but I find that behavior to be part of squeezing free computing and participating in and advocating for the corporate erosion of ownership of one's hardware environment.
OSS Resistance is about not asking for time to do something yourself while removal of unsigned casks is about what they host in the official Homebrew/cask repo. You're free to make & use your own tap to use with Homebrew without asking, so there's not really anything to square between the two stances - any conflict all comes purely from your 3rd stance about signing in general.
I just threw them a small donation for supporting this software for so long, even if it's only 98% how I'd want the project to be run all these years myself.
I square them because both of them allow me to do lots of open source work and enjoy it.
Your signing point is not accurate. It doesn’t apply to all packages, only casks in the official tap. With casks the trust model, particularly on things that auto-update and don’t expose versions or checksums on download URLs, heavily relies on Apple’s security guardrails. We pushed against them for a while but Apple’s direction of travel made it clear that it was a waste of our energy and that we were at risk of compromising our users through doing so.
You can still automatically remove quarantine in third-party taps as desired, we’re just making it less easy to do so because we consider it a security feature that should require a deliberate bypass.
I don’t think anyone is obliged to donate to Homebrew but this sort of framing, assuming you use Homebrew, isn’t great. If you find what we do morally distasteful: go use something else. MacPorts, Mise and Nix are all good. This will be better for everyone than using us begrudgingly.
Ah, I was excited by 'sandboxing on Linux', but it's only for build.
How many more supply chain attacks will it take for someone to build a really great sandboxing/permissioning system, that's easy enough to use that we actually use it?
Say I install an `ls` alternative (because it's on the HN front page as 'ls but in lang du jour' or whatever) – it should be really simple for me to allow it read-only access to only the passed directory. I don't think firejail or apparmour even supports that, and it'd probably take me half a day to figure it out in bubblewrap.
I just want a mobile-OS style pop-up the first time programs try to do something for me to deny, approve always, approve this time, approve by dir, or custom thing matching on the args.
Sounds like a great idea, thanks for volunteering to pitch in and help!
It wasn't a criticism, I was just excited for a second thinking "Homebrew's doing this, I trust that it's probably doing it well, I definitely want to check this out".
You need to rethink about this tierings https://docs.brew.sh/Support-Tiers many teams have old MacOS versions for build and other purposes and they face issues when they need to use packages for old versions. For example I use fully automated machine creation (packer, tart, vmware, etc.) and when we need to update let's say Monterey image it require to compile bunch of packages which is real headache.
Thank you. It is just funny and interesting to note people seeing Homebrew as their choice of default package manager on linux! It shows that people clearly care about the technically better solution which has a very good UX over the native choices that linux distros made over years, be it apt or yum or something else.
I install homebrew as a first thing on my corporate amazon linux too as many system packages are lacking, and I couldn't get neovim in a different way.
Awesome! Thank you for the update.
I 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...
You need to set HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS to 1, as alluded to by a hint when it (first?) occurs. This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning which is a bummer.
See also: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...
> This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning which is a bummer.
I read this as "This means if you close your eyes you don’t see things, which is a bummer."
This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning which is a bummer.
When you instruct the system not to tell you things, the system not telling you those things is a bummer?
If I could get more of the tech I interact with to stop doing things I didn't ask it to, it would reduce a lot of stress and wasted time.
Ah, I suppose I did word that poorly—I more mean that a significant breaking change (Casks that previously were documented as being excluded from auto-updating suddenly being auto-updated) which can occur silently is a rough end-user experience, even if the user explicitly opted into hiding hints.
Yes this is intended. We skip those that seem to have already auto-updated underneath. Our code for this is not yet rock solid so please file issues for those you notice are not doing the right thing here.
This sort of overly eager upgrading has caused me a lot of problems over the years. I really wish it didn't default to updating the entire world just because you want to update one package.
Interesting that the `brew-rs` experiment has concluded and didn't find much of a performance increase. I suppose that is expected though with a lot of the bottleneck being network IO?
Well, I might as well ask my tech support question here :)
I just ran the upgrade to 6.0.0, and it downloaded so many things concurrently that it killed my wifi (old router). Is there a way to cap bandwidth or maximum concurrent connections? (this is something I have to do in many download heavy apps, e.g., steam)
I don't think homebrew allows throttling bandwidth but it does let you set maximum concurrent downloads though. I believe the default is twice number of cores; you must have quite a few :) Set this to your preference:
HOMEBREW_DOWNLOAD_CONCURRENCY
You could use network link conditioner to artificially limit, or one of the apps that can enforce per app limits such as tripmode
Is the eventual goal to move most formula/cask behavior into declarative install steps and treat Ruby as an escape hatch?
Yes, exactly. The goal is you can install all official packages without needing custom postinstall/preflight/postflight blocks.
I used OSX for about a year about 10 years ago. Homebrew was what made it worth using OSX. Thanks for all the effort put into homebrew.
I'd use it today on Linux, but I'm pretty anal about only using software from the distribution repos (or compiled locally if not available.)
Is there a way to run the cask/tap search via browser address-bar %s? Like this: https://www.digikey.com/de/products?keywords=%s
Thanks for all the work you put into this over the years. Homebrew became my go-to solution for installing software on my Macs (after MacPorts) and I just realized that someone has been doing all that work for me for so long. Much appreciated!
> The master to main migration begun in 4.6.0 continues: more repositories no longer update master, GitHub Actions warn @master users to migrate to @main and the sync-default-branches workflows are removed
Speaking of important things.
I noticed the change to trust already in the previous release. To uninstall something from a not yet trusted tap, I first have to trust it, then uninstall, and then untrust it. This feels a bit weird, but maybe it makes total sense...
This sounds like a bug. Can you file an issue?
Just want to thank you, Mike. I love Homebrew and wouldn't know what to do without it. My company sponsor's the project on github and I recommend that everyone consider helping out.
Thanks for the kind words and sponsorship <3
Trying to understand if nix/nix-darwin is an alternative here. I just switched over my work machine to NixOS and I'm totally loving it. So far I've only used nix on Mac to install Wezterm, because I need the Linux and Mac versions to be exactly the same and the normal Mac downloader and Nix don't have matching versions, and that worked well.
To brew? Sort of. I use nix-darwin for everything. However, some things don’t play nice with nix. In that case you can use nix-darwin to manage brew. Basically you give it all the packages you want, and it generates a brew file and uses it.
Is there a way to `brew trust` inside my Brewfile? That'd be nice for the handful of formulas I install from github repos via `brew bundle --global`.
This is described here (https://docs.brew.sh/Tap-Trust) if you scroll down a bit.
`brew tap/recipe, trusted: true`
I’ve also dropped nix-darwin for homebrew on my new m5.
Fantastic work Mike and team, though I’m still a little confused about cask upgrades.
Congrats on the performance improvements. That's the most pleasant `brew upgrade` session I've had in years
For those of us who use homebrew today, how do we get the new cool benefits ? Is there a command to upgrade (like ```brew upgrade```) everything to the new hotness, do we need to uninstall everything and reinstall ?
It's probably discussed somewhere but didn't find when glancing at the OP.
there is `brew update`
sure, but is that doing the same as deleting all installed sw and then reinstalling it using the new safeguards?
Assuming I have already installed something homebrew 6 would not let install, will I get a warning?
I tried brew upgrade on my setup, got a bunch of warnings about untrusted taps, and it upgraded what it could, and updated itself to homebrew 6.0.0. So I guess, yay ?
Could really use a good rollback mechanism, is there one in the works perchance? I have broken my home server multiple times with bad InfluxDB and Grafana updates, and rollback was a huge pain. I’ve now disabled cleanup so old versions of packages are kept, but there must be a better way.
Thanks for your hard work!
I discovered Homebrew now sometimes asks whether I actually want to install a formula (e.g. `brew install ffmpeg` asks whether I want to install it because it has dependencies). Is there a way to disable this behavior and revert to the previous one?
Thanks :)
—-no-ask, —-yes, -y or HOMEBREW_NO_ASK=1
Nice, thanks! Added to my configuration file :)
https://github.com/Frizlab/frizlabs-conf/blob/663e287eadadd9...
Is uninstalling homebrew still as much of a mess as it was when I tried to do it in 2022 (when it left behind a messy install footprint on my Mac)?
I know this runs on Linux too. As a Linux user, I'm unclear on why I might use this instead of apt or dnf, for example. Any Linux users out there have experience with both Homebrew and one of these?
It's for predictability in upgrades. Homebrew allows you to separate system packages (from apt or dnf) from user packages (from homebrew) [1]. Running apt upgrade or dnf upgrade can render your system unbootable if you're unlucky (or unstable or degraded if you're less unlucky). Running brew upgrade can at worst break some of your own user's setup or tools.
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
Yes. I daily drive pop os now. Hate to use flatpak for anything. Only install core packages, google chrome and vscode using apt. Almost everything else is installed using homebrew. The idea is have a base stable system for UI and basic shell. Usually get the latest packages from brew. Earlier same base system but had distrobox with arch toolbox. Planning on using this scheme going forward, especially since while I love rolling release, they sometimes might have regressions which I don’t want to deal with right away. And these regressions can be both at system level or user packages level. Having a stable base helps significantly in daily driving linux in real world.
You can have multiple versions of tools installed. But overall, homebrew plays well with atomic distros. They are thing in itself, yet getting more popular lately. Im using them at home and on the server, and it feels calmer, because I can't fuck up whole system easily. Considering I'm using llms without sandbox often, this is pure gold.
Homebrew provides access to a massive catalog of software, including many tools that are not packaged for Fedora, Debian, or Ubuntu. Homebrew relies on a high level of automation in GitHub actions, which ensures users get the latest versions of tools quickly, rather than waiting for distribution-specific repositories. The Homebrew approach also decouples the underlying system from what you choose to install in user-space.
You can run Homebrew on Linux without admin privileges. Useful e.g. for shared hosting.
Small note: You need admin privileges only once for the first install which creates a new user `linuxbrew` and everything is based around `/home/linuxbrew` prefix. The issue is on systems where getting an admin access is not possible, you cannot ‘reliably’ install to a different prefix. It is currently unsupported.
Honestly, I would settle for a custom prefix if it tells me exactly what packages will break and what won’t without having to read each and every formula recipe. That’s one thing that bothered me for a while and I did not have the willpower to explore that direction without having community support.
I have been used Homebrew for years, the first choice to install an App is using the `brew install --cask` command.
But can you please support old Mac too? As you upgrade brew, many brew break for old Mac since the old library/framework. And in this situation, i had to switch from brew to macports plus brew. It's a pain for old Mac to using brew.
Sorry, we don’t have the resources to do so. We are a team of volunteers and rely on donations to pay for our CI infrastructure.
MacPorts is a better fit for older hardware.
Well done, a milestone. I can't say how much I appreciate Homebrew, been using iti for years, at least 15 years.
Brew is so good... just sponsored on github. Thanks for the hard work!
Does anyone know of a good comparison of the process to add a package to the system? I've used multiples of these sorts of user-land package managers and always find tools that aren't in the repositories that I have to install manually. It'd be great to just add these tools to an existing package manager but I've never seen this aspect of these package managers compared.
Comparison of which managers?
Adding package to homebrew is straightforward, except that it has a lot of (reasonable?) requirements to make it right. Basically, you make a PR with a "formula" to their main repo from your branch. Formulas are ruby programs. LLM can do it easily, and such code is accepted if correct.
Homebrew, mise, flox, devenv are the first ones I can think of.. Arch Linux's AURs get an honorary mention as they are used in the similar way on that distro and Arch + distrobox gets the same results. A quick search shows there are many others but it doesn't look like a comparison exists for this area and I'm getting OK results out of AI comparisons. I'll just dig into it that way.
Ask mode being the default is stellar. Thanks Mike!
Apple could’ve made something like this, or at least pay you handsomely for making Macs better to use.
Homebrew has been a gamechanger for me, thanks for all your efforts!
Does this fix the issue why the aws session-manager-plugin has to be removed?
Also, what about installation directories? I always install homebrew to ~/.brew since I know I’ll always have access to my home directory without sudo.
Okay, but can you reverse a binary tree?
We should all be ashamed of the interview culture we have created in this industry.
I didn't do shit :D
As a daily user of Homebrew for > 10 years, thanks for all your hard work.
Thanks for producing such an amazing piece of software. Most of my Mac installations are based on Homebrew, but I have to rely on version management tools like Pyenv or nvm for Python and Node. Wish there was some standard 'Homebrew' way to install multiple versions of node, php and Python
There's a selection of ways that may or may not work for you:
- `formula@version` packages
- `brew version-install` (which uses `brew extract` and `brew tap-new` under the hood)
- `version_file:` support in `brew bundle
- `brew pyenv-sync`
Have a look at https://mise.jdx.dev/, it's exactly what you're looking for!
I switched from brew to https://asdf-vm.com/ for this very reason.
I don't understand how devs don't use a tool that makes multiple versions of everything possible.
Top three things I install first are Sublime Text, Homebrew, and modern Bash (I'm not switching to Zshell). Great tools make computing enjoyable.
Homebrew first, then use it to install Sublime and Bash!
Internal JSON API being default is the real improvement here. brew update has been too chatty for years, cutting that down makes a big difference.
I assume this trust issue is related to the not-infrequent MacOS notifications asking for permission to run Ruby in the background or when the machine starts. It says nothing about Homebrew though.
macOS Permission Management regarding shell scripts is so bad. For example they show you a list of software thats allowed to access the full disk - but I have like 8 "sh" or "bash" in there and some random scripts with no way to open the enclosing directory in Finder making it basically impossible to see what it is and if its legit…
I'm not sure when they added it, but I just checked again in macOS 26 and you can right click on those sh-like entries now and hit Show in Finder.
Thanks for the homebrew and all work over those years!
I will try this new release of brew but I have been extremely satisfied with determinate nix so far. It completely changed my confidence in installing new stuff
Slightly tangential, but I went to set up Homebrew today on a new Mac. Stupidly clicked the top link in Google (which was sponsored but not obviously so). Took me to a spoof Homebrew page. I ran the script. Typed in my Mac password like a fool when prompted, and nothing happened. Then I realised what an idiot I’d been.
Claude found evidence of an exfiltration malware on my laptop and I inmediately wiped the device and started again. Revoked all my keys, rotated all my passwords. And now I pray the damage is contained.
I can’t believe that Google would have let this slip through. I probably wasn't the only one that got caught out.
We’ve complained about this to Google many times to no avail. It’s very frustrating. They are literally paid money to let people install malware on your machine. Please direct all annoyance and resentment to them (we share it).
Firstly, Mike, thank you for all you've done with HomeBrew - an amazing product. None of my ire was directed at you or HomeBrew.
I am so frustrated at Google, not just for this incident, but for many reasons (like their inexplicable shutdown of my own Adsense account years ago, and their neglect of several products I'd built against or bought). When they act, they leave us with no recourse. I feel anxious being dependent on them, even for simple stuff like my email account.
They are sufficiently big that they no longer care about the little guy anymore. They are only interested in swallowing up all the World's data and cashing in on Workspace.
Thanks for the kind words. Glad no ire directed at us. It is very frustrating I agree.
I've heard of that but never experienced it on my Google. Weird. I just retried that now and it's giving the correct link. Maybe that's why it's not being fixed.
I reported the ad to Google immediately, and when I checked back an hour later the search results were clear. But I suspect it's only a matter of time before another one slips through the net.
I think what happens is a legitimate business with a history of legit Google advertising gets compromised by malware, and then their Google adverts are flipped.
Hell yeah, tap trust!!!
With NetBSD and Macports, when I need to find a file I can predict where it is almost every time. With FreeBSD, Linux, and Brew, it feels like “here we go” while I guess. Since tools in categories like this are similar, things like this end up being tie breakers for me.
I wish tap trust operated at the author/committer level than identifier level.
Back in the day, pkgsrc was a thing (cross-platform; originally from NetBSD). Source based package distribution, it explicitly allowed for unprivileged installation to a prefix of your choice. I became very familiar with it as an ordinary Solaris user 20 years ago.
It's still a thing: https://pkgsrc.smartos.org/install-on-macos/
I was so impressed with Homebrew, I've added a formula for far2l-tty.
Thanks for your job!
I don't understand how the tap trust improves security at all. If I'm installing something from a third-party tap, instead of running tap + install, I now run tap + trust + install? How does this protect me against compromised taps?
You can now trust individual files inside taps. It was not clear to all users before now that some commands (before —-eval-all, a mess this replaces) would evaluate all packages Ruby code from all taps). This cleans that up and some other security degrading edge cases I won’t bore you with here.
Trust is also user specific now.
It’s not a silver bullet but it does help address some potential attacks and gives us a foundation to improve on over time.
Exactly - so far seems like a windows vista “are you sure?” Modal. Are we missing something here?
Does this handle macOS installs with multiple local users? I have to su into account 1 if I want to brew install something from account 2
brew as-console-user may help here. We don’t support a multiuser setup so there may be some limitations but we try our best to address problems as they come up.
Is there more documentation than this?
> as-console-user command [args …]
> Run a Homebrew command as the active macOS console user.
> This is intended for MDM, Munki and Jamf workflows where brew is invoked as root but Homebrew operations should run as the logged-in console user. The nested command is always dispatched through HOMEBREW_BREW_FILE.
— https://docs.brew.sh/Manpage#as-console-user-command-args-
This isn’t very informative. Is there more documentation somewhere else that I’m missing? Google search doesn’t really find much.
I currently have a dedicated `homebrew` user that I access with `alias brew='sudo --set-home --user=homebrew --chdir /Users/homebrew -- brew' but it’s got a number of shortcomings. What will as-console-user do differently to this?
Does Homebrew have good support for exact (and older) versions of packages now?
I'll second the recommendation for `mise`, and add: I typically use Homebrew for things I want everywhere, and if I want something everywhere then the latest version is _probably_ OK. I typically use mise en place for versions which are project-specific.
So I have a system Python (largely unused), a Homebrew python (pulled in as a dependency, I won't use it), and as many different mise/uv Pythons as I need for different projects. Similarly NodeJS and Java. I'd given up on nvm a while back, no longer use pyenv, and mise and uv work together really nicely.
Nope, still rolling. Have a look at https://mise.jdx.dev/ if you need exact versions
`brew version-install` may do what you want here.
I don't think that's a part of its goals at all.
mike, thanks for ur hard work. n all the maintainers b4.
Thanks for the hardwork.
Thank you fore homebrew. It makes macos usable.
damn, I can't believe, it's still getting updates. found out homebrew 6 months ago, I'm awe! amazing product
Mac without brew just wouldn’t be Mac. Huge respect!
I tried hosting a homebrew tap, after hosting apt and yum repositories.
That was when I realized Homebrew is much, much harder.
Your server needs to implement the git protocol. You can't just stick it on some server with a CDN in front of it, you need to run and fortify a git server.
Strange choices IMHO.
I think it is focused on GitHub. It might not be suited for many people this way, but it works well. Opionated design.
Well no one ever had issues with GitHub.
happy Bluefin Linux user and can vouch that the Homebrew experience in Linux is great as well. Really excited for where things are going.
Such an amazing project!
Remember when this guy couldn't get hired at Apple, because Apple doesn't respect their customers or developers.....
I’ve never applied for a job at Apple.
You’re maybe thinking of the creator mxcl’s viral tweet about not getting hired at Google. He did work at Apple for a while on SwiftPM.
I also am in the “applied and didn’t get hired by Google” club which let me move back to Scotland instead :)
did google apologize for not hiring you?
You’re thinking of mxcl, the creator, not me.
I also applied and failed a final stage job interview at Google (and various other places over the years) but never really bothered me that much.
Ironically I think I’d probably never have started working on Homebrew if it had.
oh sorry i was wrong, glad it happened then, and thx for your work!
No apologies needed thanks for the kind words! <3
Thanks
Seems like the sort of package that waiting on 6.0.1 might make sense.
macOS 27 (Golden Gate) drops Intel support, so ... in September 2027, macOS Intel x86_64 will be unsupported entirely and all related code deleted.
hmm... that's too bad.
absolutely solid, thanks!
Homebrew is the first thing I install on a new Mac. I love it. Thank you everyone for all the work. Looking forward to 6.0 and all the security stuff yay. I hope the apps I use that their maintainers adopt the changes.
> Homebrew is the first thing I install on a new Mac.
Absolutely!
Dependency management is still one of the hardest jobs in systems (languages, Operating systems, distributed applications, etc) - hat's off to you and your team for the hard work keeping everything together
Has anyone tried it on Linux? It has been several months since I last tried it on Linux. I found some things worked but others did not. Has anyone more recent experiences here, say, within the last 6 months, on Linux specifically?
I am using my own custom "package" manager in ruby, but naturally it is nowhere near as sophisticated as homebrew. I am looking more towards complementing this, but these days I also lack time for more thorough testing, so I try to minimize pain points (and thus also less frequently use software written by others for the most part, unless it is a key project such as libreoffice and what not).
Wdym tried?
There are many thousands of users of Linux homebrew, mostly users of atomic distros. I am one of them. I was so happy using homebrew that I've added new formula to its repo, far2l-tty
Does homebrew still do that insane thing when you want to upgrade a single package it tell you "hold my beer" and starts installing postgres and some obscure python version?
This behaviour came about because, before we did that we ended up upgrading just what you wanted and breaking other packages by mistake.
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.
Are you referring how it does a `brew upgrade` when doing a `brew install`? It should tell you how to disable that whenever it happens:
> Adjust how often this is run with `$HOMEBREW_AUTO_UPDATE_SECS` or disable with
> `$HOMEBREW_NO_AUTO_UPDATE=1`. Hide these hints with `$HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
Why is this not the default? I removed homebrew years ago, because it was just full of nasty surprises like this. Does homebrew still share dependencies? Previously you could not have package A with a transitive dependency of lib-X = v1.2 and B that requires lib-X = v.0.7.
Thank you!!
homebrew is so nice, thank you for all your effort
I don't think any software has ever wasted as much of my time as Brew. I can't think of a single positive experience I have had with it. I now absolutely refuse to use it for any reason.