[flagged]
Homebrew 7.0.0
81–90 of 271 posts
Re: Homebrew 7.0.0
#82[flagged]
"That front page" isn't the front page, it's the release notes for version 7.0.0. The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its ), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from comp…
Re: Homebrew 7.0.0
#83Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Thank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
Re: Homebrew 7.0.0
#84And that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore. I'm back to the old installation methods !
Re: Homebrew 7.0.0
#85I was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?
I’ll update Xcode, but I will definitely not install macOS 27.0
Re: Homebrew 7.0.0
#86And that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore. I'm back to the old installation methods !
Re: Homebrew 7.0.0
#87Earlier quoted context omitted.
I’d imagine they’re live updating the library paths in the binary headers, so anything shorter or equal to what they’re using is a simple rewrite, but longer is more complex.
Ah. That makes sense. It's so annoying how deeply UNIX packaging philosophy assumes that installation directories are something you hard-code at build time.
It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.
Re: Homebrew 7.0.0
#88Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
Re: Homebrew 7.0.0
#89The GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols. Is it Claude or Codex built?
Re: Homebrew 7.0.0
#90Earlier quoted context omitted.
Thank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
I don't understand the distinction you use here. Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with? None of them allow for versioned AppDirs by default as far as…
Distinction: https://news.ycombinator.com/item?id=49683258
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.