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

181–190 of 403 posts

Re: Homebrew 4.0.0

#181

Post by ianai »

lamontcg wrote: post #160
ianai wrote: post #90

Earlier quoted context omitted.

All stuff that should be in a trouble ticket from a whiney user. Which we know this type of user would be. Edit-Also, this is for Mac OS. Chose a few standard OSes to support and test them. If a system update will fix the issue then it shouldn't be fixed at the package manager level.

Much rather deal with anonymized telemetry blowing up than tickets from whiney ass users.

Does anybody put a paywall in front of submitting tickets? Seems like homebrew could if anybody. Ie $10 to submit and might need more for a larger problem.

Re: Homebrew 4.0.0

#182

Post by Terretta »

_aavaa_ wrote: post #35
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…

No kidding. First I’m hearing about it.

Probably not, as the installer tells you in the same blurb it tells you how to add brew to your .profile.

What it doesn't tell you unless you read the URL, is all you have (had) to do is "brew analytics off".

Re: Homebrew 4.0.0

#183

Post by cratermoon »

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

https://www.trevorbragdon.com/when-data-gives-the-wrong-solu...

Re: Homebrew 4.0.0

#184

Post by derstander »

pdimitar wrote: post #168
pimterry wrote: post #13

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.

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.

> We only have their pinky promise that the new analytics are anonymous.

Isn’t Homebrew open source? One could audit the source themselves. If you’re talking about what happens on the server side yes, but I don’t see the difference with any other computer I connect with over the internet.

[1] https://github.com/Homebrew/brew

Re: Homebrew 4.0.0

#185

Post by Terretta »

nishs wrote: post #162
throw0101c wrote: post #23

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

> for example "brew install" writes files into /usr/local/

I think it's /opt/homebrew on M1.

https://docs.brew.sh/FAQ#why-should-i-install-homebrew-in-th...

> 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

The single user thing is problematic in a corp env where you may have a mgmt admin user and a non-admin dev user.

Long story short, temporarily have the dev user be an admin, install brew, drop the admin priv. That works for cli tools (which is actually great), but may not work for /Applications unless you change its ownership. Used to be OSX effectively (not literally) merged ~/Applications and /Applications, but now in MacOS the security sandboxing and entitlements don't like that.

Re: Homebrew 4.0.0

#186

Post by woodruffw »

ianai wrote: post #75
pimterry wrote: post #13

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.

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

To be clear: Homebrew has no idea which users are installing what. We only store counters for package install, failure, etc. events, and everything that's stored is visible on the Homebrew website[1].

Homebrew's architecture doesn't really have a "server side" in the way your suggestion requires: the formulae and bottle components rely heavily on public services like GitHub Packages and GitHub Pages, which don't offer those kinds of analytics.

FD: Member of Homebrew.

[1]: https://formulae.brew.sh/analytics/

Re: Homebrew 4.0.0

#187

Post by bathtub365 »

Shish2k wrote: post #166
lamontcg wrote: post #161

Earlier quoted context omitted.

> 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

The groups of people who work in the industry and those who believe A/B testing is psychological experimentation aren’t disjoint.

Re: Homebrew 4.0.0

#188

Post by dividedbyzero »

bsnnkv wrote: post #158

I have a lot of love for Homebrew from many years of using it, but I don't think you'll ever find me using it in macOS or Linux again. I use Nix on both now and I'm convinced that it is the saner way of doing things.

Does Nix still have that extremely steep and high learning curve and huge time invest before you actually grok it? I'd love a Nix that is about as hard to use as homebrew, but no luck so far.

Re: Homebrew 4.0.0

#189

Post by hnlmorg »

gizmo wrote: post #47
hnlmorg wrote: 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…

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

What you're arguing about now is just that Homebrew doesn't give you a prompt. Which is a fair criticism but it doesn't really change much because if you need that other package that depends on the latest version of node, then all the prompting in the world isn't going to change the fact that you are still going to need to install that updated version.

But, as I'd mentioned before, `brew` does let you install specific versions of software too. So it's a bit of a moot point about whether you get upgraded or not since, in this circumstance, you can have your proverbial cake and eat it (ie both versions installed).

> In addition, you have different branches where the debian stable branch is extremely well tested.

Debian isn't bleeding edge and nor is it rolling release. Arch is a better comparison and people frequently complain about updates breaking things on that too (even though that does have a testing branch). To be clear, I love Arch. It is by far and away my favourite Linux and a large part of that is because of it's package management. But no system is perfect.

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

I agree Homebrew has it's warts. I just disagree with this particular complaint. I think Homebrew is doing the right thing here.

If you want to complain about how it has to operate outside of the core OS because it's a 3rd party tool, or its overuse of beer jargon as cute substitutes for the more recognisable package management terminologies then I'm 100% behind you. But to complain that it's keeping your system up-to-date when you haven't asked for a package to be version pinned feels more than a little unfair.

Post reply on HN