6 ms·

I still use MacPorts because it's actually a proper package management system. Homebrew is not, and its limitations started to show a long time ago. The obnoxio

I still use MacPorts because it's actually a proper package management system. Homebrew is not, and its limitations started to show a long time ago. The obnoxious assertion that Homebrew should take complete control of /usr/local AND be able to install in there as an unprivileged user is utterly ridiculous. It's just some nonsense that the author cooked up in his own head, contradicting a long history of convention regarding the use of /usr/local. The maintainers of packages are supposed to port their software to the relevant platform, that's their job, and yes sometimes this takes some work, whereas Homebrew seems to assume that ./configure; make; make install should flawlessly work out of the box for pretty much anything (this is not true). The fact that they actively discourage even trying to install outside of /usr/local is simply laziness (and not in a good way). This is a foolish and naive approach, and pursuing this idealistic, reductive approach for "simplicitly" breaks down very, very quickly. MacPorts is a well behaved, self-contained system, and a well designed one at that. Homebrew just dumps everything into a system directory that it really shouldn't have exclusive rights to in the first place (/usr/local). Moreover, there is nothing wrong with installing extra compilers, libraries, etc, under /opt/local and having them run alongside the system libraries. Lots of systems have provisions for doing something like this. Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Homebrew's documentation is terrible. Its terminology is facile and stupid in the way it analogizes everything with beer.

pbiggar 10y ago
> "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just some nonsense", "are supposed to port their software", "that's their job", "(that is not true)", "is simply laziness", "foolish and naive", "breaks down very very quickly", "is a horrible anti-pattern", "facile and stupid". I downvoted you. You assert a massive bunch of things with no evidence. A reasonable person could disagree with every single one of them (I do). While I could imagine your reasons for believing some (most?) of these, I would simply be arguing against the strawman I constructed. By providing actual evidence ("why do you believe this to be the case"), you would allow us have a constructive discussion on your points. Instead, you give us bile.
- clhodapp 10y ago
  Today, Homebrew does have some major shortcomings. The biggest one that comes to mind for me is the fact that it only seems to consider the dependencies of a package during its initial installation. That is, if A depends on B, installing A will trigger an install of B. However, after that, Homebrew will happily let you uninstall B (thus breaking A) without so much as a warning. Less critically, it doesn't track the fact that it only installed B for the purpose of making A work, so it can't help you clean up the left-behind-dependency cruft from the stuff you've since removed.
  - mh- 10y ago
    I don't disagree with your assertion about the state of Homebrew, but I wanted to point out the `leaves` subcommand. brew leaves: Show installed formulae that are not dependencies of another installed formula. I'm not sure if it persists this state or simply calculates it on-the-fly by enumerating your installed formulae. But it does seem like the same data or functionality could be used to prevent your uninstalled-deps scenario.
    - clhodapp 10y ago
      Hmm... Interesting. I don't think that "brew leaves" truly solves the problem, though, since the list it generates will include explicitly-installed leaves in addition to no-longer-needed dependencies. It can help narrow the list of potential candidates for removal, though, which is nice.
- brazzledazzle 10y ago
  The wheat is mixed with the chaff. Ignoring the jabs at the author and their reasoning the odd way it uses and interacts with /usr/local is worth thinking about. Sometimes challenging conventions is good but sometimes those conventions are there for very good reasons that aren't immediately obvious.
