5 ms·

How is it not as good? I'm genuinely curious because I've used apt on debian derivatives and rpm on red hat and I prefer brew to both of them. My favorite is a

by jolux 11y ago

How is it not as good? I'm genuinely curious because I've used apt on debian derivatives and rpm on red hat and I prefer brew to both of them. My favorite is actually Nix/Guix but I haven't bothered to set it up on my daily driver.

ekianjo 11y ago
A few reasons: - you have way more packages on any Linux package manager. - Linux package managers do not mess with /usr/local as expected in a UNIX compatible OS. Homebrew does. Linux package managers run as root, not in user-space. - Apparently Homebrew gets broken by Apple software/OS updates. - Linux package managers are an integral part of the OS environment and update process - it's structured this way even for critical system and kernel patches. - Aptitude, for example, gets rid of older versions of packages, while Homebrew keeps all previous versions and simply changes the symlink. Cleanup is also automated in Linux package managers, not Homebrew as far as I know. - Homebrew sometimes pulls up sources to compile software locally, while Linux distros usually pull up binaries (except AUR on Arch or Portage on Gentoo, or Sbopkg on Slackware). While compiling from source is nothing wrong, it can take a lot of time depending on what you are building.
- jordanpg 11y ago
  Most of these things are considered features of homebrew, not bugs.
  - ekianjo 11y ago
    Not being a part of the OS is a major issue, though.
  - hguant 11y ago
    Nonsense. Absolute rubbish. Being broken is a feature? Changing /usr/local instead of being sane? Leaving old versions of packages lying about instead of cleaning them up? Breaking when the Apple devs wonder if it would be fun to switch things up a bit under the hood without telling anyone? The one thing I can think of that's a "feature" is that brew compiles locally, instead of pulling down a binary, but even that has some draw backs. I'm all for product loyalty, but a spade's a spade.
    - alextgordon 11y ago
      I'm not understanding what is "insane" about installing to /usr/local/Cellar and dropping a symlink in /usr/local/bin. This is the convention on OS X. All tools I have ever seen install to /usr/local.
    - jolux 11y ago
      What exactly is wrong with writing to /usr/local? It seems to fall in line with the FHS standard, at least as far as I can tell. Sometimes older versions of different packages may be dependencies of newer packages. This is a thing that happens with software. When it's not a problem, `brew cleanup` gets rid of old versions. Most of the time brew does install binaries, they're called Bottles. When it can't find a binary, it compiles locally. Yes this is sometimes annoying but it's not a deal breaker, at least not for me. I'm not sure what you mean by "Breaking when the Apple devs wonder if it would be fun to switch things up a bit under the hood without telling anyone." This has never happened to me or anyone I know and furthermore Brew is a Unix compliant tool and OS X is a SUS compliant operating system. Sorry if I'm sounding harsh, it just sounds a little like you're a Linux user who doesn't or possibly hasn't ever used OS X. Brew is not a panacea but it's honestly pretty good. There's also MacPorts if you're used to more old-style tools and a couple other package managers as well. You can even use Nix on OS X.
    - x0 11y ago
      > Changing /usr/local instead of being sane? Better than most OS X programs, which seem to have paths like /Applications/Something.app/Contents/Resources/SomethingElse.app/Contents/Developer/Frameworks/Resources/Something.dylib/Contents/Resources/MacOS/Resources/Frameworks/Something.dylib/Contents/Developer Case in point, an excerpt from the program Lipo's usage text: fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo [input_file]
- seanwilson 11y ago
  I went from Windows to using Ubuntu for years then to Mac only a few years ago. I really disliked the packaged management as well. Homebrew and seeing individual apps give me "an update is available!" pop-ups felt like such a step backwards. However...what specifically are you wanting to install and update on Mac that a better package manager would significantly help with? I find on Mac I'm rarely installing or updating new packages so it doesn't bother me as much as I thought it would. As long as I can easily install and update Python, Node, Vagrant, Chrome and a few other things I'm happy. I'd love a laptop that had a long life battery, good screen, good build, was light, ran an open source OS that supported all the software I need etc. but you have to compromise unfortunately and I can compromise on package management.
- danieldk 11y ago
  - you have way more packages on any Linux package manager. And Homebrew tends to be more up to date then most distribution repositories. Especially if I want to have a stable OS. Linux package managers do not mess with /usr/local as expected in a UNIX compatible OS. Homebrew does. You can install Homebrew in another directory, it works fine. Linux package managers are an integral part of the OS environment and update process Which is bad. Application updates are typically tied to base system package updates. Either you use some stable branch (like Debian) stable and you are stuck with old software. Or you use some rolling release, but then your kernel, X11, Gtk+, or whatever could break. Decoupling the installation of applications from the base operating system is a good thing. - Aptitude, for example, gets rid of older versions of packages, while Homebrew keeps all previous versions and simply changes the symlink. brew cleanup ...and old versions are removed and downloads are cleared. Also, you can add the --cleanup flag to upgrade and it will remove old versions. I prefer Homebrew's approach here, because it's easier to rollback. While compiling from source is nothing wrong, it can take a lot of time depending on what you are building. Luckily, Homebrew bottles most software that has long compile times. I have a MacBook with a Core M processor and install times have never been a problem (and I have installed Boost, Rust, and ghc, to name just a few larger things).
  - ekianjo 11y ago
    > Decoupling the installation of applications from the base operating system is a good thing. How is that a good thing if an application needs some core OS features that are not available in its current state? Newer libraries become available for all software and benefit from the upgrades. And yeah, sometimes some things break, but it's easy enough to roll back to a previous library version if you need to, instead of bloating the system with multiple versions of different libraries. > You can install Homebrew in another directory, it works fine. But it's not its default. How many users change its directory ? > And Homebrew tends to be more up to date then most distribution repositories. Especially if I want to have a stable OS. Honestly you can't compete with AUR (Arch) on that level.

