Hacker News Reader

Comment by rwl4 | Hacker News Reader

It's for this very reason that I'm still one of those old-school guys who still uses MacPorts. I was horrified to see this, and in my brief time using it, it actually caused me real problems, so I went back.

View on HN

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

[2] https://github.com/Homebrew/brew/issues/142

Wow. Thanks for bringing this to my attention. I recently got a new mac and I decided to give brew a spin as my package manager. I was unimpressed with many aspects of the experience- for example, getting weird snarky messages and incorrect advice when I attempted to install texlive- but this seals it.

Back to Macports it is. I'll be sure to tell others about this.

Been using Brew for as long as i can remember. Most of the message usually require a `brew doctor` or `brew update` command which completely fixes the issue. And i cant even remember the last time i had to do that..

When they brought in brew cask i was completely blown away and i use brew exclusively for installing almost everything on my mac.

I tried macports at first, but bailed out of that after i shot myself in the foot inside the hour. Switched to brew and have never looked back since.

i must be the only person on earth that can't get brew to work right.

every so often i'll try to install something with brew, and it just won't work. the last thing i'm trying to do on planet earth is spend 30 minutes debugging a packager on my workstation (as opposed to on servers, where i do this literally all day long), so i just don't bother.

I have never had a problem with homebrew. I think some people like one or the other better as a preference though.

Last time I used Macports, the installation procedure took about six hours of compiling all packages from source (granted, that was an Atom processor). Does it support binary packages now?

Yes.

Yes, official binary archives are available since MacPorts 2.0 in 2011. Due to restrictions by the various software licenses not all are distributable, though.

> following the Google Analytics debacle

I didn't even realize Homebrew was sending my info to Google Analytics :(. I am a huge fan of Homebrew, but they really should make this opt-in vs automatic by default.

Edit: To opt out (the second line is just for confirmation):

    $ brew analytics off
    $ brew analytics

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.

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

I've found that a lot of people here in HN and Reddit are really passionate about not being tracked, so even if it was as easy as one command, the fact that Homebrew did it at all is enough to make some people not want to use it.

Nothing wrong with that viewpoint, but I just disabled it and moved on to enjoying pretty good software.

It has nothing to do with how easy or hard it is to disable. The problem is that it doesn't ask first, or even tell you what it's doing. OK, now that I know about it, I can turn it off, but how do I know they won't do something similarly ugly in a future version?

We do tell you about it before we start recording any analytics.

You do now, after people noticed what you were doing. You didn't then, when the GA integration was originally snuck in.

Privacy violations and user tracking should always be opt-in not opt-out. If nobody opts in, one should rationalize why users may not want to be tracked or have their privacy violated and question whether making it opt-out is a good decision and respectful of their users.

Most people, myself included, never even heard about this before this point, because it's never mentioned as part of the installation or usage process and is opt-out—if you know it exists and that you might want to opt out in the first place.

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

I almost went the other way (from ports to brew) because of the complex manual procedure required to fix ports when you upgrade the OS:

https://trac.macports.org/wiki/Migration

After going through the migration, it isn't that bad, but it was surprising (horrifying?) to me that ports was completely broken after an OS upgrade.

MacPorts dev here. Problems can arise when some ports have local patches for specific versions of macOS. This might work at first, but could lead to build failures or other problems later. Some ports also hardcode the OS version into their binaries. The simple way to prevent this kind of stuff is to rebuild all ports for the new platform.

Probably there would be room for improvement, but there is only little interest by contributors. This only happens once a year and after everybody went through it, they quickly loose interest in contributing anything better for the migration process.

Reply on news.ycombinator.com