guessbest 10y ago
I'd agree. I started using Slackware only in 2001 and installing to /usr/local just seems like the best way to handle application software that isn't required by the system. Since Fink got relatively abandoned, I've been using macports and have not gone back to using Fink. Macports is very useful to me for just able all 3rd party software that is unix-y and exclusively an app. The only thing I use homebrew for is cocoapods. I had a bad experience with homebrew when it first came out using, and I've been leery of it since.
devdoomari 10y ago
> be able to install in there as an unprivileged user is utterly ridiculous. this. I'm using homebrew and installing every package as my own user is a security risk. One security mistake in a package can interfere with my main user account's files / other packages / etc. Other package managers (apt, yum, macports, etc.) install each package as separate users (e.g. Mysql as user 'mysql') to prevent bad packages from 'leaking'.
- the_mitsuhiko 10y ago
  How is it a security risk?
  - viraptor 10y ago
    Anyone taking control of your account can take control of (for example) database you installed, without going via the database's authorization system. Not a huge issue on a laptop, I'd say. But in general - your normal user should be able to modify the binaries you're running without gaining some higher auth level. (for example via sudo)
  - rbanffy 10y ago
    Let's say the code of something you are running locally has a SQL injection vulnerability that allows someone to run arbitrary code on your machine (let's imagine you are running a local copy of your client's WordPress blog with dozens of plugins you don't know where they came from). When the user you, the intruding code runs as you, with your privileges. When the service runs as a restricted user, that's all access the intruder gets. Next time you go to a meetup, try to do an nmap on your surroundings.
flomo 10y ago
Yes, the single userness of Homebrew became obvious when I inherited a MacBook from someone which also contained some licensed software that couldn't not easily flattened and reinstalled. Homebrew sprays single-user shit all over the place and judging by google searches, there was not a clean way to remove it. I ended-up doing a lot of manual deleting. You couldn't even rf -rm /usr/local/, because Homebrew did not own that directory, my licence-locked software dropped stuff there too for example. Really how hard is it to type sudo? And, it just seems completely idiotic to compile standard packages for the second most popular developer ABI on the planet. How many rainforests have Homebrew users burned down to get the same binaries as the guy sitting next to them? I've been using pkgsrc lately. Binary packages that seem to work out of box and come with launchd configs. It goes into /opt/pkg/, and /opt was always better than /usr/local because of the unix philosophy that its shorter to type. Anyway, if you like Homebrew's approach to the filesystem, there was a OS you would really like, it was called Microsoft DOS. (It didn't work out in the long run.)
- ploxiln 10y ago
  Well, there's also gentoo ;)
- __david__ 10y ago
  > And, it just seems completely idiotic to compile standard packages for the second most popular developer ABI on the planet. How many rainforests have Homebrew users burned down to get the same binaries as the guy sitting next to them? I find 90% of the brew things I install are binaries (they call them "bottles"), and I don't even use brew in /usr/local (where even more binaries are available). Have you used brew recently or is your experience from some time ago?
deleted 10y ago
[deleted]
rbanffy 10y ago
> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Remember leftpad!
- danpalmer 10y ago
  Can I ask, what specifically do you find to be an anti-pattern about this?
  - rbanffy 10y ago
    http://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ http://qz.com/646467/how-one-programmer-broke-the-internet-b... is a good starting point. I sincerely thought everyone heard of this.
    - mudetroit 10y ago
      Except this had nothing to do with using a VCS system for package distribution, and everything to do with indirection provided by the index.
      - rbanffy 10y ago
        Let's invert the question: why do you think VCSs are a good idea for package management?
        danpalmer 10y ago
        I'd rather you answered the question instead of dodging it. However here are a few off the top of my head, I'm sure there are many more reasons for it and reasons against, but that is why I asked in the first place. - There are several popular, well maintained, hosted VCS providers, such as GitHub, who have good bandwidth, and host open-source projects for free. Nice as most open-source projects are unfunded. - A VCS gives you traceability in what's changing in your package repository 'for free' - nice when you open it up to contributors. - A git-based package repository can be kept locally in relatively little space, allowing for the case where the package repo host goes down - I've had issues with being unable to install from PyPI in the past because it's down, I have not had that issue with git-based repositories, for example (not a perfect comparison). - A VCS based repository can aid in creating a system where a given state of the repo is consistent, and works together, and can be upgraded atomically. Stackage is doing something like this, providing a known working set of packages at any given release (although I'm not sure if they are backing that concept with a VCS).