by jolux 11y ago

ekianjo 11y ago

A few reasons: - you have way more packages on any Linux package manager. - Linux package managers do not mess with /usr/local as expected in a UNIX compatible OS. Homebrew does. Linux package managers run as root, not in user-space. - Apparently Homebrew gets broken by Apple software/OS updates. - Linux package managers are an integral part of the OS environment and update process - it's structured this way even for critical system and kernel patches. - Aptitude, for example, gets rid of older versions of packages, while Homebrew keeps all previous versions and simply changes the symlink. Cleanup is also automated in Linux package managers, not Homebrew as far as I know. - Homebrew sometimes pulls up sources to compile software locally, while Linux distros usually pull up binaries (except AUR on Arch or Portage on Gentoo, or Sbopkg on Slackware). While compiling from source is nothing wrong, it can take a lot of time depending on what you are building.

jordanpg 11y ago
Most of these things are considered features of homebrew, not bugs.
- ekianjo 11y ago
  Not being a part of the OS is a major issue, though.
- hguant 11y ago
  Nonsense. Absolute rubbish. Being broken is a feature? Changing /usr/local instead of being sane? Leaving old versions of packages lying about instead of cleaning them up? Breaking when the Apple devs wonder if it would be fun to switch things up a bit under the hood without telling anyone? The one thing I can think of that's a "feature" is that brew compiles locally, instead of pulling down a binary, but even that has some draw backs. I'm all for product loyalty, but a spade's a spade.
  - alextgordon 11y ago
    I'm not understanding what is "insane" about installing to /usr/local/Cellar and dropping a symlink in /usr/local/bin. This is the convention on OS X. All tools I have ever seen install to /usr/local.
  - jolux 11y ago
    What exactly is wrong with writing to /usr/local? It seems to fall in line with the FHS standard, at least as far as I can tell. Sometimes older versions of different packages may be dependencies of newer packages. This is a thing that happens with software. When it's not a problem, `brew cleanup` gets rid of old versions. Most of the time brew does install binaries, they're called Bottles. When it can't find a binary, it compiles locally. Yes this is sometimes annoying but it's not a deal breaker, at least not for me. I'm not sure what you mean by "Breaking when the Apple devs wonder if it would be fun to switch things up a bit under the hood without telling anyone." This has never happened to me or anyone I know and furthermore Brew is a Unix compliant tool and OS X is a SUS compliant operating system. Sorry if I'm sounding harsh, it just sounds a little like you're a Linux user who doesn't or possibly hasn't ever used OS X. Brew is not a panacea but it's honestly pretty good. There's also MacPorts if you're used to more old-style tools and a couple other package managers as well. You can even use Nix on OS X.
  - x0 11y ago
    > Changing /usr/local instead of being sane? Better than most OS X programs, which seem to have paths like /Applications/Something.app/Contents/Resources/SomethingElse.app/Contents/Developer/Frameworks/Resources/Something.dylib/Contents/Resources/MacOS/Resources/Frameworks/Something.dylib/Contents/Developer Case in point, an excerpt from the program Lipo's usage text: fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo [input_file]
seanwilson 11y ago
I went from Windows to using Ubuntu for years then to Mac only a few years ago. I really disliked the packaged management as well. Homebrew and seeing individual apps give me "an update is available!" pop-ups felt like such a step backwards. However...what specifically are you wanting to install and update on Mac that a better package manager would significantly help with? I find on Mac I'm rarely installing or updating new packages so it doesn't bother me as much as I thought it would. As long as I can easily install and update Python, Node, Vagrant, Chrome and a few other things I'm happy. I'd love a laptop that had a long life battery, good screen, good build, was light, ran an open source OS that supported all the software I need etc. but you have to compromise unfortunately and I can compromise on package management.
danieldk 11y ago
- you have way more packages on any Linux package manager. And Homebrew tends to be more up to date then most distribution repositories. Especially if I want to have a stable OS. Linux package managers do not mess with /usr/local as expected in a UNIX compatible OS. Homebrew does. You can install Homebrew in another directory, it works fine. Linux package managers are an integral part of the OS environment and update process Which is bad. Application updates are typically tied to base system package updates. Either you use some stable branch (like Debian) stable and you are stuck with old software. Or you use some rolling release, but then your kernel, X11, Gtk+, or whatever could break. Decoupling the installation of applications from the base operating system is a good thing. - Aptitude, for example, gets rid of older versions of packages, while Homebrew keeps all previous versions and simply changes the symlink. brew cleanup ...and old versions are removed and downloads are cleared. Also, you can add the --cleanup flag to upgrade and it will remove old versions. I prefer Homebrew's approach here, because it's easier to rollback. While compiling from source is nothing wrong, it can take a lot of time depending on what you are building. Luckily, Homebrew bottles most software that has long compile times. I have a MacBook with a Core M processor and install times have never been a problem (and I have installed Boost, Rust, and ghc, to name just a few larger things).
- ekianjo 11y ago
  > Decoupling the installation of applications from the base operating system is a good thing. How is that a good thing if an application needs some core OS features that are not available in its current state? Newer libraries become available for all software and benefit from the upgrades. And yeah, sometimes some things break, but it's easy enough to roll back to a previous library version if you need to, instead of bloating the system with multiple versions of different libraries. > You can install Homebrew in another directory, it works fine. But it's not its default. How many users change its directory ? > And Homebrew tends to be more up to date then most distribution repositories. Especially if I want to have a stable OS. Honestly you can't compete with AUR (Arch) on that level.