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…
Homebrew 7.0.0
191–200 of 271 posts
Re: Homebrew 7.0.0
#192Awesome, 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. alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup"
Re: Homebrew 7.0.0
#193does 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.
Re: Homebrew 7.0.0
#194Re: Homebrew 7.0.0
#195Earlier quoted context omitted.
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 atomi…
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?
Re: Homebrew 7.0.0
#196[flagged]
https://docs.brew.sh/Homebrew-Security-and-Supply-Chain We take supply chain security very seriously, moreso than many package managers.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
Re: Homebrew 7.0.0
#197Farewell, Homebrew. It's been a good run. - 2019 Intel iMac user.
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 str…
Re: Homebrew 7.0.0
#198Today, 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).
Re: Homebrew 7.0.0
#199Earlier quoted context omitted.
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 neithe…
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
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.
Re: Homebrew 7.0.0
#200Farewell, 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 neithe…
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.