ambicapter 10y ago
> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Can you go into this? I have to write an update framework at my job and I want to know as much as possible about it before I start.
- sitkack 10y ago
  I believe "anti-pattern" is a way to assert an opinion by giving it the color of best practice. > It is a best practice to assert ones opinion by declaring the alternative as an anti-pattern.
D4AHNGM 10y ago
Without going into the rest of your points, which seem bizarrely furious at a piece of software, nothing about Homebrew forces you to live inside `/usr/local`. It is recommended, but if you want to run in `/opt/brew` or `~/brew` you'll get a warning some things may not work but that's it. There's no hard block, and the vast majority of core formulae can pour their bottles anywhere.

pbiggar 10y ago

> "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just some nonsense", "are supposed to port their software", "that's their job", "(that is not true)", "is simply laziness", "foolish and naive", "breaks down very very quickly", "is a horrible anti-pattern", "facile and stupid". I downvoted you. You assert a massive bunch of things with no evidence. A reasonable person could disagree with every single one of them (I do). While I could imagine your reasons for believing some (most?) of these, I would simply be arguing against the strawman I constructed. By providing actual evidence ("why do you believe this to be the case"), you would allow us have a constructive discussion on your points. Instead, you give us bile.

clhodapp 10y ago
Today, Homebrew does have some major shortcomings. The biggest one that comes to mind for me is the fact that it only seems to consider the dependencies of a package during its initial installation. That is, if A depends on B, installing A will trigger an install of B. However, after that, Homebrew will happily let you uninstall B (thus breaking A) without so much as a warning. Less critically, it doesn't track the fact that it only installed B for the purpose of making A work, so it can't help you clean up the left-behind-dependency cruft from the stuff you've since removed.
- mh- 10y ago
  I don't disagree with your assertion about the state of Homebrew, but I wanted to point out the `leaves` subcommand. brew leaves: Show installed formulae that are not dependencies of another installed formula. I'm not sure if it persists this state or simply calculates it on-the-fly by enumerating your installed formulae. But it does seem like the same data or functionality could be used to prevent your uninstalled-deps scenario.
  - clhodapp 10y ago
    Hmm... Interesting. I don't think that "brew leaves" truly solves the problem, though, since the list it generates will include explicitly-installed leaves in addition to no-longer-needed dependencies. It can help narrow the list of potential candidates for removal, though, which is nice.
brazzledazzle 10y ago
The wheat is mixed with the chaff. Ignoring the jabs at the author and their reasoning the odd way it uses and interacts with /usr/local is worth thinking about. Sometimes challenging conventions is good but sometimes those conventions are there for very good reasons that aren't immediately obvious.

guessbest 10y ago

I'd agree. I started using Slackware only in 2001 and installing to /usr/local just seems like the best way to handle application software that isn't required by the system. Since Fink got relatively abandoned, I've been using macports and have not gone back to using Fink. Macports is very useful to me for just able all 3rd party software that is unix-y and exclusively an app. The only thing I use homebrew for is cocoapods. I had a bad experience with homebrew when it first came out using, and I've been leery of it since.

devdoomari 10y ago

> be able to install in there as an unprivileged user is utterly ridiculous. this. I'm using homebrew and installing every package as my own user is a security risk. One security mistake in a package can interfere with my main user account's files / other packages / etc. Other package managers (apt, yum, macports, etc.) install each package as separate users (e.g. Mysql as user 'mysql') to prevent bad packages from 'leaking'.

the_mitsuhiko 10y ago
How is it a security risk?
- viraptor 10y ago
  Anyone taking control of your account can take control of (for example) database you installed, without going via the database's authorization system. Not a huge issue on a laptop, I'd say. But in general - your normal user should be able to modify the binaries you're running without gaining some higher auth level. (for example via sudo)
