Live data from Hacker News

Homebrew 4.0.0

brew.sh

91–100 of 403 posts

Re: Homebrew 4.0.0

#91

Man there are a lot of complaints about this free software no one is forcing you to use. I would start with a thanks to the people who spend a lot of time on this, and probably not for much wealth. I know I greatly appreciate the existence of homebrew.

Entitlement syndrome. Nothing is perfect, not even paid software is perfect. At least open source gives a chance for someone to look into how it's done, suggest/discuss something different and submit a modification if affordable.

EDIT: Typo

Re: Homebrew 4.0.0

#92
post #9

Earlier quoted context omitted.

You know, as the law requires in the EU

I don't think that's true - AFAICT there's no EU law banning analytics. EU law just restricts storing & processing _personal_ data (GDPR) and storing unnecessary data on machines without consent (ePrivacy/'cookie law'). If you want to log fully anonymized data, without persistent tracking ids and without leaking personal data to 3rd parties en route (so no "send it to Google and they promise to anonymize the IP after…

> EU law just restricts storing & processing _personal_ data (GDPR)

To be clear to anyone reading: using Google Analytics without a non-Google-hosted anonymisation step breaks GDPR. This _has_ been litigated in court in several countries. There's no "ifs" or "buts" about it.

Re: Homebrew 4.0.0

#93

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

Moved from homebrew to nix. Haven't looked back. If something is not on nix, I just build/compile it myself.

Re: Homebrew 4.0.0

#94
post #68
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…

> 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 product of many thousands of hours of skilled work, the kind of service developers used to pay money for. In exchange, they ask for some non-personal statistics to help them avoid mistakes which could cause problems for you. I don’t think it’s fair to act like they’re tricking you when you’re getting so much out of the deal and it’s all disclosed publicly. They could be tracking stats on the package distribution infrastructure without your knowledge at all but instead chose to be fully above board about what the system does and why, and offer a trivial opt-out mechanism.

Re: Homebrew 4.0.0

#95

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.

It's hard to send stuff over the Internet without exposing some personal information, like your ip number. I guess they might send it over TOR to get around that.

This is exactly the use case that Oblivious HTTP is being built for in he IETF.

Re: Homebrew 4.0.0

#96
post #47
post #40

Earlier quoted context omitted.

You can specify specific package versions in brew if you want specific versions pinned. The default behaviour of using the latest in repo is correct and is how every package manager works. It’s the behaviour people expect and it’s the behaviour that is arguably more secure (the fact that homebrew is bleeding edge does create issues here but generally speaking my point stands). I believe you pin using the @ symbol fol…

This is not at all how every package manager works. On debian if you install a package it will just install that package and it will warn you if dependencies will require upgrading first. It won't upgrade totally unrelated packages and break everything for you. In addition, you have different branches where the debian stable branch is extremely well tested. Homebrew is way, way worse than any other package manager be…

> Homebrew is way, way worse than any other package manager because it just breaks stuff all the time.

I hear this a lot, but as a 12+ year user of Homebrew it simply does not match my experience, other than for Python which is in and of itself fundamentally broken regardless of where you get it from. Indeed, I’ve spent far longer screwing about trying to get up-to-date dependencies on recent Ubuntu releases than thinking about it.

Re: Homebrew 4.0.0

#97

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

How to nuke it? Just in case...

Re: Homebrew 4.0.0

#98
post #86
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.

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.

Re: Homebrew 4.0.0

#99

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

That's a Node problem. They make semver-major breaks on a regular schedule, which is a flabbergasting policy. Besides, you're still in trouble even if you don't upgrade, because then your JS deps will eventually start breaking from a too-old Node. And if you don't upgrade deps, you risk vulnerabilities, and you won't know which one of the 20 "critical" npm reports are ReDoS spam, and which one are actually important.

Re: Homebrew 4.0.0

#100

Man there are a lot of complaints about this free software no one is forcing you to use. I would start with a thanks to the people who spend a lot of time on this, and probably not for much wealth. I know I greatly appreciate the existence of homebrew.

[flagged]
Post reply on HN