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

Homebrew 1.0.0

brew.sh

Post reply on HN
Print view View original

231–240 of 255 posts

Re: Homebrew 1.0.0

#231

Post by davb »

petre wrote: post #200
davb wrote: post #71

Earlier quoted context omitted.

I switched to MacPorts following the Google Analytics debacle [1] and how it was handled [2]. I had this expectation that MacPorts would be backwards and full of ancient packages but it's not - it's fantastic! The package repository is really good, the project itself is stable and it doesn't have a default-on analytics component aggregating my package data at Google. [1] https://news.ycombinator.com/item?id=11566720…

Why would anoyone deliberately bother writing google analytics code in homebrew is beyond me. It should be optin or someone who is sufficiently pissed off could fork it and remove the offending code.

The devs' justification was that if it was opt-in, most people wouldn't do it. They thought it better to turn it on and force users to go manually disable it.

I disagreed in the GitHub issue about this. Debian's Popcorn (package popularity analytics) is opt-in - a choice on install that defaults to "off". That would be the perfect solution. Ultimately those who agreed with me were told that the decision was made and there would be no further discussion - the issue was closed and locked.

Re: Homebrew 1.0.0

#232

Post by davb »

rcarmo wrote: post #211
davb wrote: post #71

Earlier quoted context omitted.

I switched to MacPorts following the Google Analytics debacle [1] and how it was handled [2]. I had this expectation that MacPorts would be backwards and full of ancient packages but it's not - it's fantastic! The package repository is really good, the project itself is stable and it doesn't have a default-on analytics component aggregating my package data at Google. [1] https://news.ycombinator.com/item?id=11566720…

was it that hard to just, you know, type "brew analytics off"? Or was there more to that decision?

Actually, at the time I left for MacPorts, "brew analytics off" wasn't an option. Analytics was turned on without warning and without any obvious way to turn it off. They added an environment variable but still left it opt-out (on by default). I disagreed but users who complained were told that the decision was made and no further discussion would be allowed. [1]

> If you feel that way: please use another package manager.

I didn't like how it was handled. I think any sort of analytics, especially by third party companies with real capabilities for correlation and de-anonymisation should be strictly opt-in (off by default).

Opt-in doesn't really hurt users who don't care about privacy and security. Opt-out does hurt users who care about those things. Many organisations have security policies that discourage using software that "calls home". I'd trust the software much more if it didn't have that functionality at all.

The developer's justification was that if it was off by default, no-one would turn it on. I think that speaks volumes about how users feel about analytics these days. Some users suggested a Debian Popcorn style dialog ("We'd love it if you could help us gather some information about package usage, etc etc. Would you like to participate [y/N]", off by default but a question on first run asking the user if they'd like to help). We were told "no".

Overall, I thought it was a bad idea and the situation was handled poorly. For something as integral as a package manager I expect more.

[1] https://github.com/Homebrew/brew/issues/142#issuecomment-214...

Re: Homebrew 1.0.0

#233

Post by saynsedit »

tnorthcutt wrote: post #207
saynsedit wrote: post #168

/usr/local was bad but /usr/local/Homebrew is worse. The best would have been /opt/brew (short, no uppercase letter)

Why is /usr/local/Homebrew bad?

Because the UNIX hierarchy is standardized. System admins only expect bin, lib, etc, share, etc. to be in /usr/local. Imagine deleting /usr/local with the intention of only deleting local packages and accidentally breaking a Homebrew install.

Not to mention it's an uppercase H which breaks UNIX file name convention.

Re: Homebrew 1.0.0

#234

Post by mikepurvis »

mikemcquaid wrote: post #124
mikepurvis wrote: post #48

Earlier quoted context omitted.

