Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homebrew 4.0.0

brew.sh

Post reply on HN
Print view View original

111–120 of 403 posts

Re: Homebrew 4.0.0

#111

Post by kdtsh »

t8sr wrote: 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…

FWIW, Homebrew uses /opt/homebrew instead of /usr/local on Apple Silicon installations, as far as I know that was the main sticking point for the complaint that it took over your system. Still isn’t terribly useful for multi-user systems as far as I know, but for my personal laptop this will never be a problem that I have to deal with.

I used pkgsrc on macOS for a while but ended up going back to Homebrew because it was easier and there were more packages relevant to my needs; I also found packages in pkgsrc wouldn’t play nicely with zsh or bash completion sometimes, I believe this was related to patches specifically required for macOS for these packages. The concept of casks is also very nice, as it means I can manage most packages using a single package manager instead of doing dmg->drag-n-drop installations or mucking around with install/uninstall scripts. Building and maintaining a dumb cask formula is also pretty easy for apps where there isn’t already an available cask.

I haven’t used Macports so couldn’t compare - can Macports install .app applications?

Re: Homebrew 4.0.0

#112

Post by eesmith »

aa-jv wrote: post #68
eesmith wrote: post #37

Earlier quoted context omitted.

How is it hidden or hard to opt-out? From https://docs.brew.sh/Analytics you can opt out using: export HOMEBREW_NO_ANALYTICS=1 -or- brew analytics off 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…

None of this is user-friendly - all of it is obfuscated. I have to add resources to my system (env vars) in order to opt-out - and that is the issue! There are no hints/tips about this produced to educate a new user - if it weren't for your help, I wouldn't have known. The non-resource-using method I propose is that homebrew merely ask the user if its okay, after 5 or 10 runs, to send some info - and then shows me th…

> I have to add resources to my system (env vars) in order to opt-out - and that is the issue!

FWIW, I use "brew analytics off", not an environment variable.

You can't install brew without adding resources to your system.

But I think your real complaint is not about resources, but that the default is "opt-in with a warning" rather than "opt-out then ask for permission".

Which I can understand and agree with.

What I disagree with is characterizing the process as "hidden or hard to opt-out."

> There are no hints/tips about this produced to educate a new user - if it weren't for your help, I wouldn't have known.

I don't understand how you can say this.

The hint/tip is produced in the installer output. I quoted it. It even uses a terminal bell and bold text.

