Live data from Hacker News

Homebrew 4.0.0

brew.sh

171–180 of 403 posts

Re: Homebrew 4.0.0

#171

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,…

Yes.

If you install untrusted code, it can do nefarious things.

No platform can save you from yourself.

Re: Homebrew 4.0.0

#172
post #67

As an old hand who was around when homebrew started, I feel obliged to let people know there are alternatives. If you find brew's take-over-your-system-and-youll-thank-me approach off putting, and/or you value stability over the coolness factor, MacPorts is still alive and well ( https://www.macports.org ), and in-fact has basically all the same packages brew does. In 18 years of using MacPorts, it's never messed up…

I've been trying Nix devenv[0] and nix-darwin[1] on Mac recently and having a blast. Definitely better than the stuff I had to build around Homebrew to make development environments consistent across machines. Nix-darwin even has support to install Homebrew packages.

[0] https://devenv.sh [1] https://github.com/LnL7/nix-darwin

Re: Homebrew 4.0.0

#173
post #44

Reminder that nothing in Homebrew has any signing or attempt at supply chain integrity. Now that they are moving away from clients using git, so even git commit signing is off the table now. When you install brew you are giving hundreds of people (or anyone who has access to their Github accounts) full remote code execution on your machine. Never ever use brew on a machine you use to access production.

Don't install untrusted code on your machine or your machine may do untrusted things.

If you're worried about it, compile your own builds.

Re: Homebrew 4.0.0

#174
post #165
post #115

Earlier quoted context omitted.

> No, maintaining environment variables to prevent tooling from sending unknown analytical data: this is not trivial. It is an anti-pattern designed to gain the data from un-sophisticated users, rather than treating users with respect and letting them have agency over whether their resources are used by the homebrew developers A dark pattern would conceal this, not prominently warn you, or it would be hard to do - no…

I updated to 4.0 and didn't get an alert about the new analytics - if I hadn't read about it here, I wouldn't even know there were different environment variables to stop analytics tracking now. I'd wager there are thousands of users who would prefer this not be tracking them, but yet do not know it is. That's a dark pattern.

> I wouldn't even know there were different environment variables to stop analytics tracking now.

Where does it say there are different environment variables to stop analytics tracking now?

The linked-to post says there's a new setting if you are okay with the new analytics and don't want to use the Google analytics:

> If you had previously set HOMEBREW_NO_ANALYTICS because you didn’t like Google Analytics and/or data being sent to the USA: please consider unsetting this and setting HOMEBREW_NO_GOOGLE_ANALYTICS instead, allowing analytics data to be sent to our new InfluxDB host.

but that reads like the old settings still work with brew 4.0.

Re: Homebrew 4.0.0

#175
post #75

Earlier quoted context omitted.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

> Why does a package manager need to track their users at all? Do any of you actually work in this industry shipping software products to end users? Without telemetry the problem there is literally one of trying to read the mind of your end users to figure out what they're doing, hoping that your internal CI manages to reflect the configuration in their environment.

This industry has managed to ship software products without telemetry just fine - mass-collecting usage data from end users is only a relatively recent trend.

Re: Homebrew 4.0.0

#176

Earlier quoted context omitted.

> Why does a package manager need to track their users at all? According to https://docs.brew.sh/Analytics they use it to measure how often formulas fail to install, to get overall metrics on which OS versions are used, and to correlate those (i.e. to tell on which OS versions specific packages fail to install correctly). > A maintainer has no need to know who's installing what Aside from the IP, they don't know who'…

I agree that they don't need to know the "who", but it is perfectly understandable that they want to know "what" is being installed. And as part of the "what", they would want to know on which platform, and whether the install succeeded or failed, and probably a few other metrics about the install to ensure that things are working correctly and identify gaps that should be filled. Based on what I read on the site, th…

They can already gleen a lot of this since they run the hosted formula db anyway. A 90-day analytics capture isn't a big deal IMO.

Re: Homebrew 4.0.0

#177
post #67

As an old hand who was around when homebrew started, I feel obliged to let people know there are alternatives. If you find brew's take-over-your-system-and-youll-thank-me approach off putting, and/or you value stability over the coolness factor, MacPorts is still alive and well ( https://www.macports.org ), and in-fact has basically all the same packages brew does. In 18 years of using MacPorts, it's never messed up…

The benefit of using Brew is that almost every stackoverflow or blog post contains brew commands you can copy/paste.

Just like using any popular framework, the most popular one comes with plenty of benefits outside of the technical differences.

Re: Homebrew 4.0.0

#178
post #2

> Homebrew’s analytics are now sent both to Google Analytics and our new, self-hosted InfluxDB instance hosted in the EU. > If you had previously set HOMEBREW_NO_ANALYTICS because you didn’t like Google Analytics and/or data being sent to the USA: please consider unsetting this and setting HOMEBREW_NO_GOOGLE_ANALYTICS instead, allowing analytics data to be sent to our new InfluxDB host. My package manager was reporti…

I find this very invasive and I am glad I never used homebrew and always used Macport instead.

Re: Homebrew 4.0.0

#179
post #75

Earlier quoted context omitted.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

> Why does a package manager need to track their users at all? According to https://docs.brew.sh/Analytics they use it to measure how often formulas fail to install, to get overall metrics on which OS versions are used, and to correlate those (i.e. to tell on which OS versions specific packages fail to install correctly). > A maintainer has no need to know who's installing what Aside from the IP, they don't know who'…

Aside from the IP? IP nowadays is all you need…

Re: Homebrew 4.0.0

#180
post #75

Earlier quoted context omitted.

As in the post: they're intending to drop the GA part entirely within 90 days, and it sounds like the new metrics are entirely anonymous, and so not covered by GDPR etc. IANAL but as far as I can tell that should avoid all legal concerns once GA is gone.

Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

"Without telemetry, developers rely on bug reports and surveys to find out when their software isn’t working or how it is being used. Both of these techniques are too limited in their effectiveness."

https://research.swtch.com/telemetry-intro

Post reply on HN