As someone who maintain a ROS installation scheme for Mac based on homebrew ( https://github.com/mikepurvis/ros-install-osx ), this is a constant source of frustration. Even a fairly vanilla ROS installation has a deep dependency tree— there are any of several dozen major packages which can at any moment release a new major version and break us.

If you rely heavily on Homebrew in this way you should instead vendor all the formulae you depend on so that updates do not happen without your manual intervention.

That's basically what is done, on a piecemeal basis as things break, but it would be untenable to do it for the dozens of system dependencies, especially when I don't have the resources to set up a whole parallel bottling infrastructure.

In the end, most ROS Mac users still choose an Ubuntu, Debian, or Fedora VM— having a stable set of underlying packages is worth the tradeoff in convenience and performance.

Re: Homebrew 1.0.0

#235

Post by sperglord »

freehunter wrote: post #224
stephenr wrote: post #150

Earlier quoted context omitted.

> not for the reasons any package manager is classically considered good You can say that again. Homebrew's dependency management is a fucking joke, to the point that it might as well not exist.

That's the reason I stopped using Homebrew and plenty of other comments have said the same thing. Maybe it's changed recently, but last time I used it (about a year ago), dependencies were not cleanly resolved in every case.

What better alternative exists?

Re: Homebrew 1.0.0

#236

Post by kawsper »

mikemcquaid wrote: post #126
FabHK wrote: post #94

Brew is awesome. Note though that it gathers anonymous aggregate user behaviour analytics and reports to Google Analytics, see https://git.io/brew-analytics . You can opt out with brew analytics off

That's obviously fine for you to do but it's worth noting that we remove software that no-one uses where "no-one" is defined by "no-one using analytics". That's actually our main use-case for analytics.

Couldn't you just look at the download numbers instead?

Re: Homebrew 1.0.0

#237

Post by veidr »

eridius wrote: post #219
aphextron wrote: post #210

Earlier quoted context omitted.

Meh. I know "how to work in a big company" and choose not to. Talented people will always do whatever they want.

You choose not to, but you could if you wanted to, right? He apparently wanted to, otherwise he wouldn't have gone to Apple in the first place, but he just doesn't know how to work in a corporate environment. In fact, he says as much in this tweet: https://twitter.com/mxcl/status/773574683518119936

You seem to be looking at this through a somewhat unusual prism.

You and I both "know how" to eat discarded food out of a trash dumpster.

But absent some truly compelling reason, we wouldn't choose to do so, right?

Re: Homebrew 1.0.0

#238

Post by a-no-n »

mikemcquaid wrote: post #178
falcolas wrote: post #162

Earlier quoted context omitted.

> we remove software Why? Personally, the only reason I would remove software from a repository is if it didn't work, impacted performance, or cost me an unreasonable amount of money/time. There's a really long tail for software packages.

In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.

How did the "royal we" arrive at this "reasoning?"

If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but-really-fucking-important packages.

Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which has matured to the point stability; there's zero functional value added in refactored code being "new." Ongoing support, adding features and keeping pace with platform compatibility are separate issues from judging code to be "inferior" despite working because it's "old." What may seem "dead" to people whom don't know about particular packages but may well just be stable and resting very quietly because it just works.

Re: Homebrew 1.0.0

#239

Post by stephenr »

sperglord wrote: post #235
freehunter wrote: post #224

Earlier quoted context omitted.

That's the reason I stopped using Homebrew and plenty of other comments have said the same thing. Maybe it's changed recently, but last time I used it (about a year ago), dependencies were not cleanly resolved in every case.

What better alternative exists?

Depends what sort of packages you want.

I used to use it for things like local installs of server-side stuff (e.g. language runtime, database server, cache server, etc) but I've moved to using vagrant (and in turn Debian, so Apt) for those things.

For dev tools such as Mercurial, Git, Autotools, etc there are first/third party .pkg installers available.

Re: Homebrew 1.0.0

#240

Post by mikemcquaid »

DeadBabyOrgasm wrote: post #222
mikemcquaid wrote: post #129

Earlier quoted context omitted.

We're attempting to merge the two projects so eventually Linuxbrew/brew can go away. It's a relatively slow process, though.

What about chromebrew [0] (homebrew for chrome os)? [0]: https://github.com/skycocker/chromebrew

It doesn't appear related so would be hard to merge.
Post reply on HN