by mikemcquaid
7 subcomments
- 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 have full compatibility. Hopefully this will help share effort across the wider ecosystem.
by ryandrake
4 subcomments
- What would be great is a Homebrew-compatible system that doesn't cut off support for older machines. I have a 3.8 GHz Quad core i5 iMac that still crushes, yet Homebrew has determined that I'm just too old and icky[1] to work with anymore. I had to move over to MacPorts, which is surprisingly nice, but I still miss brew.
Yea, I know. It's open source. They can do what they want. Still sucks.
1: https://docs.brew.sh/Support-Tiers
- 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.
by themadsens
0 subcomment
- I naively assumed it would work on the already installed homebrew packages. No such luck.
After installing, 'nb list' and thus eg. 'nb outdated' will yield the empty list!
I have absolutely no use for a competing homebrew installation that is mostly compatible ..
by chuckadams
1 subcomments
- This might be a good thing for homebrew to adopt for the download/install process, but if it doesn't include a ruby interpreter, I have a hard time seeing how it's going to be compatible with anything but searching and installing bottles. I install most of my packages from a Brewfile, which itself is Ruby code.
- Inaccessible: net::ERR_CERT_AUTHORITY_INVALID
by luizfelberti
2 subcomments
- It might be good to explain how this differs from zerobrew [0], which is trying to accomplish the same thing
[0] https://github.com/lucasgelfond/zerobrew
by 12_throw_away
0 subcomment
- So, A) to what extent is this vibe coded? And B) what is "trilok.ai" where you download it from?
- Do you choose compatibility or speed?
nb info --cask codex-app
nb: formula '--cask' not found
nb: formula 'codex-app' not found
- How does this work? AFAIK Homebrew formulae are written in Ruby [0].
Do they use some kind of Ruby parser to parse formulae?
[0]: https://github.com/Homebrew/homebrew-core/blob/26-tahoe/Form...
- This is most certainly vibed with a few optimization focused prompts. Yes - performance is a feature, but so is lack of risk.
by manlymuppet
0 subcomment
- If we get the Bun-ification of every package manager and language ecosystem that would be an awesome thing. This is a great trend.
by alsetmusic
0 subcomment
- I'm not a Python dev, but I appreciate the motivation uv has inspired across other package managers. I tried another brew replacement called zerobrew last month. It installed packages to a different directory from homebrew, so I didn't actually test drive after seeing that. Regardless, I look forward to the competition pushing mainstream tools to improve their performance.
- And why does speed matter in this case?
by an0malous
2 subcomments
- Does it reinstall postgres for every package install?
- I've been looking for something like this, especially to use only with casks now that Homebrew has removed support for not adding the quarantine bit. Looking forward to giving it a try!
- what happens if I test this tool by installing some packages and then remove (the tool)? will I still be able to use Homebrew to manage these new packages?
- The current version of brew has a flaw where the installer can't install isolated dependency trees in a sterile manner. If you have packages A, B, C, and D that all have updates, and assuming A,B,C depend on each other and come out to a total of say 1MB, and D is 1000MB, brew works in a MapReduce manner where it will attempt to finish downloading everything in parallel (even though the real bottleneck is D) before doing any installation.
Since the first 3 has no dependency on D, a better way would be to install them in parallel while D is still downloading.
by peytongreen_dev
0 subcomment
- [flagged]