I can understand that you might prefer, say entering "yes/no" to a "may we enable analytics?" question (though it's a bit more complicated as someone may be fine with the new EU-based InfluxDB analytics but not Google Analytics).

But that's not the same as saying there are "no hints/tips about this produced to educate a new user", when it's right there in the installation output.

> merely ask the user if its okay, after 5 or 10 runs

Tracking the number of runs since the previous report is also adding resources to your system, which makes it hard for me to understand how adding those resources to your system is fine but adding an on/off resource is not.

I agree it's a dark pattern which makes it less likely that people will opt-out.

But I also think "unfeasible" is not an good characterization of "read the installation output then run 'brew analytics off'".

Re: Homebrew 4.0.0

#113

Post by cassianoleal »

ianai wrote: post #89
cassianoleal wrote: post #83

Earlier quoted context omitted.

Assuming their claims of anonymity are true, they won't be tracking users at all. I imagine they can get much richer metrics through this as opposed to only tracking downloads on the server side. I'm not saying I like it. In fact, I plan to keep it disabled. I'm just saying it's a bit naïve to think client-side analytics are the same as server-side download tracking.

Richer how, exactly? I fundamentally don't 'get' what richness they actually need. If anything they need money, of course, and to know their software works for their users. Prior to release have a test system install the full base, test those packages work, and you know anything less will work too.

I haven't looked at what they're actually collecting, but here's a few things that come to mind:

- Time to install packages - Versions of things - Has the compilation (when required) failed? What dependency versions are installed? - CPU architecture - OS version ...

There's a lot more that can be sent from the client that's not available on the server side.

> I fundamentally don't 'get' what richness they actually need.

That's fine. Perhaps you could ask them instead of ranting about what you don't know or don't 'get' in a public forum?

> to know their software works for their users

Sounds like you're not very far from understanding why they want better telemetry.

> Prior to release (...) and you know anything less will work too.

Things break in unexpected ways. OSs are complex systems and there's a lot of interactions between components. Homebrew's user base is enormous and very diverse. There's 2 different architectures, many OS versions, lots of environment variables that might be set differently in each user's systems, different versions of libraries, ... I could go on but I think you get the picture.

Edit: s/collected/collecting/

Re: Homebrew 4.0.0

#114

Post by Larrikin »

ianai wrote: post #98
brookst wrote: post #86

Earlier quoted context omitted.

Maybe they want to include the most common packages in their unit tests, or understand usage patterns so they can prioritize development? It’s very hard to write and maintain good software without knowing how it’s used. No package manager needs to know how you specifically use it, but aggregate data and the ability to identify scenarios it does not handle well are both very important for SW lifecycle.

It's 2023. Hard drive space shouldn't be an issue. Test installing the full software suite, make it work, and you know the lesser installs will all work.

How much would you be willing to pay so that Homebrew can maintain a large amount of hardware covering nearly all configurations?

Re: Homebrew 4.0.0

#115

Post by acdha »

aa-jv wrote: post #109
acdha wrote: post #94

Earlier quoted context omitted.

> None of this is user-friendly - all of it is obfuscated This is a message which is printed with very clear instructions the first time you run any command. It’s a simple command and there’s no noticeable difference in resource usage compared to the actual package management system, which also needs environmental variables to be set. The big thing you’re missing is that the Homebrew maintainers are freely giving you…

>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 - not requiring only a skill you already used and giving you precise instructions. I think there’s a legitimate debate for opt in or out but I don’t think “dark” is warranted for something people are talking about because it’s in the open and prominently disclosed.

Re: Homebrew 4.0.0

#116

Post by justinclift »

Larrikin wrote: post #114
ianai wrote: post #98

Earlier quoted context omitted.

It's 2023. Hard drive space shouldn't be an issue. Test installing the full software suite, make it work, and you know the lesser installs will all work.

How much would you be willing to pay so that Homebrew can maintain a large amount of hardware covering nearly all configurations?

Just checked their OpenCollective, and they seem to have about US$100k there:

https://opencollective.com/homebrew#category-BUDGET

They seem to be receiving about US$2k/month via Patreon too:

https://www.patreon.com/homebrew

I think their Patreon was around the same when I looked ~12 months ago.

Re: Homebrew 4.0.0

#117

Post by orf »

ianai wrote: post #98
brookst wrote: post #86

Earlier quoted context omitted.

Maybe they want to include the most common packages in their unit tests, or understand usage patterns so they can prioritize development? It’s very hard to write and maintain good software without knowing how it’s used. No package manager needs to know how you specifically use it, but aggregate data and the ability to identify scenarios it does not handle well are both very important for SW lifecycle.

It's 2023. Hard drive space shouldn't be an issue. Test installing the full software suite, make it work, and you know the lesser installs will all work.

Do you think “hard drive space” is the constraining factor when building and testing over 6.5k third party packages?

Do you really not see any advantage to maintainers having visibility into what packages people actually use?

Re: Homebrew 4.0.0

#118

Post by yrro »

stjo wrote: 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…

Homebrew should support the DO_NOT_TRACK environment variable.

https://consoledonottrack.com/

It doesn't look likely though. I don't think it looks good that comments pointing out that Homebrew's existing behaviour (collecting analytics without obtaining informed consent from users) violates the law have been classified as abuse and hidden!

https://github.com/Homebrew/brew/pull/6745

Re: Homebrew 4.0.0

#120

Post by steve1977 »

yrro wrote: post #118
stjo wrote: 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…

Homebrew should support the DO_NOT_TRACK environment variable. https://consoledonottrack.com/ It doesn't look likely though. I don't think it looks good that comments pointing out that Homebrew's existing behaviour (collecting analytics without obtaining informed consent from users) violates the law have been classified as abuse and hidden! https://github.com/Homebrew/brew/pull/6745

Or, just not track.
Post reply on HN