MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain.
This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there.
Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
In today's world, the "multiple versions of complex products like PHP or MySQL at once" isn't a compelling argument for me as I use docker to solve that problem.
> Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as all users on the system share the same software?"
If I read homebrew's install.sh correctly, it changes ownership of a few directories under /usr/local, not /usr/local itself (on x86, on ARM it follows a different path). This matches how my current Mac, which has brew, is currently setup as well.
# Required installation paths. To install elsewhere (which is unsupported)
# you can untar https://github.com/Homebrew/brew/tarball/master
# anywhere you like.
...
# On Intel macOS, this script installs to /usr/local only
HOMEBREW_PREFIX="/usr/local"
...
directories=(bin etc include lib sbin share opt var
Frameworks
etc/bash_completion.d lib/pkgconfig
share/aclocal share/doc share/info share/locale share/man
share/man/man1 share/man/man2 share/man/man3 share/man/man4
share/man/man5 share/man/man6 share/man/man7 share/man/man8
var/log var/homebrew var/homebrew/linked
bin/brew)
group_chmods=()
for dir in "${directories[@]}"; do
if exists_but_not_writable "${HOMEBREW_PREFIX}/${dir}"; then
group_chmods+=("${HOMEBREW_PREFIX}/${dir}")
fi
done
... and further on, after some checks, group_chmods turns into chowns ...
if [[ "${#chowns[@]}" -gt 0 ]]; then
ohai "The following existing directories will have their owner set to ${tty_underline}${USER}${tty_reset}:"
printf "%s\n" "${chowns[@]}"
fiHaven't used Homebrew in quite a time, so I'm not sure.
'ls -l /usr' reveals that /usr/local is root:wheel just like all other folders under /usr. How exactly is homebrew changing ownership?
Anyway, this requirement is well documented and not new:
https://github.com/Homebrew/brew/issues?q=is%3Aissue+%2Fusr%...
http://github.com/Homebrew/brew/blob/master/docs/Installatio...
Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Nope - intel Mac on Big Sur:
drogers@SJCMACJDYMD6M ~ % ls -l /usr
[snip]
drwxr-xr-x 15 root wheel 480 Dec 14 20:10 local
[end snip]
And for the record, neither of your links support your claim.
https://apple.stackexchange.com/questions/1393/are-my-permis...
https://superuser.com/questions/1264673/chown-usr-local-oper...
No, I'm on an Intel chip, not M1.
>Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Again, no, not on my machine it doesn't. /usr/local is root:wheel. This is a newish (to me) machine that I gave first birthday to beginning of December 2020. The first thing I did was installed brew and started installing the things that makes my computer useful to me. No permissions were asked to be changed.
Dunno if it needs this now anymore -- i think they moved to /usr/local/Homebrew some time ago -- but this was a big deal for a few years
The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated.
I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up.
That's a "my experience" story and isn't meant to be defining.
I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them.
For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.
https://google.com/?q=nix+on+mac+os+x
Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there.
And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew does.
Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run.
If you've ever updated readline via Homebrew, you can pretty much just watch everything burn.
If you've ever tried to use an old version of Postgres, good luck. Particularly if you're wanting to mix and match versions of PostGIS.
If you're running an old version of macOS, you're out in the cold. Although, I must admit, recently this seems to be handled much better.
This comment actually just spurred me to find this (https://gist.github.com/jb510/99f12b1ac70f1cf8b780) which may fix the issue of forgetting to manually update.
Given the intervals between running Homebrew, you just know it’s going to spin for a minute or two updating every damn time you try to use it, usually when you want something installed fast.
If you like treating your Mac like a very MacMacMac pet, a pm designed for Mac is probably better.
If you'd like to treat your Mac like UnixMac livestock, you probably want a cross-platform pm.
Using Nix means the core of my dev needs are met by config shared between my NixOS and macOS systems, with some idiomatic unshareable bits around the edges.
(I don't want to trivialize the gaps or over-sell Nix here. Nix forms a foundation for accomplishing this, but I do still have non-trivial bootstrap scripts for macOS.)
That said, I think most people want darwin failures to be able to block, so it's mostly about getting on top of them to the point where it's practical to keep them triaged. Domen is working on getting a part-time position funded to work on issues here (https://opencollective.com/nix-macos), though individual package breaks are probably down the list.
I feel things have stabilized significantly in recent days, though. I haven’t had a single Darwin breakage on the unstable channel since the release of 20.09. Perhaps the Zero Hydra Failures effort[1] helped.
Recently I had nomad breakage on -unstable caused by nvml support, which pulls in nvidia_x11, which pulls in linux_5_4, which of course not installable on darwin[1]. The maintainer fixed it very quickly (thank you!) but I still need to wait few more days for it to be included in -unstable.
In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement.
[1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
For Google, it's likely the former is more important than the latter for a lot of their projects. An architecture that doesn't scale or doesn't always do the right thing or sometimes messes up data, can be catastrophic at the scale of Google.
This is the sort of myths we hold about interviews. That the company is doing such deep dive on us that they are reading our Github commits and considering the trade-offs of MacPorts vs. Homebrew architecture.
There isn’t, Homebrew is far superior in my opinion, and everyone I know using a Mac. We all left MacPorts ages ago.
It’s safe to say that has nothing to do with him not getting the job.
This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?
Relevant: https://xkcd.com/1200/
Yikes. That particular attack did not occur to me.
I'd been considering trying macports but this has convinced me.
As I seem to remember it, homebrew rankles if you use sudo but also complains if you’re not an admin account, which struck me as ironic and irritating all at once, and means that xkcd isn’t quite as relevant.
Isn't this just whataboutism though? Yes that's potentially a problem but it's an orthogonal one. So not really relevant to this discussion.
A hypothetical solution to the problem in the linked XKCD would be to somehow prevent an attacker accessing your bank, it would not be to allow an attacker to install drivers without your permission.
> With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).
This calculus change is basically my primary concern.
Of course it's not ideal that Homebrew apps have access to everything in my Home, but that's still better than them having access to everything on my system.
The fundamental issue is that the POSIX user model has no concept of one user being strictly less privileged than another, and therefore all impersonations require root.
And note that the situation on Debian and Ubuntu is much worse than either of these models, because every package has an opportunity to run arbitrary commands as root as part of the postinstall and at various other times during the package lifecycle. So basically you've owned yourself the first time you add some user's random PPA and run `apt dist-upgrade` to pull new versions from it.
And getting the tools team at work to vend both brew and macports seems malicious so I just suck it up there.
[1] https://github.com/Homebrew/homebrew-core/blob/master/Formul...
On the other hand, what I will say in favour of Homebrew is that its popularity does make life much easier as there's so much software available on it. Even very small / niche / new projects will often have a Homebrew package.
The former is more popular and easier to get started with and bigger community, but the latter is higher quality and better designed.
Macports is also good about naming different versions, so you can have python-34, python-37, and python-29 installed together.
“it doesnt deal well with multiple versions at the same time”
Also what system/os are you comparing to?
Macports never did this and kept libraries side by side cleanly.
Now, this is from the point of view of a software developer with a specific niche requirement. For normal users, from a security standpoint, it would most likely make sense to remove old versions of openssl.
I also very rarely update my Homebrew packages because there is no telling what will break half the time due to this.
And the fact that simply installing a package force updates every other package by default! I needed a single tiny utility while on a screen share recently, I `brew install` it. 15 minutes later Brew was still figuring the world out and it ended up being faster to just find the utility on Github and download it manually to use while letting Brew do its thing in the background. Still no idea if it ever ended up installing...
Don't get me wrong, I still think brew has been handy for me over the years. But I breathe a sigh of relief whenever I `apt-get` something on a Debian box and it behaves in a sane manner.
So quite limited in scope and not much configurable options and if you say that you need some features, they'll tell you you're doing it wrong.
It is quite easy to install though and has a lot of packages but if you have specific needs that are unmet, you are on your own.
It's more of a update manager than a true package manager.
The last years have shown clearly that Apple doesn’t go out of their way to make things easy for devs if it doesn’t helps their main client group.
It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer.
Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild).
Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects).
I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.
The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode.
There would be now need for a Apple Homebrew to use or provide universal binaries.
Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment) with the tools he needs on this system. Switching CPU architecture would be solved with reinstalling Homebrew on the new system (like it is now).
I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't respond further unless you are absolutely confident your position is in good faith and supported by personal relevant experience.
I know its warts. I don't say that it isn't broken for the usecase you are describing. I'm saying that like the Homebrew developers, if Apple were in charge of Homebrew, they wouldn't care about such a use case because it would only affect a tiny percentage of their user base.
If you don't believe that just look how old the user base command line tools are that are installed by default on macOS.
For example bash is "GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17), Copyright (C) 2007 Free Software Foundation, Inc." That's 14 years ago.
MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?