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.
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.
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).
> 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.
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.
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.
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.
reply