Live data from Hacker News

Homebrew 4.0.0

brew.sh

161–170 of 403 posts

Re: Homebrew 4.0.0

#161
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.

> 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.

Re: Homebrew 4.0.0

#162

On macOS, has anyone moved from/to MacPorts to/from Homebrew? Why did you move? What are the pros and cons of each system?

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.

Re: Homebrew 4.0.0

#163

[flagged]

You shouldn’t use brew for development tools and runtimes really, you should should use a language specific version manager or asdf. Brew for system stuff.

Agreed, sdkman and mini conda are two nice options for this.

In general, anything Java, python, node.js, etc. related you don't want to have installed globally if you can avoid it.

Re: Homebrew 4.0.0

#164

Earlier quoted context omitted.

Im okay with sending data to the server if things break and be asked each time to okay it. Is it safe to assume that if no errors or exceptions are encountered nothing should be sent back home?

How can they monitor failure rate if they only track failures though?

Why does it have to be a rate? Failures counts and failure types are good enough to extrapolate whatever else you need

Re: Homebrew 4.0.0

#165
post #115
post #109

Earlier quoted context omitted.

>the kind of service developers used to pay money for I've donated to homebrew, I support them that way. The moral issue is, I'm using their tools and trusting them, and they are violating that trust by phoning home and sending analytic data without my involvement or approval. While it may seem trivial to you to set an environment variable, having to do that with every new homebrew install adds up, and when its forgo…

> 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.

Re: Homebrew 4.0.0

#166
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.

I think HN has a very varied audience - some work in the industry, others want A/B testing to be made illegal on the grounds that it is non-consensual mind-control experimentation :P

Re: Homebrew 4.0.0

#167
post #73

Earlier quoted context omitted.

That's opt-out, though? It's nice that they tell you, but they don't give you a choice. They're just warning you that you need to opt out. That's not the same as opting in. They're also claiming to log anonymous data while the data they collect is actually pseudonymous as its tied to your specific machine/user, which means it has a whole different status in different privacy jurisdictions. It seems like they could ma…

They don’t collect data until after you’ve been given the chance to opt out. > It seems like they could make the data collection anonymous relatively easily if they just stop tracking individual user installs, though. Doing that would skew the reports to more active users & automated scripts. If you’re asking questions like “how many people will notice if we deprecate this?” you don’t want to count the guy who hammer…

> They don’t collect data until after you’ve been given the chance to opt out.

That does still make it opt-out, though, even if it's a friendly opt-out. Microsoft's dotnet tools do the same thing.

> Doing that would skew the reports to more active users & automated scripts. If you’re asking questions like “how many people will notice if we deprecate this?” you don’t want to count the guy who hammers “brew update” every other command many times more than someone who updates weekly.

I know why they're collecting personal identifiers and I completely understand their reasoning behind it. Every website and service does this in some fashion because most requests are automated. You should still ask before you submit any telemetry, though.

Re: Homebrew 4.0.0

#168

Earlier quoted context omitted.

They'd be well advised to make this opt-in only for legal reasons. This is not going to go down well in a lot of places and they might get exposed to law suits.

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.

We only have their pinky promise that the new analytics are anonymous. For all we know this might be a PR operation because people increasingly dislike Google, and they'll sell the "anonymous" analytics to Google under the table.

I'll make it a goal to stop all their tracking on the level of my router.

Re: Homebrew 4.0.0

#169
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.

Re: Homebrew 4.0.0

#170
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.

Any actual arguments?

I don't see why something that's little more than a file server needs telemetry.

Post reply on HN