Rendered at 19:28:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
deanc 13 hours ago [-]
I don't agree with everything that Homebrew does, but the primary maintainers are visible, vocal and very opinionated. They have shown credibility and earnt my trust over the years given it is a crucial entry point to potential malware to my system.
Homebrew has continued to improve performance each major version. It's certainly a lot quicker nowadays than 5 years ago. I want reliability and safety in a package manager, speed is nice to have.
I applaud competition, but something like this starts with trust zero as far as I'm concerned. If there is one place that I want human input over LLM it's here. It needs to scream: smart humans are in control and overseeing the project. I don't see that here.
codetiger 12 hours ago [-]
100% agree on your comment. For a package manager, speed is aspiration but security and reliability are basic requirements. And the credibility is a big plus. Today anyone can build a package manager in a week with AI, but once the system grows, how is the team going to manage? This is where credibility matters.
unsnap_biceps 11 hours ago [-]
Honestly the latest speedups have brought it fast enough that I no longer really notice it anymore.
eviks 12 hours ago [-]
> If there is one place that I want human input over LLM it's here. It needs to scream: smart humans are in control and overseeing the project. I don't see that here.
How is Homebrew fundamentally different (as of today) - they vibe code. For example, the new app BrewUI is vibe coded, Claude is #2 contributor.
Does this scream "smart humans"?
saagarjha 12 hours ago [-]
I don't see what is unreasonable about vibe coding an optional GUI for your package manager
eviks 12 hours ago [-]
It doen't align with "your" principle of "If there is one place that I want human input over LLM it's here."
saagarjha 11 hours ago [-]
Yes, but the point is that the humans made the choice to apply it to something that is of low importance and not core to the project.
eviks 11 hours ago [-]
That wasn't the point, and it's also a fundamental mistake to think that the app store app for anapp store is of low importance, but also it doesn't resolve anything - if it's "a crucial entry point to potential malware to my system." how does it help that it's an entry point to a smaller part of your user base? And if that's just fine, what principle would stop the vibes from permeating "the core"??? The core also has llm contributions
anonreplier 11 hours ago [-]
The point you are ignoring or missing is that the homebrew maintainers have earned the trust to use AI contributions and have not simply whacked out a 100% vibe coded app in a week.
eviks 10 hours ago [-]
That's another made up point not coming from the source. But also, that's almost literally what they did. Ok, it wasn't in a week but a few months and the % is not 100%, but still more than 50%
But then this project's first release was in Feb, so it's actually been longer in development than the brew UI app! It's not a 1-week app! Stop making hypothetical stuff up, look at real apps
anonreplier 10 hours ago [-]
This isn't just a replacement for the homebrew UI, it's for the CLI too, so comparison invalid. I see the dev behind it has a whole 4 years of github experience - only the most recent 2 of which with anything significant (presumably model written), how reassuring.
eviks 7 hours ago [-]
The comment you originally replied addresses the "invalid" comparison, so circle back there. And you have the same issue here - how does "years of github experience" connects to concerts about LLM output in security-critical package managers?
cpursley 11 hours ago [-]
Yes, using tooling is literally what differentiates humans from the apes. Claude and the like are just the next evolution of tooling. BrewUI looks fine to me and I certainly prefer it (as it's native) over all the "hand-crafted" node/electron dumpster fires. If you want to continue to rub sticks together to make fire, nobody is stopping you (except perhaps the market).
eviks 11 hours ago [-]
No, you have a primitive understanding of evolution. Apes literally use tools. And if you want to play with AI fire in the "crucial entry point to potential malware to my system", nobody is stopping you either (even if you trust your own ringing security endorsement of "looks fine to me"), but that would still not address the core point of this discussion
gentlerain 12 hours ago [-]
The biggest challenge with all these new packages coming up is support for edge cases and maintainability over the years.
AI may make it easy to clone or port something to a new language but it will later need a dedicated human to put in a shift and fine tune it.
So unless you are ready to keep jumping to the newest, it's better to stay with the trusted for now.
lrvick 8 hours ago [-]
Maybe Homebrew is reliable, but do not assume it is safe. It has always operated on the honor system for contributions and code review. Every maintainer is able to merge anything they want without review or signatures. No matter how good their intentions, Homebrew is a massive supply chain attack waiting to happen.
tacker2000 13 hours ago [-]
Smart humans?
Is it smart to deprecate everything the minute Apple sunsets their OS version?
This is not a smart package manager, its a manager for the “dumb” masses, that need to be saved and protected from themselves by forcing them into the next walled garden, so to speak…
Another recommendation for mise, in my case it has already fully replaced brew, stow and direnv since I started using it this January, and it has many more features I'm not using yet (secret management, tasks, automation, ...), all from a single rust binary.
Also, unlike homebrew/linuxbrew, the install path for apps can be set to anywhere and is fully portable (it's all relative symlinks).
So far I never had any issue with it or any backward incompatibilities when upgrading, despite the very frequent releases and constant new features. The developer also seems very security minded (he immediately added a "minimum release age" feature for all apps when the trivy github action debacle was made public)
kstrauser 13 hours ago [-]
Oh! I thought it was a wrapper around brew so you could list all your tools in one place, but you’re right, it bypasses homebrew altogether. Nice.
I’ve recently started using mise to manage dotfiles, including its own config, and sync them on all my systems. Now I can easily have all the same packages installed everywhere. I am loving mise a lot these days.
potamic 11 hours ago [-]
mise is great with running multiple versions of a package, something I've found not very seamless with brew.
jdxcode 10 hours ago [-]
i benchmarked it locally a few weeks ago and it's much faster than homebrew 7
how much faster is kind of a useless metric: it's so highly variable on which command and things like network speed, expect 2x-1000x faster depending on what we're talking about
weikju 13 hours ago [-]
TIL. Thanks for that!
nine_k 12 hours ago [-]
"Alternative to homebrew (the CLI utility)" -> "Frontend to Homebrew (the package system)".
Along these lines, I wonder when somebody will come up with a "universal package manager" that factors out the dependency resolution, content-addressable store, packing / unpacking, file manipulation, signatures, etc. Small plugins, maybe just declarative descriptions, would suffice to connect it to stores like npm, homebrew, pypi, maybe even cargo and nixpkgs.
tasuki 12 hours ago [-]
We certainly have no shortage of "universal package managers". Most package managers try to do just that.
saagarjha 12 hours ago [-]
May I introduce you to the lord and savior Bazel (or CMake if Google gives you the ick)
davidguetta 11 hours ago [-]
it's called codex / claude code as far as i'm concerned
BugsJustFindMe 14 hours ago [-]
> "zerobrew does the relocation in-process and links from a content-addressed store"
Ok, but why a new app for that instead of a PR for brew?
gavinsyancey 13 hours ago [-]
Some combination of
- homebrew maintainers wouldn't be interested in accepting this as a PR unless it's actually maintainable, as they're the ones who would have to take responsibility for maintaining it going forward. And it needs to integrate well with the existing architecture, be well-designed and well-documented, have a migration plan and fallbacks for edge cases that are currently supported but won't work with this, etc. OPs implementation works, but is some combination of hacked together / slopcoded and it would take a lot of work to get it into a shape that could be accepted upstream. OP isn't interested in (or isn't capable of) putting in that work.
- "I made zerobrew, with 7.6K GitHub stars and thousands of users" sounds more impressive than "I made a contribution to homebrew that sped up package installation by up to 100x" despite the latter being both harder and more useful.
fooker 13 hours ago [-]
Open source projects have insane levels of gatekeeping nowadays.
It’s sad, but also makes some sense.
Nobody wants to maintain someone else’s AI slop when they could do their own version of the slop.
geraneum 12 hours ago [-]
> insane levels of gatekeeping
Good! I want to be able to trust and rely on homebrew, authorization, authentication, infra, os and other _crucial_ software. The bar should be really high and I appreciate the efforts of open source maintainers now more than ever.
fooker 12 hours ago [-]
I didn’t say it was bad, my response was to a question asking why this wasn’t a pull request for homebrew.
saagarjha 12 hours ago [-]
Consider not using loaded words then
fooker 6 hours ago [-]
Oh it is gatekeeping :)
Everyone doing any kind of gatekeeping is convinced that it’s for a great reason.
geraneum 3 hours ago [-]
> Oh it is gatekeeping
That's exactly the problem with loaded words. People often use it to mean different things.
For example, in open source software, "open" has a different meaning than it does in "open door". It never meant that anyone could upstream their desired changes. It meant, and still means, that you can take the code and do whatever you want with it without legal consequences. You can still do this.
What's changed is the large volume of slop and garbage thrown at open source maintainers. When these are understandably rejected, people (or AI companies) get upset and complain about gatekeeping.
fooker 3 hours ago [-]
All good, and that’s exactly the answer to ‘why is this a new project rather than a homebrew PR’, which is what this comment chain is about.
potamic 14 hours ago [-]
What's the significance of warm speedup in the benchmarks? For most new installs, cache would mostly be empty, shouldn't the cold numbers be more significant for day to day use?
sampullman 13 hours ago [-]
If you ask an AI agent to make some nice benchmarks for your readme, it will often include extra comparisons that aren't particularly relevant.
BugsJustFindMe 14 hours ago [-]
None, unless you happen to enjoy installing the same thing over and over again on the same machine.
sunnysahijwani 12 hours ago [-]
[flagged]
gregoriol 12 hours ago [-]
Why would one care for 100x faster homebrew? it's a tool you use every now and then, you rarely install or upgrade 1000 things, and when you do it doesn't really matter if it takes 10s or 0.1s
meghanto 13 hours ago [-]
I tried zb for a while now but ended up having to uninstall it and revert back to regular homebrew. It breaks with basic stuff like node half the time
sashank_1509 12 hours ago [-]
I guess the LLM reward hacked instead of solving the problem
sevg 14 hours ago [-]
Warning for those that care: LLM readme.
iagooar 14 hours ago [-]
I wonder how the industry has not yet learned to use ASD-STE100 Simple Technical English for documentation. It makes it so much more polished and so much less AI-sloppy.
saagarjha 12 hours ago [-]
I wonder how the industry has not yet learned that humans like to read human prose instead of Claude with a disguise
worthless-trash 14 hours ago [-]
I find the english perhaps a little too rigid when reading it for non technical manuals. I do agree though it is definitely LESS slop.
cachebag 6 hours ago [-]
Incorrect, I wrote every line myself.
sevg 6 hours ago [-]
If you don’t care about hand-writing a readme, fine nobody is forcing you, but to lie about it is just sad.
cachebag 6 hours ago [-]
What an odd thing to lie about. Did you even read the thing? Or you did you see too many words and figure, "meh, probably AI generated."
cosmotic 2 hours ago [-]
Where did the 100x claim come from? The first sentence on the linked page says up to 6.6x faster.
wg0 14 hours ago [-]
Homebrew fails to install on Intel Macs. Says unsupported.
binaryturtle 14 hours ago [-]
I don't think MacPorts users have those kind of problems.
Personally I was burnt by Homebrew many years ago already. I lost trust in any such package managers. Since then I went back to just compile everything myself (I manage about 300 packages like that in my installation.) It's not that a big of problem. Only initially when you need to bootstrap everything to replace Homebrew it was quite the time investment, of course. But now you compile like a package here or there… just follow the script. It's very quickly done.
The best thing… no clutter. Every package has its strict directory. I only symlink from that what I need into /usr/local/bin.
frizlab 14 hours ago [-]
Given the number of patches homebrew has to download for a number of packages, I doubt it’s that easy
eviks 12 hours ago [-]
> Every package has its strict directory. I only symlink
Isn't that exactly the benefit of homebrew? It installs in one folder and symlinks.
And my guess, it would've been much easier to remove extra symlinks you don't need from its package manifest rather than rewrite the whole system
binaryturtle 11 hours ago [-]
Homebrew links everything by default (at least that's how it was), so you ended up with all kind of extra junk files all over the place you never needed that comes with some packages... all cluttering up things in the /usr/local main directories and the PATH.
Homebrew additionally also had bunch of other directories, a huge git checkout, etc. then add the weird permission restrictions/ limitations on top of it… many packages then stopped supporting the customisation options at some point, so you were forced to rebuild half of them yourself anyway, if you needed the respective options. Now you had even more mess in /usr/local. :-)
It may work for some, but it wasn't for me anymore (and I used Homebrew for many years before that.)
Brian_K_White 13 hours ago [-]
Same. When they explained why they assumed and required /usr and/or /usr/local was owned by steve or bill or whatever, with a straight face, I was gobsmacked and never touched it again.
Like, how did people so ignorant come to manage such a project? I excuse most of the users but not the authors who have the balls to call themselves "engineers" on top.
I wouldn't be suprised if they weren't the very reason shortly after that Apple took over ownership and brute force OS control over those dirs.
mschuster91 13 hours ago [-]
It's just the same on Linux though. Don't touch anything under /usr but /usr/local or you will run into issues, third-party software uses /usr/local, and that is why Macports ended up in /opt/local - guaranteed free of collisions.
duskwuff 14 hours ago [-]
Intel macOS is only marginally supported by upstream Homebrew:
> [...] We also recommend users consider installing NixOS, which should continue to run on essentially all Intel Macs. [...]
mediumsmart 14 hours ago [-]
for a while now - macports for the intel aficionados
saagarjha 12 hours ago [-]
*the PPC aficionados
reader9274 12 hours ago [-]
I don't use homebrew for speed. I use it for trust
theCodeStig 6 hours ago [-]
I use nix-darwin as a replacement for homebrew, and it’s served me well for circa 8 years.
Nix isn’t for everyone, but I find it to be far more stable.
figmert 12 hours ago [-]
I tried zerobrew before the original author archived it. It really was faster. There's even a mise plugin for it, but the plugin for it wasn't great to be honest. Caused some wild slowdowns on my prompt. I think it's cos zb or maybe the plugin loads some huge Homebrew version file every time it's invoked. Didn't look too much into it, but it was killed my prompt on slower connections
maayank 11 hours ago [-]
With coding agents available for the config files, I don’t see any reason not to use nix. Easy rollbacks, temp envs with different versions, what not to like.
karel-3d 14 hours ago [-]
Most of the slowness in brew comes from download times, so I don't really need this I think? I never thought "brew is too slow" except when it's downloading.
But I always thought I don't need pnpm untill I started using it, so. I don't know.
(I always knew I needed actually good python package manager before uv came, though.)
frizlab 12 hours ago [-]
Latest version of brew is now fast enough for making having a faster version useless IMHO.
14 hours ago [-]
ajdude 8 hours ago [-]
I see claude as a contributor. Was this vibecoded?
zazibar 8 hours ago [-]
It's on the frontpage of HN in 2026, of course it's vibecoded.
MiroslavPokorny 15 hours ago [-]
I would mention in the title here thaat zerobrew uses the same install files as homebrew.
jackwsmth 14 hours ago [-]
This is pretty cool - but Homebrew is also being in Rust right now, right?
Homebrew has continued to improve performance each major version. It's certainly a lot quicker nowadays than 5 years ago. I want reliability and safety in a package manager, speed is nice to have.
I applaud competition, but something like this starts with trust zero as far as I'm concerned. If there is one place that I want human input over LLM it's here. It needs to scream: smart humans are in control and overseeing the project. I don't see that here.
How is Homebrew fundamentally different (as of today) - they vibe code. For example, the new app BrewUI is vibe coded, Claude is #2 contributor.
Does this scream "smart humans"?
AI may make it easy to clone or port something to a new language but it will later need a dedicated human to put in a shift and fine tune it.
So unless you are ready to keep jumping to the newest, it's better to stay with the trusted for now.
Is it smart to deprecate everything the minute Apple sunsets their OS version?
This is not a smart package manager, its a manager for the “dumb” masses, that need to be saved and protected from themselves by forcing them into the next walled garden, so to speak…
So far I never had any issue with it or any backward incompatibilities when upgrading, despite the very frequent releases and constant new features. The developer also seems very security minded (he immediately added a "minimum release age" feature for all apps when the trivy github action debacle was made public)
I’ve recently started using mise to manage dotfiles, including its own config, and sync them on all my systems. Now I can easily have all the same packages installed everywhere. I am loving mise a lot these days.
how much faster is kind of a useless metric: it's so highly variable on which command and things like network speed, expect 2x-1000x faster depending on what we're talking about
Along these lines, I wonder when somebody will come up with a "universal package manager" that factors out the dependency resolution, content-addressable store, packing / unpacking, file manipulation, signatures, etc. Small plugins, maybe just declarative descriptions, would suffice to connect it to stores like npm, homebrew, pypi, maybe even cargo and nixpkgs.
Ok, but why a new app for that instead of a PR for brew?
- homebrew maintainers wouldn't be interested in accepting this as a PR unless it's actually maintainable, as they're the ones who would have to take responsibility for maintaining it going forward. And it needs to integrate well with the existing architecture, be well-designed and well-documented, have a migration plan and fallbacks for edge cases that are currently supported but won't work with this, etc. OPs implementation works, but is some combination of hacked together / slopcoded and it would take a lot of work to get it into a shape that could be accepted upstream. OP isn't interested in (or isn't capable of) putting in that work.
- "I made zerobrew, with 7.6K GitHub stars and thousands of users" sounds more impressive than "I made a contribution to homebrew that sped up package installation by up to 100x" despite the latter being both harder and more useful.
It’s sad, but also makes some sense.
Nobody wants to maintain someone else’s AI slop when they could do their own version of the slop.
Good! I want to be able to trust and rely on homebrew, authorization, authentication, infra, os and other _crucial_ software. The bar should be really high and I appreciate the efforts of open source maintainers now more than ever.
Everyone doing any kind of gatekeeping is convinced that it’s for a great reason.
That's exactly the problem with loaded words. People often use it to mean different things.
For example, in open source software, "open" has a different meaning than it does in "open door". It never meant that anyone could upstream their desired changes. It meant, and still means, that you can take the code and do whatever you want with it without legal consequences. You can still do this.
What's changed is the large volume of slop and garbage thrown at open source maintainers. When these are understandably rejected, people (or AI companies) get upset and complain about gatekeeping.
Personally I was burnt by Homebrew many years ago already. I lost trust in any such package managers. Since then I went back to just compile everything myself (I manage about 300 packages like that in my installation.) It's not that a big of problem. Only initially when you need to bootstrap everything to replace Homebrew it was quite the time investment, of course. But now you compile like a package here or there… just follow the script. It's very quickly done.
The best thing… no clutter. Every package has its strict directory. I only symlink from that what I need into /usr/local/bin.
Isn't that exactly the benefit of homebrew? It installs in one folder and symlinks. And my guess, it would've been much easier to remove extra symlinks you don't need from its package manifest rather than rewrite the whole system
Homebrew additionally also had bunch of other directories, a huge git checkout, etc. then add the weird permission restrictions/ limitations on top of it… many packages then stopped supporting the customisation options at some point, so you were forced to rebuild half of them yourself anyway, if you needed the respective options. Now you had even more mess in /usr/local. :-)
It may work for some, but it wasn't for me anymore (and I used Homebrew for many years before that.)
Like, how did people so ignorant come to manage such a project? I excuse most of the users but not the authors who have the balls to call themselves "engineers" on top.
I wouldn't be suprised if they weren't the very reason shortly after that Apple took over ownership and brute force OS control over those dirs.
https://docs.brew.sh/Support-Tiers
Thanks to LLMs I just vibe my own package management system based on debian packages and have my own registry now with stuff that I care about
From https://nixos.org/manual/nixpkgs/unstable/release-notes#x86_...
> [...] We also recommend users consider installing NixOS, which should continue to run on essentially all Intel Macs. [...]
But I always thought I don't need pnpm untill I started using it, so. I don't know.
(I always knew I needed actually good python package manager before uv came, though.)
https://github.com/Homebrew/brew-rs
curl && tar -x && ./configure && make install ? Guess what, it's the same with more steps.
Bruh…