Live data from Hacker News

Nanobrew: The fastest macOS package manager compatible with brew

nanobrew.trilok.ai

81–90 of 156 posts

Re: Nanobrew: The fastest macOS package manager compatible with brew

#81
post #68

Earlier quoted context omitted.

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

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

Re: Nanobrew: The fastest macOS package manager compatible with brew

#82
post #7

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

[dead]

Re: Nanobrew: The fastest macOS package manager compatible with brew

#83
post #68

Earlier quoted context omitted.

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…

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

Re: Nanobrew: The fastest macOS package manager compatible with brew

#84
post #41

Earlier quoted context omitted.

Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon

Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow. It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated. Glad to hear a Rust rewrite is coming to Homebre…

> Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow

Because how often are you running it where it's not anything but a opportunity to take a little breather in a day? And I do mean little, the speedups being touted here are seconds.

I have the same response to the obsession with boot times, how often are you booting your machine where it is actually impacting anything? How often are you installing packages?

Do you have the same time revulsion for going to the bathroom? Or getting a glass of water? or basically everything in life that isn't instantaneous?

Re: Nanobrew: The fastest macOS package manager compatible with brew

#86
post #57
post #54

Earlier quoted context omitted.

Context for those unaware: the commenter, mikemcquaid, is the project lead for Homebrew.

Thank you, his arguments totally makes sense, only the part that makes me icky is: > There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. People are free and probably do this because it is slow. Alternatives often are not a bad thing.

Yeah, tbh homebrew is slow as fuck. It literally took 30 minutes to install aws cli on my 2020 mbp. I will happily flock to every new version that's faster.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#87
post #79
post #36

Earlier quoted context omitted.

Makes no sense, the wording suggests it can use Homebrew's backend, not that it's a complete alternative to Homebrew. Nobody is confused about that.

The recipes for building and installing homebrew packages are written in Ruby You cannot really be compatible with this unless you run the Ruby as the install scripts could do whatever arbitrary computations In reality most recipes contain a simple declarative config but nothing stops you from doing Ruby in there. Hence to achieve total compatibility one would need to run Ruby

Is this still true since they swapped to distributing binaries rather than building from source on each install? It's been years since I last installed something from homebrew that built from source, so something that could install the same binaries would be compatible from my standpoint.

That said, it's also been a while since I've really had any huge complaints about brew's speed. I use Linux on my personal machines, and the difference in experience with my preferred Linux distro's package manager and brew used to be laughable. To their credit, nowadays, brew largely feels "good enough", so I honestly wouldn't even argue for porting from Ruby based on performance needs at this point. I suspect part of the motivation might be around concerns about relying on the runtime to be available. Brew's use of Ruby comes from a time when it was more typical for people to rely on the versions of Python and Ruby that were shipped with MacOS, but nowadays a lot of people are probably more likely to use tooling from brew itself to manage those, and making everything native avoids the need to bootstrap from an existing runtime.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#88
post #7

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

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.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#89
post #28

If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…

Heyyyy, who are you to tell us what is and isn't compatible with homebrew? (Just kidding, thank you for creating homebrew and your continued work on it!)

I think Max Howell created Homebrew. I think McQuaid is the current maintainer

Re: Nanobrew: The fastest macOS package manager compatible with brew

#90
post #7

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

> 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

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
Post reply on HN