Live data from Hacker News

Homebrew 7.0.0

brew.sh

191–200 of 271 posts

Re: Homebrew 7.0.0

#191
post #129

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…

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?

Re: Homebrew 7.0.0

#192

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. alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup"

Adding the `-y`-s is probably cowboy shit. I do have a `brew autoremove` at the end though

Re: Homebrew 7.0.0

#193

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.

Re: Homebrew 7.0.0

#194
post #57

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.

Re: Homebrew 7.0.0

#195
post #45
post #37

Earlier 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…

> 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?

Re: Homebrew 7.0.0

#196
post #27

[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.

Re: Homebrew 7.0.0

#197
post #13

Farewell, 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…

If the old Intel Mac still works, what should one do? Dump it into a landfill?

Re: Homebrew 7.0.0

#198

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

[dead]

Re: Homebrew 7.0.0

#199
post #54

Earlier 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?

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.

Re: Homebrew 7.0.0

#200
post #13

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 neithe…

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.

Post reply on HN