Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
Rewriting a program in Rust (specifically) really only makes sense for a few reasons:
1) the existing implementation is in an unsafe, cumbersome language (C, C++).
2) the existing implementation language is too slow and that slowness cannot be worked around.
3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.
1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
I was kinda kidding because parent called it "blazing" fast lol. I didn't think it was Rust. Blazing fast software is reserved as a descriptor for Rust programs :)
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.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
> Where do you draw the line between system packages and user facing apps?
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
> 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?
> 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.
> 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.
> 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.)
I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off.
> Does Aurora sometimes reboot multiple times when doing updates?
I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.
Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only).
The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working.
Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to.
Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine).
Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.
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".
I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.
"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.
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.
> 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 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.
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?
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.
> 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.
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?
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.
Yup! We’ve been using it for a really long time at this point.
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
> 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.
That's the beauty of asdf and then mise; they leverage existing solutions where possible, and unify how to get versioned runtimes for projects. Rust? rustup with mise, ruby? Precompiled when possible, otherwise ruby-build. Etc.
I'm not sure if I trust or want pnpm to support bundling rust for binary plugins, or various sundry toolchains.
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!
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions
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.
> So is sudo... And that's not "too risky" for the entire industry.
Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package. That's different for Mise, though, because there are a lot of ways to work productively without it. I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
> Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package.
Regarding Run0, I'd prefer to not rely so much on Polkit authentication after crazy vulnerabilities such as PwnKit (a pkexec vuln, but a good reminder that moving the security boundary won't magically solve issues).
> I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
I SUPER agree with you on that, btw. It's just likely that mise solves a problem which is much bigger for me than it is for you. Honestly, I'd prefer if I could manage everything with my distro packages, but, for a multitude of reasons, they're rarely enough for development tooling with multiple versions and environments.
I split my usage. Homebrew for OS things mise for the various tooling.
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
I 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.
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.
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?“
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.
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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.
So discard a working and perfectly good Macbook to be replaced by a new one manufactured by the World’s #1 CO2 emitter and transported probably halfway around the world in a container ship burning dirty bunker fuel.
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.
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.
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!
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.
And what if you are a developer and need to replace a well specced Mac and don’t have serious budget, especially considering recent memory and storage price increases?
Rather than a coffee table status symbol or a fashion accessory for pretending to write a novel in the coffee shop?
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).
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!
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)
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.
I always found it much slower when compared to brew and sometimes would just hang and get stuck when installing something. Plus the lack of casks does make it less of a direct replacement.
How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems.
Exactly. That's all I'm asking for. If version X works on my system today and version Y needs an OS bump, well... that sucks and is avoidable, but whatever. I expect to be able to obtain and use version X tomorrow and into the future. That's it. I'm not asking to make version Y work for me, but it would be nice if they didn't add the OS dependency.
But increasingly, developers can't even manage to keep version X around and working, despite them having to simply not do anything to it to keep it from breaking.
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.
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?
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.
NixOS is an open source project that runs great on my 2013 Dell laptop. I think the real point of distinction is that brew depends on Apple's OS and SDK, which somewhat ties their hands, while other OSs don't.
There's been a huge step up in basically everything going from intel to apple silicon. It's not a comparable hardware in any sense, and as such, it really does feel like it became a paperweight? I know I never wanted to see an intel macbook ever again the moment I tried M1. It's maybe hard to comprehend how different it is if you haven't used both. And at the same time I'm happy with my x86 desktop for 10+ years. Only thing that really improved in that span was storage.
So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.
What does saying "working tech" do for you? If I have a working Samsung CRT from 25 years ago do I ping them about smart TV support? Nowadays it's a shitty situation with planned obsolescence; but 6 years for an open source project dedicating resources to a dead end is more than enough and appreciated.
Sure, but 2019s Intel Macs are aboslutely usable for most tasks, and given much of the agentic dev. happens... somewhere remotely, it is more an opportunity to reuse this equipment for various tasks, rather than pollute the already dirty Earth with more electronic waste.
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!
Same here, but I understand their position. Meanwhile I rely on packages publishing builds for Intel Mac in GitHub (surprisingly a lot) or building from source code. I just asked AI to build me install system.
I 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.
See the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.
I’d imagine they’re live updating the library paths in the binary headers, so anything shorter or equal to what they’re using is a simple rewrite, but longer is more complex.
The present is built mostly on layers of the long-past :)
It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.
Yea, my understanding is that the split between / and /usr used to be more or less: the drive they used for / ran out of space, so they mounted another drive as /usr. As a consequence, / became where you put stuff that was essential during early boot, while /usr was where you put everything else.
But these days, "early boot" is handled by initramfs and we've all got drives large enough to not need the split anyway.
The dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
As a MacPorts users (generally light-weight, just a few things here and there):
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it!
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
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.
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?
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.
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.
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
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.
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.
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.
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
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?
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!
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me.
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
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.
Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
Glad to hear it. A lot of time and energy has gone into performance work so glad that’s noticeable! Thanks for the kid words too <3
It is Rust now?
It's still in ruby, although I see the new GUI is in swift: https://github.com/homebrew
Rewriting a program in Rust (specifically) really only makes sense for a few reasons:
1) the existing implementation is in an unsafe, cumbersome language (C, C++).
2) the existing implementation language is too slow and that slowness cannot be worked around.
3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.
1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
I was kinda kidding because parent called it "blazing" fast lol. I didn't think it was Rust. Blazing fast software is reserved as a descriptor for Rust programs :)
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.
Thank you for Linux Homebrew! It works so damn well.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
> Where do you draw the line between system packages and user facing apps?
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
> 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?
> 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.
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.
> 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.)
I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off.
> Does Aurora sometimes reboot multiple times when doing updates?
I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.
Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only).
The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working.
Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to.
Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine).
Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.
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".
I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.
"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.
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.
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.
> 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?
for reference: https://docs.appimage.org/reference/appdir.html
> I don't understand the distinction you use here.
Distinction: https://news.ycombinator.com/item?id=49683258
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
On Linux I use mise to install CLI tools
I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
Silly question - but how do you apply the cooldown to brew itself ?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
You can’t, by design. We instead apply if for you on upstream packages from NPM, PyPi, etc.
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
I think at one point you said you’re working on a rust rewrite? Is that still in the cards?
I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches).
The lessons learned were instead used to make the Ruby frontend much faster.
I don't know anything about homebrew, but have a question ...
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
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.
> 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.
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
https://fishshell.com/blog/rustport/
Fish 4.0: The Fish of Theseus (fishshell.com)
906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments
https://news.ycombinator.com/item?id=42535217
They experimented with it but ultimately decided to focus on perf with their existing ruby codebase.
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
Can’t speak for others but a lot of my work. I review it all locally first. The flow feels a lot like reviewing human PRs locally.
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
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.
Looks cool! Building.
`The macOS deployment target is set to 27.0, but the range of supported ....`
Golden Gate AAAAAARRRGGGHHHHHH
Just another few days, right? :)
Definitely notice the speed increase. Thank you for Homebrew. It's one thing that makes macOS bearable.
Was issue with upgrade running out of disk space fixed?
[dead]
TIL Homebrew has its own sandbox mechanism - looks like it's built around their own sandbox-exec wrapper, at least on macOS: https://github.com/Homebrew/brew/blob/d79ef822ab8136e393ed5f...
Yup! We’ve been using it for a really long time at this point.
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
> Why would you even use python without uv anymore
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.
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.
[0]: https://pnpm.io/cli/runtime
That's the beauty of asdf and then mise; they leverage existing solutions where possible, and unify how to get versioned runtimes for projects. Rust? rustup with mise, ruby? Precompiled when possible, otherwise ruby-build. Etc.
I'm not sure if I trust or want pnpm to support bundling rust for binary plugins, or various sundry toolchains.
But use what works for you.
> I'm not sure if you're saying avoid using system python?
That's what I'm saying, yes. System python should be treated as a REPL for interactive shell scripting and otherwise ignored entirely.
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.
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!
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.
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions
The bus factor makes no sense to you?
https://en.wikipedia.org/wiki/Bus_factor
do you have any kind of succession plan in place in case you get incapacitated for one reason or another? anyone you trust enough for that?
Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project
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.
> So is sudo... And that's not "too risky" for the entire industry.
Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package. That's different for Mise, though, because there are a lot of ways to work productively without it. I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
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.
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"
Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.
I've found `mise` more useful solely because it also handles things like tasks and daemons.
Yeah, the combination with mise is what make this great.
I also started using Mise for global CLI tools instead of brew and it’s working really well
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
re: npm, if you upgrade your global node version, you will lose that installation, right?
no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)
Mise is really sloppily vibe coded these days
What broke and affected you?
my split: brew for casks, mise for tools
mise also can manage brew
Okay
The GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols.
Is it Claude or Codex built?
I didn’t build it. The emoji were my idea. I (and Homebrew) have used them heavily before LLMs did. Maybe LLMs loving them is my fault. Sorry if so.
Have we pinned down the emdashes source yet? ;-P
I think it's because LLMs tend to obsessively write in a this-therefore-that kind of way, where an emdash is often the most semantically fitting punctuation.
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.
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?“
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.
Long term it matters very much if your car is Toyota or BMW or Kia or John Deere though.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
My point was “why do you assume it’s one of the two”.
Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
Sorry we couldn’t support this for longer :(
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
My personal opinion, but I'd rather see wider macOS support than Linux support, if it's a sheer matter of where time is allocated.
Linux already has world class package managers.
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).
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.
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
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.
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.
The polite Homebrew project that used to market themselves with "MacPorts driving you to drink?" on their website.
Different philosophy of dependency management.
They've never actively disallowed it, and volunteers have been happy to maintain it.
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.
> GitHub Actions will retire Intel macOS runners in autumn 2027
But why drop before that?
Thank you for all of your hard work, I’ve been very happily using Homebrew on OS X / macOS since 2010.
No need to be sorry, the situation is understandable.
very disappointed about this
I think they would be able to support older architectures under a paid contract if absolutely needed, for the right price.
Other than that, I'm grateful for the free software.
We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.
You have no idea what rug pull means, do you?
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.
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.
1: https://news.ycombinator.com/item?id=49687331
You're right, expecting other people to do your work for your for free is indeed a problem with the industry!
> Find an ARM Mac used (like an M1) and upgrade.
And throw away perfectly good hardware.
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.
>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.
Tinkering and building for fun brings joy, joy is the point of life. Tinker mindfully. “Tinker and build what matters, to you.”
In general I agree, but recycling old power hungry gear may be better for the environment in the long term.
So discard a working and perfectly good Macbook to be replaced by a new one manufactured by the World’s #1 CO2 emitter and transported probably halfway around the world in a container ship burning dirty bunker fuel.
Per unit costs are pretty low, and old Intel gear particularly energy guzzling.
That hardly happens on desktop/laptop Linux. Seems like a proprietary OS problem tbh.
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.
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.
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!
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!
> Farewell, Homebrew. It's been a good run. - 2019 Intel iMac user.
welcome. - 2015 intel macbook user
MacPorts is still there for us.
Check out MacPorts. They have installers going all the way back to Leopard.
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.
> used M2 MacBook Air
And what if you are a developer and need to replace a well specced Mac and don’t have serious budget, especially considering recent memory and storage price increases?
Rather than a coffee table status symbol or a fashion accessory for pretending to write a novel in the coffee shop?
If the old Intel Mac still works, what should one do? Dump it into a landfill?
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).
Electronics recycling exists, plus a few dollars for the aluminum case.
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.
Adding the `-y`-s is probably cowboy shit. I do have a `brew autoremove` at the end though
[flagged]
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!
And that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore.
I'm back to the old installation methods !
I recommend MacPorts, the migration is easy, you copy the package names you installed with brew, uninstall homebrew (there's an unisntall script on brew.sh FAQ section, it will also uninstall all homebrew packages (but not the casks)) then install macports and reinstall the packages with sudo port. Although the selection is smaller on macports and newer packages might not have a prebuilt pkg for your OS so you still might end up building manually (My poor i5 4core had to attempt building nodejs26 because there wasn't a pkg for Ventura)
Actually, Homebrew 7 is supported on your Mac, you just have to install Linux to use it. :)
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
Apple was selling Intel Mac Pros in 2023, it's absurd these things are coming up on EOL already.
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.
I always found it much slower when compared to brew and sometimes would just hang and get stuck when installing something. Plus the lack of casks does make it less of a direct replacement.
MacPorts has been there this whole time.
I've used MacPorts on macOS versions that don't support the latest OS, which per homebrew policy seems to be versions upto N-2.
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
Are you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.
6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems.
Bits don't rot.
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.
Exactly. That's all I'm asking for. If version X works on my system today and version Y needs an OS bump, well... that sucks and is avoidable, but whatever. I expect to be able to obtain and use version X tomorrow and into the future. That's it. I'm not asking to make version Y work for me, but it would be nice if they didn't add the OS dependency.
But increasingly, developers can't even manage to keep version X around and working, despite them having to simply not do anything to it to keep it from breaking.
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.
Ask MacPorts, which goes all the way back to Leopard-era PowerPC!
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.
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?
How does MacPorts manage to do it?
Why don't you ask them?
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.
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.
I managed to sell my battered old 32-bit Thinkpad on eBay last year. I couldn’t put Trixie on it, but Bookworm installed fine.
There's been a huge step up in basically everything going from intel to apple silicon. It's not a comparable hardware in any sense, and as such, it really does feel like it became a paperweight? I know I never wanted to see an intel macbook ever again the moment I tried M1. It's maybe hard to comprehend how different it is if you haven't used both. And at the same time I'm happy with my x86 desktop for 10+ years. Only thing that really improved in that span was storage.
So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.
You're on macOS. you should know full well that they do not care about those values.
I have one of the last Intel Macs and works perfectly fine (on Sonoma). How long should I expect working tech being supported?
I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
Sonoma will be getting its last security update imminently (possibly tomorrow).
What does saying "working tech" do for you? If I have a working Samsung CRT from 25 years ago do I ping them about smart TV support? Nowadays it's a shitty situation with planned obsolescence; but 6 years for an open source project dedicating resources to a dead end is more than enough and appreciated.
And given the performance jump from Intel to Apple Silicon, the perceived difference is 10+ years even.
Sure, but 2019s Intel Macs are aboslutely usable for most tasks, and given much of the agentic dev. happens... somewhere remotely, it is more an opportunity to reuse this equipment for various tasks, rather than pollute the already dirty Earth with more electronic waste.
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
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!
Same here, but I understand their position. Meanwhile I rely on packages publishing builds for Intel Mac in GitHub (surprisingly a lot) or building from source code. I just asked AI to build me install system.
I’m installing Linux on my 2019 16” today.
FYI Macos will also stop with major updates for Intel macs. You can just keep using brew 6 on macos 26.
Have you tried Mac Ports?
You do realize Intel support is gone, right? You won't be installing anything on your Intel Mac very soon...
[flagged]
I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc.
https://mise.jdx.dev/bootstrap/packages/brew.html
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.
Does installation still require root and a dedicated user account on Linux?
That really put me off.
See the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.
Wait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?
Pouring a bottle requires rewriting paths embedded in binaries, which results in a cap.
Postgres is an example of this: the various directories are set at build time.
I’d imagine they’re live updating the library paths in the binary headers, so anything shorter or equal to what they’re using is a simple rewrite, but longer is more complex.
Ah. That makes sense.
It's so annoying how deeply UNIX packaging philosophy assumes that installation directories are something you hard-code at build time.
The present is built mostly on layers of the long-past :)
It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.
Yea, my understanding is that the split between / and /usr used to be more or less: the drive they used for / ran out of space, so they mounted another drive as /usr. As a consequence, / became where you put stuff that was essential during early boot, while /usr was where you put everything else.
But these days, "early boot" is handled by initramfs and we've all got drives large enough to not need the split anyway.
It was also useful for many machines to share a single /usr over NFS
The dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
Bubblewrap is history starting with 7.0.0 according to the release notes
I always download the install script and change the directory to my user home directory, ~/.brew
Does that break anything? Surprised it’s not the default.
The dedicated user account is optional.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
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
As a MacPorts users (generally light-weight, just a few things here and there):
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it!
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
1: https://news.ycombinator.com/item?id=49681546
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.
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?
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.
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.
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
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.
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.
People have been integrating/recommending brew on immutable distributions.
> Better newer package support when you're on something slower moving like a Debian distro?
exactly
the gui homebrew manager is a nice addition!
it can be installed with:
brew install homebrew-app
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.
[0]: https://github.com/Homebrew/BrewUI/issues/167/
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
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?
This is a bug, sorry. Working on it.
Fixed and in 7.0.1.
You can download Xcode 27 RC now from https://developer.apple.com/download/applications/.
What is the impact of being tier 2?
I’ll update Xcode, but I will definitely not install macOS 27.0
Not usually a “+1” or “Me too!” kinda guy but homebrew is incredible and makes dev on Mac quite seamless. Huge thanks to the team.
I am quite disappointed by their decision to remove wine[1] from brew. The utility of it is obvious, and it's very popular software.
[1] https://formulae.brew.sh/cask/wine-stable
I don’t think utility or popularity had anything to do with the decision. It’s just that they no longer support casks with unsigned binaries.
You could create a third-party tap to install wine via homebrew.
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!
Thanks for the hard work, but the Tahoe limitation for the GUI app is absolutely ridiculous.
Yeah, I'm holding onto Sequoia until after Golden Gate is GA. I've heard nothing good about Tahoe.
same. "macOS Tahoe 26+" requirement is a bummer.
Fantastic, thx for the effort!
Does it still need root on Linux? That makes it an instant no go.
For initial installation to the default prefix someone needs to create the home directory and that person is probably root.
We hope to allow all prefixes under 64 bytes in future.
I guess the Hackintosh era is (finally) facing its death...
Tried the app. Just gives me the error message "Failed to decode Homebrew JSON output".
A new era of native macOS apps is upon us.
GUIs abound. Rejoice!
Time to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
I have this bound to an alias: bu
Run it every couple of days, easy peasy.
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.
1. https://github.com/whoschek/homebrew-cooldown
That's a very good idea. Thanks for the link. Ideally this should be a feature in homebrew.
It absolutely should be.
Thank you so much for doing this, for years you make me feel like home, or the year 2010. Please don't ever stop!
still needs fucking 'sudo'
[flagged]
[flagged]
[dead]
[flagged]
https://docs.brew.sh/Homebrew-Security-and-Supply-Chain
We take supply chain security very seriously, moreso than many package managers.
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.
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.
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?
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.
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.
https://github.com/whoschek/homebrew-cooldown
[flagged]
"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.
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.
If you actually clicked through to their homepage, I imagine you would find the “what does homebrew do” section quite enlightening.
I did. If you actually read what I wrote you would see that I read it.
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.
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.
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.
So how does one install postgresql on a Mac?
https://www.postgresql.org/download/macosx/
"brew install postgresql", unless you meant without Homebrew, in which case you could download the sources manually and compile with "make".
It’s a package manager for Mac.
So Mac doesn't have a package manager?
No first-party package manager.
does App Store count?
It’s just another software package manager for installing dev tools
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.
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.
[dead]
These release notes appear generated by LLM, with the usual extreme verbosity. Wish a human had done a better job editing these.
An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me.
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
Don’t let the reflexive grumps get you down.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
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?
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.
Perhaps you should volunteer your services so that the project for which you paid $0 can have release notes more to your liking.