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.
Nanobrew: The fastest macOS package manager compatible with brew
11–20 of 156 posts
Re: Nanobrew: The fastest macOS package manager compatible with brew
#12This 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.
Edit: no, it won't...
Re: Nanobrew: The fastest macOS package manager compatible with brew
#13nb info --cask codex-app
nb: formula '--cask' not found
nb: formula 'codex-app' not found
Re: Nanobrew: The fastest macOS package manager compatible with brew
#14If 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…
I didn't know about the pending, official Rust frontend! That's very interesting.
Re: Nanobrew: The fastest macOS package manager compatible with brew
#15This 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 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
Re: Nanobrew: The fastest macOS package manager compatible with brew
#16This 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.
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...
Re: Nanobrew: The fastest macOS package manager compatible with brew
#17Re: Nanobrew: The fastest macOS package manager compatible with brew
#18Re: Nanobrew: The fastest macOS package manager compatible with brew
#19This 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
Re: Nanobrew: The fastest macOS package manager compatible with brew
#20This 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