Homebrew is not a sentient being, so I don't think it's really possible to insult it.

Installing global software without superuser rights is a security failure, not a feature. You can argue about this, but you're wrong. Decades of good Unix security says Homebrew is doing it wrong.

Also your understanding of this problem is wrong: Homebrew does not install tools in "user space". I know the default path used to be "/usr/local" but that is not "user space". It's still global to the machine.

Apt is perfectly capable of downloading packages from a HTTPS server, or any of the other protocols supported by apt transports - because its actually a problem that had some thought put into it, rather than just "hey lets clone this git repo that keeps growing over time to everyones machine".

My real issue with Homebrew is about how half-assed the approach is, and how the core developers essentially react like children when questioned/challenged about their solutions.

Initially Homebrew was source only: there was no binary distribution, everything was build locally, all the time. Because security is just a pesky annoyance, it does this all as the user - rather than the more sensible approach of building as a regular user, and then installing as root. But like I say, pesky security.

Several years ago Homebrew added the concept of binary distribution. The problem is, they either drank a bottle of tequila each before implementing it, or they have literally never use another package manager before.

Without binary distribution in the picture, the logic for handling dependencies mostly worked OK. If you had a Homebrew package that depends on what Apt would call a "virtual package" - i.e. something that is provided by multiple other packages, and you build from source, it will check if one of those dependencies is installed, and if not, build and install one - probably just the first one, I'd imagine.

When Homebrew added the ability to install prebuilt binary packages.... they never changed the dependency management (or if they did, they didn't change it to support the virtual package pattern, which is not exactly rare in real package management systems).

So if you have package A, which depends on Foo, and Foo is provided by both B and C, when you do a source install, it'll check if anything providing Foo is installed already. No? Ok, build and install something that provides Foo, so we'll use B. Now carry on and build and install A with a dependency on B.

In the same scenario, but you want to do a binary install... Homebrew has already done all that "Ok, what provides Foo.. Ok, build and install B, now proceed and build A with a dependency on B"... So you do a binary install of A, having previously installed C, and all of a sudden, it'll tell you it has to uninstall C. Because the binary package doesn't have a dependency on Foo. It has a dependency on B.

The suggested solution is to install from source... Well was.. I don't know what they say now, because I know when a tool is not worth wasting my time on, and I promptly stopped using Brew when this came up.

This is what the Homebrew website says, right now, about building from source:

> Building from source takes a long time, is prone to fail, and is not supported.

The dependency scenario gets even more fucked, if you want or need to provide a dependency from a different repository (called a tap, because apparently nobody told these people that alcoholism is a thing, and over-worked analogies make you sound like an idiot)... You can't. You just, can't. There is deliberately no way to satisfy dependencies from third party repositories, overriding the "core" repo.

The project decided at some point that they need to know who installs what, and when, and what colour underwear they had on at the time..

For reference, Debian does also have a 'package tracking' concept too, the `popularity-contest` package. What Debian does, is ask the user if they'd like to provide package statistics, and then goes to quite long lengths to give the user multiple options to ensure that the data sent is anonymous, and stores that data on project-controlled server(s)....

What did Homebrew do? Oh. Right. They send data to Google Analytics, and it's opt-in by default.

Homebrew is a tire fire inside a dumpster fire, and any time the fire department turns up and says "hey it doesn't have to be this way" the project says "no no, we like it this way".

> I mean, having to register as a developer, get a certificate to sign your apps, and still have to send off your software to Apple each time you update it before you can distribute it on your own website is pretty "strict" compared to every other OS.

It's suddenly very clear to me why you think Homebrew is high quality software if you think signing your apps is some onerous task.

> It doesn't seem to do much to prevent malware in the wild either.

Can you point to some evidence of specifically malicious software that has passed the Notarisation process?