FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
64% Positive
Analyzed from 6801 words in the discussion.
Trending Topics
#homebrew#brew#intel#macos#support#macports#don#package#install#linux
Discussion (225 Comments)Read Original on HackerNews
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
Rewriting a program in Rust (specifically) really only makes sense for a few reasons:
1) the existing implementation is in an unsafe, cumbersome language (C, C++).
2) the existing implementation language is too slow and that slowness cannot be worked around.
3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.
1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.
Distinction: https://news.ycombinator.com/item?id=49683258
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
The lessons learned were instead used to make the Ruby frontend much faster.
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
Fish 4.0: The Fish of Theseus (fishshell.com)
906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments
https://news.ycombinator.com/item?id=42535217
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
`The macOS deployment target is set to 27.0, but the range of supported ....`
Golden Gate AAAAAARRRGGGHHHHHH
Just another few days, right? :)
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
Probably wouldn't:
https://mise.jdx.dev/mise-cookbook/python.html#mise-uv
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
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!
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
This is all you have to add to the config file:
[bootstrap.packages]
"brew:git" = "latest"
"brew-cask:ghostty" = "latest"
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
Is it Claude or Codex built?
If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
- 2019 Intel iMac user.
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
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.
Linux already has world class package managers.
Supporting macOS Intel has been significantly harder, slower and more expensive for us the last few years than adding ARM Linux support. If it was easy and free we’d have kept it for longer (until Apple and GitHub killed theirs at least which is coming in less than a year).
That said, after trying Bazzite I now prefer CachyOS and Arch as a whole.
I can see the appeal of using Homebrew and Flatpak to keep OS updates a little more separate from app updates, although I don't really see a specific need for it for myself.
ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.
That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.
But why drop before that?
No need to be sorry, the situation is understandable.
Other than that, I'm grateful for the free software.
Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.
1: https://news.ycombinator.com/item?id=49687331
And throw away perfectly good hardware.
welcome. - 2015 intel macbook user
I thought my Intel Mac from that era was incredibly weird. Little firmware-ish things were so glitchy and sluggish. At some point the wake from sleep/lid open just took forever in ways that didn't happen on older Intel Mac models (or maybe I was going crazy). I just had this strange feeling that Apple was knowingly half-hearting their Intel drivers and products as a whole as they were putting more energy into developing Apple Silicon.
Dude, you owe it to yourself to just grab a used M2 MacBook Air or something along those lines. Treat yourself. You'll be kicking yourself for not doing so sooner. (Don't get a MacBook Neo, too many compromises including poor battery life, a used Air is much better, and if you use more than one external monitor use caution on what model/CPU you choose).
Sure, a laptop should last longer than 7 years, but this is one of those "Apple yeets out a new architecture" exceptions like the PowerPC to Intel transition. Better to accept it and move on. 7 years is still a solid run. You've only got ~2 more years left until you start losing security updates anyway.
The other machine I highly recommend is Linux/Framework 13 Pro with the Intel Core Ultra Series 3, although that's a whole different price class, and obviously not everyone can make that move in terms of software compatibility.
I think that, for the parent commenter to my original comment, this Intel Mac no longer fits their use case. They can fight it and suffer or get the right tool for the job. I'm sure the person who buys it from them won't care that the current version of Homebrew doesn't work on it.
Intel Macs run Linux very well, I might add.
It should also be noted that, yes, most electronics eventually get scrapped for parts and raw materials. It doesn't really take all that long for important components to fail to a point where a computer is not really worth dealing with anymore. Yes, they can be repaired in many cases, but that's only generally worth it to a small group of vintage enthusiasts (and I say this as someone who very much enjoys vintage computing myself).
When I eventually upgrade my hardware, I’ll happily use Homebrew again. In the meantime, MacPorts!
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
1: https://news.ycombinator.com/item?id=49681546
Haven’t used MacPorts since. Has it gotten any better at those things?
The second has also never happened to me. macports installs the packages into a separate prefix, and you just add that to the path, so I wonder how it could bork irretrievably.
Regarding instructions: for most packages, I found that just replacing `brew` with `sudo port` is enough, as most ports are available. And quite a few install instructions mention homebrew together with macports. I have not run into missing packages, but sometimes the ones that existed were a little out of date.
Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things.
The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store).
Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects.
For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me.
Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable.
MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts.
Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages.
All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it.
I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment.
Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps.
The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to.
I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble.
I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager.
For people who like macOS' app installation procedures: Nix + pkgsrc
For people who like Nix but want a disciplined escape hatch: Nix + MacPorts
For people who like Nix and want absolute coverage: Nix + Homebrew
For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix
For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI)
I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing.
And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.
I've always used it on my Mac work machines, but always used my native package managers on Linux. What are the reasons to run homebrew on Linux? Better newer package support when you're on something slower moving like a Debian distro?
I've standardized my config scripts on using language managers for those tools (go, cargo, uv), which isn't perfect, so maybe brew is worth a chance.
exactly
I'm back to the old installation methods !
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.
I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
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/
That really put me off.
Postgres is an example of this: the various directories are set at build time.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
it can be installed with:
brew install homebrew-app
https://mise.jdx.dev/bootstrap/packages/brew.html
mise has been an absolute delight.
The supply chain security policy of brew is basically non existent and optimized for low-friction contributions. Think wikipedia. No enforced commit signing, review signing, or multi-party release signing, and thus everything is honor system.
Do not put brew anywhere near systems that access production or even on systems used to review production-bound code.
We take supply chain security very seriously, moreso than many package managers.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
If you have concrete concerns, please bring them to us. Vague concerns and hand-waving about “people getting hurt” isn’t appropriate or productive.
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.
I’ll update Xcode, but I will definitely not install macOS 27.0
[1] https://formulae.brew.sh/cask/wine-stable
You could create a third-party tap to install wine via homebrew.
Run it every couple of days, easy peasy.
1. https://github.com/whoschek/homebrew-cooldown
GUIs abound. Rejoice!
We hope to allow all prefixes under 64 bytes in future.
Looks like this release breaks Intel Macs. Very very sad. Not even 5+ year old hardware is apparently supportable to some devs
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
Homebrew has never been better performant, secure, tested, linted and typed. I understand the LLM dubiousness (I used to share it myself) but we’re the type of project where it’s very easy to get agents to do sensible end-to-end testing and review a nice language (Ruby). Just us on our outputs, not just our inputs.
One of our former maintainers was in high school when working on Homebrew. I’m sure many people would have found that worrying. His code was great, though (I reviewed most of it) and he made the project better. Same ultimately with LLMs. Your mileage may vary.