Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
d3Xt3r 5 hours ago [-]
Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
mikemcquaid 5 hours ago [-]
Glad to hear it. A lot of time and energy has gone into performance work so glad that’s noticeable! Thanks for the kid words too <3
mikae1 2 hours ago [-]
Thank you for Linux Homebrew! It works so damn well.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
curt15 2 hours ago [-]
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
mikae1 2 hours ago [-]
> Where do you draw the line between system packages and user facing apps?
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
32 minutes ago [-]
shevy-java 1 hours ago [-]
I don't understand the distinction you use here.
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am
not really into any arbitrary disctinction random linux distributions try
to push down onto the (downstream) userbase. Besides, if you compile from source, why
would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS
uses a hashed name, so that is the only exception I can think of (and GoboLinux
of course), but as far as I know if you are on e. g. a debian system, you can
not use it for a versioned AppDir layout.
mikae1 27 minutes ago [-]
> I don't understand the distinction you use here.
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
F3nd0 45 minutes ago [-]
> NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course)
Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
jdorfman 18 minutes ago [-]
Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
darkamaul 2 hours ago [-]
Silly question - but how do you apply the cooldown to brew itself ?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
mikemcquaid 2 hours ago [-]
You can’t, by design. We instead apply if for you on upstream packages from NPM, PyPi, etc.
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
lukeify 5 hours ago [-]
I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
larodi 42 minutes ago [-]
would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
mikemcquaid 28 minutes ago [-]
Can’t speak for others but a lot of my work. I review it all locally first. The flow feels a lot like reviewing human PRs locally.
I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
hk1337 2 hours ago [-]
I split my usage. Homebrew for OS things mise for the various tooling.
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
9dev 2 hours ago [-]
Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
atmosx 27 seconds ago [-]
Python might be just one of the languages required by the dev stack not the only language. Mise is the right tool for the job.
artdigital 1 hours ago [-]
I also started using Mise for global CLI tools instead of brew and it’s working really well
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
Yup! We’ve been using it for a really long time at this point.
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
blixt 1 hours ago [-]
I was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?
illiac786 30 minutes ago [-]
What is the impact of being tier 2?
I’ll update Xcode, but I will definitely not install macOS 27.0
mikemcquaid 26 minutes ago [-]
This is a bug, sorry. Working on it.
internet2000 1 hours ago [-]
The GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols.
Is it Claude or Codex built?
mikemcquaid 25 minutes ago [-]
I didn’t build it. The emoji were my idea. I (and Homebrew) have used them heavily before LLMs did. Maybe LLMs loving them is my fault. Sorry if so.
illiac786 27 minutes ago [-]
I don’t get these questions asking if it’s codex or Claude – I see them often. Does it matter? There are other options out there also, it feels strange to ask this. Like asking “is your car a Toyota or a BMW?“
csande17 4 minutes ago [-]
[delayed]
asadhaider 3 hours ago [-]
Awesome, I just checked and had already upgraded at some point. I run the alias command below every now and then which keeps everything up to date.
Just remember that brew still must never be installed on a machine you need to be able to trust.
The supply chain security policy of brew is basically non existent and optimized for low-friction contributions. Think wikipedia. No enforced commit signing, review signing, or multi-party release signing, and thus everything is honor system.
Do not put brew anywhere near systems that access production or even on systems used to review production-bound code.
We take supply chain security very seriously, moreso than many package managers.
dezgeg 34 minutes ago [-]
How is that any different from PyPI, npm, cargo, etc?
roger_ 3 hours ago [-]
Does installation still require root and a dedicated user account on Linux?
That really put me off.
mikemcquaid 2 hours ago [-]
See the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.
mort96 1 hours ago [-]
Wait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?
akerl_ 1 hours ago [-]
I’d imagine they’re live updating the library paths in the binary headers, so anything shorter or equal to what they’re using is a simple rewrite, but longer is more complex.
mort96 47 minutes ago [-]
Ah. That makes sense.
It's so annoying how deeply UNIX packaging philosophy assumes that installation directories are something you hard-code at build time.
akerl_ 28 minutes ago [-]
The present is built mostly on layers of the long-past :)
It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.
mort96 18 minutes ago [-]
Yea, my understanding is that the split between / and /usr used to be more or less: the drive they used for / ran out of space, so they mounted another drive as /usr. As a consequence, / became where you put stuff that was essential during early boot, while /usr was where you put everything else.
But these days, "early boot" is handled by initramfs and we've all got drives large enough to not need the split anyway.
orf 1 hours ago [-]
Pouring a bottle requires rewriting paths embedded in binaries, which results in a cap.
Postgres is an example of this: the various directories are set at build time.
wscott 3 hours ago [-]
The dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
trallnag 3 hours ago [-]
Bubblewrap is history starting with 7.0.0 according to the release notes
hk1337 2 hours ago [-]
I always download the install script and change the directory to my user home directory, ~/.brew
dghlsakjg 3 hours ago [-]
The dedicated user account is optional.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
aydgn 3 hours ago [-]
Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
mikemcquaid 2 hours ago [-]
Sorry we couldn’t support this for longer :(
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
donatj 59 minutes ago [-]
My personal opinion, but I'd rather see wider macOS support than Linux support, if it's a sheer matter of where time is allocated.
Linux already has world class package managers.
mikemcquaid 21 minutes ago [-]
Linux Homebrew users would disagree.
Supporting macOS Intel has been significantly harder, slower and more expensive for us the last few years than adding ARM Linux support. If it was easy and free we’d have kept it for longer (until Apple and GitHub killed theirs at least which is coming in less than a year).
jezek2 1 hours ago [-]
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
sethaurus 18 minutes ago [-]
That's an excellent question for the maintainers of the MacPorts project! It can supplement the very clear and polite answer you've already received from a maintainer of Homebrew.
kps 4 minutes ago [-]
Different philosophy of dependency management.
eu 1 hours ago [-]
very disappointed about this
michaelsbradley 23 seconds ago [-]
Same boat: 2018 Intel Mac mini, stuck on macOS 10.15.
When I eventually upgrade my hardware, I’ll happily use Homebrew again. In the meantime, MacPorts!
kps 17 minutes ago [-]
MacPorts is still there for us.
AbuAssar 2 hours ago [-]
the gui homebrew manager is a nice addition!
it can be installed with:
brew install homebrew-app
2 hours ago [-]
gdevenyi 1 hours ago [-]
Does it still need root on Linux? That makes it an instant no go.
mikemcquaid 23 minutes ago [-]
For initial installation to the default prefix someone needs to create the home directory and that person is probably root.
We hope to allow all prefixes under 64 bytes in future.
touwer 3 hours ago [-]
Fantastic, thx for the effort!
max979 2 hours ago [-]
Time to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
inatreecrown2 2 hours ago [-]
I have this bound to an alias: bu
Run it every couple of days, easy peasy.
basedpolymer 3 hours ago [-]
And that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore.
I'm back to the old installation methods !
supriyo-biswas 7 minutes ago [-]
I've used MacPorts on macOS versions that don't support the latest OS, which per homebrew policy seems to be versions upto N-2.
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
mikae1 3 hours ago [-]
Actually, Homebrew 7 is supported on your Mac, you just have to install Linux to use it. :)
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
asimovDev 31 minutes ago [-]
I recommend MacPorts, the migration is easy, you copy the package names you installed with brew, uninstall homebrew (there's an unisntall script on brew.sh FAQ section, it will also uninstall all homebrew packages (but not the casks)) then install macports and reinstall the packages with sudo port. Although the selection is smaller on macports and newer packages might not have a prebuilt pkg for your OS so you still might end up building manually (My poor i5 4core had to attempt building nodejs26 because there wasn't a pkg for Ventura)
wpm 48 minutes ago [-]
MacPorts has been there this whole time.
yladiz 3 hours ago [-]
How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
watermelon0 2 hours ago [-]
Are you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
nebezb 10 minutes ago [-]
No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.
VCFundedGenYer 6 minutes ago [-]
You're on macOS. you should know full well that they do not care about those values.
basiliobeltran 3 hours ago [-]
I have one of the last Intel Macs and works perfectly fine (on Sonoma). How long should I expect working tech being supported?
I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
lnenad 2 hours ago [-]
What does saying "working tech" do for you? If I have a working Samsung CRT from 25 years ago do I ping them about smart TV support? Nowadays it's a shitty situation with planned obsolescence; but 6 years for an open source project dedicating resources to a dead end is more than enough and appreciated.
2 hours ago [-]
trvz 56 minutes ago [-]
And given the performance jump from Intel to Apple Silicon, the perceived difference is 10+ years even.
larodi 45 minutes ago [-]
Sure, but 2019s Intel Macs are aboslutely usable for most tasks, and given much of the agentic dev. happens... somewhere remotely, it is more an opportunity to reuse this equipment for various tasks, rather than pollute the already dirty Earth with more electronic waste.
VCFundedGenYer 6 minutes ago [-]
You do realize Intel support is gone, right? You won't be installing anything on your Intel Mac very soon...
ActionHank 29 minutes ago [-]
I’m installing Linux on my 2019 16” today.
daliusd 2 hours ago [-]
Same here, but I understand their position. Meanwhile I rely on packages publishing builds for Intel Mac in GitHub (surprisingly a lot) or building from source code. I just asked AI to build me install system.
Achterlangs 2 hours ago [-]
FYI Macos will also stop with major updates for Intel macs. You can just keep using brew 6 on macos 26.
wltr 3 hours ago [-]
Have you tried Mac Ports?
alex7o 3 hours ago [-]
[flagged]
yard2010 3 hours ago [-]
Thank you so much for doing this, for years you make me feel like home, or the year 2010. Please don't ever stop!
launchkitcodes 1 hours ago [-]
[dead]
assimpleaspossi 1 hours ago [-]
[flagged]
pdpi 43 minutes ago [-]
"That front page" isn't the front page, it's the release notes for version 7.0.0.
The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its <title>), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from complaining that Postgres release notes don't explain that Postgres is a database.
assimpleaspossi 33 minutes ago [-]
Yes. Thank you. The link text gives the impression that is the front page and I didn't notice. I'm sure a lot of people don't notice which is the issue I'm trying to point out.
drewbug01 54 minutes ago [-]
If you actually clicked through to their homepage, I imagine you would find the “what does homebrew do” section quite enlightening.
assimpleaspossi 52 minutes ago [-]
I did. If you actually read what I wrote you would see that I read it.
mcsniff 59 minutes ago [-]
It's a package manager.
The second header on the main page:
What Does Homebrew Do?
Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.
assimpleaspossi 55 minutes ago [-]
That doesn't make sense. Why do I need Homebrew to install the command line tools of macOS on macOS? Doesn't macOS already have them installed? Same for Linux, etc.
atombender 50 minutes ago [-]
Replace "need" with "want" and it might make more sense?
Homebrew is the Mac equivalent of APT, Pacman, RPM, BSD ports, etc. It's a fairly traditional package manager for software that doesn't come with macOS. "brew install postgresql" installs Postgres into /opt/homebrew, for example.
assimpleaspossi 47 minutes ago [-]
So how does one install postgresql on a Mac?
42 minutes ago [-]
coherentpony 58 minutes ago [-]
It’s a package manager for Mac.
assimpleaspossi 52 minutes ago [-]
So Mac doesn't have a package manager?
niek_pas 39 minutes ago [-]
No first-party package manager.
asimovDev 36 minutes ago [-]
does App Store count?
hooverlabs 59 minutes ago [-]
It’s just another software package manager for installing dev tools
Rendered at 14:05:22 GMT+0000 (Coordinated Universal Time) with Vercel.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.
Distinction: https://news.ycombinator.com/item?id=49683258
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
The lessons learned were instead used to make the Ruby frontend much faster.
Fish 4.0: The Fish of Theseus (fishshell.com)
906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments
https://news.ycombinator.com/item?id=42535217
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
I’ll update Xcode, but I will definitely not install macOS 27.0
Is it Claude or Codex built?
The supply chain security policy of brew is basically non existent and optimized for low-friction contributions. Think wikipedia. No enforced commit signing, review signing, or multi-party release signing, and thus everything is honor system.
Do not put brew anywhere near systems that access production or even on systems used to review production-bound code.
We take supply chain security very seriously, moreso than many package managers.
That really put me off.
It's so annoying how deeply UNIX packaging philosophy assumes that installation directories are something you hard-code at build time.
It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.
But these days, "early boot" is handled by initramfs and we've all got drives large enough to not need the split anyway.
Postgres is an example of this: the various directories are set at build time.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
- 2019 Intel iMac user.
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
Linux already has world class package managers.
Supporting macOS Intel has been significantly harder, slower and more expensive for us the last few years than adding ARM Linux support. If it was easy and free we’d have kept it for longer (until Apple and GitHub killed theirs at least which is coming in less than a year).
When I eventually upgrade my hardware, I’ll happily use Homebrew again. In the meantime, MacPorts!
it can be installed with:
brew install homebrew-app
We hope to allow all prefixes under 64 bytes in future.
Run it every couple of days, easy peasy.
I'm back to the old installation methods !
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its <title>), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from complaining that Postgres release notes don't explain that Postgres is a database.
The second header on the main page:
What Does Homebrew Do?
Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.
Homebrew is the Mac equivalent of APT, Pacman, RPM, BSD ports, etc. It's a fairly traditional package manager for software that doesn't come with macOS. "brew install postgresql" installs Postgres into /opt/homebrew, for example.