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).
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.
Rewriting a program in Rust (specifically) really only makes sense for a few reasons:
1) the existing implementation is in an unsafe, cumbersome language (C, C++).
2) the existing implementation language is too slow and that slowness cannot be worked around.
3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.
1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
I was kinda kidding because parent called it "blazing" fast lol. I didn't think it was Rust. Blazing fast software is reserved as a descriptor for Rust programs :)
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?
> 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.
It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.
But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
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.
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.
> 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?
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?
I don't know anything about homebrew, but have a question ...
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
> I suspect that the number of people that use and know Groovy is steadily declining
One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
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).
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
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.
So is sudo... And that's not "too risky" for the entire industry.
That's not to say bus factor is irrelevant (I personally think about it a lot when choosing software projects), but truthfully the bus factor here especially doesn't matter much, as mise is an easy tool to replace (with asdf, for example) if something goes wrong with it eventually.
I highly recommend trying it out. I resisted using it for some time, but it solved some pain points I had with NodeJS, Ruby, and Python regarding installation.
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions
I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc.
I think it's because LLMs tend to obsessively write in a this-therefore-that kind of way, where an emdash is often the most semantically fitting punctuation.
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?“
Long term it matters very much if your car is Toyota or BMW or Kia or John Deere though.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
If you say "AI tools", some vibe-coders try to equivocate between tools that generate the whole program for you and, like, an editor that uses an scoring algorithm to decide which method to show at the top of an autocomplete list. But if you say "vibe coding", some vibe-coders try to claim that what they're doing technically isn't vibe coding because they applied some non-zero amount of testing or review during the process.
If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
> 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.
Homebrew is incredibly useful for immutable Linux distributions.
That said, after trying Bazzite I now prefer CachyOS and Arch as a whole.
I can see the appeal of using Homebrew and Flatpak to keep OS updates a little more separate from app updates, although I don't really see a specific need for it for myself.
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).
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.
I'm probably the millionth person to parrot this to you but my goodness you are a hero if you can tolerate the Intel Mac experience in 2026.
I thought my Intel Mac from that era was incredibly weird. Little firmware-ish things were so glitchy and sluggish. At some point the wake from sleep/lid open just took forever in ways that didn't happen on older Intel Mac models (or maybe I was going crazy). I just had this strange feeling that Apple was knowingly half-hearting their Intel drivers and products as a whole as they were putting more energy into developing Apple Silicon.
Dude, you owe it to yourself to just grab a used M2 MacBook Air or something along those lines. Treat yourself. You'll be kicking yourself for not doing so sooner. (Don't get a MacBook Neo, too many compromises including poor battery life, a used Air is much better, and if you use more than one external monitor use caution on what model/CPU you choose).
Sure, a laptop should last longer than 7 years, but this is one of those "Apple yeets out a new architecture" exceptions like the PowerPC to Intel transition. Better to accept it and move on. 7 years is still a solid run. You've only got ~2 more years left until you start losing security updates anyway.
The other machine I highly recommend is Linux/Framework 13 Pro with the Intel Core Ultra Series 3, although that's a whole different price class, and obviously not everyone can make that move in terms of software compatibility.
I've been using homebrew for so long, I can't tell you how much it has helped me to spend more hours developing and less managing packages and updates, etc. Thank you so much, congratulations on the update!
Always a joy to see security and performance as a big highlight on a release. Brew is notably slow compared to the other package managers I use, but never in an unbearable way.
I've always used it on my Mac work machines, but always used my native package managers on Linux. What are the reasons to run homebrew on Linux? Better newer package support when you're on something slower moving like a Debian distro?
I've standardized my config scripts on using language managers for those tools (go, cargo, uv), which isn't perfect, so maybe brew is worth a chance.
As a MacPorts users (generally light-weight, just a few things here and there):
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it!
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t.
Haven’t used MacPorts since. Has it gotten any better at those things?
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.
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.
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.
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.
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.
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)
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.
6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems.
NixOS is an open source project that runs great on my 2013 Dell laptop. I think the real point of distinction is that brew depends on Apple's OS and SDK, which somewhat ties their hands, while other OSs don't.
There's been a huge step up in basically everything going from intel to apple silicon. It's not a comparable hardware in any sense, and as such, it really does feel like it became a paperweight? I know I never wanted to see an intel macbook ever again the moment I tried M1. It's maybe hard to comprehend how different it is if you haven't used both. And at the same time I'm happy with my x86 desktop for 10+ years. Only thing that really improved in that span was storage.
So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.
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.
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.
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.
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?
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.
An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me.
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
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).
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.
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
It is Rust now?
It's still in ruby, although I see the new GUI is in swift: https://github.com/homebrew
Rewriting a program in Rust (specifically) really only makes sense for a few reasons:
1) the existing implementation is in an unsafe, cumbersome language (C, C++).
2) the existing implementation language is too slow and that slowness cannot be worked around.
3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.
1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
I was kinda kidding because parent called it "blazing" fast lol. I didn't think it was Rust. Blazing fast software is reserved as a descriptor for Rust programs :)
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.
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?
> 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.
It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.
But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
On Linux I use mise to install CLI tools
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.
> I don't understand the distinction you use here.
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.
> 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?
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
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.
Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
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?
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.
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
I think at one point you said you’re working on a rust rewrite? Is that still in the cards?
I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches).
The lessons learned were instead used to make the Ruby frontend much faster.
I don't know anything about homebrew, but have a question ...
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
> I suspect that the number of people that use and know Groovy is steadily declining
One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
https://fishshell.com/blog/rustport/
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
They experimented with it but ultimately decided to focus on perf with their existing ruby codebase.
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
TIL Homebrew has its own sandbox mechanism - looks like it's built around their own sandbox-exec wrapper, at least on macOS: https://github.com/Homebrew/brew/blob/d79ef822ab8136e393ed5f...
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).
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
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.
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
re: npm, if you upgrade your global node version, you will lose that installation, right?
no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)
Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
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.
Last time I checked, Mise is still a one-man show. That’s way too risky for a critical party of my supply chain for my taste.
So is sudo... And that's not "too risky" for the entire industry.
That's not to say bus factor is irrelevant (I personally think about it a lot when choosing software projects), but truthfully the bus factor here especially doesn't matter much, as mise is an easy tool to replace (with asdf, for example) if something goes wrong with it eventually.
I highly recommend trying it out. I resisted using it for some time, but it solved some pain points I had with NodeJS, Ruby, and Python regarding installation.
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions
do you have any kind of succession plan in place in case you get incapacitated for one reason or another? anyone you trust enough for that?
Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project
Okay
my split: brew for casks, mise for tools
Mise is really sloppily vibe coded these days
What broke and affected you?
I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc.
https://mise.jdx.dev/bootstrap/packages/brew.html
The GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols.
Is it Claude or Codex built?
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.
Have we pinned down the emdashes source yet? ;-P
I think it's because LLMs tend to obsessively write in a this-therefore-that kind of way, where an emdash is often the most semantically fitting punctuation.
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?“
Long term it matters very much if your car is Toyota or BMW or Kia or John Deere though.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
My point was “why do you assume it’s one of the two”.
If you say "AI tools", some vibe-coders try to equivocate between tools that generate the whole program for you and, like, an editor that uses an scoring algorithm to decide which method to show at the top of an autocomplete list. But if you say "vibe coding", some vibe-coders try to claim that what they're doing technically isn't vibe coding because they applied some non-zero amount of testing or review during the process.
If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
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.
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.
Homebrew is incredibly useful for immutable Linux distributions.
That said, after trying Bazzite I now prefer CachyOS and Arch as a whole.
I can see the appeal of using Homebrew and Flatpak to keep OS updates a little more separate from app updates, although I don't really see a specific need for it for myself.
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).
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
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.
Different philosophy of dependency management.
Thank you for all of your hard work, I’ve been very happily using Homebrew on OS X / macOS since 2010.
No need to be sorry, the situation is understandable.
very disappointed about this
I think they would be able to support older architectures under a paid contract if absolutely needed, for the right price.
Other than that, I'm grateful for the free software.
I'm probably the millionth person to parrot this to you but my goodness you are a hero if you can tolerate the Intel Mac experience in 2026.
I thought my Intel Mac from that era was incredibly weird. Little firmware-ish things were so glitchy and sluggish. At some point the wake from sleep/lid open just took forever in ways that didn't happen on older Intel Mac models (or maybe I was going crazy). I just had this strange feeling that Apple was knowingly half-hearting their Intel drivers and products as a whole as they were putting more energy into developing Apple Silicon.
Dude, you owe it to yourself to just grab a used M2 MacBook Air or something along those lines. Treat yourself. You'll be kicking yourself for not doing so sooner. (Don't get a MacBook Neo, too many compromises including poor battery life, a used Air is much better, and if you use more than one external monitor use caution on what model/CPU you choose).
Sure, a laptop should last longer than 7 years, but this is one of those "Apple yeets out a new architecture" exceptions like the PowerPC to Intel transition. Better to accept it and move on. 7 years is still a solid run. You've only got ~2 more years left until you start losing security updates anyway.
The other machine I highly recommend is Linux/Framework 13 Pro with the Intel Core Ultra Series 3, although that's a whole different price class, and obviously not everyone can make that move in terms of software compatibility.
We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.
That hardly happens on desktop/laptop Linux. Seems like a proprietary OS problem tbh.
You have no idea what rug pull means, do you?
MacPorts is still there for us.
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!
I've been using homebrew for so long, I can't tell you how much it has helped me to spend more hours developing and less managing packages and updates, etc. Thank you so much, congratulations on the update!
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.
Always a joy to see security and performance as a big highlight on a release. Brew is notably slow compared to the other package managers I use, but never in an unbearable way.
I've always used it on my Mac work machines, but always used my native package managers on Linux. What are the reasons to run homebrew on Linux? Better newer package support when you're on something slower moving like a Debian distro?
I've standardized my config scripts on using language managers for those tools (go, cargo, uv), which isn't perfect, so maybe brew is worth a chance.
> Better newer package support when you're on something slower moving like a Debian distro?
exactly
People have been integrating/recommending brew on immutable distributions.
As a MacPorts users (generally light-weight, just a few things here and there):
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it!
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
1: https://news.ycombinator.com/item?id=49681546
I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t.
Haven’t used MacPorts since. Has it gotten any better at those things?
Does installation still require root and a dedicated user account on Linux?
That really put me off.
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.
Wait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?
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.
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.
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.
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.
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.
It was also useful for many machines to share a single /usr over NFS
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.
Bubblewrap is history starting with 7.0.0 according to the release notes
I always download the install script and change the directory to my user home directory, ~/.brew
The dedicated user account is optional.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
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 !
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)
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.
Apple was selling Intel Mac Pros in 2023, it's absurd these things are coming up on EOL already.
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.
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.
No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.
6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems.
Bits don't rot.
How many of those 20 year old projects had to go through an architecture change that the manufacturer no longs supports? Come on man be reasonable.
NixOS is an open source project that runs great on my 2013 Dell laptop. I think the real point of distinction is that brew depends on Apple's OS and SDK, which somewhat ties their hands, while other OSs don't.
There's been a huge step up in basically everything going from intel to apple silicon. It's not a comparable hardware in any sense, and as such, it really does feel like it became a paperweight? I know I never wanted to see an intel macbook ever again the moment I tried M1. It's maybe hard to comprehend how different it is if you haven't used both. And at the same time I'm happy with my x86 desktop for 10+ years. Only thing that really improved in that span was storage.
So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.
You're on macOS. you should know full well that they do not care about those values.
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
Sonoma will be getting its last security update imminently (possibly tomorrow).
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.
And given the performance jump from Intel to Apple Silicon, the perceived difference is 10+ years even.
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.
MacPorts has been there this whole time.
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.
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.
FYI Macos will also stop with major updates for Intel macs. You can just keep using brew 6 on macos 26.
I’m installing Linux on my 2019 16” today.
Have you tried Mac Ports?
You do realize Intel support is gone, right? You won't be installing anything on your Intel Mac very soon...
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?
You can download Xcode 27 RC now from https://developer.apple.com/download/applications/.
This is a bug, sorry. Working on it.
What is the impact of being tier 2?
I’ll update Xcode, but I will definitely not install macOS 27.0
I am quite disappointed by their decision to remove wine[1] from brew. The utility of it is obvious, and it's very popular software.
[1] https://formulae.brew.sh/cask/wine-stable
I don’t think utility or popularity had anything to do with the decision. It’s just that they no longer support casks with unsigned binaries.
You could create a third-party tap to install wine via homebrew.
Not usually a “+1” or “Me too!” kinda guy but homebrew is incredible and makes dev on Mac quite seamless. Huge thanks to the team.
I guess the Hackintosh era is (finally) facing its death...
Thanks for the hard work, but the Tahoe limitation for the GUI app is absolutely ridiculous.
A new era of native macOS apps is upon us.
GUIs abound. Rejoice!
the gui homebrew manager is a nice addition!
it can be installed with:
brew install homebrew-app
Fantastic, thx for the effort!
Time to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
I have this bound to an alias: bu
Run it every couple of days, easy peasy.
Thank you so much for doing this, for years you make me feel like home, or the year 2010. Please don't ever stop!
Does it still need root on Linux? That makes it an instant no go.
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.
Unfortunately this project has a case of dread with every update to me. To see what is being force changed, worse support or even removed features.
Looks like this release breaks Intel Macs. Very very sad. Not even 5+ year old hardware is apparently supportable to some devs
still needs fucking 'sudo'
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.
https://docs.brew.sh/Homebrew-Security-and-Supply-Chain
We take supply chain security very seriously, moreso than many package managers.
How is that any different from PyPI, npm, cargo, etc?
These release notes appear generated by LLM, with the usual extreme verbosity. Wish a human had done a better job editing these.
An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me.
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
Don’t let the reflexive grumps get you down.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
Perhaps you should volunteer your services so that the project for which you paid $0 can have release notes more to your liking.