Hacker News Reader

> "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.

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.

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.

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.

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.

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.)

Well, there's also gentoo ;)

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

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.

> 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'.

How is it a security risk?

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)

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.

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.

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

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.

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

Can I ask, what specifically do you find to be an anti-pattern about this?

http://qz.com/646467/how-one-programmer-broke-the-internet-b... is a good starting point.

I sincerely thought everyone heard of this.

Except this had nothing to do with using a VCS system for package distribution, and everything to do with indirection provided by the index.

Let's invert the question: why do you think VCSs are a good idea for package management?

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).

But that specific incident had nothing to do with using a VCS for packages? He removed left-pad from npms index, the code behind it was still online. Or did you mean more generally in a "single point of failure/removal" sense?

When you have a system where an individual can remove one item in a vast dependency tree where no one has central oversight you create risks like this. This also says a lot about relying on external dependencies like there is no tomorrow, but the point is still valid. I can imagine a thousand ways to break a system like this.

Apart from that, version control systems are optimized for controlling versions, not delivering static content.