6 ms·

Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPort

Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPorts. A more current update to this post would probably be more helpful. 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-package-managers/ https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...

lucideer 6y ago
> 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?
- Wowfunhappy 6y ago
  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.
  - lucideer 6y ago
    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.
  - kstrauser 6y ago
    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.
    - Wowfunhappy 6y ago
      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.
      - kstrauser 6y ago
        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.
- nrclark 6y ago
  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.
  - Wowfunhappy 6y ago
    And, they actually enforce this with a specially provisioned MacPorts user. So although it requires sudo, MacPorts installs don’t actually run as root.
- mikepurvis 6y ago
  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/ https://xkcd.com/1200/
  - brigandish 6y ago
    > 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.
  - lucideer 6y ago
    > 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.
    - mikepurvis 6y ago
      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.
- saagarjha 6y ago
  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.
jimbokun 6y ago
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.
- hombre_fatal 6y ago
  > 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.
- lawnchair_larry 6y ago
  > 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.
- jgwil2 6y ago
  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.

lucideer 6y ago

> 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?

Wowfunhappy 6y ago
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.
- lucideer 6y ago
  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.
- kstrauser 6y ago
  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.
  - Wowfunhappy 6y ago
    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.
    - kstrauser 6y ago
      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.
nrclark 6y ago
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.
- Wowfunhappy 6y ago
  And, they actually enforce this with a specially provisioned MacPorts user. So although it requires sudo, MacPorts installs don’t actually run as root.
mikepurvis 6y ago
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/ https://xkcd.com/1200/
- brigandish 6y ago
  > 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.
- lucideer 6y ago
  > 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.
  - mikepurvis 6y ago
    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.
saagarjha 6y ago
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.

jimbokun 6y ago

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.

hombre_fatal 6y ago
> 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.
lawnchair_larry 6y ago
> 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.
jgwil2 6y ago
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.