Rendered at 07:56:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mikemcquaid 23 hours ago [-]
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 23 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 22 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
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.
bitexploder 15 hours ago [-]
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 :)
jdxcode 8 hours ago [-]
i just tested and `mise bootstrap` is over twice as fast at installing when a bottle was in the cache. other commands like `status/check` are 20-30x faster. that's without spending much work at all on perf—i'm sure i could bring these numbers down much further.
mikae1 20 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 20 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 19 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.
setopt 14 hours ago [-]
> 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.
Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?
mikae1 1 hours ago [-]
> Are you saying that Silverblue-based distros are noticeably more stable than Fedora?
TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time.
Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).
It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.
setopt 1 hours ago [-]
Thanks for the input!
> I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).
Two follow-up questions on this:
- How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)
- Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.
nxobject 16 hours ago [-]
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".
setopt 1 hours ago [-]
"Conflict" is maybe a strong word? Homebrew installs stuff into its own directory tree so it should in theory not have issues coexisting with native packages.
c0_0p_ 7 hours ago [-]
Same, for me it made it possible for me to work on Linux with teammates on Mac with very little messing around of the setup scripts.
18 hours ago [-]
LeBit 17 hours ago [-]
On Linux I use mise to install CLI tools
shevy-java 19 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 18 hours 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 19 hours 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?
I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
jdorfman 18 hours ago [-]
Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
darkamaul 20 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 19 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.
e40 12 hours ago [-]
Definitely notice the speed increase. Thank you for Homebrew. It's one thing that makes macOS bearable.
lifty 21 hours ago [-]
I think at one point you said you’re working on a rust rewrite? Is that still in the cards?
mikemcquaid 20 hours ago [-]
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.
clumsysmurf 16 hours ago [-]
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?
mikemcquaid 13 hours ago [-]
Ultimately you don’t need to know much Ruby to maintain or contribute to Homebrew. Ruby makes it very easy to write custom DSLs that don’t feel like Ruby. I didn’t really know any before working on Homebrew and it’s now my primary language.
That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API.
This will likely get extended over time to eventually allow package definitions to themselves be in JSON.
robertlagrant 15 hours ago [-]
> 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.
hn8726 15 hours ago [-]
Except ~nobody uses declarative gradle in production yet, and groovy is mostly declining in favour of also turing complete Kotlin. It's yet to be discovered how declarative gradle fares and how much of imperative glue real-life projects will need
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 18 hours 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 actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
larodi 13 hours ago [-]
Thank you, very insightful. TBH, expected an actual flow of nonsense and suspicion meanwhile, but a daly later there is still none, perhaps the general sentiment already shifted enough. It also confirms the notion that the credibility of the author is more important than the credibility of the means to develop. Also, of course, we're all going to move to newer brew sooner or later, so this all effort is much appreciated.
threecheese 10 hours ago [-]
Looks cool! Building.
`The macOS deployment target is set to 27.0, but the range of supported ....`
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).
Sytten 20 hours ago [-]
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
9dev 20 hours ago [-]
Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
e12e 8 hours ago [-]
> Why would you even use python without uv anymore
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
maxloh 31 minutes ago [-]
Old Mise user too.
Now that PNPM supports managing runtimes [0], I found that most of Mise's offerings are actually built into package managers. Maybe I will have it graduates from my machine when I have time.
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.
zbentley 15 hours ago [-]
True, but Python is the one with an env management system (virtual environments) which is the most prone to breakage for projects that depend on system Python.
Uv is far superior to both Mise and Homebrew for Python work, and I find that it removes the vast majority of pain preventing me from using Homebrew by default for most things, and Mise only occasionally for specific dev envs. Mise is a great tool though!
9dev 18 hours ago [-]
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.
jdxcode 17 hours ago [-]
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.
OberstKrueger 17 hours ago [-]
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
weaksauce 15 hours ago [-]
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?
jdxcode 15 hours ago [-]
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
doodlesdev 17 hours ago [-]
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.
hk1337 20 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.
impulser_ 14 hours ago [-]
You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install.
This is all you have to add to the config file:
[bootstrap.packages]
"brew:git" = "latest"
"brew-cask:ghostty" = "latest"
threecheese 6 hours ago [-]
Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.
artdigital 19 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
llimllib 16 hours ago [-]
re: npm, if you upgrade your global node version, you will lose that installation, right?
jdxcode 16 hours ago [-]
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)
16 hours ago [-]
bodash 19 hours ago [-]
my split: brew for casks, mise for tools
acedTrex 18 hours ago [-]
Mise is really sloppily vibe coded these days
kstrauser 17 hours ago [-]
What broke and affected you?
zymhan 15 hours ago [-]
Okay
internet2000 19 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 18 hours 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.
conorcleary 18 hours ago [-]
Have we pinned down the emdashes source yet? ;-P
simondotau 17 hours ago [-]
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.
threecheese 6 hours ago [-]
Apple devices produce a ton of emdashes; "Smart Punctuation" is enabled by default on iOS and iPadOS, maybe Mac as well - and it's at least a decade old.
I've had to disable it on all my iDevices bc it breaks some Markdown parsers. How big a % of training data was produced on an Apple device? Ehhhhh probably small.
illiac786 18 hours 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 18 hours ago [-]
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.
tbeseda 16 hours ago [-]
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.
illiac786 15 hours ago [-]
My point was “why do you assume it’s one of the two”.
15 hours ago [-]
aydgn 21 hours ago [-]
Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
mikemcquaid 20 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 19 hours 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 18 hours 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).
Grombobulous 15 hours ago [-]
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.
jezek2 19 hours ago [-]
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
isityettime 14 hours ago [-]
Breadth of support and retention of historical support are also priorities that differ between other software distributions, especially free operating systems.
See Debian vs. Ubuntu, or NetBSD vs. DragonflyBSD.
Some software distributions emphasize package freshness and coverage, like Homebrew does, which multiplies the support burden involved for each architecture or platform supported.
Others have a more prominent focus on backwards compatibility or exotic architectures, but have a smaller or slower-moving package set.
sethaurus 18 hours 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.
vor_ 8 hours ago [-]
The polite Homebrew project that used to market themselves with "MacPorts driving you to drink?" on their website.
kps 18 hours ago [-]
Different philosophy of dependency management.
frumplestlatz 11 hours ago [-]
They've never actively disallowed it, and volunteers have been happy to maintain it.
mwpmaybe 14 hours ago [-]
So much of GNU et al is already in Homebrew that I wonder how close you are to being able to support Intel Macs using the Linux/amd64 branch (or backend or whatever you call it) of Homebrew or something close to it, possibly after installing a few base libraries and utilities from MacPorts.
ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.
That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.
eviks 11 hours ago [-]
> GitHub Actions will retire Intel macOS runners in autumn 2027
But why drop before that?
michaelsbradley 18 hours ago [-]
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.
eu 19 hours ago [-]
very disappointed about this
xtracto 16 hours ago [-]
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.
ryandrake 17 hours ago [-]
We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.
dghkk 17 hours ago [-]
You have no idea what rug pull means, do you?
toomuchtodo 14 hours ago [-]
Uncompensated volunteers dropping support for a 7 year old device that is shortly going to be unsupported by the manufacturer isn't a rug pull.
Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.
ryandrake 13 hours ago [-]
As I replied in another comment[1], it's their software, their choice. Homebrew devs are doing the volunteer work, so they get to decide the support period and when to pull the rug out. I'll still shake my fists about it, because it's personally my biggest problem with the entire software industry's attitude, not just open source.
You're right, expecting other people to do your work for your for free is indeed a problem with the industry!
tonyedgecombe 14 hours ago [-]
> Find an ARM Mac used (like an M1) and upgrade.
And throw away perfectly good hardware.
mixmastamyk 12 hours ago [-]
In general I agree, but recycling old power hungry gear may be better for the environment in the long term.
toomuchtodo 13 hours ago [-]
If it no longer is supported by software, it’s no longer perfectly good. Certainly, if you want to spend your time on supporting unsupported hardware based on personal belief, that’s a choice, and it’s your time. Compare to the cost of replacing the hardware. Time is not free, it is the ultimate non renewable resource. We are all slowly dying one day at a time, is that how you want to spend your time?
Recycle old gear when the math no longer maths and move on.
tonyedgecombe 11 hours ago [-]
>We are all slowly dying one day at a time, is that how you want to spend your time?
Mindless consumption isn't going to extend your life.
toomuchtodo 10 hours ago [-]
Tinkering and building for fun brings joy, joy is the point of life. Tinker mindfully. “Tinker and build what matters, to you.”
isityettime 15 hours ago [-]
That hardly happens on desktop/laptop Linux. Seems like a proprietary OS problem tbh.
ryandrake 10 hours ago [-]
You're definitely right about that. I'll admit it. If you're not the kind of person who likes to throw all your electronics out every few years to spend $thousands on new ones then the Apple ecosystem is not for you.
isityettime 9 hours ago [-]
It's a weird situation in that the standards for mobile devices like cell phones and tablets are on the floor compared to those for PCs, so Apple's same 6-year cutoff feels respectable for smartphones but miserly for laptops.
rmnclmnt 2 hours ago [-]
Any modern Linux distro works great on Intel Macs. Been daily driving with Debian 13 initially and now NixOS on my MBP2015, have not used the MacOS Sequoia partition for months!
mediumsmart 13 hours ago [-]
> Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
welcome.
- 2015 intel macbook user
vor_ 8 hours ago [-]
Check out MacPorts. They have installers going all the way back to Leopard.
kps 18 hours ago [-]
MacPorts is still there for us.
18 hours ago [-]
Grombobulous 15 hours ago [-]
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.
eu 14 hours ago [-]
If the old Intel Mac still works, what should one do? Dump it into a landfill?
Grombobulous 12 hours ago [-]
I sell all my previous devices on second hand markets like eBay. That question becomes "not my problem:" whoever else is buying it has some kind of use case even though I am done with the system and it no longer fits my use case anymore.
I think that, for the parent commenter to my original comment, this Intel Mac no longer fits their use case. They can fight it and suffer or get the right tool for the job. I'm sure the person who buys it from them won't care that the current version of Homebrew doesn't work on it.
Intel Macs run Linux very well, I might add.
It should also be noted that, yes, most electronics eventually get scrapped for parts and raw materials. It doesn't really take all that long for important components to fail to a point where a computer is not really worth dealing with anymore. Yes, they can be repaired in many cases, but that's only generally worth it to a small group of vintage enthusiasts (and I say this as someone who very much enjoys vintage computing myself).
mixmastamyk 12 hours ago [-]
Electronics recycling exists, plus a few dollars for the aluminum case.
michaelsbradley 18 hours 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!
14 hours ago [-]
asadhaider 21 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.
Interesting. I use `--greedy` for casks but not regular formulae.
bessbd 14 hours ago [-]
Adding the `-y`-s is probably cowboy shit. I do have a `brew autoremove` at the end though
t27dev 20 hours ago [-]
[flagged]
khalic 17 hours ago [-]
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!
basedpolymer 21 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 !
asimovDev 18 hours 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)
mikae1 20 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.
sethops1 17 hours ago [-]
Apple was selling Intel Mac Pros in 2023, it's absurd these things are coming up on EOL already.
vor_ 8 hours ago [-]
Check out MacPorts. It was the original package manager, still going strong, and it supports Macs going all the way back to the Leopard era. It also always used /opt instead of taking over /usr/bin like Homebrew.
wpm 19 hours ago [-]
MacPorts has been there this whole time.
supriyo-biswas 18 hours 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.
yladiz 21 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 19 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 18 hours 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.
ryandrake 17 hours ago [-]
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.
nebezb 4 hours ago [-]
Bits certainly don’t rot and you’re welcome to stay on the latest stable version that runs on your architecture.
And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.
richwater 15 hours ago [-]
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.
vor_ 8 hours ago [-]
Ask MacPorts, which goes all the way back to Leopard-era PowerPC!
ryandrake 13 hours ago [-]
Homebrew doesn't have to lift a finger to support Intel Macs. It already does! All they have to do is not kill support for them.
Hey, it's their software, they are all volunteers and can do whatever they want. I'm grateful for the short window of time in which I was able to use their software. I don't get to decide their support period, but I will still hopelessly complain about it. "Deliberately breaking compatibility with a computer because it is old" is my biggest axe to grind with the whole software industry, and I'll shake my fists at this cloud until I die.
yladiz 10 hours ago [-]
Software maintenance is not free, especially for a project the size of Homebrew, and it's perfectly reasonable for software to not be supported on older computers due to maintenance burden, with a good example being 32 bit processors. If you had a 32 bit processor would you expect all of your software that was supported now to be supported forever, just because it supports it now?
vor_ 8 hours ago [-]
How does MacPorts manage to do it?
threecheese 6 hours ago [-]
Why don't you ask them?
ryandrake 10 hours ago [-]
I would not expect the software to continue to get updates, but I would expect the software to continue to work.
I'm salty today because I tried to run Fusion 360, and found that Autodesk just out of the blue decided that 1. My computer is too old to run the software (which ran just fine a few weeks ago on the same computer); 2. That I needed to update the software, and 3. The update will not run on my "old" computer. They took software that ran fine on my computer and deliberately pulled the rug out. Fuck Autodesk. I'm spending the entire afternoon exporting dozens of files I have on their cloud, one at a time, since they apparently can't even manage to keep an existing version of the software running.
yjftsjthsd-h 17 hours ago [-]
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.
rplnt 18 hours ago [-]
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.
VCFundedGenYer 18 hours ago [-]
You're on macOS. you should know full well that they do not care about those values.
basiliobeltran 20 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
mrpippy 18 hours ago [-]
Sonoma will be getting its last security update imminently (possibly tomorrow).
lnenad 20 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.
20 hours ago [-]
vor_ 8 hours ago [-]
Years, honestly. After all, Intel Macs just received a major macOS release from Apple only 12 months ago. MacPorts manages to support all the way back to Leopard!
trvz 19 hours ago [-]
And given the performance jump from Intel to Apple Silicon, the perceived difference is 10+ years even.
larodi 19 hours 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.
trvz 14 hours ago [-]
1) usable for most tasks != pleasent to use for most tasks
2) using an Intel Mac as your main computer, for most tasks != using it as a home server
daliusd 20 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 20 hours ago [-]
FYI Macos will also stop with major updates for Intel macs. You can just keep using brew 6 on macos 26.
ActionHank 18 hours ago [-]
I’m installing Linux on my 2019 16” today.
wltr 21 hours ago [-]
Have you tried Mac Ports?
VCFundedGenYer 18 hours ago [-]
You do realize Intel support is gone, right? You won't be installing anything on your Intel Mac very soon...
alex7o 21 hours ago [-]
[flagged]
throw0101a 18 hours ago [-]
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?
ryandrake 17 hours ago [-]
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!
Yes, the pride in aggressively dropping support for Macs that just received a major OS release from Apple only 12 months ago (and they were selling just three years ago) is a little off-putting.
apothegm 16 hours ago [-]
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?
teh64 9 hours ago [-]
I switched from brew to macports, and I have not experienced the first problem at all. In fact, I had more problems with brew, where some package needed to be updated that I did not want, and I caused a cascade of issues.
The second has also never happened to me. macports installs the packages into a separate prefix, and you just add that to the path, so I wonder how it could bork irretrievably.
Regarding instructions: for most packages, I found that just replacing `brew` with `sudo port` is enough, as most ports are available. And quite a few install instructions mention homebrew together with macports. I have not run into missing packages, but sometimes the ones that existed were a little out of date.
kccqzy 9 hours ago [-]
I reluctantly switched from MacPorts to Homebrew around 2014. At that time Homebrew had that yuck factor by recommending it be installed into /usr/local rather than /opt. But still, I switched because there were more formulae in HB than ports in MP. And it turns out that the Homebrew install location is customizable anyways.
ihuman 15 hours ago [-]
I switched from macports to homebrew a decade ago. I needed the lastest version of a program, and I found homebrew updated formulas faster than macports did
isityettime 14 hours ago [-]
I use basically every general-purpose package manager available on macOS simultaneously in a kind of tiered hierarchy of preference.
Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things.
The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store).
Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects.
For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me.
Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable.
MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts.
Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages.
All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it.
I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment.
Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps.
The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to.
I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble.
I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager.
For people who like macOS' app installation procedures: Nix + pkgsrc
For people who like Nix but want a disciplined escape hatch: Nix + MacPorts
For people who like Nix and want absolute coverage: Nix + Homebrew
For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix
For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI)
I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing.
And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.
14 hours ago [-]
jjice 17 hours ago [-]
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.
tkel 17 hours ago [-]
People have been integrating/recommending brew on immutable distributions.
andriy_koval 15 hours ago [-]
> Better newer package support when you're on something slower moving like a Debian distro?
exactly
roger_ 21 hours ago [-]
Does installation still require root and a dedicated user account on Linux?
That really put me off.
mikemcquaid 20 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 19 hours ago [-]
Wait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?
orf 19 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.
akerl_ 19 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 19 hours 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_ 18 hours 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 hours 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.
yjftsjthsd-h 17 hours ago [-]
It was also useful for many machines to share a single /usr over NFS
wscott 21 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 20 hours ago [-]
Bubblewrap is history starting with 7.0.0 according to the release notes
hk1337 20 hours ago [-]
I always download the install script and change the directory to my user home directory, ~/.brew
dghlsakjg 21 hours ago [-]
The dedicated user account is optional.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
AbuAssar 20 hours ago [-]
the gui homebrew manager is a nice addition!
it can be installed with:
brew install homebrew-app
20 hours ago [-]
spdustin 14 hours ago [-]
Excellent update, very speedy on upgrades now. Amazing what a little (safe) concurrency will do.
Homebrew.app, however, has a show-stopper for me. "Failed to decode Homebrew JSON output" on the installed/upgrades panel. I'm guessing the Discover panel would normally indicate which Formulae/Casks are already installed, but because it couldn't parse the JSON output, that feature (if it exists) doesn't work.
I'll file an issue—I know HN isn't your bug tracker :)
Edit: there's an issue there already, and I sorted out the root cause: iTerm2's shell integration. If you're using zsh as your shell, the solution is here [^0] in the second comment.
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.
lrvick 14 hours ago [-]
I hate to have to be this harsh as it is clear you did a lot of work, but I have warned members of the brew team about serious gaps here multiple times over the years and seemingly nothing has been done. Brew is not anywhere close to a level of supply chain security to be allowed anywhere near production access or production code review.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
woodruffw 10 hours ago [-]
I’m one of Homebrew’s security maintainers, and I don’t recall any contact with you. Who did you reach out to?
If you have concrete concerns, please bring them to us. Vague concerns and hand-waving about “people getting hurt” isn’t appropriate or productive.
lrvick 6 hours ago [-]
I had jumped into chats and a github issue as I recall, probably 7-8 years ago based on the employer I was researching it for, but would be hard to track that down now.
Anyway, my tone may not be entirely constructive, but it is one of frustration as seemingly no one is taking supply chain attacks seriously anywhere I look. I am quite sure if homebrew was backdoored, it would give an attacker control of production systems of countless financial companies, defense contractors, healthcare providers, AI labs. I think it is insane they trust rando homebrew maintainers with that much power, but they do and they are probably not going to stop because they do not even understand these risks, and there are not practical alternatives to brew on MacOS.
So that puts some major responsibility on the Homebrew team to either warn people to stop using it in high risk environments, or manage homebrew in a way appropriate for those environments.
Stagex actually does every single thing I am recommending Homebrew do, and with a way smaller team. What we do is also nowhere near enough, but the bar is in hell.
How is that any different from PyPI, npm, cargo, etc?
angry_octet 10 hours ago [-]
They are all significant risks, and we pay significant money to JFrog for their X-ray product to scan and alert on bad dependencies, and significant internal tooling to track which package was used on which developer enclaves.
lrvick 14 hours ago [-]
Those are also all just as bad but you can at least run those fully in containers or vms and never let them touch your host system.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
azuanrb 17 hours ago [-]
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 migrated our monorepo to use mise with bootstrap and mise-tasks. I was able to delete a whole heap of setup scripts and our brewfile. First time setup is extremely simple now and re-running for updates is blazing fast.
mise has been an absolute delight.
yougotwill 8 hours ago [-]
Congrats on the release @mikemcquaid. I like how the trusted taps feature could be opted into early. It made it easier to migrate my setup before it became compulsory. Hope big changes like that can keep the same flow. Keep up the great work!
denkmoon 8 hours ago [-]
I’ve really been enjoying nix as my package manager on macos. It’s on a separate volume so feels even more isolated from clobbering my macos and has, in my uninformed opinion, better sandboxing and reproducible builds
blixt 19 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?
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.
mpweiher 12 hours ago [-]
Tried the app. Just gives me the error message "Failed to decode Homebrew JSON output".
]brew -v
Homebrew 7.0.1
1matin 17 hours ago [-]
I guess the Hackintosh era is (finally) facing its death...
touwer 21 hours ago [-]
Fantastic, thx for the effort!
max979 20 hours ago [-]
Time to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
inatreecrown2 20 hours ago [-]
I have this bound to an alias: bu
Run it every couple of days, easy peasy.
x3n0ph3n3 14 hours ago [-]
If you're going to update that frequently, you may want to consider something that allows for cooldown like this [1]. I've gotten more nervous about supply-chain attacks over the last few months.
That's a very good idea. Thanks for the link. Ideally this should be a feature in homebrew.
x3n0ph3n3 9 hours ago [-]
It absolutely should be.
pietz 17 hours ago [-]
Thanks for the hard work, but the Tahoe limitation for the GUI app is absolutely ridiculous.
17 hours ago [-]
x3n0ph3n3 14 hours ago [-]
Yeah, I'm holding onto Sequoia until after Golden Gate is GA. I've heard nothing good about Tahoe.
jitbit 8 hours ago [-]
same. "macOS Tahoe 26+" requirement is a bummer.
yard2010 21 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!
gdevenyi 19 hours ago [-]
Does it still need root on Linux? That makes it an instant no go.
mikemcquaid 18 hours 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.
MattDamonSpace 16 hours ago [-]
A new era of native macOS apps is upon us.
GUIs abound. Rejoice!
12345hn6789 18 hours ago [-]
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
Erold 50 minutes ago [-]
[flagged]
ryanmerket 15 hours ago [-]
[flagged]
launchkitcodes 19 hours ago [-]
[dead]
assimpleaspossi 19 hours ago [-]
[flagged]
pdpi 19 hours 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 18 hours 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 19 hours ago [-]
If you actually clicked through to their homepage, I imagine you would find the “what does homebrew do” section quite enlightening.
assimpleaspossi 19 hours ago [-]
I did. If you actually read what I wrote you would see that I read it.
mcsniff 19 hours 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 19 hours 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 19 hours 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.
"brew install postgresql", unless you meant without Homebrew, in which case you could download the sources manually and compile with "make".
coherentpony 19 hours ago [-]
It’s a package manager for Mac.
assimpleaspossi 19 hours ago [-]
So Mac doesn't have a package manager?
niek_pas 19 hours ago [-]
No first-party package manager.
asimovDev 18 hours ago [-]
does App Store count?
19 hours ago [-]
hooverlabs 19 hours ago [-]
It’s just another software package manager for installing dev tools
mkrishnan 16 hours ago [-]
still needs fucking 'sudo'
ricksunny 14 hours ago [-]
does it self-uninstall cleanly (i.e. without leaving a footprint behind) yet? if not I don’t care about this or the next ‘upgrade’, and I can’t believe Homebrew project leaders push upgrades without addressing this basic flaw.
mikemcquaid 14 hours ago [-]
Yes. If/when it doesn’t: it’s a bug and we’ll fix it. We can’t fix things people don’t report. Also: this is open source: you also could choose to fix it. Unsurprisingly the Homebrew maintainers do not spend a lot of their time uninstalling Homebrew.
jasonmp85 14 hours ago [-]
[dead]
tkel 17 hours ago [-]
These release notes appear generated by LLM, with the usual extreme verbosity. Wish a human had done a better job editing these.
mikemcquaid 17 hours ago [-]
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.
perardi 15 hours ago [-]
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.
csande17 16 hours ago [-]
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.
elixirnogood 14 hours ago [-]
Does it surprise you that people are getting more skeptical when the software that installs system packages is getting more and more generated by AI?
mikemcquaid 13 hours ago [-]
We have a Landlock (formerly Bubblewrap) Linux sandbox due to an LLM. It sat unfixed on our roadmap for almost a decade. I and at least one other maintainer (as well as several LLMs) reviewed every line of code.
Homebrew has never been better performant, secure, tested, linted and typed. I understand the LLM dubiousness (I used to share it myself) but we’re the type of project where it’s very easy to get agents to do sensible end-to-end testing and review a nice language (Ruby). Just us on our outputs, not just our inputs.
One of our former maintainers was in high school when working on Homebrew. I’m sure many people would have found that worrying. His code was great, though (I reviewed most of it) and he made the project better. Same ultimately with LLMs. Your mileage may vary.
orangecat 15 hours ago [-]
Perhaps you should volunteer your services so that the project for which you paid $0 can have release notes more to your liking.
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.
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.
Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?
TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time.
Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).
It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.
> I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).
Two follow-up questions on this:
- How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)
- Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.
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.
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.
The lessons learned were instead used to make the Ruby frontend much faster.
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?
That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API.
This will likely get extended over time to eventually allow package definitions to themselves be in JSON.
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.
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...
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
`The macOS deployment target is set to 27.0, but the range of supported ....`
Golden Gate AAAAAARRRGGGHHHHHH
Just another few days, right? :)
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).
Probably wouldn't:
https://mise.jdx.dev/mise-cookbook/python.html#mise-uv
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
Now that PNPM supports managing runtimes [0], I found that most of Mise's offerings are actually built into package managers. Maybe I will have it graduates from my machine when I have time.
[0]: https://pnpm.io/cli/runtime
Uv is far superior to both Mise and Homebrew for Python work, and I find that it removes the vast majority of pain preventing me from using Homebrew by default for most things, and Mise only occasionally for specific dev envs. Mise is a great tool though!
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.
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.
This is all you have to add to the config file:
[bootstrap.packages]
"brew:git" = "latest"
"brew-cask:ghostty" = "latest"
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
Is it Claude or Codex built?
I've had to disable it on all my iDevices bc it breaks some Markdown parsers. How big a % of training data was produced on an Apple device? Ehhhhh probably small.
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.
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.
- 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).
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.
See Debian vs. Ubuntu, or NetBSD vs. DragonflyBSD.
Some software distributions emphasize package freshness and coverage, like Homebrew does, which multiplies the support burden involved for each architecture or platform supported.
Others have a more prominent focus on backwards compatibility or exotic architectures, but have a smaller or slower-moving package set.
ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.
That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.
But why drop before that?
No need to be sorry, the situation is understandable.
Other than that, I'm grateful for the free software.
Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.
1: https://news.ycombinator.com/item?id=49687331
And throw away perfectly good hardware.
Recycle old gear when the math no longer maths and move on.
Mindless consumption isn't going to extend your life.
welcome. - 2015 intel macbook user
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 think that, for the parent commenter to my original comment, this Intel Mac no longer fits their use case. They can fight it and suffer or get the right tool for the job. I'm sure the person who buys it from them won't care that the current version of Homebrew doesn't work on it.
Intel Macs run Linux very well, I might add.
It should also be noted that, yes, most electronics eventually get scrapped for parts and raw materials. It doesn't really take all that long for important components to fail to a point where a computer is not really worth dealing with anymore. Yes, they can be repaired in many cases, but that's only generally worth it to a small group of vintage enthusiasts (and I say this as someone who very much enjoys vintage computing myself).
When I eventually upgrade my hardware, I’ll happily use Homebrew again. In the meantime, MacPorts!
I'm back to the old installation methods !
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.
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
Bits don't rot.
And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.
Hey, it's their software, they are all volunteers and can do whatever they want. I'm grateful for the short window of time in which I was able to use their software. I don't get to decide their support period, but I will still hopelessly complain about it. "Deliberately breaking compatibility with a computer because it is old" is my biggest axe to grind with the whole software industry, and I'll shake my fists at this cloud until I die.
I'm salty today because I tried to run Fusion 360, and found that Autodesk just out of the blue decided that 1. My computer is too old to run the software (which ran just fine a few weeks ago on the same computer); 2. That I needed to update the software, and 3. The update will not run on my "old" computer. They took software that ran fine on my computer and deliberately pulled the rug out. Fuck Autodesk. I'm spending the entire afternoon exporting dozens of files I have on their cloud, one at a time, since they apparently can't even manage to keep an existing version of the software running.
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.
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
2) using an Intel Mac as your main computer, for most tasks != using it as a home server
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?
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
Haven’t used MacPorts since. Has it gotten any better at those things?
The second has also never happened to me. macports installs the packages into a separate prefix, and you just add that to the path, so I wonder how it could bork irretrievably.
Regarding instructions: for most packages, I found that just replacing `brew` with `sudo port` is enough, as most ports are available. And quite a few install instructions mention homebrew together with macports. I have not run into missing packages, but sometimes the ones that existed were a little out of date.
Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things.
The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store).
Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects.
For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me.
Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable.
MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts.
Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages.
All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it.
I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment.
Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps.
The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to.
I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble.
I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager.
For people who like macOS' app installation procedures: Nix + pkgsrc
For people who like Nix but want a disciplined escape hatch: Nix + MacPorts
For people who like Nix and want absolute coverage: Nix + Homebrew
For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix
For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI)
I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing.
And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.
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.
exactly
That really put me off.
Postgres is an example of this: the various directories are set at build time.
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.
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
it can be installed with:
brew install homebrew-app
Homebrew.app, however, has a show-stopper for me. "Failed to decode Homebrew JSON output" on the installed/upgrades panel. I'm guessing the Discover panel would normally indicate which Formulae/Casks are already installed, but because it couldn't parse the JSON output, that feature (if it exists) doesn't work.
I'll file an issue—I know HN isn't your bug tracker :)
Edit: there's an issue there already, and I sorted out the root cause: iTerm2's shell integration. If you're using zsh as your shell, the solution is here [^0] in the second comment.
[0]: https://github.com/Homebrew/BrewUI/issues/167/
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.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
If you have concrete concerns, please bring them to us. Vague concerns and hand-waving about “people getting hurt” isn’t appropriate or productive.
Anyway, my tone may not be entirely constructive, but it is one of frustration as seemingly no one is taking supply chain attacks seriously anywhere I look. I am quite sure if homebrew was backdoored, it would give an attacker control of production systems of countless financial companies, defense contractors, healthcare providers, AI labs. I think it is insane they trust rando homebrew maintainers with that much power, but they do and they are probably not going to stop because they do not even understand these risks, and there are not practical alternatives to brew on MacOS.
So that puts some major responsibility on the Homebrew team to either warn people to stop using it in high risk environments, or manage homebrew in a way appropriate for those environments.
Stagex actually does every single thing I am recommending Homebrew do, and with a way smaller team. What we do is also nowhere near enough, but the bar is in hell.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
https://mise.jdx.dev/bootstrap/packages/brew.html
mise has been an absolute delight.
I’ll update Xcode, but I will definitely not install macOS 27.0
[1] https://formulae.brew.sh/cask/wine-stable
You could create a third-party tap to install wine via homebrew.
Run it every couple of days, easy peasy.
1. https://github.com/whoschek/homebrew-cooldown
We hope to allow all prefixes under 64 bytes in future.
GUIs abound. Rejoice!
Looks like this release breaks Intel Macs. Very very sad. Not even 5+ year old hardware is apparently supportable to some devs
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.
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.
> 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.
Homebrew has never been better performant, secure, tested, linted and typed. I understand the LLM dubiousness (I used to share it myself) but we’re the type of project where it’s very easy to get agents to do sensible end-to-end testing and review a nice language (Ruby). Just us on our outputs, not just our inputs.
One of our former maintainers was in high school when working on Homebrew. I’m sure many people would have found that worrying. His code was great, though (I reviewed most of it) and he made the project better. Same ultimately with LLMs. Your mileage may vary.