HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying) behavior. Set it in your bashrc or zshrc.

(report card for an0malous): "Does not play nice with other students."

Brew definitely used to be a lot slower, and I used to find it very tedious. I feel like they've done a reasonably good job in improving that over the years though (with the switch to distributing binaries by default being a huge win in terms of speed). I have to wonder if stuff like this is more due to lingering feelings from before combined with the easy access to vibe coding tools. If LLM coding came a few years earlier, maybe projects like this one would have made more sense to me.

Agreed here. The speed bottleneck I run into is simply that there's often a lot of packages that need updating, so there's a lot to download. And if anything needs to be compiled from source then the time that takes will dominate (though I think everything I currently run is thankfully pre-built)

If I have to deal with even the mention of another package manager in the cross-platform dev ecosystem I am going to snap

Run Linux on it. Apple has cut that OS off anyway. Would be safer security wise to have an OS that's updated

My brew update/upgrade takes forever

Yes MacPorts is the way. I switched after a new MacOS release meant mine was too old - brew update uninstalled a bunch of stuff I had been using then it stopped and let me know.

There's also https://github.com/dortania/OpenCore-Legacy-Patcher for the adventurous.

I've been a lightweight homebrew user for many, many, many years now. I just use it to download or update a thing I need, once every 3-6mo.

It constantly blows my mind how insanely long it takes just to do a few simple things on the fastest hardware I've ever owned in my life.

If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.

Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back!

Edit: no, it won't...

The same criticism has been said of Deno and Pnpm and bun, and yet, despite all these years since their respective releases, node and npm remain slower than all three options.

You could use the OpenCode legacy patcher to upgrade to v15/Sequoia: https://dortania.github.io/OpenCore-Legacy-Patcher/

> I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update

I definitely have thought something along those lines (mostly when I go to install a small tool, and get hit with 20 minutes of auto-updates first).

Pretty sure I also will not be adopting this particular solution, however

To be fair, Apple stopped providing security fixes for Mojave ~4+ years ago, and there have been 7 or 8 new os releases since then…

I don’t think it’s reasonable to expect an open source project to support everything

I've wanted brew to be faster. It would be a nice QoL for me.

>Install zerobrew via brew as per the official instructions.

>Immediately get an error saying the install path is too long and needs to be fixed as /opt/zerobrew/prefix is too many bytes.

Yeah gonna need some work.

Zerobrew looks mature, I'll check it out.

Btw, I noted this:

> Zerobrew is experimental. We recommend running it alongside Homebrew rather than as a replacement, and do not recommend purging homebrew and replacing it with zerobrew unless you are absolutely sure about the implications of doing so.

So I guess its fine to run this alongside Homebrew and they don't conflict.

And zerobrew, like the original Homebrew, is compatible with Linux.

It appears that Nanobrew is not.

I care about the light-weight efficiency of these new native code variants much more when I want to use brew on some little Linux container or VM or CI, than I do for my macOS development machine.

It uses the Homebrew API and uses its own dependency resolver and linker to pull Homebrew's precompiled packages.

Well, pnpm solves the storage issue, which is a more pressing reason to use it. (I don't know about deno/bun)

Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?

Yeah, but do they work? Last time I gave bun a chance their runtime had serious issues with frequent crashes. Faster package installation or spin-up time is meaningless if it comes at the cost of stability and compatibility.

I'm not sure if I just have way fewer things installed than most people or I just update more often, but I haven't experienced anything like this for years. I run `brew upgrade` probably around once every (work)day, usually right before doing a git pull or something, and then I'll quickly look at a couple emails or slack messages, and then it's always done by the time I switch back

Sure, but this might win you a couple of years max. Homebrew's "Support Tiers" page, which I linked, also addresses OCLP users, going so far as to specify a minimum Intel architecture. So, even if you use OCLP to allow support for newer OS versions, eventually your CPU architecture will be too old and you're back in Tier 3.

Also, the writing is on the wall: Ultimately, Homebrew will be ARM-only, once Apple's legacy support becomes ARM-only. At which point it's game-over for Intel Macs.

Homebrew solves the "availability of software" problem in the Mac ecosystem, but it does not solve the "Need to stay on the new hardware treadmill" problem.

I've never thought "only 2 seconds faster" - I've certainly thought "why is this taking half the time it takes Gentoo to recompile an entire server".

FWIW this seems to have improved in recent years. Back in the dark times of non parallelized downloads I would purposefully wait to end of day and fire the thing off before leaving

I think MacPorts still supports PowerPC Macs. I would need to rebuild my G5 to verify it because the hard disk is long dead, but last time I checked, it worked.

I get it - it’s a different beast with very different ideas behind it, but MacPorts is BSD-solid, and that’s a lot.

But you can turn that behavior off, IIRC it tells you the environment variable to set if you don’t want it to do that every time it runs.

I agree it’s annoying, but I haven’t turned it off because it’s only annoying because I’m not keeping my computer (brew packages) up-to-date normally (aka, it’s my own fault).

I agree in principle but Homebrew only supports the latest 3 versions of macOS. Right now Ventura 13 which came out in October 2022 is unsupported.

I wish I could remember the details -- I know I got annoyed with things being slow and when I got a new computer decided to go the no-homebrew route. I'm using nix, and it seems fine so far, but I also really don't understand it at all, which is a little concerning. :-)

bun is my go to for npm packages; it’s so much better and faster than npm, it’s not funny.

Never had any issues.

I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command

Terrible default behavior is a great reason to abandon a software package.

I still think that's entirely fair for a power user tool like homebrew. With the upgrade rates of macOS that probably means that's 98% of the users would be covered. Expecting an open source project to accept bug requests from a bigger variety of versions that then would need test devices on these versions to replicate issues sounds unrealistic. Bigger companies, or Apple itself I would hold to much higher standards when it comes to that.

brew used to say, more or less, "This OS is old and unsupported. Don't submit bug reports. If you have problems, too bad. If you submit a PR to fix something, we might merge it". Fair enough, right? Now it just says, "Go fuck yourself, grandpa."

> power user tool like homebrew.

That makes no sense then. A power user may still want to run older OS versions for a reason. Take the training wheels off it and then it'll be a power user tool.

> A power user may still want to run older OS versions for a reason.

No doubt there are edge cases like that, but I don't fault a project for not catering to the < 1% of users who would fall into that bucket and would probably be the ones that cause trickier support cases. These would maybe also be the user that could just install it without homebrew then, it's not like homebrew is the only way to install software.