The amount of value returned to the Apple ecosystem through brew is remarkable and while this post makes me even more in awe of the care that goes towards the community, I'm sad that one of the richest companies in the world isn't giving more back.
Our audit of Homebrew
81–90 of 205 posts
Re: Our audit of Homebrew
#82Before moving to Nix, I was using MacPorts since Homebrew had some...eccentric behavior at the time (didn't work with multi-user setups, owned your /usr/local, lots of "works on my machine" problems from auto-updating and lack of version control, ...). One thing that has always felt insecure about Homebrew to me was the ability to use GitHub (not Git) URLs as ad-hoc packages. I wonder if that is how TOB-BREW-13 worke…
Funny that you mention it, I also went Homebrew -> MacPorts -> Nix.
Homebrew had analytics and broke versions too often. MacPorts is way more stable, but some niche packages would not build well, and I had terminfo issues with tmux.
Nix allows me to override most of that, and I can share home manager config with my Debian workstation.
Re: Our audit of Homebrew
#83Earlier quoted context omitted.
> Key difference is Mac ports keeps its tree separate in /opt What do you mean by this? brew has been linking from /opt/homebrew for years now.
I did not know about the new directory practice, thanks. From what their site says it looks like it was done this way to keep ARM native stuff separate from old intel code which can still work under Rosetta. But I don't see any indication homebrew stopped linking system libraries as a matter of course (correct me if I'm wrong). MacPorts makes a point of not doing this. /opt/local is its own universe and dependencies…
I much rather them use system libraries than build parallel libs that don’t go through Apple’s vetting / changes. This has worked well for me in practice. I’ve actually never run into an issue where the system library got updated and that broke homebrew’s apps.
Re: Our audit of Homebrew
#84Apple should have been the one funding the audit.
Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.
Re: Our audit of Homebrew
#85Before moving to Nix, I was using MacPorts since Homebrew had some...eccentric behavior at the time (didn't work with multi-user setups, owned your /usr/local, lots of "works on my machine" problems from auto-updating and lack of version control, ...). One thing that has always felt insecure about Homebrew to me was the ability to use GitHub (not Git) URLs as ad-hoc packages. I wonder if that is how TOB-BREW-13 worke…
Nix also allows github.
Re: Our audit of Homebrew
#86Earlier quoted context omitted.
I've been using MacPorts for as long as I've wanted a macOS package manager, and it's been working very well for me.
Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.
Here's my guess.
Homebrew had at least these things going for it:
- it has always had a strong emphasis on presenting a simple, clean, pleasant, pretty, playful UI and executed that well
- when it came out, source-based package managers for macOS generally didn't have any binary caching mechanisms, so compile time mattered
- Homebrew's embrace of the base system as opposed to bringing its own dependencies bought it greater reuse at the cost of robustness, driving down total time to install many packages
- the language that `brew` and its packages were written in was trendy at thw time as well as pre-installed on macOS, which made them instantly accessible to huge numbers of web developers
- the older macOS package managers generally drew on traditions and tooling from the Linux world (e.g., Fink, with Debian tooling) or the wider Unix world (e.g., MacPorts and various *BSD ports systems and packages written in some Tcl IIRC).
Re: Our audit of Homebrew
#87Earlier quoted context omitted.
Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.
Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?
Re: Our audit of Homebrew
#88Apple should have been the one funding the audit.
Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
IMO, it's just counter to what Apple aspires MacOS to be.
If they would do it all over again, I would bet that they would have wanted to make MacOS be like iOS.
Re: Our audit of Homebrew
#89Earlier quoted context omitted.
so many projects release only formulas for homebrew. I keep both and try to use McPorts first.
Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.
On an old Macbook I keep around for various rare offline tasks, I actually did go back to MacPorts from Homebrew. Chief reason being: Homebrew doesn't support old versions of the OS so I was SOL trying to install a new package on it. The backwards compatibility is a nice feature!
My current machine is also not on the latest so I wonder if an attempt to brew update would nag me now...
Re: Our audit of Homebrew
#90I’m still good on MacPorts. Seems I’m alone these days. Works fine for me.
I mostly just use Nix, but I also have pkgsrc, MacPorts, and (kinda) Homebrew installed on my Mac.
The only ones with any CLI tools installed, though, are Nix and pkgsrc.