6 ms·

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more rob

by mapgrep 11y ago

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X libraries for various things. But then it is much more fragile when your system updates. Macports really only depends on a slice of Xcode; from time to time updates will fail to install until you open Xcode and accept whatever new license Apple has bundled with it. But you don't get key components changing out from underneath your packages due to an Apple System Update. My bias here is that I'm a longtime happy Macports user who has tried to use homebrew repeatedly, encountered lots of failed recipes, and gone back to Macports, shaking my head at all the hype around homebrew and the fact that is has somehow become a defacto developer default despite some really sloppy, poorly thought through practices. (And I know that's harsh but for a long time they trashed Macports right in their tagline — "Is MacPorts driving you to drink?" — which just seemed gratuitous.)

outworlder 11y ago
Perhaps the easy of writing recipes, combined with good timing (Ruby was all the rage), is what made people go to homebrew.
joshmoz 11y ago
Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy. I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return. Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.
- rsync 11y ago
  "Agreed, I don't understand why so many people use homebrew instead of macports." This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive. The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.
  - mapgrep 11y ago
    Just FYI anyone can download XCode from the App Store, it doesn't require a "dev login". (Agree it would be nice if MacPorts only required the XCode Command Line tools like homebrew, it would be one less download.)
    - Scarbutt 11y ago
      I was going to try macports but the XCode download turn me off, why it can rely only on the command line tools?
      - nomel 11y ago
        Don't many of the dev command line tools, like clang, come from xcode?
        mnem 11y ago
        The command line tools package includes all you need to compile with and is far smaller than Xcode. I think it's about 150mb.
        rsync 11y ago
        Yes, that's true, and of course that's what I'd like to do (command line tools only), but last time through that was yet another ten minutes to find the correct xcode and match things up and so on ... I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.
robbles 11y ago
The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't compiling.
- mmastrac 11y ago
  Ditto. And Homebrew's policy of avoiding installation of built-in packages by default means that you don't accidentally break your whole system when MacPorts shadows a critical core package.
  - mzs 11y ago
    Run otool to check but Apple at least builds their stuff right and it's getting harder for companies to shoot themselves in the foot like that cause Xcode automatically does the right stuff for devs that are rushed not careful.
  - teacup50 11y ago
    I can't fathom how MacPorts could ever break your whole system. - MacPorts' /opt/local is not in any of the default system paths. - MacPorts uses sandboxing to ensure that builds can't stomp anything outside of /opt/local
    - jkyle 11y ago
      Not sure about the above poster, but the only times I've heard folks claim that macports broke their system was when they were setting DYLD_LIBRARY_PATH. edit should be noted you really ought not do this and if you absolutely have to you should use DYLD_FALLBACK_LIBRARY_PATH
  - thomnific 11y ago
    Maybe you didn't know about port select (like me when I started using Macports): http://stackoverflow.com/questions/6612009/macports-port-select-commands http://stackoverflow.com/questions/6612009/macports-port-sel...
cdonnellytx 11y ago
The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. SIP doesn't block /opt; if it did, MacPorts would also have broken, sudo or no sudo.
- mapgrep 11y ago
  SIP doesn't block /opt for the exact reason MacPorts relies on /opt: It's not part of the existing operating system. In other words, this situation isn't just good luck for MacPorts, it's a direct result of the design decisions behind MacPorts, and the design decisions behind homebrew.
- matwood 11y ago
  > The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. This goes against all that I have read and my own experiences with the betas. Maybe Apple changed something last minute. See here: http://www.macworld.com/article/2948140/os-x/private-i-el-capitans-system-integrity-protection-will-shift-utilities-functions.html http://www.macworld.com/article/2948140/os-x/private-i-el-ca... The specifics of System Integrity Protection are that no user, application, or process will be able to write files or modify files in the root System folder or the /bin, /sbin, and /usr directories, which are hidden by default in OS X’s Finder. The /usr/local folder remains accessible, however; it’s a long-running convention in Unix and variants as a place to stash material and software that individual users rely on.
  - osxrand 11y ago
    The bit you quoted doesn't contradict what the OP stated, if /usr/local _does not_ exist, not even root can create it. If it exists, we can use it as before. Considering how many times I've installed OS X, I can't recall if /usr/local is there by default (excluding 10.11 for the moment). Will have to do another few installs and check.
    - dpatriarche 11y ago
      On my Yosemite system /usr/local was created by default when the OS was installed.
WorldWideWayne 11y ago
Unless you're making iOS software, why not just use Linux? I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.
- s73v3r 11y ago
  OS X has always provided a fine Unix experience for me.
  - WorldWideWayne 11y ago
    If you're OK with Apple taking away root privileges on your box, then I guess a lot of things that are fine with you are not going to be fine with other people. Enjoy using Apple's computers...and they are Apple's, not yours because if they were, you'd be in control.
    - Alphasite_ 11y ago
      Feel free to disable sip, or just unprotect the folders you don't want protected (although the latter would get wiped out after updates).
      - WorldWideWayne 11y ago
        Sounds like a great UX.
deleted 11y ago
[deleted]

by mapgrep 11y ago

outworlder 11y ago

Perhaps the easy of writing recipes, combined with good timing (Ruby was all the rage), is what made people go to homebrew.

joshmoz 11y ago

Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy. I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return. Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.

rsync 11y ago
"Agreed, I don't understand why so many people use homebrew instead of macports." This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive. The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.
- mapgrep 11y ago
  Just FYI anyone can download XCode from the App Store, it doesn't require a "dev login". (Agree it would be nice if MacPorts only required the XCode Command Line tools like homebrew, it would be one less download.)
  - Scarbutt 11y ago
    I was going to try macports but the XCode download turn me off, why it can rely only on the command line tools?
    - nomel 11y ago
      Don't many of the dev command line tools, like clang, come from xcode?
      - mnem 11y ago
        The command line tools package includes all you need to compile with and is far smaller than Xcode. I think it's about 150mb.
        rsync 11y ago
        Yes, that's true, and of course that's what I'd like to do (command line tools only), but last time through that was yet another ten minutes to find the correct xcode and match things up and so on ... I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.

robbles 11y ago

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't compiling.

mmastrac 11y ago
Ditto. And Homebrew's policy of avoiding installation of built-in packages by default means that you don't accidentally break your whole system when MacPorts shadows a critical core package.
- mzs 11y ago
  Run otool to check but Apple at least builds their stuff right and it's getting harder for companies to shoot themselves in the foot like that cause Xcode automatically does the right stuff for devs that are rushed not careful.
- teacup50 11y ago
  I can't fathom how MacPorts could ever break your whole system. - MacPorts' /opt/local is not in any of the default system paths. - MacPorts uses sandboxing to ensure that builds can't stomp anything outside of /opt/local
  - jkyle 11y ago
    Not sure about the above poster, but the only times I've heard folks claim that macports broke their system was when they were setting DYLD_LIBRARY_PATH. edit should be noted you really ought not do this and if you absolutely have to you should use DYLD_FALLBACK_LIBRARY_PATH
- thomnific 11y ago
  Maybe you didn't know about port select (like me when I started using Macports): http://stackoverflow.com/questions/6612009/macports-port-select-commands http://stackoverflow.com/questions/6612009/macports-port-sel...

cdonnellytx 11y ago

The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. SIP doesn't block /opt; if it did, MacPorts would also have broken, sudo or no sudo.

mapgrep 11y ago
SIP doesn't block /opt for the exact reason MacPorts relies on /opt: It's not part of the existing operating system. In other words, this situation isn't just good luck for MacPorts, it's a direct result of the design decisions behind MacPorts, and the design decisions behind homebrew.
matwood 11y ago
> The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. This goes against all that I have read and my own experiences with the betas. Maybe Apple changed something last minute. See here: http://www.macworld.com/article/2948140/os-x/private-i-el-capitans-system-integrity-protection-will-shift-utilities-functions.html http://www.macworld.com/article/2948140/os-x/private-i-el-ca... The specifics of System Integrity Protection are that no user, application, or process will be able to write files or modify files in the root System folder or the /bin, /sbin, and /usr directories, which are hidden by default in OS X’s Finder. The /usr/local folder remains accessible, however; it’s a long-running convention in Unix and variants as a place to stash material and software that individual users rely on.
- osxrand 11y ago
  The bit you quoted doesn't contradict what the OP stated, if /usr/local _does not_ exist, not even root can create it. If it exists, we can use it as before. Considering how many times I've installed OS X, I can't recall if /usr/local is there by default (excluding 10.11 for the moment). Will have to do another few installs and check.
  - dpatriarche 11y ago
    On my Yosemite system /usr/local was created by default when the OS was installed.

WorldWideWayne 11y ago

Unless you're making iOS software, why not just use Linux? I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.

s73v3r 11y ago
OS X has always provided a fine Unix experience for me.
- WorldWideWayne 11y ago
  If you're OK with Apple taking away root privileges on your box, then I guess a lot of things that are fine with you are not going to be fine with other people. Enjoy using Apple's computers...and they are Apple's, not yours because if they were, you'd be in control.
  - Alphasite_ 11y ago
    Feel free to disable sip, or just unprotect the folders you don't want protected (although the latter would get wiped out after updates).
    - WorldWideWayne 11y ago
      Sounds like a great UX.

deleted 11y ago

[deleted]