- rbanffy 10y ago
  Let's say the code of something you are running locally has a SQL injection vulnerability that allows someone to run arbitrary code on your machine (let's imagine you are running a local copy of your client's WordPress blog with dozens of plugins you don't know where they came from). When the user you, the intruding code runs as you, with your privileges. When the service runs as a restricted user, that's all access the intruder gets. Next time you go to a meetup, try to do an nmap on your surroundings.

flomo 10y ago

Yes, the single userness of Homebrew became obvious when I inherited a MacBook from someone which also contained some licensed software that couldn't not easily flattened and reinstalled. Homebrew sprays single-user shit all over the place and judging by google searches, there was not a clean way to remove it. I ended-up doing a lot of manual deleting. You couldn't even rf -rm /usr/local/, because Homebrew did not own that directory, my licence-locked software dropped stuff there too for example. Really how hard is it to type sudo? And, it just seems completely idiotic to compile standard packages for the second most popular developer ABI on the planet. How many rainforests have Homebrew users burned down to get the same binaries as the guy sitting next to them? I've been using pkgsrc lately. Binary packages that seem to work out of box and come with launchd configs. It goes into /opt/pkg/, and /opt was always better than /usr/local because of the unix philosophy that its shorter to type. Anyway, if you like Homebrew's approach to the filesystem, there was a OS you would really like, it was called Microsoft DOS. (It didn't work out in the long run.)

ploxiln 10y ago
Well, there's also gentoo ;)
__david__ 10y ago
> And, it just seems completely idiotic to compile standard packages for the second most popular developer ABI on the planet. How many rainforests have Homebrew users burned down to get the same binaries as the guy sitting next to them? I find 90% of the brew things I install are binaries (they call them "bottles"), and I don't even use brew in /usr/local (where even more binaries are available). Have you used brew recently or is your experience from some time ago?

deleted 10y ago

[deleted]

rbanffy 10y ago

> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Remember leftpad!

danpalmer 10y ago
Can I ask, what specifically do you find to be an anti-pattern about this?
- rbanffy 10y ago
  http://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ http://qz.com/646467/how-one-programmer-broke-the-internet-b... is a good starting point. I sincerely thought everyone heard of this.
  - mudetroit 10y ago
    Except this had nothing to do with using a VCS system for package distribution, and everything to do with indirection provided by the index.
    - rbanffy 10y ago
      Let's invert the question: why do you think VCSs are a good idea for package management?
      - danpalmer 10y ago
        I'd rather you answered the question instead of dodging it. However here are a few off the top of my head, I'm sure there are many more reasons for it and reasons against, but that is why I asked in the first place. - There are several popular, well maintained, hosted VCS providers, such as GitHub, who have good bandwidth, and host open-source projects for free. Nice as most open-source projects are unfunded. - A VCS gives you traceability in what's changing in your package repository 'for free' - nice when you open it up to contributors. - A git-based package repository can be kept locally in relatively little space, allowing for the case where the package repo host goes down - I've had issues with being unable to install from PyPI in the past because it's down, I have not had that issue with git-based repositories, for example (not a perfect comparison). - A VCS based repository can aid in creating a system where a given state of the repo is consistent, and works together, and can be upgraded atomically. Stackage is doing something like this, providing a known working set of packages at any given release (although I'm not sure if they are backing that concept with a VCS).

ambicapter 10y ago

> Also, using version control systems as distribution and deployment systems is a horrible anti-pattern and I really, really wish people would stop doing this. Can you go into this? I have to write an update framework at my job and I want to know as much as possible about it before I start.

sitkack 10y ago
I believe "anti-pattern" is a way to assert an opinion by giving it the color of best practice. > It is a best practice to assert ones opinion by declaring the alternative as an anti-pattern.

D4AHNGM 10y ago

Without going into the rest of your points, which seem bizarrely furious at a piece of software, nothing about Homebrew forces you to live inside `/usr/local`. It is recommended, but if you want to run in `/opt/brew` or `~/brew` you'll get a warning some things may not work but that's it. There's no hard block, and the vast majority of core formulae can pour their bottles anywhere.