I'm going to ditto the positive comments. Kudos to the maintainers - not just for the package itself but for growing it. They successfully went from a hacky page with some scripts, to a big giant repository, to multiple repos, to a fully fledged mature best-practices package manager for macOS with all the bells and whistles.
The sign of a great project isn't just that it does one thing well, but that it grows with the needs of the users and engages with them to constantly make something better without falling prey to bloat. And by that measure, Homebrew gets a gold star.
I started writing a package manager example app, and I quickly learned how much work goes into creating a good one. Ever since I have been grateful for any work others put into working on package management!
I asked a simple question, which is basically the same question I ask any time someone rushes to praise Homebrew like it's the best thing since installable software.
The person I replied to stated that Homebrew follows best practices. I asked how that's possible when it has two major failings compared to pretty much every other package management tool.
The Homebrew project has made it clear that they have no intention of fixing these two failings:
- they've doubled-down on the "install binaries writable by users", and proclaim the issue of owning /usr/local "fixed". Now you just need to own /usr/local/bin, which basically means nothing has changed from a security point of view.
- even when they finally admit the dependency management issue with binary packages, their solution is to just remove/disable some binary packages, forcing all users to compile them from source, and close the issue.
The project has massive, glaring issues. Honestly, it's like a competition these days between NPM and Homebrew to see which can be a worse tool. At least NPM doesn't insist globally installed packages be user-writable.
(That aside, this praise was good to read. Homebrew didn't work well enough for me a few years back, so I got a Linux computer. I'll reconsider Macs next year when it is ~ time to get a new laptop.)
Edit: Let user "homebrew" have id 0. I tried MacPorts too. Hopefully either works for me next time.
No. Root is the specific user which should do installations. Thus, the "solution" is for Homebrew to stop pretending that password-less binary installs is a "feature" instead of a massive security hole.
Honestly, Homebrew doesn't seem like a reason to either use or not use a Mac. For me personally, (as I mentioned elsewhere), the small amount of unix-y host (i.e. macOS) software I install is available in native Installer packages. The rest I install in Debian VMs.
For those that need/want more unix-y tools at the host level, there are a lot of positive comments about MacPorts in this thread, and it specifically doesn't have the permissions issue that Homebrew has (it requires being run as sudo, as it drops to a special account for compiling, and then later installs as root)
Agreed. Homebrew has saved countless hours for developers, I can't believe how many hours I used to spend installing/updating different versions for testing. Now we just run (>brew switch package version) done.
I don't like 'me too's, but Homebrew has been absolutely invaluable to me. The icing on the cake is that I can just install my own software in /usr/local/Cellar/<name>/<version> or make my own tap and enjoy many of the benefits of Homebrew.
Thanks Homebrew maintainers, you make macOS rock even more!
Ditto. I install almost everything via brew and brew cask, and store the list of packages in git. It makes setting up a new machine a breeze. Thanks for all your hard work!
If you want to go a step further there's also Strap which will bootstrap your macOS system with some sensible defaults and install Homebrew, your dotfiles and your Brewfile:
https://github.com/mikemcquaid/strap
I've been looking like this for quite a while. I'm still looking through it all, but I don't suppose you have a solution for setting System Preferences, particularly Trackpad settings and remapping the Caps Lock key to Ctrl?
I have very mixed feelings about homebrew. When it works, it is awesome, but when it doesn't it can be a serious nightmare. In particular, homebrew refuses to run under sudo. Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). I have mostly stopped using it for this reason.
I understand that running a program that runs third-party scripts under sudo is a security nightmare, but there has to be a better solution than globally chowning /usr/local.
[UPDATE] Apparently, this is no longer the case. Good to know!
[UPDATE2] Alas, the problem seems to not have been fully addressed. You still need to chown /usr/local/bin :-(
That's not quite as bad as all of /usr/local, but still not great. Why "e.g."? What else is there? And why not just use /usr/local/homebrew or even better, a path determined by an environment variable? I don't mind giving you a user-owned directory to install things in. I mind very much being required to change system default security settings.
Yeah, that's kind of the situation I'm in. So for any given package it's a crap shoot whether or not it will work. (And if it doesn't work, uninstalling it can be a real problem!) Hence my continued mixed feelings about homebrew in general.
We don't require you to take ownership of any directories that already exist when macOS is installed (i.e. `/usr/local` subdirectories but not `/usr/local` itself). Regardless of whether we should have picked another path, changing now would require rebuilding all our binary packages and that's a lot of effort with little return and almost certain breakages.
I haven't done a clean install of OS X in a long time, but I'm pretty sure /usr/local/bin exists. But even if it doesn't I don't find this a compelling argument. Having /usr/local/bin owned by root is a universally accepted standard in the unix world, and with very good reason: having /usr/local/bin owned by a user introduces security risks.
/usr/local/bin is a global resource. It is generally full of binaries that get run by many different users including root. If a regular user can replace those binaries the result is a privilege escalation.
Well, by default /usr/local/bin is empty. But people commonly install things there that eventually get run by root. The most obvious example is various programming languages, different versions of Python, alternate shells, etc.
(Reaching back into foggy memory...) The last time I installed Homebrew, I think I had the problem that `/usr/local/bin` didn't exist, and I didn't have write permissions for `/usr/local/` so I couldn't create it (w/out sudo/chown) etc. This, using Sierra.
Does that seem likely? Usual? What's the ideal solution?
Why don't you have your binaries installed in a user-owned directory like ~/brew or whatever, and then put that at the front of the path? Asking people to `chown` a system path is plainly a contravention of the principle of least privilege.
`~/brew` varies from username to username and requires us to be able to relocate all binaries so they reference the correct path. We do this for as many as possible but it's not possible for all of them.
I'm on an older version (0.9.5); how do I fix the ownership of my /usr/local tree?
EDIT: I know how to `chown`, I mean more, what can I give back to root, what needs to remain under homebrew's control? Does the new version ship with a tool/command that does this?
> Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm).
Why is this a really bad idea for a personal machine? The only problems I can think of are some subdirectories that are conventionally given some other user ownership to make running a related server under a specific user, and the problem of putting potentially arbitrary probably unreviewed executables in a system-wide path. But the former problem is one you wrestle with anyway if /usr/local is owned by root. And the latter problem... you're going to have some path where you're putting all this stuff, and it's either going to be a personally owned or system owned path. The system-owned choice means giving your package manager sudo and having to run things with sudo (which, without attention, means giving the executables system-wide access). What other problems does a personally owned path create? What's the alternative?
> Why is this a really bad idea for a personal machine?
It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root.
> What's the alternative?
/usr/local/homebrew/bin. Or even better /opt/homebrew/bin. Or even better, a path that is set in an environment variable.
Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.
Also you can actually install it wherever you like, this is just the default/recommended location:
Other than being in a different directory, what difference is that going to make?
Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.)
You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.
Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise.
Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.
/usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.
It would prevent privilege escalation attacks on binaries that I have already installed in /usr/local/bin. Yes, packages installed in /opt/homebrew/bin could be attacked separately, but at least the vulnerable binaries are isolated so it's easier to keep an eye on them and make sure none of them are ever run with privileges.
But you're right: to really fix this problem requires that homebrew change its installation process entirely.
The "don't compile as root" argument is correct, that too is a bad idea. But that's exactly why traditional "./configure; make; sudo make install" instructions separate the initial build (using the default make target) from a the install target.
It's why binary packages for basically every platform are built using a controlled, non root-user environment, but installed using root-equivalent permissions.
This was a problem for me. I installed Homebrew to my home directory [1] and it works great. I no longer need to chown /usr/local or run any commands under sudo.
I have the same concerns and have been using Nix for my Mac package manager [1] instead. Functionally it's far better, though with far fewer packages available currently.
I've been meaning to try out Nix for probably years. I work in vfx and large facilities have particular needs that most packaging systems don't support, but there's a huge about of investment that can be leveraged (dependency resolution, caching).
I did a fresh install of macOS with Sierra and decided to use Nix instead of Homebrew this time around. So far I've only started reading through the docs and only have a few things installed; git, vim, tmux. What are your thoughts about using it as a Homebrew alternative?
I've been using Homebrew for years and have been a huge fan so far. I often look at formulas when trying to build things from scratch on Linux.
If you're considering it for a Homebrew alternative, the main thing is to make a list of all the packages you must have, and then all the ones you would like to have, and then check if they're in Nix. Decide whether you can live with that or not.
The about page sums its features up pretty well, see if there's anything that particularly appeals to you there: http://nixos.org/nix/about.html
Also the HN link in my previous comment has some good discussion of it, just scroll down past the initial Docker comparison thread.
For me the main benefit of it is that I trust it. It doesn't take over system directories like Homebrew, which bugs me even though I'm on a single-user system where that should be ok. Both installs and uninstalls are deterministic, complete, and don't screw anything else up in the system. You can install different versions of the same package side-by-side, which the Debian and Red Hat Alternatives systems also enable, but Nix is more sophisticated about it tagging everything with a cryptographic hash of its build tree. MacPorts and pkgsrc may also provide some of this, but Nix feels more like the git of package managers than anything else I've used, eg the one that finally gets packaging right.
Absolutely. That's why the canonical gnu installation separates "make" from "make install". But homebrew could do the same thing (and maybe it does now -- I need to go back and revisit this because apparently this issue has been resolved.)
Very much the reason why MacPorts requires sudo, so it can drop to a less-privileged "macports" user for builds, without putting your own user account at risk.
Not to rain on anyone's parade, but I find MacPorts to be superior to Homebrew in every way, from writing the ports themselves, to installing them and managing them. I used to use Homebrew some time ago, but when I got my Mac Mini, I decided to forgo it in favor of MacPorts and Pkgsrc (which Joyent also provides binaries of for OSX). Whatever MacPorts doesn't have (a rare occurrence), Pkgsrc tends to have it. If not, writing a MacPort is incredibly easy with their provided DSL.
I was pleasantly surprised that, despite Homebrew taking so much of the OSX package management mind-share these days, MacPorts still has an active and vibrant community going strong. I was also pleasantly surprised by just how well Pkgsrc works on OSX, despite its origins on NetBSD. In fact, Pkgsrc works so well that I've switched to using it on Slackware as my primary package manager for anything not in the base system, preferring it to SlackBuilds.org and sbotools (though I still use sbotools whenever Pkgsrc doesn't have a package I want — which sometimes leads to duplicate dependencies in different paths... still haven't figured out how to avoid that yet...).
There are lots of minor changes, but nothing major IMHO. The reason for bumping the minor version are a couple of breaking changes:
- Disable SHA-1 checksum support in formulae
- Disable running Homebrew as the root user (e.g. sudo brew)
- Bottles with _or_later tags no longer use _or_later in their filenames so the existing bottle can be reused
Of specific interest: "This deprecation was announced and these methods removed/undocumented before 1.0.0 was tagged so arguably it was not part of the public API when 1.0.0 shipped."
I'm ambivalent. If I rev 1.0 - 1.1, then I'm going to assume the API won't change, even if I'm using undocumented and warning-spitting methods.
But I shouldn't be doing that, I shouldn't roll in a minor update without at least reading the change log, it's a FOSS project run by a volunteer staff, and brew never swore an oath to follow the laws of versioning as set by semver.org.
If the brew documentation said, "We use semantic versioning," then I'd say the complainants were correct. Otherwise, versions are just versions, and all you can count on is (Major Changes).(Medium Changes).(Minor Changes).(Tiny Changes).(etc.)
edit: Thoughts:
Years and years ago, I spent a lot of time and energy ranting about the fact that Google called GMail "beta software" when it was clearly not feature complete, and beta has a meaning, and we are just destroying a useful system of names for the software testing and release cycle, and…
But in the end, version numbers and development stages are language, and you cannot force your language on others, irregardless of whether or not you'd like to.
> I'm going to assume the API won't change, even if
> I'm using undocumented and warning-spitting methods.
And here I disagree, quite strongly. If I'm using
"undocumented and warning-spitting methods" then I know what
I have done is a hack and those methods could disappear or
change at any time and I should proceed at my own peril.
>And here I disagree, quite strongly. If I'm using "undocumented and warning-spitting methods" then I know what I have done is a hack and those methods could disappear or change at any time and I should proceed at my own peril.
We're in complete agreement, actually. I'm just saying that I generally don't expect things like that to change on a point release, not that it can't, won't, or shouldn't. You're definitely juggling chainsaws if you're in a situation like that.
We don't drop privileges when building (as we're not designed to run as root) and the macOS sandbox has issues with the root user so unfortunately you're giving every package you install root access to write to (almost) anywhere on your system. This is bad so we've stopped it.
Using the root user like this is used by a tiny minority of our users. The deprecation notice noted we'd happily accept a PR that implemented the privilege dropping but one never came. In a world where Homebrew is run by a full-time, paid staff we'd likely have implemented it but there's too much other, more important stuff that needs done by our understaffed team.
Always good news to see progress in Brewland. I personally do not like having it installed in /usr/local and have ensured it never is on my installation, but I've not had the chance to ever discuss with one of their team why they do it and what things may possibly explode by not having Brew installed to /usr/local
We put as much stuff as possible in `/usr/local/Homebrew` and `/usr/local/Cellar` now so hopefully that helps a bit. `/usr/local/bin` and friends are now mostly just symlinks. As mentioned in another comment, we've got some historical and current reasons for this location and build our binary packages (bottles) for there but you can install Homebrew in any location you want: https://github.com/Homebrew/brew/blob/master/docs/Installati...
For C libraries, having it in /usr/local is a benefit, since many already default to looking there, like cmake and autoconf scripts. Otherwise you have to fix that for many build scripts.
While I share your misgivings about sticking stuff like this at the "system" level, I think they are right to do so in this case, for simplicities sake.
/usr/local is explicitly for user/administrator managed software versus /usr being for system managed stuff, it's the correct location for this on any UNIX/POSIX-like system.
Annoyingly, the FHS isn't POSIX (nor SUS) and thus not Unix. There's thus no real standardisation on what the filesystem should look like and thus even Guix or Gobolinux can be POSIX candidates.
Even macOS takes advantage of this nonstandardisation by putting stuff in /Applications, /Library and /Users.
The debate about what belongs in /usr, /usr/local, /opt (and hahaha, /opt/local) is mostly subjective opinions about just how local these local things are.
Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts.
For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade computers, there's only one thing to copy over.
I do this. It's simple enough to install homebrew, to, say, $HOME/.homebrew. I haven't had any problems with this approach, but then, I don't use Ruby, and if I did I wouldn't use homebrew to manage it.
Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts.
The multiuser features are used to provide defense in depth, especially for developer machines.
For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade computers, there's only one thing to copy over.
Apple's migration tool and cloning have always worked for me.
One of the issues I recall comes from not using Homebrew exclusively. For example, installing GPG from package puts files in the same location, and I've had conflicts in the past. It's not always possible to use Homebrew exclusively, so I move it elsewhere to mitigate this possible problem.
The points are opinionated (which is nice!) but a tad obsolete these days.
1. /usr/local/bin is already in your PATH
But not /usr/local/sbin, which I had to add anyway.
2. Tons of build scripts break
Not that much anymore, and gems can now be configured much more easily thanks to bundler. It's indeed a chore to tell configure to link against this or that, but most of the time you just build a package anyway (trivial with pacman/abs) for things to be managed.
3. no need to worry about messing up existing tools.
But many third party tools install stuff in /usr/local. Also, SIP prevents any mess from happening to system stuff.
Also, regarding sudo:
But do you trust the multi-megabyte Makefile that Homebrew runs?
No I don't, that's why make/make install gets run as a regular user but under fakeroot when packaging with, say, pacman/abs.
Running the install phase as root allows the package manager to make things just work, such as installing OpenVPN (which depends on tuntaposx kexts), or install daemons under their own user and have them launched on system boot (not user login) by /Library/LaunchDaemons, or install Python under /Library/Frameworks (which ironically, brew builds as a framework but stores somewhere else).
Again, those are tradeoffs and it's good that a stance is taken either way.
Disclaimer: long-time tentative maintainer of Arch OS X
Macports. It works and does what I need it to do. I switched to Mac from Linux, and with that background it was unnerving to see a system deliberately written to install non-root-owned files in /usr, so I ruled Homebrew out. I've always found it puzzling that people ask whether anyone "still" uses Macports, as though it is some decrepit thing. Homebrew is the one that seems strange to me.
I'm a daily linux user, but occasionally some job requires me to use a Mac. Every time I see some OSX tool that starts with the premise of "just go ahead and `sudo chown` a system location and then curl this script into a `sudo bash` pipe" I just think to myself, if they care so little about security to not get the easy stuff right, can I really expect them to nail the hard stuff?
Usually not. I'll have to give Macports a try. As I understand it, it's an implementation/port of the BSD ports system, so I'd expect it to have a more solid foundation.
I switched to MacPorts from Fink (RIP). It feels about the same as using pkg on a modern FreeBSD box. Pros compared to Homebrew: doesn't litter symlinks everywhere, behaves the way you expect a package manager to. Cons: Not as cool™, tends to have less frequently updated packages.
I still use macports! As for why, there are a couple of reasons.
First, Macports is often the fastest at updating their ports database after new versions of an upstream are released. Next, I also like that Macports doesn't really rely on anything OS-X specific except for Xcode. So I don't need to worry about crap like whether some Python package will work with Apple's Python distribution, or whether installing a new version of Openssh will break any core Mac OS components.
> I don't need to worry about crap like whether some Python package will work with Apple's Python distribution
This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO) since you face fewer issues with breakage. OS X can update its userland tools and you generally don't care.
This is also exactly why i use MacPorts. It works. It doesn't do silly stuff. It's been consistently solid for years.
Today, i got into a fight with Homebrew because i wanted to use a second user account on my laptop. I have one primary account, and another i use when doing workshops with clients, so i don't accidentally show them my sekrit files. The only way to get brew to install things without making trouble was to sudo -i to my primary account in a shell.
Don't get me started on "brew install docker" vs "brew cask install docker".
That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
> That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.
You are probably using on old version of OS X that does not yet support TLS 1.2. Therefore system's libcurl cannot talk to https://kernel.org anymore, which got very strict recently. As a workaround, you can download the tarball manually with your browser and place it into /opt/local/var/macports/distfiles/git/.
Macports doesn't really rely on anything OS-X specific except for Xcode
And that's a big problem right there, I don't use xcode and its also a 15GB install!, so a waste to my small 128GB ssd.
Not to mention you will get nagging updates of a huge app you don't use, which takes lots of time to download and install.
Why doesn't macports make their pkg manager work just with the xcode cli tools? and for those pkgs that need xcode, tell the user they need to install xcode first.
Homebrew maintainer view: MacPorts is a good package manager built by smart people and we end up sharing e.g. patches sometimes. I used to use it before Homebrew and it was good. Nowadays it's worth using whichever one takes the approach that feels best to you.
Pkgsrc is fantastic and never gave me the lib conflict headaches I had with Homebrew. It's also really easy to contribute a package or fix. Plus I use pkgsrc in the cloud, so my dev machine works like my production machine.
MacPorts user here. It keeps ALL of its stuff in a single directory, and you just have to add it to the path. All package managers screw up from time to time, however MacPorts mistakes/inconsistencies are easily fixed, Homebrew has always been a pain in the ass for me. Also, no telemetry.
I do. I don't have anything against brew, I think it is great that it is available, but I've used Macports since before brew existed. Macports' philosophy and where it puts things just seems to jive more with how I think that type of tool should work and behave. There also might be a little bit of unjustifiable anti-ruby bias on my part at work there too. I'm glad both alternatives exist.
I use macports. No particular reason, it just works for me and I don't see any reason to switch. It also feels more BSD-like, which is a plus for me, though I didn't dig deep enough.
Have you tried installing TeX Live with Homebrew? I can't even fathom using a package manager that complains about managing packages 'cause it is too hard.
Maybe they updated the error message. Here is what it said that last time I tried Homebrew:
$ brew info texlive
Installing TeX from source is weird and gross, requires a lot of patches,
and only builds 32-bit (and thus can't use Homebrew deps on Snow Leopard.)
We recommend using a MacTeX distribution: https://www.tug.org/mactex/
Here is one more reason I use MacPorts, because it never does crap like this:
$ brew search x11
x11vnc
Error: GitHub API Error: API rate limit exceeded for 0.0.0.0. (But here's the good n ews: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
Try again in 54 minutes 49 seconds, or create a personal access token:
https://github.com/settings/tokens
and then set it as HOMEBREW_GITHUB_API_TOKEN.
I can answer that that precisely: 4. I was testing Homebrew in a virtual machine to see how it compared to MacPorts, Nix, and Pkgsrc at the time and can restore the virtual machine with Terminal still open and my complete session viewable.
Sure the "fix" is simple. But when I'm evaluating something I'm possibly going to make part of my life, I have to ask myself: how many more surprises await me?
Based on my evaluation of the available package managers, my ranking (for macOS) is:
I tried switching to nix, but homebrew's command line argument "design" has spoiled me. With homebrew I'm usually able to guess command arguments, where as with every other package manager I have to google when I want to do something I haven't done before.
For example, I want to search for a package name before installing. I'm guessing it's just "brew search pkg"... yup. Now what do I do with nix? Google says it's "nix -qa pkg", that totally makes sense, and I just love how I have to memorize some arcane letters.
This is true for virtually every linux package manager I've tried (wtf is apt-cache? I can't remember pacman commands after using it for a year). Seriously, typing anything with a minus sign is slower than typing word, so what's even the point? At this point I won't (choose to) use a package manager that doesn't get this right.
Haha, this is true, Nix's commandline is not exactly intuitive. I've been using apt, vim, and other similarly unintuitive stuff for a long time though so I just deal with it or script it, but totally understand anyone who prefers something more semantic.
Basically all of the unixy tools I need host-side (a lot of my work happens in Debian VM's or on remote Debian servers) are available as native Installer Packages (.pkg or .mpkg bundles)
This boils down to: Vagrant, Mercurial, Git, GPG Suite, Autotools, tree and wget.
And for updates you manually hunt down the new .pkg installers? Package managers are not only there to install some version of the software, but also to keep it up-to-date.
Disabling sha1 does not seem like a good decision. There are still enough upstream software projects that only publish their checksums as sha1 or even only md5. Keeping the original checksum allows quick comparison that a Formula is meant to use the same tarballs that were published by upstream. The problems of algorithms such as sha1 or md5 can be remedied by an additional strong checksum in the Formula. Checksum calculation is so fast that doing it twice will not matter.
There is nothing wrong with calculating your own additional checksum, but as far as I can see, sha256 is now the only supported checksum type in Homebrew at all.
Windows 10 now has support for the Ubuntu subsystem. You have to flip some settings to enable it and install it, but it's very easy to setup and it creates a complete Linux shell within Windows, including full support for apt-get.
With this, it's possibly a better Unix experience than macOS. I haven't used it enough to confidently make such a big statement, but it's worked very well so far in my trials.
Of all package managers I use, homebrew is without a doubt the most satisfying. It tracks updates closely and has always had any package I was looking for, yet I don't remember the last time I ran into an error.
(I'm sure all three happen, but if I can't find them with close to 200 packages installed, they must be doing something right)
Despite the warnings from their team, as soon as I switched to /opt/homebrew all of my homebrew problems went away.
The biggest issue by far are the number of traditional packages that install in /usr/local with root privileges, thereby clobbering homebrew and making "brew doctor" freak out.
To echo everyone else: Apple should be paying you folks a boat load of money. If homebrew didn't exist, I don't think we'd bother with macOS as a developer environment.
I absolutely adore Homebrew and can't thank the package maintainers enough. I think of all the times I battled with compiling some package, or installing it via MacPorts only to struggle updating it.
I have mixed feelings about Homebrew. Don't get me wrong, it's great, good job everyone involved. It makes my OSX laptop a viable development option for me. Without Homewbrew I wouldn't use it.
Alas that's also the problem. It makes OSX so familiar that this one OSX machine has now crept into my collection of Linux boxes and won't leave (thank you iOS development). I guess if your only complaint is that the software is too good...that's a pretty great thing :)
Sometimes I wonder how valuable Apple thinks Homebrew is for them. Any info on how much they contribute to the project?
Recently had to reinstall my mac from scratch. I was able to install 95% of my daily software through brew, by far a new record. Big thanks to the developers / maintainers of this project.
I love homebrew! I have it all on of my macOS machines. Best, easiest way to install common software I use between computers (Where supported, anyway) and developer packages. Now if we could just get http://linuxbrew.sh/ up to the same caliber....:)
There is definitely a lot to like about Homebrew (it's better than macports), but like others have said, when stuff goes wrong you can end up spending an entire day googling, only to end up going down a rabbit hole of archaic and often obsolete commands that may or may not work.
Once you get your environment set up it's fine, but try updating to the most recent Mac OS version with a ruby environment and you'll find pretty much all your gemsets broken in one way or another (if you have anything that needs native building).
I might just be bitter, though, as I spent most of a day working through this exact situation just last week.
It's funny how every hipster dev uses a MacBook for development, yet you have to resort to this kind of hacks from day one if you want to be productive. Anyway.
Docker for mac has replaced homebrew for me. Run anything under the sun in a temporary container and mount the current directory. Works great and is very nice isolating everything
Yeah, OK. We get it. You don't like something quasi-related to this post. So you're going to get a jab in wherever you can. Good job on you. Enjoy the rest of your week.
It's pretty ridiculous. They're giving Google a map of everything individual users install. The only reason it's "anonymous" is that they're relying on Google to throw away personally identifying data before Homebrew sees it.
Don't you think it's reasonable to make that sort of thing opt-in? This feels like the kind of presumption of a right to observe users that normally makes HN howl.
It's upsetting that Apple doesn't care about developers. Why is there no Apple maintained package management system? This results in having to turn to solutions like Homebrew, which -- while a valiant effort -- is completely insufficient for distributing state across multiple machines.
The sign of a great project isn't just that it does one thing well, but that it grows with the needs of the users and engages with them to constantly make something better without falling prey to bloat. And by that measure, Homebrew gets a gold star.