This is very interesting, and maybe sheds light on why Google decided not to hire Max. There seems to be some consensus that MacPorts has the better architecture, while Homebrew has been better at responding to users, even according to Max himself.

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.

> maybe sheds light on why Google decided not to hire Max.

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.

I promise you that Homebrew is operating "at scale." Considering that Google hires many kids straight out of school who have never built any significant real-world software at all, I think this hypothesis is highly unlikely.

> There seems to be some consensus that MacPorts has the better 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.

> found it a bit cumbersome with the “no sudo” requirement

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?

My understanding is that the whole reason for running the outer commands as sudo is so that the inner build/install commands can be run in a far more restricted environment. Because brew runs as your own user, every build has access to your entire home directory, the whole homebrew folder, etc. It's nice in principle to not have to "trust" any of homebrew with sudo, but in reality, the trust surface area is far larger. 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).

Relevant: https://xkcd.com/1200/

I am confused by this. sudo seems like a far larger surface area than running as me. If it's just me then it's just me, but if it's sudo, then it's the entire box.

It depends whether you trust the tool maintainers more than the package definition maintainers. I certainly would. But don't take my word for it— here's a MacPorts developer explaining the sandboxing of builds:

https://apple.stackexchange.com/a/106942

> Directories listed in multiple users' $PATH that are writable without superuser privileges can be used for attacks (e.g., by placing a sudo binary that will log the password there). The same can be done by malicious software running as your user in order to get your password

Yikes. That particular attack did not occur to me.

Thank you for this link. This is the first robust argument for running as root that I've seen, and completely upends my assumptions.

I'd been considering trying macports but this has convinced me.

> inner build/install commands can be run in a far more restricted environment

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.

> every build has access to your entire home directory, the whole homebrew folder, etc.

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 point is that they wouldn't. Only the core brew utility would, because in almost all cases, it would be immediately downgrading itself to either a dedicated homebrew user, or in the case of builds, to a nobody user who does its work in /tmp and only has write access to the one install path it has been allocated (which is then chowned to the brew user afterward).

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.

The problem is that the way they do it breaks the UNIX model. /usr/local is common to all users, but Homebrew gives it the current user's permissions. This consequently creates weirdness if you actually use multiple user accounts.

Exactly why I prefixed my comment with "this is one of the FEW features I do love". The exact technical approach Hombrew ends up taking to a lot of problems always seems not quite right whenever I've dug a little deeper.

Fair point, but I bet the number of Macs in the wild shared by multiple people who would want to run Homebrew are vanishingly small.

Sure, but it's a native feature built into the Mac platform. If software is going to prevent that from working properly, then that should be communicated very clearly.

Is this an issue in practice in more than a rounding error number of Macs? I'd bet lots of money that the vast majority of developers (that is, people likely to be installing Homebrew in the first place) are using effectively single-user systems.

I'm not sure about unprivileged installs, but MacPorts is very good about sticking to /opt/local. It doesn't ever place anything (including config files) outside of /opt/local. So you get pretty good assurance that it won't trash your system too badly.

And, they actually enforce this with a specially provisioned MacPorts user. So although it requires sudo, MacPorts installs don’t actually run as root.

Yes, it does; you can just configure it with --prefix (to move it out of /opt/local) and --with-no-root-privileges. The downside is that you won't be able to use the binary packages anymore, but I think that is true for Homebrew as well.