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

241–250 of 403 posts

Re: Homebrew 4.0.0

#241

Post by saghm »

mdaniel wrote: post #220
modernerd wrote: post #139

Earlier quoted context omitted.

Using SQLite instead of JSON could have worked too and would likely make the manifests smaller: > curl -sI https://formulae.brew.sh/api/formula.json | grep content-length => 19898457 (~19.9MB) > curl -sI https://formulae.brew.sh/api/cask.json | grep content-length => 4023930 (~4MB) But the JSON API has been around for a while so brew 4.0 just makes use of it by default. Brew 3.3 added an off-by-default HOMEBREW_INSTA…

> instead of checking out the large (and slow) homebrew/core and homebrew/taps repos I actually wanted to ask why they don't just prune the history of those repos to cut down on their clone size? OT1H, I could actually imagine some software historian being curious what flags were required to build sqlite 3.6.20 from 2009 (872f50ac61d7) but OTOH building a whole new distribution system instead of effectively git-squas…

> OTOH building a whole new distribution system instead of effectively git-squash feels weird

Or even just `clone` with `--depth=1`? Just because the history exists doesn't mean you have to fetch it.

Re: Homebrew 4.0.0

#242

Post by pdimitar »

woodruffw wrote: post #231
pdimitar wrote: post #170

Earlier quoted context omitted.

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

Homebrew is a package manager with thousands of packages, not a file server. We maintain those packages, and knowing when they break (or can be deprecated due to lack of use) is critical to the project's sustenance.

Okay, fair enough. But the breakage can't be detected without telemetry then, I take it?

If so, that's... not ideal for sure.

Re: Homebrew 4.0.0

#243

Post by afavour »

grugagag wrote: post #164
cassianoleal wrote: post #143

Earlier quoted context omitted.

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

They really aren't. If a package is downloaded 100k times and fails 1k times it's a very different issue than if it's downloaded 1k times and fails 1k times.

Re: Homebrew 4.0.0

#244

Post by hardware2win »

mola wrote: post #232
pancrufty wrote: post #212

Earlier quoted context omitted.

Opt-in analytics are useless, unless a large part of your userbase just clicks through the entire wizard without thinking; there’s little overlap with Homebrew’s userbase

Ok, so don't do analytics.

Then have worse product for the users?

Re: Homebrew 4.0.0

#245

Post by SllX »

nrvn wrote: post #70
anshargal wrote: post #50

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

This, absolutely! 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.

In 2010 I wanted Apple to do this.

In 2023 I want Apple to stay as far the hell away as possible from App and package management as possible on my Macintosh. I don’t have the same hang ups on my iPhone, but I don’t want a merger of policies and incentives between the two platforms either.

Re: Homebrew 4.0.0

#246

Post by microtonal »

woodruffw wrote: post #218
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 doesn't "report" anything to Google, much less anything of yours (implying unique identification). This is an unnecessary editorialization. You can see exactly how Homebrew does analytics here[1], and you can see the sum total of the information collected here[2]. No identifiable information is collected or retained. [1]: https://github.com/Homebrew/brew/blob/master/Library/Homebre... [2]: https://formulae.b…

From the Homebrew documentation:

A Homebrew analytics user ID, e.g. 1BAB65CC-FE7F-4D8C-AB45-B7DB5A6BA9CB. This is generated by uuidgen and stored in the repository-specific Git configuration variable homebrew.analyticsuuid within $(brew --repository)/.git/config. This does not allow us to track individual users, but does enable us to accurately measure user counts versus event counts. The ID is specific to the Homebrew package manager, and does not permit Homebrew maintainers to e.g. track you across websites you visit.

IANAL, but an UUID is definitely PID under the GDPR:

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

Also see recital 30:

Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

The GDPR doesn't only take into account whether an identifier can currently be used to identify a person, but also whether the data can be correlated in the future to do so (e.g. by correlating package installs with visiting project websites, thus deanonymizing the UUID).

The only safe way to abide by the GDPR is to avoid storing any non-essential data without consent.

I am pretty sure that Homebrew have been violating the GDPR for years by making analytics opt-out. Sadly, anyone who tries to warn them gets banned from their issue tracker.

Re: Homebrew 4.0.0

#247

Post by throwaway5959 »

mola wrote: post #232
pancrufty wrote: post #212

Earlier quoted context omitted.

Opt-in analytics are useless, unless a large part of your userbase just clicks through the entire wizard without thinking; there’s little overlap with Homebrew’s userbase

Ok, so don't do analytics.

Yes, hardware2win, have a worse product. Not everything needs to be phoning home all the time.

Re: Homebrew 4.0.0

#248

Post by hardware2win »

Patrol8394 wrote: post #179
pimterry wrote: post #88

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

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

I think nowadays IP is less and less relevant when majority of people sit on dynamic IPs

Re: Homebrew 4.0.0

#249

Post by pdimitar »

shepherdjerred wrote: post #219
pdimitar wrote: post #170

Earlier quoted context omitted.

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

> something that's little more than a file server You're doing an awful disservice to Homebrew.

I am, yes, and sorry about it.

I don't like telemetry at all and I believe we have to find other ways to do QA. Hence my strong reaction.

Re: Homebrew 4.0.0

#250

Post by lamontcg »

woodruffw wrote: post #231
pdimitar wrote: post #170

Earlier quoted context omitted.

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

Homebrew is a package manager with thousands of packages, not a file server. We maintain those packages, and knowing when they break (or can be deprecated due to lack of use) is critical to the project's sustenance.

And with packages that compile.

Which the software that I used to be employed maintaining has actually broken homebrew compiles when they've been installed at the same time (which I think I made better but I never got the PM who actually owned the product to spend the resources to properly fix).

A good example of how the configuration in the end user environment can affect package installation.

Post reply on HN