1) Rarely breaks. Worst I've seen is needing a permissions tweak after an OS upgrade, in many years of use. Back when I switched from Macports I switched because ordinary usage kept rendering Macports so goddamn broken that it was easier to nuke its directory and start over rather than figure out how to fix whatever my bold command of "install package" had destroyed this time. I've never seen normal or even slightly abnormal use put Homebrew in a broken state that required manual intervention to fix.
2) Command line UI is alright. This should be a given but isn't always.
3) Can manage proprietary software for me. There's almost nothing I use (maybe actually nothing?) on my Mac that Homebrew doesn't have an up-to-date package for, aside from Apple-provided apps.
4) Enough people use it that despite being a semi-free-for-all community-run thing packages are pretty much never broken, including the proprietary ones. I'm also continually surprised by how often I find some obscure thing with five stars on Github, want to try it out, and sure enough, there's a Homebrew package.
5) Lets you manage your packages with ordinary user-level permissions. No root elevation required.
6) I can clean practically all of what it's done and get back to a nearly-vanilla system (with the exception of some of the proprietary apps) by deleting one directory. My system and GUI will still boot like nothing's happened. IMO keeping your user-level packages strictly separate from the system-level ones, and managed totally separately, is absolutely the right way to go. I didn't realize how much I wanted this until I started using Homebrew on a Mac, after many many years of Linux package management.
7) It leaves system-level packages that it upgrades alone, so doesn't break core system stuff (I would fucking love this to become a norm on Linux—system uses and assumes latest LTS version for stuff like Python, but I can install whatever version I like for my own use, without affecting that whatsoever and without having to use a different goddamn version-management tool for every single language)
8) I'm pretty sure you can have more than one version of something installed at once and there's a command to switch between them (juggling symlinks, probably), but my recollection of this is vague and may be wrong.
9) If you're actually doing multi-user on your desktop/laptop I think it lets you have per-user install directories and active packages—but I don't really know anyone who does this, and haven't known people to share a computer, really, since over 15 years ago. Amusingly enough, iPads, with practically nothing resembling multi-user support, are the exception to this use pattern, as those seem to get shared among members of a family all the time.
Bad things:
1) Requires Ruby (seems like a dumb complaint, I know, but I hate installing an entire scripting language for a single command line tool, and no not all Linux distros ship with Ruby by default, far from it)
2) I dunno if it still does (I'm working mostly on Debian now) but for approximately forever it's had a completely braindead default for how often it auto-updates its package list when running other commands, and you had to go change that every time you installed it on a new machine so you'd not rip your hair out in frustration when your command to install a package was delayed because it'd been a whopping 16 minutes since the last time it checked for updated packages. Why the hell this didn't default to, like, 12 hours or something is entirely beyond me. AFAIK everyone hates the default behavior, to the point that it's become a common jokey-reference among Mac nerds, and I've never been able to figure out why anyone would want it.
Homebrew is solid, and I think you make a good list.
I had it break before with weird cyclical linking issues, but mostly it works good enough.
What I was more curious about is what specifically sets it apart from a solid Linux package manager?
> Lets you manage your packages with ordinary user-level permissions. No root elevation required.
This is the one major difference I'd say is not currently common on Linux. Could be easily solved by keeping package list databases in $HOME - the only reason root is required nowdays is because these are usually kept as 1 copy per system.
> This is the one major difference I'd say is not currently common on Linux. Could be easily solved by keeping package list databases in $HOME - the only reason root is required nowdays is because these are usually kept as 1 copy per system.
As I posted elsewhere, I think it'd actually be very hard to replicate the experience of Homebrew on macOS, on Linux, specifically for GUI programs, because not only is the the Linux GUI (and related multimedia capabilities, for that matter) so much more fragmented than macOS (where all that ships as one big, stable package) but that fragmentation bleeds through to and manifests in one's experience with individual applications. If not for that, yeah, it'd be very achievable.
Its package selection is also a whole lot bigger than most Linux package managers, in my experience. I don't think I've seen a selection nearly this wide since I was a Gentoo user, many moons ago.
The CLI is better than most Linux package managers—some of those are improving, though. Good error messages and "did you mean..." go a long way.
> think it'd actually be very hard to replicate the experience of Homebrew on macOS, on Linux, specifically for GUI programs, because not only is the the Linux GUI (and related multimedia capabilities, for that matter) so much more fragmented than macOS (where all that ships as one big, stable package
Curious about this, since as far as audio goes, as long as there's PulseAudio on the system, all others tend to have compatibility with it in mind.
> Its package selection is also a whole lot bigger than most Linux package managers, in my experience
That could be, but I personally haven't had an issue with the Arch repo + AUR selections, that's tens of thousands of packages.
> Good error messages
Hmm, these are mostly there, I just made a mistake on purpose and got this, (pacman):
error: invalid option: '--search' and '--sysupgrade' may not be used together
> and "did you mean...
Did you mean would be nice. Git has that and it's certainly helpful
> Curious about this, since as far as audio goes, as long as there's PulseAudio on the system, all others tend to have compatibility with it in mind.
There are hold-out ALSA users (even Linux OSS users still around, I think) and I gather people who need well-performing audio for Serious Work (particularly anything latency-sensitive or requiring that multiple streams be mixed at high quality without errors), and have decided to use Linux for it, end up having to replace or bypass PulseAudio one way or another (this info may be out of date, but given PA's history, I kinda doubt it).
I think the Pulse situation is very similar to the one with systemd (they’re even by the same author IIRC). There are some haters, but if you’re a hater-hater than you can just ignore them (eg. GNOME IUUC depends on both Pulse and systemd, and haters of the dependencies who want the DE just have to find their own shims, like Gentoo’s, deal with some error messages (random games and things often give me a lot of audio-related ones, but generally work ok anyway) or just leave for another DE or WM).
2) Command line UI is alright. This should be a given but isn't always.
3) Can manage proprietary software for me. There's almost nothing I use (maybe actually nothing?) on my Mac that Homebrew doesn't have an up-to-date package for, aside from Apple-provided apps.
4) Enough people use it that despite being a semi-free-for-all community-run thing packages are pretty much never broken, including the proprietary ones. I'm also continually surprised by how often I find some obscure thing with five stars on Github, want to try it out, and sure enough, there's a Homebrew package.
5) Lets you manage your packages with ordinary user-level permissions. No root elevation required.
6) I can clean practically all of what it's done and get back to a nearly-vanilla system (with the exception of some of the proprietary apps) by deleting one directory. My system and GUI will still boot like nothing's happened. IMO keeping your user-level packages strictly separate from the system-level ones, and managed totally separately, is absolutely the right way to go. I didn't realize how much I wanted this until I started using Homebrew on a Mac, after many many years of Linux package management.
7) It leaves system-level packages that it upgrades alone, so doesn't break core system stuff (I would fucking love this to become a norm on Linux—system uses and assumes latest LTS version for stuff like Python, but I can install whatever version I like for my own use, without affecting that whatsoever and without having to use a different goddamn version-management tool for every single language)
8) I'm pretty sure you can have more than one version of something installed at once and there's a command to switch between them (juggling symlinks, probably), but my recollection of this is vague and may be wrong.
9) If you're actually doing multi-user on your desktop/laptop I think it lets you have per-user install directories and active packages—but I don't really know anyone who does this, and haven't known people to share a computer, really, since over 15 years ago. Amusingly enough, iPads, with practically nothing resembling multi-user support, are the exception to this use pattern, as those seem to get shared among members of a family all the time.
Bad things:
1) Requires Ruby (seems like a dumb complaint, I know, but I hate installing an entire scripting language for a single command line tool, and no not all Linux distros ship with Ruby by default, far from it)
2) I dunno if it still does (I'm working mostly on Debian now) but for approximately forever it's had a completely braindead default for how often it auto-updates its package list when running other commands, and you had to go change that every time you installed it on a new machine so you'd not rip your hair out in frustration when your command to install a package was delayed because it'd been a whopping 16 minutes since the last time it checked for updated packages. Why the hell this didn't default to, like, 12 hours or something is entirely beyond me. AFAIK everyone hates the default behavior, to the point that it's become a common jokey-reference among Mac nerds, and I've never been able to figure out why anyone would want it.