> brew update will now be run automatically less often (every 24 hours rather than every 5 minutes) and these auto-updates will be much faster as they no longer need to perform the slow git fetch of the huge homebrew/core and homebrew/cask taps’ Git repositories.
Excellent! Thanks to the brew team for this — it was always frustrating to install something and have to wait for a full, slow update first.
I was just wondering, have they considered storing all that in an SQLite file? And then you could refresh the file every 6 hours, say, and post it on a CDN?
maybe even just create an aliased sh function that just prepends that instead of typing it out each time.
I've been doing that forever. It really is incredibly annoying how it just keeps endlessly running without doing some gymnastics (yeah sure I could add that env var set to 1 in my zshrc but I mean its just a silly default behavior)
I use homebrew like a black box. I’m glad it exists, but I have no idea how it works and why it’s so complicated. When something breaks and Google is no help I just nuke it and start from scratch.
It’s only happened twice in more than a decade, but I still have the feeling that I was better off compiling stuff manually and cultivating a tidy /usr/local/bin like I did in early 2000s. But it’s probably rose-colored glasses and I’d definitively never take the time these days.
I think you’re right about the rose-colored nostalgia: it’s easy to forget how far behind people got on updates. I remember so many support emails where someone had hit a bug which had been patched a year earlier but never thought to install it. A couple of times where people reinvented something which had been added to PHP in the meantime because they didn’t know it was there.
> It’s only happened twice in more than a decade, but I still have the feeling that I was better off compiling stuff manually and cultivating a tidy /usr/local/bin like I did in early 2000s. But it’s probably rose-colored glasses and I’d definitively never take the time these days.
While I use Homebrew on my Mac — it is a major risk. I am afraid that the project is not following strict security policies and will be compromised at some point. Evil package or evil version of brew can steal or modify my data.
I think this will also hurt the Mac platform. I wish Apple would invest some effort into building an App Store for cli programs. While it may be complicated for the community(require signing, sandboxing, developer effort), it is likely to have better security guarantees than Homebrew.
> While I use Homebrew on my Mac — it is a major risk. I am afraid that the project is not following strict security policies and will be compromised at some point. Evil package or evil version of brew can steal or modify my data.
This is a genuine question: what is your threat model, and what security policies would you like to see? It's hard to imagine a threat model that assumes an "evil version of brew" that doesn't also prevent you from installing any third-party software on your machine. Malicious packages are always possible, but Homebrew's integrity checks do an adequate (but improvable!) job of making such attacks auditable; I'm not aware of any successful supply-chain attacks mounted against Homebrew users.
I have a lot of experience with various package managers, and Homebrew is not particularly out of band with its peers (which should be read, partially, as a general indictment of packaging practices).
I'm not a very technical person, but I think MacPorts adheres better to macOS standards and security practices. (At least it asks my admin password before any major interaction.) Been using for a few years, coming from Homebrew, and it's running smoothly.
Or just hire a few FTEs to properly support and maintain the CLI. Pull in new FreeBSD base at releases if they really want to axe their overhead. It's always just read as absolutely lazy how slowly the CLI progresses. Hire a few more and they could absolutely offer a package repo. This company dwarfs Red Hat prior acquisition.
A company like Apple could kick whatever money to an OSS project and write it off as charity for taxes, I think for that matter.
Same here.. I just want a default sandbox (no network + only file access to it's subdirectories)
The alternative is to run VMs/containers/etc for each project. But at that point, it will the beginning of the end for Apple's software, cause you're esentially running linux and using macOS as a terminal/thin client.. (Unit) devtools is how they got big with OS/X, and I think they sometimes forget this.
They have, it's called Macports. It started as a port to Darwin of the existing *BSD ports and (I believe) is subsidized by Apple.
It installs itself in /opt/local, it respects the Apple SIP.
Homebrew basically sucks, because it doesn't follow Unix conventions and it doesn't follow MacOS conventions.
Macports has both pre-compiled and build-from-source, supports current and past MacOS releases, uses xcode/clang for compilation, supports port variants and multiple versions installed in parallel (with "port select" to choose a default) etc etc.
No thank you. I don't want a walled garden where Apple has absolute authority to enforce anti-competitive policies like they do with the existing App Store (especially on iOS), and where they require you to pay an annual fee to publish anything, and where they tie everything to an AppleID.
I use a Macbook for work, and every day I go without having to create an AppleID is a good day.
What I want is a dang CLI package manager, and Homebrew is pretty alright at that. No, it's not perfect, but it's far better than anything Apple has done related to app stores.
By this logic, the ability to install arbitrary software is a major risk.
I strongly disagree with this stance, and it's a very authoritarian one at that. The common people can't be trusted with freedom so we should give up that freedom and trust in <insert authority here>. I find this stance morally repugnant and entirely at odds with where the future of technology should be going.
Tl;Dr: Hard disagree. Some of us prefer to use our computers as general computing devices, as opposed to just being desk-driven iPhones.
Apple should close this gap and I am puzzled why they have not done that yet. Because even for iOS development people need things beyond the xcode toolcahin and they resort to either of the available options. Homebrew is just one of them.
Not only cli app store but the mac app store also badly needs some love.
I have a lot of love for Homebrew from many years of using it, but I don't think you'll ever find me using it in macOS or Linux again. I use Nix on both now and I'm convinced that it is the saner way of doing things.
I moved from Homebrew to MacPorts on a local, personal-use Intel Mac.
I chose Homebrew some years ago when I was not as experienced a programmer, because it was more popular than MacPorts. When I revisited the choice last year, I chose MacPorts.
On Homebrew:
* It has a Frankenstein permissions model; for example "brew install" writes files into /usr/local/* with your regular user account as the owner of the files.
* The permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew, as far as I know, and I dislike software with such design choices.
* Noisy messages and undesired colors in the command line output.
These issues are absent in MacPorts. Overall, MacPorts appears more mature and more Unix-like than Homebrew.
The cons of the move are that not all the packages I want are available in MacPorts. However I have sufficient experience now to package crucial missing ones into MacPorts.
I switched from MacPorts to Homebrew very early on because it was better contained. I had to support developers who would build with MacPorts and end up with something which would crash with a linker error when they shared it with someone off the team because it was using a MacPorts binary in a non-standard location, or whose shell scripts broke expecting a GNU CLI utility version which was in their path but not their users. MacPorts also took forever to build since it dragged in so many replacements for system libraries.
Homebrew has done a much better job of staying out of the way.
Moved from Homebrew and Nix to MacPorts for a while around the M1 transition. Came away quite liking MacPorts; it was simple, and it worked.
Moved back to Nix when it was ready for Apple Silicon, mainly for better isolation / reproducability, ephemeral environments, and parity with my other systems. But if I need something that's not in nixpkgs, I'll look at MacPorts first.
1. I have used Fink. And I have used MacPorts. Now I use Homebrew.
2. When I get super-annoyed with a system, perhaps because it has entered a state where it won't update, I do a web search to see if folks have jumped from that ship to another. If there is a consensus, I jump with crowd. If not, I try to clear the decks, e.g. reinstalling from scratch, to see if I can improve my situation.
3. I don't have a list for you on the pros and cons. There may be some merit in choosing a system that is widely used, because then others might be able to help you if you encounter problems. By that measure, I think Homebrew is the best choice at the moment. But I've no reason to think there won't be something else just around the corner. I wish Apple would get in this game, but after so many decades of Apple standing by without acting, I am not especially sanguine.
Macports had broken multiple times in a year, under totally ordinary operation (nothing weird, just installing and uninstalling packages without doing anything that ought to be risky). A couple times I'd decided it was easier to just delete its entire directory and start over. Big rpm-hell vibes from the bad old days.
Switched to Homebrew. It's broken a couple times in a decade or so, only on OS upgrades. Easy fixes. I like the sudo-free package management. I like that it lets me manage a lot more of my software than Macports did (bigger selection, and "casks" for commercial software, which are now integrated into the main UI so that's not even some extra thing to learn anymore—it feels like being back on Gentoo with a good binary package cache)
Switched to MacPorts on an older machine which Homebrew dropped support for (and deleted all prebuilt binaries)
While neither is great as a package manager, especiall with their dependency resolution, here are a few pros&cons:
Apps: ++ Brew has a much more up-to-date collection, also more non-source binaries.
App customization:
+ Port, Brew dropped support for custom install flags a while ago
+ Brew you can setup autoupdate for your personal customizations with github actions since the main repo is using them, Ports does it manually, so you can't copy&paste their action for your use
(+ Brew allows you to install Mac .app bundles in a custom folder)
Security: + Ports has a slightly better security model (folder persmissions are better though I think it only matters for multi-user machines, so mostly no relevant; it also does some sandboxing on install via a specially created user), the downside is annoying sudo, but you can remove the need for sudo for some less sensitive ops like update/uninstall to cut down on the annoyance
Space: + Brew. Both waste it with their poor package repository architecture, but with Brew you can at least delete the repo after the first install and use their API to download updates. With Ports you can't do that, moreover it duplicates its registry (one for sync, uncompressed, another for local use)
Docs: + Brew, also random Google/SO answers are less likely to be outdated
UI: + Brew. Has more info (like size), better formatted
One thing about Homebrew that's really great and somewhat obscure is that you can use Ruby code inside brewfiles. I use that to have just one brewfile in yadm and make it do slightly different things on work vs personal laptop.
I despise, despise, Homebrew's "we know better than you" approach to always installing the latest versions of every dependency. How tf is this fine? They don't even offer alternative. They just say "we can't test all of the packages installed and all version combinations, so this is the best we can do". Well, no one asked you to test my exact setup. All I'm asking for is: if I have perfectly working Node 18 and I need to install fcking Shopify CLI, don't fcking install Node 19 and break my whole setup! Tf?!
I wish we could get the industry to understand that when you build-in analytics and make it hard for people to opt out, you're using their resources.
Sure, people don't pay for things like Homebrew (can they even?) - but this is no reason to extract resources from end users without their consent or agency.
I have to work very hard to get something like Homebrew installed and in-use in my organization - the IT guys detest it, since they don't have the wherewithal to understand it (or else they'd be higher-paid developers) so when I finally do get it installed and in use (because it is a very productive tool), having it phone home just makes the situation worse. IT guys have asked for my blood on more than one occasion, just because they see something 'uncontrollable' phoning home .. this does a lot more harm than good.
That said, homebrew has been absolutely responsible for making MacOS usable for development purposes in this ol' hackers lab, so I'll keep using it - but I sure do wish they'd care a little more about the position they put us in, having to justify the use of it to IT guys ..
EDIT: Thinking about it, I'm actually not averse to phoning-home, just the automatic/hidden nature of it. If brew asked me, every 5 or so times that I ran it, if I would like to participate in sending anonymized analytics to the brew devs, and showed me what was being sent (instead of obfuscating it), I'd be a lot more inclined to click "[Yes] - this one time" almost every single time ..
The installer gives a warning message before sending the first analytics, with a pointer to the above URL for how to disable analytics. From install.sh:
ring_bell
# Use an extra newline and bold to avoid this being missed.
ohai "Homebrew has enabled anonymous aggregate formulae and cask analytics."
echo "$(
cat <<EOS
${tty_bold}Read the analytics documentation (and how to opt-out) here:
${tty_underline}https://docs.brew.sh/Analytics${tty_reset}
No analytics data has been sent yet (nor will any be during this ${tty_bold}install${tty_reset} run).
EOS
)
"
> and showed me what was being sent (instead of obfuscating it),
You can also view all the information that is sent by Homebrew’s
analytics by setting HOMEBREW_ANALYTICS_DEBUG=1 in your environment.
Please note this will also stop any analytics from being sent.
I verified that using it dumps JSON analytics to the terminal, and it didn't seem that obfuscated, given the documentation in that Analytics page.
> EDIT: Thinking about it, I'm actually not averse to phoning-home, just the automatic/hidden nature of it. If brew asked me, every 5 or so times that I ran it, if I would like to participate in sending anonymized analytics to the brew devs, and showed me what was being sent (instead of obfuscating it), I'd be a lot more inclined to click "[Yes] - this one time" almost every single time ..
I'd take a minute to rip the fckng line of code bugging me every 5 installs out of the code. Thing is, if you make telemetry opt-in, it's the same as just not adding it in the first place. Only a handful of users will opt in, rendering the data pretty much useless, especially as it's install and install-fail counts.
If they included any personal data, it'd be opt-in by law (at least here in EU). As they don't, they don't have to, and I'm fine with it.
I used Linuxbrew for a while before switching completely to nix-pkg due to some recurring issues I had downloading some packages. nix-pkg is quite nice and noticeably faster, although rough around the edges, and the commands are hard to remember (so I just set some aliases), but overall I am happy.
Thank you. I tend to rely for even open source GUI apps because the experience of installing/removing packages have been smooth (at least for me) so even on Ubuntu, I find myself using brew instead of apt/snap for personal use.
Side question - what can we do about improving security? Of the possibility that packages are not poisoned? Some sort of central CA/GPG or similar requiring to sign the packages or there would always be some holes and it is a hard problem to solve?
[+] [-] modernerd|3 years ago|reply
Excellent! Thanks to the brew team for this — it was always frustrating to install something and have to wait for a full, slow update first.
[+] [-] atonse|3 years ago|reply
[+] [-] febstar|3 years ago|reply
Nice. Rust Cargo is also trialling out something similar.
[+] [-] arthurcolle|3 years ago|reply
maybe even just create an aliased sh function that just prepends that instead of typing it out each time.
I've been doing that forever. It really is incredibly annoying how it just keeps endlessly running without doing some gymnastics (yeah sure I could add that env var set to 1 in my zshrc but I mean its just a silly default behavior)
[+] [-] tambourine_man|3 years ago|reply
It’s only happened twice in more than a decade, but I still have the feeling that I was better off compiling stuff manually and cultivating a tidy /usr/local/bin like I did in early 2000s. But it’s probably rose-colored glasses and I’d definitively never take the time these days.
[+] [-] acdha|3 years ago|reply
[+] [-] FnuGk|3 years ago|reply
thats exactly what homebrew does.
[+] [-] wg0|3 years ago|reply
[+] [-] anshargal|3 years ago|reply
I think this will also hurt the Mac platform. I wish Apple would invest some effort into building an App Store for cli programs. While it may be complicated for the community(require signing, sandboxing, developer effort), it is likely to have better security guarantees than Homebrew.
[+] [-] woodruffw|3 years ago|reply
This is a genuine question: what is your threat model, and what security policies would you like to see? It's hard to imagine a threat model that assumes an "evil version of brew" that doesn't also prevent you from installing any third-party software on your machine. Malicious packages are always possible, but Homebrew's integrity checks do an adequate (but improvable!) job of making such attacks auditable; I'm not aware of any successful supply-chain attacks mounted against Homebrew users.
I have a lot of experience with various package managers, and Homebrew is not particularly out of band with its peers (which should be read, partially, as a general indictment of packaging practices).
[+] [-] vlunkr|3 years ago|reply
[+] [-] rpgbr|3 years ago|reply
[+] [-] ianai|3 years ago|reply
A company like Apple could kick whatever money to an OSS project and write it off as charity for taxes, I think for that matter.
[+] [-] jbverschoor|3 years ago|reply
The alternative is to run VMs/containers/etc for each project. But at that point, it will the beginning of the end for Apple's software, cause you're esentially running linux and using macOS as a terminal/thin client.. (Unit) devtools is how they got big with OS/X, and I think they sometimes forget this.
[+] [-] rswail|3 years ago|reply
It installs itself in /opt/local, it respects the Apple SIP.
Homebrew basically sucks, because it doesn't follow Unix conventions and it doesn't follow MacOS conventions.
Macports has both pre-compiled and build-from-source, supports current and past MacOS releases, uses xcode/clang for compilation, supports port variants and multiple versions installed in parallel (with "port select" to choose a default) etc etc.
Not sure why people use anything else.
[+] [-] ubertaco|3 years ago|reply
I use a Macbook for work, and every day I go without having to create an AppleID is a good day.
What I want is a dang CLI package manager, and Homebrew is pretty alright at that. No, it's not perfect, but it's far better than anything Apple has done related to app stores.
[+] [-] noptd|3 years ago|reply
I strongly disagree with this stance, and it's a very authoritarian one at that. The common people can't be trusted with freedom so we should give up that freedom and trust in <insert authority here>. I find this stance morally repugnant and entirely at odds with where the future of technology should be going.
Tl;Dr: Hard disagree. Some of us prefer to use our computers as general computing devices, as opposed to just being desk-driven iPhones.
[+] [-] nrvn|3 years ago|reply
Apple should close this gap and I am puzzled why they have not done that yet. Because even for iOS development people need things beyond the xcode toolcahin and they resort to either of the available options. Homebrew is just one of them.
Not only cli app store but the mac app store also badly needs some love.
[+] [-] vorpalhex|3 years ago|reply
If you install untrusted code, it can do nefarious things.
No platform can save you from yourself.
[+] [-] cunningfatalist|3 years ago|reply
[+] [-] ripley12|3 years ago|reply
[+] [-] bsnnkv|3 years ago|reply
[+] [-] Lio|3 years ago|reply
Mike, Max and the gang have materially improved my life at least, cheers! :D
[+] [-] gandalfgeek|3 years ago|reply
There's so much thankless toil that goes into maintaining package infrastructure that we all just take for granted. Thank you!
[+] [-] nikolay|3 years ago|reply
[0]: https://github.com/search?q=repo%3AHomebrew%2Fhomebrew-core+...
[+] [-] throw0101c|3 years ago|reply
[+] [-] nishs|3 years ago|reply
I chose Homebrew some years ago when I was not as experienced a programmer, because it was more popular than MacPorts. When I revisited the choice last year, I chose MacPorts.
On Homebrew:
* It has a Frankenstein permissions model; for example "brew install" writes files into /usr/local/* with your regular user account as the owner of the files.
* The permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew, as far as I know, and I dislike software with such design choices.
* Noisy messages and undesired colors in the command line output.
These issues are absent in MacPorts. Overall, MacPorts appears more mature and more Unix-like than Homebrew.
The cons of the move are that not all the packages I want are available in MacPorts. However I have sufficient experience now to package crucial missing ones into MacPorts.
[+] [-] acdha|3 years ago|reply
Homebrew has done a much better job of staying out of the way.
[+] [-] callahad|3 years ago|reply
Moved back to Nix when it was ready for Apple Silicon, mainly for better isolation / reproducability, ephemeral environments, and parity with my other systems. But if I need something that's not in nixpkgs, I'll look at MacPorts first.
[+] [-] dchest|3 years ago|reply
[+] [-] bluenose69|3 years ago|reply
1. I have used Fink. And I have used MacPorts. Now I use Homebrew.
2. When I get super-annoyed with a system, perhaps because it has entered a state where it won't update, I do a web search to see if folks have jumped from that ship to another. If there is a consensus, I jump with crowd. If not, I try to clear the decks, e.g. reinstalling from scratch, to see if I can improve my situation.
3. I don't have a list for you on the pros and cons. There may be some merit in choosing a system that is widely used, because then others might be able to help you if you encounter problems. By that measure, I think Homebrew is the best choice at the moment. But I've no reason to think there won't be something else just around the corner. I wish Apple would get in this game, but after so many decades of Apple standing by without acting, I am not especially sanguine.
[+] [-] yamtaddle|3 years ago|reply
Macports had broken multiple times in a year, under totally ordinary operation (nothing weird, just installing and uninstalling packages without doing anything that ought to be risky). A couple times I'd decided it was easier to just delete its entire directory and start over. Big rpm-hell vibes from the bad old days.
Switched to Homebrew. It's broken a couple times in a decade or so, only on OS upgrades. Easy fixes. I like the sudo-free package management. I like that it lets me manage a lot more of my software than Macports did (bigger selection, and "casks" for commercial software, which are now integrated into the main UI so that's not even some extra thing to learn anymore—it feels like being back on Gentoo with a good binary package cache)
[+] [-] sirodoht|3 years ago|reply
[+] [-] eviks|3 years ago|reply
While neither is great as a package manager, especiall with their dependency resolution, here are a few pros&cons:
Apps: ++ Brew has a much more up-to-date collection, also more non-source binaries.
App customization: + Port, Brew dropped support for custom install flags a while ago + Brew you can setup autoupdate for your personal customizations with github actions since the main repo is using them, Ports does it manually, so you can't copy&paste their action for your use (+ Brew allows you to install Mac .app bundles in a custom folder)
Security: + Ports has a slightly better security model (folder persmissions are better though I think it only matters for multi-user machines, so mostly no relevant; it also does some sandboxing on install via a specially created user), the downside is annoying sudo, but you can remove the need for sudo for some less sensitive ops like update/uninstall to cut down on the annoyance
Space: + Brew. Both waste it with their poor package repository architecture, but with Brew you can at least delete the repo after the first install and use their API to download updates. With Ports you can't do that, moreover it duplicates its registry (one for sync, uncompressed, another for local use)
Docs: + Brew, also random Google/SO answers are less likely to be outdated
UI: + Brew. Has more info (like size), better formatted
[+] [-] anacrolix|3 years ago|reply
[+] [-] dividedbyzero|3 years ago|reply
[+] [-] dmillar|3 years ago|reply
[+] [-] Mystery-Machine|3 years ago|reply
[+] [-] aa-jv|3 years ago|reply
Sure, people don't pay for things like Homebrew (can they even?) - but this is no reason to extract resources from end users without their consent or agency.
I have to work very hard to get something like Homebrew installed and in-use in my organization - the IT guys detest it, since they don't have the wherewithal to understand it (or else they'd be higher-paid developers) so when I finally do get it installed and in use (because it is a very productive tool), having it phone home just makes the situation worse. IT guys have asked for my blood on more than one occasion, just because they see something 'uncontrollable' phoning home .. this does a lot more harm than good.
That said, homebrew has been absolutely responsible for making MacOS usable for development purposes in this ol' hackers lab, so I'll keep using it - but I sure do wish they'd care a little more about the position they put us in, having to justify the use of it to IT guys ..
EDIT: Thinking about it, I'm actually not averse to phoning-home, just the automatic/hidden nature of it. If brew asked me, every 5 or so times that I ran it, if I would like to participate in sending anonymized analytics to the brew devs, and showed me what was being sent (instead of obfuscating it), I'd be a lot more inclined to click "[Yes] - this one time" almost every single time ..
[+] [-] eesmith|3 years ago|reply
According to that https://docs.brew.sh/Analytics page, to see what it sends:
I verified that using it dumps JSON analytics to the terminal, and it didn't seem that obfuscated, given the documentation in that Analytics page.[+] [-] d12bb|3 years ago|reply
I'd take a minute to rip the fckng line of code bugging me every 5 installs out of the code. Thing is, if you make telemetry opt-in, it's the same as just not adding it in the first place. Only a handful of users will opt in, rendering the data pretty much useless, especially as it's install and install-fail counts.
If they included any personal data, it'd be opt-in by law (at least here in EU). As they don't, they don't have to, and I'm fine with it.
[+] [-] modernerd|3 years ago|reply
They can and should! https://github.com/homebrew/brew#donations
[+] [-] bdsa|3 years ago|reply
seems like an unfair characterisation (having been both!)
[+] [-] Mystery-Machine|3 years ago|reply
[+] [-] toastercat|3 years ago|reply
[+] [-] wg0|3 years ago|reply
Side question - what can we do about improving security? Of the possibility that packages are not poisoned? Some sort of central CA/GPG or similar requiring to sign the packages or there would always be some holes and it is a hard problem to solve?
[+] [-] ossusermivami|3 years ago|reply
[+] [-] unconed|3 years ago|reply
"But they're not the same!"
I don't care.
[+] [-] rainboiboi|3 years ago|reply
[+] [-] mkrishnan|3 years ago|reply