Which might break some scripts that expect home brew not to require user input. The right way to do it would be to ask if a terminal was available but in reality, scripts are not careful enough to tell applications that they are in fact headless. I've seen some scripts break under that assumption.
As in, people want privacy at the expense of volunteer time.
Simple solution: Charge people for using Homebrew who don't want to send analytics in, fund Homebrew development with those funds. Otherwise, its an external cost being foisted on the volunteers by developers who want privacy at the cost of additional volunteer time.
EDIT: The tone of this thread is the exact problem with open source projects and participation. "I want a say, but I'm not willing to contribute in any way except use your tool you're providing for free." Sad, but expected.
I think most people aren't concerned so much about sharing usage data. The problem is specifically the way it's being shared via a third party. Other apps ask if I mind sharing some data (e.g., Firefox), and I don't have a problem with that.
Okay. Is everyone going to pony up for a self-hosted analytics box and the time to manage it? No? Of course not. Everyone wants to complain, no one would contribute resources to do it though. Privacy has a high moral value (its free to want it and complain about it), but small economic value (you use Chrome? It sends everything you do back to Google. You'll still use it, because its better than not).
a HN thread is not the appropriate place to ask for resources for a project.
There are many OS projects out there with larger needs than an analytics server that have managed to get the support they need. If resources are an ongoing problem you even have the option of applying to join a free software foundation like Apache that has resources.
> join a free software foundation like Apache that has resources
There's a reciprocal arrangement here. One of the requirements of joining the Apache Software Foundation is using "Apache" when refering to the name of the software product for the first time in a new context, e.g. first mention on a webpage. Apache Groovy was promoted from Apache's incubator last November (2015), so I've been doing just that ever since. Unfortunately, many of the developers who work on Groovy don't bother, availing themselves of those resources but not giving back to the foundation the small amount asked.
Just like open-source doesn't come with warranties from the creator, it also doesn't come with obligations to the end user other than to abide by the license.
You use Homebrew. In return, you send anonymous stats to save the developers time. If you'd prefer not to, set the env var or stop using Homebrew.
Alternatively, fork it, take out the modifications, and run your own version of Homebrew. But that takes time, and effort; that same time and effort homebrew devs are trying to save with a feature. Why is your time as a user valuable but the Homebrew dev's time not?
Although if Homebrew wasn't using Google Analytics, maybe people would. It could just be a "Do you mind sending us anonymous usage data? [y/N]" prompt. Many other apps do something equivalent, and I don't mind giving it to them. The fact that those apps ask in the first place makes me much more amenable to the idea.
Or, even worse, there'd be a selection effect where the distribution of people who opt in is skewed from the total distribution of Homebrew users, ruining the dataset for any analysis one might want to do to it. There's a reason that Nielson Ratings collection isn't opt-in.
Funny, it's been quite a few years, but I remember being a Nielson family for a few months, and it was absolutely opt-in. We had to fill out a little booklet with what we were watching and data about ourselves.
Disagree. Google Analytics is a network of companies that has agreed to privately collection information about users without their permission or even knowledge. It is malware that should not be included in Homebrew. The only ethical decision we can make as developers is not to use it.
Yeah, I'll confess that this is a real deal breaker for me personally .. I'll be having a closer look at ports and maybe fink soon. Maybe after all its time to get off OSX and back to Linux, where these sorts of things happen less frequently ..
I'd assume that software that wasn't sending analytics wouldn't start doing so without at least informing me first, but I'd be wrong. I think the parents point is that we can't trust Homebrew to do the right thing, because they've now chosen not to.
Who knows!? This marks quite a change in attitude where the end user is suddenly responsible for staying on top of newly silently introduced opt-out settings. I'm pretty disappointed and feel the amount of trust I've had in the maintainers have dropped considerably. Sneakily sending random HTTP requests to third party analytics services and stuffing my dotfiles with unique identifiers for tracking purposes is not what I expected from a friendly open source project.
This could have been handled much better with some sort of opt-in prompt like the debian installer does for its popcon usage tracker.
>This marks quite a change in attitude where the end user is suddenly responsible for staying on top of newly silently introduced opt-out settings. I'm pretty disappointed and feel the amount of trust I've had in the maintainers have dropped considerably.
I agree with you. I'd much rather have this be out in the open - like, ever 5th time I run 'brew' or something, it asks me for permission to send analytics, and the options are "YES-once, YES-Always, NO-NEVER", and if I say NO, NEVER, it never asks me again.
If spying on me can be automated, so can not spying on me.
Yep, and as you can see if you read the code there are as few references to GA as possible so that it’d be easy to change the service we use without editing code everywhere.
Maybe try out Nix while you're at it, too! I'm using NixOS, and I'm pretty happy with it so far. The standalone package manager fills the same niche as Homebrew, I think.
If it means that much to you, why not add host file entries to point GA's DNS records at 0.0.0.0 or something else invalid? If you don't trust that either, supplement it with packet filter rules to drop traffic heading to the IP addresses to which those names (currently) resolve. Switching platforms seems like a major overreaction here.
Collecting telemetry is reasonably, but it seems inappropriate for Google to get a copy and to be able to identify which of their users installed a particular piece of software from the IP address.
So yes. Running their own server would be much preferable.
It's worth noting that AIP's functionality requires you to trust Google -- the data is received by them, but their design specifies that they mask it before it's processed or stored.
While I feel we should all treat Google with skepticism here, I didn't realize they (and so failed to acknowledge) that Homebrew was attempting to remedy that, so I apologize for speaking out of turn.
I think it would be, yes. At least, it would not get into the hands of an external 3rd party (that as we know, lives from selling / using data they gather from people).
"We use the information we collect from all of our services to provide, maintain, protect and improve them, to develop new ones, and to protect Google and our users. We also use this information to offer you tailored content – like giving you more relevant search results and ads."
"When you visit a website that uses our advertising products (like AdSense), social products (like the +1 button) or analytics tools (Google Analytics), your web browser automatically sends certain information to Google... When you visit websites or use apps that use Google technologies, we may use the information we receive from those websites and apps..."
Google Analytics protects the confidentiality of Google Analytics data in several ways:
Google Analytics data may not be shared without customer consent, except under certain limited circumstances, such as when required by law.
Security-dedicated engineering teams at Google guard against external threats to data. Internal access to data (e.g., by employees) is regulated and subject to the Employee Access Controls and Procedures.
For their definition of "confidential", which they can change at any time.
> certain limited circumstances
If they only intended the "required by law" example, they wouldn't use such a broad - and completely undefined - set of circumstances.
> guard against external threats
Google may have good security practices now, but an continually growing collection of highly-revealing tracking data is a very tempting target for many businesses, governments, etc. If Google (or anybody else) wants to claim that they are protecting your data, they should indemnify the subjects of their spying against any damages those caused by those "external threats".
>they should indemnify the subjects of their spying against any damages those caused by those "external threats"
I despise GA as much as the next guy, but you'd have to be pretty crazy to expect any business to provide such a guarantee. Google isn't your insurance company.
I don't really expect that anyone would make that kind of guarantee; I'm arguing in the style of a proof by contradiction. These businesses shouldn't be making this kind of claim, and they shouldn't be holding onto data beyond what is necessary. Data should be expunged as soon as possible, because then there isn't anything to protect.
Businesses are acting like there is no risk in holding personal information. When people complain, they respond with claims that the data is safe. When businesses act like they are secured and that we should trust them, we should be asking them to stand behind those claims. I agree, this is crazy, but businesses really want to make strong claims but not be bound by those claims. An honest business that actually believed in their own promises shouldn't have problem putting those promises into a formal guarantee.
> this is a decision that should be up to the user, not the webmaster.
This may be a dumb example, but if I get someone (I don't know very well) a glass of water from the kitchen, I won't take a little sip from it on the way. Yes, they might not care, and it's super unlikely that I would infect them with anything. But it's still not my call, and you only need to see someone not get something so basic once to lose a lot of trust in them, certainly if they actually start arguing about it. It's more than optional courtesy, it's a respect for boundaries and personal choices.
And it doesn't matter at all how much they are doing otherwise for you, that is orthogonal. By that I mean: nobody asked anyone to make something for free, we're just asking people to not unwittingly have them feed GA if they don't want to. If there are too many things to fix and too few developers, fix fewer things. It's just homebrew, not cancercure. If enough users disagree with that, let them all opt-in and/or volunteer their own time, problem solved either way.
We don’t have the resources for this. If you have any suggestion for a service that doesn’t require us time to manage we’d be very grateful. Homebrew have a dozen maintainers for >30 PRs & issues per day plus maintaining our own CI infrastructure plus normal development; and all of this is on our spare time.
As a Homebrew user, thanks for your efforts. I'm totally fine with the change myself, and I apologize for everyone else in here who cares about their privacy, but doesn't really care about the time volunteers are committing, nor the time savings from this feature.
So the project is short-handed, but wants to take on scouring analytics to start packaging common things people are doing with the software.
If you're too busy to do this "right" why bother? Are you hoping making more shortcuts will increase adoption?
Current employer doesn't much care about these things, but last employer did. Having shared this thread with their IT folks, they've decided to cut people off from homebrew while they figure it out.
I guess costing yourself users is one way to free up some time.
Add a feature where users can opt-in for periodic reports to be uploaded as a private gist, and a link is transmitted to you. GitHub is already a trusted party where Homebrew is concerned, so the loss of privacy is minimal. Users control their own GitHub accounts, so they control of the permanence of the data you collect on them. You can use Google Forms to transmit the links, so your infrastructure is cheap-to-free. For bonus points, encrypt the links with your public key.
I'm always amused by the way some people try to extend the definition of malware beyond its scope. This isn't malware. It's just anonymous usage tracking. If you don't like it you can turn it off. I hope you don't use a smartphone because the amount of intrinsic "malware" you must be subjected to must be unbearable.
"Malware" is an umbrella term used to refer to a variety of forms of hostile or intrusive software, including computer viruses, worms, trojan horses, ransomware, spyware, adware, scareware, and other malicious programs. It can take the form of executable code, scripts, active content, and other software.
I didn't say that this usage of GA is malware, I said that GA, the network, is a malware. So while Homebrew may (or may not) be protecting their users identities while using a malware service, they are still choosing to use a malware service.
Tracking people's online activity through a large percentage of the internet, without their consent or even knowledge qualifies as malicious to me.
But surely you can see the similarity here. The tracking software wasn't in Homebrew before, is added without asking you when you update, and is completely useless to you as a user but builds information about you and sends it to a third party.
If it's not malware, it's certainly really similar to it.
Definitions vary, but I once wrote these notes for the definition in a security policy. It is probably more broad than what some people would write.
Malware
-------
- Any software that actively attempts to do any of the following:
- Do harm to the system, applications or data
- Deliberately weakens system security
- By changing system or user security settings
- Contains or installs backdoors
- Downloads updates as executables
- Use executables to wrap otherwise readable data
- Expects higher or more privileges than is needed by it's function.
- Circumvent the wishes or intention of the user
- Makes it self the default application for file-types that already have an application assigned to them
- Inserts itself into other applications against the users expectation (eg. as a plugin)
- Uses the privileges of other applications to circumvent system policy
- Hide its activity from inspection
- Anti-debugging, and other rootkit like behaviour
- Use "dark patterns" to trick the user into performing or agreeing to some action
- Installs toolbars, etc.
- Compromise the privacy of the user
- Phones home, access data irrelevant to it's function
- Resists removal
It does not compromise the user's privacy in any way. GA prohibits PII. Also, the webmaster has to opt-in to share the data with Google in the first place.
People just LOOVE to be outraged. For example in this thread people rage about google getting hands on their data. When I point out that the webmaster has to explicitly chose to share the data with google, I get downvoted. When I say that GA prohibits the use of PII, I get downvoted. It doesn't matter that I'm right. People WANT to be outraged. Reason, no reason, doesn't matter.
It certainly appears not. They're using curl and reporting a UID they generate.
A Homebrew analytics user ID e.g. 1BAB65CC-FE7F-4D8C-AB45-B7DB5A6BA9CB. This
is generated by uuidgen and stored in ~/.homebrew_analytics_user_uuid. This
does not allow us to track individual users but does enable us to accurately
measure user counts vs. event counts
You can always even check the code that’s running on your own computer. If you installed Homebrew in /usr/local the relevant files are /usr/local/Library/Homebrew/utils/analytics.sh and /usr/local/Library/Homebrew/utils/analytics.rb.
This is the sort of defeatist and way-too-easy attitude that turns things to garbage all around. In many ways, bringing up issues that affect many opinionated people's core values is how things get fixed. If this was said for everything that was free, then we wouldn't have anything.
For example:
"Linux has issues" "It's free. Nobody's forcing you to use it."
or
"FreeBSD has issues.." "It's Free. Nobody's forcing you to use it."
or
"I had a hard time installing Gentoo because of bad documentation. Somebody should fix that. No, seriously, metaland." "It's Free. Nobody's forcing you to use it."
I'm all for "beggars can't be choosers", but when there's nothing else to choose, of course people are going to complain.
What is the mechanism in which Homebrew inserts itself into every shell session anyway? I had expected it to be loaded somewhere in some shell initialization script, such as .bashrc or .bash_profile, but I couldn't find anything.
But then, by which mechanism does Homebrew notify GA that I have opened a terminal tab? There is a curl command executed every time, and I see a connection to GA with Little Snitch.
Is there some way to see the caller of a process? htop displays no parent in the tree view.
"oconnore" is a perfectly valid unique identifier on HackerNews that doesn't tie to anything about you if you don't have your email address in your profile. This is no different.
The difference is, it's a choice to post on a public website. homebrew is a package management tool, there is no expectation that it will send information about you to Google.
This. The reasons they articulate for suddenly deciding on performing this data collection, and for doing it via GA are laughable. I am sufficiently annoyed at this because of the generation of yet another outbound data stream from my system, but the fact that in all likelihood the project will do nothing with this data really annoys me. There is zero need for this in a package system.
Maybe this is sufficiently private, maybe not. I'm not a security expert.
Maybe GA's fingerprinting heuristics are advanced enough to know that because user 1034324234 installed spacemacs at 4:01 and I visited the spacemacs documentation at 4:01 that there's a decent chance I'm user 1034324234.
Decent enough to see if the pattern happens again. After a few rounds of this, it's close enough to serve me ads based on user 1034324234's install patterns.
My reasoning? Because it's good to respect the privacy and choices of your users. Homebrew never called home to Google in the past, most people would not reasonably expect it to suddenly start doing so without letting them know.
I expect that if it was opt-in most people wouldn't take the active step to do so. And if given a choice on first-run, a large proportion of users would choose to disable the analytics reporting.
Making it opt-out seems deceitful - an attempt to trick users into leaving it enabled.
And the Homebrew developer responses thus far on the GitHub issue (users should be watching the documentation and Twitter feed - they'd have seen the announcement) seem unrealistic and unfair.
This should have been opt-in from day one, not opt-out. Especially if it's changing existing behaviour (having never automatically reported telemetry in the past).
Or, you could edit /usr/local/Library/Homebrew/utils/analytics.rb to send Google Analytics garbage (from random UUIDs) until Homebrew makes this feature opt-in.
Fair point, the public shaming that is happening now is probably punishment enough.
Frankly I don't trust the opt-out code to be (and remain) bug-free. There are, as far as I can tell from searching, no tests. So I feel more comfortable maintaining a patched version with the calls nooped instead.
I'm really having trouble understanding this (and I appear to be in a very very tiny minority). Why would it bother you if homebrew devs and Google knew which packages you had installed?
Homebrew maintainer here. Remember that we didn’t put these analytics in place to get rich or get free beer at the local pub. Screwing up the stats won’t help anyone.
We currently don’t have any overview of our userbase; we don’t even know how many people use Homebrew. More importantly, Homebrew currently only bottles the default options but we know some people use some options that cause the formulae to build from source. If tomorrow we see that e.g. `brew install foo --with-bar` is run by hundreds of people everyday we could start bottling it and saving time to everyone. But right now that’s completely dark; the only insights we have about the usage is people opening issues/PRs.
Yeah it’s not implemented yet. We’re doing it incrementally and actually started shipping the first bits one month ago (but it was opt-in for tests). Bottling the most used options is something we’re really excited both as maintainers and users and is IMO the number 1 reason these analytics will benefit everyone. We’re currently looking how it behaves and will add them soon.
The biggest benefit of this change is getting people to reconsider their usage of homebrew. For example, now I'm looking into Nix. These sorts of changes fuel competition and innovation.
I'm reminded of when Adblock Plus went sour, and we got uBlock Origin. There are lots of examples of this.
I can’t speak for all the team here but yes that’s something we’d consider. Someone suggested Keen IO on the issues tracker which is not open-source but it’s the only viable alternative that has been proposed so far, and it’s not from Google so some people would be more happy with that.
The fact that they are transparent about this, that we can opt-out if we want and that they're open source makes me feel more than comfortable sharing anonymous usage information with them. Homebrew has been amazing for me!
Is an alert displayed to the user the first time it tries to send info to Google? If not, that is far from "transparent". It's good that they tell you how to opt out on the website, but I can't remember the last time I went to the website. Probably when I first installed Homebrew on this Mac.
This. Either everyone should be notified before the first google analytics transmission so that they can choose to opt in our out. Or the default should be off and maybe on new installs they can choose to opt in. At the opt in/out dialog (when you give the users a choice) you can make the default to opt-in, but having the default as opt-in without any input from the user is bad form. It is similar to spammers calling your e-mail address "double opt-in" because they got you to open an e-mail and you didn't click the unsubscribe link.
How should this be handled if the software in question is a server daemon? I want the users to make an explicit choice but it's not obvious what's the best way to do that.
I feel like on update would be better. Answering a yes/no/never isn't that much of an ask, I don't think. And that way you get a chance to use the software before you have to make a decision.
Or if you want to cover existing users, just ask during the first interactive invocation, when there is no prior user chosen setting (works for new installs too)...
pseudocode:
choice = no
if $brew_prefix/etc/homebrew.yaml:
choice = read analytics $brew_prefix/etc/homebrew.yaml
else:
if interactive-tty and cmd != "--prefix":
choice = ask-user "enable anonymous analytics (it helps us!)? Y/N: "
write analytics=<choice> $brew_prefix/etc/homebrew.yaml
if choice == yes:
enable-analytics
I brew updated a few times today and finally got that message. By the time that message showed up, the file ~/.homebrew_analytics_user_uuid was already 4 hours old, which makes me wonder when they actually started doing the analytics
I updated Homebrew almost daily and my .homebrew_analytics_user_uuid shown that it was created on Apr 24[1], which means I have been sending the analytics data without knowing for two days already (UTC+7) :-\
Get littlesnitch on Mac and you won't need to rely on third parties alerting about outgoing connections, although I recon the when we're talking about something like homebrew it's not easy to vet every single outgoing connection.
Still littlesnitch is really awesome for the privacy conscious users.
For posterity, Homebrew is using curl to talk to Google Analytics. You will have to selectively block curl by destination in Little Snitch (or only allow the various other hosts Homebrew uses).
In a similar vein, installing uMatrix makes you (rightfully) paranoid about what web pages are collecting from you. "Wait I can disable 28 Javascript scripts and iframes and the page loads OK?"
Only if you let them.
I have installed little snitch and the only applications that have unlimited access to the Internet (all servers on port 80/443) are my web browsers. The other applications barely have access to their on servers (only if I find it necessary for them to auto-check for updates) let alone google analytics.
To achieve the best security, you should disable most bultin rules or customize them yourself.
Many of the requests come from various services that I don't feel knowledgeable enough to disable. Like gamed, iTunes etc. no easy way to figure out if something is phoning home or a (close to) critical OS X service.
Could you point to a source which would help me educate myself?
Well, blocking OS X from phoning home is probably impossible or at best very dangerous (because you block all of OS X's anti-virus blacklists).
But most other processes are easy to block. The first thing you should do is check the name of the process. If it is something like iTunes, you need to ask yourself if you want iTunes to have Internet (do you want Apple Music/radio, wifi sync, and the iTunes Store? If not, just block all ports/servers for iTunes. If you only want Wifi sync, enable connections to the local network only (best do it manually in the rule settings). If you want iTunes to have Internet, I'd allow port 80 and 443 to apple servers and apples CDN (you will end up having ~15 rules, just allow the servers as you see fit and when prompted). Since iTunes is from Apple, it uses some system services to communicate with iCloud additionally, by default they are all enabled and you don't have to do anything.
All essential system processes are allowed by default. I personally disabled most of them since I don't need most of them. Let's have a look at gamed. gamed is a system process to communicate with the Game Center services. If you want Game Center to work, you will also need to enable this process. You can learn that by yourself if you click at the question mark on the bottom left corner when an alert pops up. It shows additional information for all system applications, and most popular apps. If it says that this process is needed for Game Center but you don't play any games on your Mac, it is safe to disable.
You can do that for all processes and eventually work out a list with trusted services and applications. I personally often only allow some applications Internet to port 80 and 443 and only if I know the apps really need it. If you don't trust the app at all, you should update it manually (by downloading the newest version on their website).
I block the google analytics at DNS level at home. However, don't use a Google product such as Chrome as it will totally ignore your DNS settings. There is also an issue of some webpages not loading because its waiting for google analytics to finish loading. So I normally re-direct the data to an internal server in my net that captures all the traffic, which will allow the server to finish loading (also allows me to replace image Ads with Jolly Rogers images).
The issue with this is that the DNS settings only apply at home. And most mobile devices totally ignores the DNS settings as well, using the one provided my my carrier instead.
This is a very single-user-centric view. Some of us have Macs with many hundreds of users.
And so .. It is too invasive of my .bashrc/.profile that I have to use it to disable spy activity. I'd rather brew just have its own flag somewhere that says "Don't ever send analytics, ever, for any user on this system.."
You would still need to do it for every user, anytime you create a new one. I fail to see how that's any different from, say `echo "export HOMEBREW_NO_ANALYTICS=1" >> .bashrc`
Of course, the better alternative IS for it to be opt-in, which it should be.
.. makes brew responsible for it. There is a big difference. Some of us don't want to have to maintain yet another .bashrc file tweak just to have a safe and sane environment.
I hope the homebrew guys will pay attention to this issue.
That's basically the main reason why I left MacPorts. The other was the fact that they'd build their own version of already installed programs. The worst offender for a long time was tetex until they finally added support for looking at an existing tetex installation.
I also ran into a number of broken ports. I had used Fink, but I ran into issues with its packaging too. So, when I heard about Homebrew, I decided to try it. It's been pretty decent for me so I've stuck with it. The only major issue I've had has been related to Octave, but that's been a problem for MacPorts too as the OS X version isn't as up to date as the Linux version at times.
> Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby?
Yes, I must admit I chose the word "antiquated" quite intentionally, as Homebrew seems to get so much attention (for now) because it's written in Ruby and the website (http://brew.sh/) is shiny, rather than technical merits.
> It was nice back then. Packages didn't install themselves in /usr/local.
You might enjoy Nix, then -- for that reason, and the following:
1. Everything is stored in /nix/store -- nothing ever touches /{local,}/{bin,lib,share}
2. Profiles are symlink forests that merge multiple packages into one FSH[1]-like tree -- each link pointing into /nix/store. When you install a package, a new symlink forest is created replacing the one at ~/.nix-profile (your user profile, being the default). If you request that nix rollback to a previous "generation" of your profile, all Nix has to do is replace the ~/.nix-profile link to instead point at the previous generation's symlink forest (you can think of this as bumping HEAD in git -- it's nearly instantaneous). If upgrading a package goes wrong, just rollback.
3. Because Nix knows the entire dependency graph, its trivial to distribute a build plan across multiple machines (you can set this up to happen by default)
4. We have a continuous integration server (Hydra[2]) that builds and signs all of our packages. Of course, there's nothing stopping you from building from source (or you could run your own Hydra instance, if you so wish).
The purpose of /usr/local is for you to put stuff there, but it actually causes a lot of problems if a package manager does it.
- your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it
- build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to
Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly.
Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?
I think you must have ignored a substantial portion of my comment. Let's take a look at what (part of) my Nix store looks like (you'll see it fundamentally looks nothing like /usr/local):
Note that each package under /nix/store is its own prefix; that is, it contains its own bin, lib, share, etc.
/usr/local is a dumping ground "for use by the system administrator when installing software locally"[1]. If you need multiple versions of automake installed: tough luck, the paths collide. If you need multiple versions of Erlang: tough luck, the paths collide.
Would you like to be able to rollback your system by changing one symlink[2]? Too bad: when you last installed packages into /usr/local, your package manager clobbered the previous version.
Technically, we could make /usr/local a symlink forest pointing into /nix/store, but we don't: we want to make sure that only the packages we explicitly declared are picked up by build tools, rather than defaulting to searching through the currently "installed" packages.
> /nix/store? Really? You can't just make up new root level directories. That's so wrong.
Can you substantiate your claim? Note that "it doesn't feel right" doesn't count as a rational criticism.
[2]: This probably sounds like a bold claim. I tried to explain how this works above, but if you don't believe me, feel free to ask and I'll explain further. Alternatively, feel free to read the first paragraph here: http://nixos.org/nix/manual/#sec-profiles
Funny that you should mention the FHS. From that same document:
Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.
They really should be using /opt:
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree
Aren't the majority of Homebrew users on Mac OS X? Does Nix work on Mac OS X?
Don't get me wrong: Homebrew is impressive in how many bad ideas it has implemented in a project that is so exceedingly popular; good marketing and ease of use are amazingly powerful. I thoroughly dislike Homebrew, and sincerely hope people choose not to use it, at all (but especially not on servers).
And, also don't get me wrong: I really like Nix, and I believe it has mostly right decisions across the board. If I had my druthers, Nix would be what our near-term package management future looks like.
But, if we're talking about Mac (and gods I hope there aren't a lot of people using Homebrew on other Operating Systems, particularly Linux, where we have an embarrassment of riches in terms of good, even great, package managers), I suspect recommending pkgsrc would be a better near term solution. It is more mature on OS X, and it has more packages than Nix. And, while it is not as modern as Nix, it is an acceptable package manager on most fronts, and doesn't exhibit Homebrew's alarming lack of foresight on security questions.
In short: I like Nix a lot. I dislike Homebrew a lot. So, we're agreed on those points. But, for Mac OS X users looking for a better alternative to Homebrew, pkgsrc seems to be the current best choice (Fink is poorly maintained, macports is slightly better maintained, but pkgsrc is a better package manager).
Here's why I don't like Homebrew, and why I believe Nix is (almost) strictly an improvement over it:
1. Updating packages is not safe. If I update openssl and the ABI changes, all of my currently installed packages that depend on it are now broken -- time to rebuild everything. I've burned way too many hours on ABI breakage and rebuilding everything. That problem can't happen with Nix because Nix will ensure that each library is linked precisely to the versions of the libs they need.
2. Nix has a continuous integration server (called Hydra[1]) that builds every package, and caches the binaries. Because Nix knows each packages entire dependency graph, Hydra only needs to build just the packages that have changed. When I want to update some packages, I can count on not having to rebuild everything myself. Each binary package is signed, so I know my stuff is coming from the build server, regardless of whether or not I get the files through a cache or third party. I can also run my own Hydra instance to build my OS X and Linux packages, and I can share the binaries with others should I wish.
3. The lack of determinism. With Nix on OS X, packages are built using OS X's native Sandbox APIs to ensure that the build process can only see the dependencies that were explicitly specified. This guarantees that if the build works on my machine, it will work on yours -- whereas I've seen brew formulas under-specify configure flags and such, resulting in the default of linking to non brew installed libraries, causing quite a bit of confusion when things don't work at run time, or just flat out fail to build.
4. Brew is OS X specific. Nix works on OS X, Linux, and a FreeBSD. As someone who deploys to Linux virtual servers, it's nice that I can use the same versions of packages both in development and production.
It's not all roses, though. We have a smaller community of OS X users at this point, so not everything works (thus my "almost" qualification). Regarding the underlying tech and the outlook for the future, Nix is a superior tool.
I wrote a blog post a while back about my experiments with Homebrew, which covers most of the major security concerns I have with it. I hope it's clear from the post (linked below) that I went into the process with an open mind, and even positive expectations, because so many people really like Homebrew. But, I was alarmed at the implications of some of the decisions they've made; I understand why they made the design choices they made, but I don't think the trade off is even close to worth it. It is, as noted, particularly scary for server use, but I would be hesitant to use it for any purpose.
After that post was written, I continued to tinker with Homebrew (because it is so popular, it was really hard to completely toss it aside), but found a number of other problems. While it has lots of packages and they are often very up to date, updating over time and upgrading/downgrading versions, both proved fragile.
In a world with so many really good package managers, I find it unfortunate that the one that captured so many people's imagination and enthusiasm is broken by design, and in ways that have been understood for decades (even before good package managers, it was understood that you don't run all your servers as the same user). Or, at the very least, cannot ever be a general purpose package manager for operating systems; if you understand the limitations and know you can never safely deploy to servers using Homebrew, and only ever use it on private development laptop/desktop systems, then I won't judge. I understand it is easy to use, has a lot of packages, and has a lot of good documentation. Those are good things.
Anyway, I'm a packaging nerd. It's a thing I'm weirdly passionate about (I've contributed patches to yum in the distant past, have been a maintainer of packages for all sorts of operating systems and OSS and commercial projects, and I maintain the package repositories for my company's products and projects). I have strong opinions, but they are based on much (much!) more than average experience; over the past two decades I've spent a lot of time building packages (for Linux, Windows, Mac OS X, Solaris, FreeBSD, etc.). It may even be the technical area I have spent the most time on, since it's been consistent across nearly every company and project I've ever worked for/on. Homebrew strikes me as a huge step backward.
Could you elaborate what you dislike most about home brew? I only don't like that they refuse to package old versions, although they are still supported by the author and quite popular (I'm looking at you Python).
Furthermore, it often leaves deprecated APIs on my computer without offering to upgrade them (because other packages rely on them).
"[...] we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us [...]"
Isn't this a false dichotomy? Why can't other measures be used that don't require "resources" to do "detailed user studies" yet don't require on-by-default information capturing? Surely there are many open source projects that persist to make their users happy without this information, correct?
Isn't this the same info they'd get if they ran their own registry like every other package manager (instead of using GitHub)? In the grand scheme of things, this seems pretty minor to me.
See, that's why I am a diehard macports user.
/opt/local and not /usr/local.
No cross pollution with my own configure && make && make install packages, nicely separated and maintained.
I don't mind homebrew collecting anonymous information about me but I do not want Google to get even more information about me (and since the ip address I use with homebrew is the same I use to surf the web, the information is not anonymous for Google).
Thanks for the link! I have been using http://winhelp2002.mvps.org/hosts.htm for many years but it looks like StevenBlack's file is more comprehensive and updated more frequently.
Just used this list to set up DNS blocks on my network (DD-WRT/DNSmasq forcibly handles DNS traffic, with a bash script to add IPv6 hosts entries). Seems to work well so far.
As I see more applications try and hit remote ad servers, I feel even better that I'm blocking all of these ad servers with my /etc/hosts file using https://github.com/StevenBlack/hosts. The update will be a no-op from my machine.
Would really prefer it to be opt-in instead of opt-out as others have said. Sharing the info with Homebrew is one thing, the GA borg-malware is another entirely. Something like that should require an explicit request. At least in the browser, I can blacklist all requests with uBlock.
Atom does the same thing and I'm not a fan. You have to explicitly remove the analytics 'package'. Soon every piece of software will be reporting, silently.
Tonight I'm going to read about pkgsrc and tomorrow give a try. It has active community last time I used it few years ago. Seems to have also binaries available at http://pkgsrc.joyent.com/install-on-osx/
My quick notes on how to get started with pkgsrc
More info: http://pkgsrc.org/
http://wiki.netbsd.org/pkgsrc/pkgsrc_64bit_osx/
# Download pkgsrc
curl -O https://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc.tar.bz2
# validate shasum
$ curl -O https://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc.tar.bz2.SHA1
$ cat pkgsrc.tar.bz2.SHA1
$ shasum pkgsrc.tar.bz2
# extract pkgsrc archive. Mine lives at ~/Work and I also install built packages under Work.
$ tar jxvf pkgsrc.tar.bz2
# bootstrap
$ cd pkgsrc/bootstrap
$ ./bootstrap --abi=64 --prefer-pkgsrc=yes --unprivileged --compiler=clang --prefix="$HOME/Work/pkg"
# append prefix/bin to your PATH
$ cat ~/.bash_profile
export PATH="$PATH:$HOME/Work/pkg/bin"
# re-login to make PATH effective
# Example build of dos2unix (poor example because lots of dependencies like perl...)
$ cd pkgsrc/converters/dos2unix/
$ bmake install
...
===> Installing binary package of dos2unix-7.3.3
$ file ~/Work/pkg/bin/dos2unix
/Users/petri/Work/pkg/bin/dos2unix: Mach-O 64-bit executable x86_64
I love the knee-jerk hostile reactions to any sort of phoning home by an application. They've provided extensive explanations on what is collected, why they're collecting it, who has access, what it's for, and even the code that does the actual collecting and it still isn't enough for people.
While I'm against this type of thing typically, this information is exactly what someone who is concerned about it needs to see, and if they don't want to be involved they include the opt-out on the very same page. I don't see how this could get any better, this could be held up as a gold standard for Microsoft and Google moving forward.
This type of data is invaluable to developers, I can't tell you how frustrating it is that so many people now refuse to share it because of overblown privacy concerns. The data is anonymized and no one cares enough about what you're doing to de-anonymize it.
There are real threats to your privacy out there and spending time on stuff like this just adds to the noise.
Your arguments are ridiculous. Humans judge; we're good at it. Burn us enough times with false promises of privacy or outright lies and yes, we will learn to become very skeptical and untrusting. You're asking people to continue trusting a system that has proven to be working against users' best interests for a long time.
The data is not sufficiently anonymized. Your public IP address is sent to Google and--the burden of proof is on Google to prove this doesn't happen--there is nothing stopping Google from comparing that data to other requests they get from the same IP address (say, from your browser). Maybe Google can't personally identify me from this data, but they can sure target me with ads, which--shock--make them money.
Here's a quick and dirty way to opt out for BASH and ZSH users for easy copy/pasting.
BASH:
cat <<EOF >> .bashrc
# Opt out of Homebrew analytics
export HOMEBREW_NO_ANALYTICS=1
if [[ -e "$HOME/.homebrew_analytics_user_uuid" ]]; then
rm -f "$HOME/.homebrew_analytics_user_uuid"
fi
EOF
ZSH:
cat <<EOF >> .zshrc
# Opt out of Homebrew analytics
export HOMEBREW_NO_ANALYTICS=1
if [[ -e "$HOME/.homebrew_analytics_user_uuid" ]]; then
rm -f "$HOME/.homebrew_analytics_user_uuid"
fi
EOF
Good call. I was mainly using `-f` to suppress the prompt about deleting the file, but you're correct, it's unnecessary to have the if statement in this case.
You don’t need to remove that file; the whole point of this env variable is that it stops Homebrew from sending any data. It won’t even be created if that variable is set.
That's only true if the variable is set before the first instance when data would have been sent, otherwise the file will exist (as it did on my system).
AFAIK, Max Howell was rejected from a position at Google, and now his trademark making use of Google? Let him take a look at GNU.ORG; if he can see any GA code.
328 comments
[ 3.4 ms ] story [ 301 ms ] threadThe right thing to do would be to make it opt in, not opt out. (Which would not be without precedent. Debian's popcon is opt-in.)
They could have a prompt with a countdown, you opt in it you don't say 'no' after a minute.
Simple solution: Charge people for using Homebrew who don't want to send analytics in, fund Homebrew development with those funds. Otherwise, its an external cost being foisted on the volunteers by developers who want privacy at the cost of additional volunteer time.
EDIT: The tone of this thread is the exact problem with open source projects and participation. "I want a say, but I'm not willing to contribute in any way except use your tool you're providing for free." Sad, but expected.
There are many OS projects out there with larger needs than an analytics server that have managed to get the support they need. If resources are an ongoing problem you even have the option of applying to join a free software foundation like Apache that has resources.
There's a reciprocal arrangement here. One of the requirements of joining the Apache Software Foundation is using "Apache" when refering to the name of the software product for the first time in a new context, e.g. first mention on a webpage. Apache Groovy was promoted from Apache's incubator last November (2015), so I've been doing just that ever since. Unfortunately, many of the developers who work on Groovy don't bother, availing themselves of those resources but not giving back to the foundation the small amount asked.
Alternatively, fork it, take out the modifications, and run your own version of Homebrew. But that takes time, and effort; that same time and effort homebrew devs are trying to save with a feature. Why is your time as a user valuable but the Homebrew dev's time not?
http://popcon.debian.org/
This could have been handled much better with some sort of opt-in prompt like the debian installer does for its popcon usage tracker.
I agree with you. I'd much rather have this be out in the open - like, ever 5th time I run 'brew' or something, it asks me for permission to send analytics, and the options are "YES-once, YES-Always, NO-NEVER", and if I say NO, NEVER, it never asks me again.
If spying on me can be automated, so can not spying on me.
Its, of course, always your choice if you're willing to trade it for something.
Do you think money or privacy violations must be part of the equation to make good software?
That is like the old argument against free/open software that I heard from a lot of people, back in the 90's. I thought we were past that.
Don't let the door hit you on the way out. No one will miss you!
So yes. Running their own server would be much preferable.
> The Google Analytics anonymous IP setting is enabled i.e. 1 (https://developers.google.com/analytics/devguides/collection...)
I'm not sure if they use it to improve their ad products, but I wouldn't be surprised if the answer is no.
Secondly, do you have a source for that? I find that a very dubious claim, from a business perspective.
https://www.google.com/intl/en/policies/privacy/
"When you visit a website that uses our advertising products (like AdSense), social products (like the +1 button) or analytics tools (Google Analytics), your web browser automatically sends certain information to Google... When you visit websites or use apps that use Google technologies, we may use the information we receive from those websites and apps..."
https://www.google.com/policies/privacy/partners/
It should be noted this does not directly contradict what GP claims.
"""
Google Analytics protects the confidentiality of Google Analytics data in several ways:
Google Analytics data may not be shared without customer consent, except under certain limited circumstances, such as when required by law.
Security-dedicated engineering teams at Google guard against external threats to data. Internal access to data (e.g., by employees) is regulated and subject to the Employee Access Controls and Procedures.
"""
https://support.google.com/analytics/answer/6004245?hl=en
For their definition of "confidential", which they can change at any time.
> certain limited circumstances
If they only intended the "required by law" example, they wouldn't use such a broad - and completely undefined - set of circumstances.
> guard against external threats
Google may have good security practices now, but an continually growing collection of highly-revealing tracking data is a very tempting target for many businesses, governments, etc. If Google (or anybody else) wants to claim that they are protecting your data, they should indemnify the subjects of their spying against any damages those caused by those "external threats".
I despise GA as much as the next guy, but you'd have to be pretty crazy to expect any business to provide such a guarantee. Google isn't your insurance company.
Businesses are acting like there is no risk in holding personal information. When people complain, they respond with claims that the data is safe. When businesses act like they are secured and that we should trust them, we should be asking them to stand behind those claims. I agree, this is crazy, but businesses really want to make strong claims but not be bound by those claims. An honest business that actually believed in their own promises shouldn't have problem putting those promises into a formal guarantee.
Yet you do seem to expect that guarantee:
> An honest business that actually believed in their own promises shouldn't have problem putting those promises into a formal guarantee.
You can't use such guarantees to vet businesses because no sane company would meet your requirements!
This may be a dumb example, but if I get someone (I don't know very well) a glass of water from the kitchen, I won't take a little sip from it on the way. Yes, they might not care, and it's super unlikely that I would infect them with anything. But it's still not my call, and you only need to see someone not get something so basic once to lose a lot of trust in them, certainly if they actually start arguing about it. It's more than optional courtesy, it's a respect for boundaries and personal choices.
And it doesn't matter at all how much they are doing otherwise for you, that is orthogonal. By that I mean: nobody asked anyone to make something for free, we're just asking people to not unwittingly have them feed GA if they don't want to. If there are too many things to fix and too few developers, fix fewer things. It's just homebrew, not cancercure. If enough users disagree with that, let them all opt-in and/or volunteer their own time, problem solved either way.
But nobody actually cares that much, only enough to complain. At length.
Do you want to share data with google to imrpove our products?
Do you want to pool your data for benchmarking purposes?
Both are unchecked by default. But here you go, I will search for "google analytics data sharing" for you.
https://support.google.com/analytics/answer/1011397?hl=en
If you're too busy to do this "right" why bother? Are you hoping making more shortcuts will increase adoption?
Current employer doesn't much care about these things, but last employer did. Having shared this thread with their IT folks, they've decided to cut people off from homebrew while they figure it out.
I guess costing yourself users is one way to free up some time.
How does that sound?
"Malware" is an umbrella term used to refer to a variety of forms of hostile or intrusive software, including computer viruses, worms, trojan horses, ransomware, spyware, adware, scareware, and other malicious programs. It can take the form of executable code, scripts, active content, and other software.
Tracking people's online activity through a large percentage of the internet, without their consent or even knowledge qualifies as malicious to me.
If it's not malware, it's certainly really similar to it.
If software compromises my privacy, I feel that I have been betrayed and lost something that I can not take back.
If you don't get to automatically participate in a "anonymous" usage survey, have you lost something you can not undo?
That in my opinion, is why software should always err on the side of privacy.
...anyway, complaining about getting downvoted is a surefire way to keep getting downvoted :P
Requiring the user to set an environment variable to opt out is smarmy.
Of course, you have to trust homebrew, but hell, you're already running their software, so it's a little late.
For example: "Linux has issues" "It's free. Nobody's forcing you to use it."
or
"FreeBSD has issues.." "It's Free. Nobody's forcing you to use it."
or
"I had a hard time installing Gentoo because of bad documentation. Somebody should fix that. No, seriously, metaland." "It's Free. Nobody's forcing you to use it."
I'm all for "beggars can't be choosers", but when there's nothing else to choose, of course people are going to complain.
Is there some way to see the caller of a process? htop displays no parent in the tree view.
Keep in mind that no personal info is ever sent. Just a random UUID.
> Just your universally unique id
...
This. The reasons they articulate for suddenly deciding on performing this data collection, and for doing it via GA are laughable. I am sufficiently annoyed at this because of the generation of yet another outbound data stream from my system, but the fact that in all likelihood the project will do nothing with this data really annoys me. There is zero need for this in a package system.
How is a Homebrew UUID personal info?
Maybe this is sufficiently private, maybe not. I'm not a security expert.
Maybe GA's fingerprinting heuristics are advanced enough to know that because user 1034324234 installed spacemacs at 4:01 and I visited the spacemacs documentation at 4:01 that there's a decent chance I'm user 1034324234.
Decent enough to see if the pattern happens again. After a few rounds of this, it's close enough to serve me ads based on user 1034324234's install patterns.
:shrug: doesn't sound crazy to me.
I expect that if it was opt-in most people wouldn't take the active step to do so. And if given a choice on first-run, a large proportion of users would choose to disable the analytics reporting.
Making it opt-out seems deceitful - an attempt to trick users into leaving it enabled.
And the Homebrew developer responses thus far on the GitHub issue (users should be watching the documentation and Twitter feed - they'd have seen the announcement) seem unrealistic and unfair.
This should have been opt-in from day one, not opt-out. Especially if it's changing existing behaviour (having never automatically reported telemetry in the past).
Any rubyists want to provide a patch to do this?
use their opt-out if you want
Frankly I don't trust the opt-out code to be (and remain) bug-free. There are, as far as I can tell from searching, no tests. So I feel more comfortable maintaining a patched version with the calls nooped instead.
We currently don’t have any overview of our userbase; we don’t even know how many people use Homebrew. More importantly, Homebrew currently only bottles the default options but we know some people use some options that cause the formulae to build from source. If tomorrow we see that e.g. `brew install foo --with-bar` is run by hundreds of people everyday we could start bottling it and saving time to everyone. But right now that’s completely dark; the only insights we have about the usage is people opening issues/PRs.
I'm reminded of when Adblock Plus went sour, and we got uBlock Origin. There are lots of examples of this.
pseudocode:
[1]: https://files.grid.in.th/plBnTi.png
Still littlesnitch is really awesome for the privacy conscious users.
Also, Microsoft really needs to clean up their domain usage, because it takes 999 permission rules to run Office.
To achieve the best security, you should disable most bultin rules or customize them yourself.
Could you point to a source which would help me educate myself?
But most other processes are easy to block. The first thing you should do is check the name of the process. If it is something like iTunes, you need to ask yourself if you want iTunes to have Internet (do you want Apple Music/radio, wifi sync, and the iTunes Store? If not, just block all ports/servers for iTunes. If you only want Wifi sync, enable connections to the local network only (best do it manually in the rule settings). If you want iTunes to have Internet, I'd allow port 80 and 443 to apple servers and apples CDN (you will end up having ~15 rules, just allow the servers as you see fit and when prompted). Since iTunes is from Apple, it uses some system services to communicate with iCloud additionally, by default they are all enabled and you don't have to do anything. All essential system processes are allowed by default. I personally disabled most of them since I don't need most of them. Let's have a look at gamed. gamed is a system process to communicate with the Game Center services. If you want Game Center to work, you will also need to enable this process. You can learn that by yourself if you click at the question mark on the bottom left corner when an alert pops up. It shows additional information for all system applications, and most popular apps. If it says that this process is needed for Game Center but you don't play any games on your Mac, it is safe to disable.
You can do that for all processes and eventually work out a list with trusted services and applications. I personally often only allow some applications Internet to port 80 and 443 and only if I know the apps really need it. If you don't trust the app at all, you should update it manually (by downloading the newest version on their website).
The issue with this is that the DNS settings only apply at home. And most mobile devices totally ignores the DNS settings as well, using the one provided my my carrier instead.
http://unix.stackexchange.com/questions/117467/how-to-perman...
And so .. It is too invasive of my .bashrc/.profile that I have to use it to disable spy activity. I'd rather brew just have its own flag somewhere that says "Don't ever send analytics, ever, for any user on this system.."
Doesn't it have its own global config? I confess that I'm too miffed by this intrusion in my privacy to be bothered to find out ..
What I want:
There, now I don't have to think about it any more, nor maintain a .profile/.bashrc, nor do it every single time for every user.Of course, the better alternative IS for it to be opt-in, which it should be.
>>>`echo "export HOMEBREW_NO_ANALYTICS=1" >> .bashrc`
.. makes me responsible for it. This:
>>> brew analytics no-never
.. makes brew responsible for it. There is a big difference. Some of us don't want to have to maintain yet another .bashrc file tweak just to have a safe and sane environment.
I hope the homebrew guys will pay attention to this issue.
https://news.ycombinator.com/item?id=9695102
He works at Apple.
http://nixos.org/nix
https://github.com/NixOS/nixpkgs
https://blog.errright.com/switching-from-homebrew-to-nix/
It was nice back then. Packages didn't install themselves in /usr/local.
I also ran into a number of broken ports. I had used Fink, but I ran into issues with its packaging too. So, when I heard about Homebrew, I decided to try it. It's been pretty decent for me so I've stuck with it. The only major issue I've had has been related to Octave, but that's been a problem for MacPorts too as the OS X version isn't as up to date as the Linux version at times.
Yes, I must admit I chose the word "antiquated" quite intentionally, as Homebrew seems to get so much attention (for now) because it's written in Ruby and the website (http://brew.sh/) is shiny, rather than technical merits.
> It was nice back then. Packages didn't install themselves in /usr/local.
You might enjoy Nix, then -- for that reason, and the following:
1. Everything is stored in /nix/store -- nothing ever touches /{local,}/{bin,lib,share}
2. Profiles are symlink forests that merge multiple packages into one FSH[1]-like tree -- each link pointing into /nix/store. When you install a package, a new symlink forest is created replacing the one at ~/.nix-profile (your user profile, being the default). If you request that nix rollback to a previous "generation" of your profile, all Nix has to do is replace the ~/.nix-profile link to instead point at the previous generation's symlink forest (you can think of this as bumping HEAD in git -- it's nearly instantaneous). If upgrading a package goes wrong, just rollback.
3. Because Nix knows the entire dependency graph, its trivial to distribute a build plan across multiple machines (you can set this up to happen by default)
4. We have a continuous integration server (Hydra[2]) that builds and signs all of our packages. Of course, there's nothing stopping you from building from source (or you could run your own Hydra instance, if you so wish).
[1]: http://www.pathname.com/fhs/ [2]: http://nixos.org/hydra/
/nix/store? Really? You can't just make up new root level directories. That's so wrong.
- your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it
- build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to
Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly.
Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?
I think you must have ignored a substantial portion of my comment. Let's take a look at what (part of) my Nix store looks like (you'll see it fundamentally looks nothing like /usr/local):
Note that each package under /nix/store is its own prefix; that is, it contains its own bin, lib, share, etc./usr/local is a dumping ground "for use by the system administrator when installing software locally"[1]. If you need multiple versions of automake installed: tough luck, the paths collide. If you need multiple versions of Erlang: tough luck, the paths collide.
Would you like to be able to rollback your system by changing one symlink[2]? Too bad: when you last installed packages into /usr/local, your package manager clobbered the previous version.
Technically, we could make /usr/local a symlink forest pointing into /nix/store, but we don't: we want to make sure that only the packages we explicitly declared are picked up by build tools, rather than defaulting to searching through the currently "installed" packages.
> /nix/store? Really? You can't just make up new root level directories. That's so wrong.
Can you substantiate your claim? Note that "it doesn't feel right" doesn't count as a rational criticism.
[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...
[2]: This probably sounds like a bold claim. I tried to explain how this works above, but if you don't believe me, feel free to ask and I'll explain further. Alternatively, feel free to read the first paragraph here: http://nixos.org/nix/manual/#sec-profiles
Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.
They really should be using /opt:
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree
Don't get me wrong: Homebrew is impressive in how many bad ideas it has implemented in a project that is so exceedingly popular; good marketing and ease of use are amazingly powerful. I thoroughly dislike Homebrew, and sincerely hope people choose not to use it, at all (but especially not on servers).
And, also don't get me wrong: I really like Nix, and I believe it has mostly right decisions across the board. If I had my druthers, Nix would be what our near-term package management future looks like.
But, if we're talking about Mac (and gods I hope there aren't a lot of people using Homebrew on other Operating Systems, particularly Linux, where we have an embarrassment of riches in terms of good, even great, package managers), I suspect recommending pkgsrc would be a better near term solution. It is more mature on OS X, and it has more packages than Nix. And, while it is not as modern as Nix, it is an acceptable package manager on most fronts, and doesn't exhibit Homebrew's alarming lack of foresight on security questions.
http://pkgsrc.org
In short: I like Nix a lot. I dislike Homebrew a lot. So, we're agreed on those points. But, for Mac OS X users looking for a better alternative to Homebrew, pkgsrc seems to be the current best choice (Fink is poorly maintained, macports is slightly better maintained, but pkgsrc is a better package manager).
1. Updating packages is not safe. If I update openssl and the ABI changes, all of my currently installed packages that depend on it are now broken -- time to rebuild everything. I've burned way too many hours on ABI breakage and rebuilding everything. That problem can't happen with Nix because Nix will ensure that each library is linked precisely to the versions of the libs they need.
2. Nix has a continuous integration server (called Hydra[1]) that builds every package, and caches the binaries. Because Nix knows each packages entire dependency graph, Hydra only needs to build just the packages that have changed. When I want to update some packages, I can count on not having to rebuild everything myself. Each binary package is signed, so I know my stuff is coming from the build server, regardless of whether or not I get the files through a cache or third party. I can also run my own Hydra instance to build my OS X and Linux packages, and I can share the binaries with others should I wish.
3. The lack of determinism. With Nix on OS X, packages are built using OS X's native Sandbox APIs to ensure that the build process can only see the dependencies that were explicitly specified. This guarantees that if the build works on my machine, it will work on yours -- whereas I've seen brew formulas under-specify configure flags and such, resulting in the default of linking to non brew installed libraries, causing quite a bit of confusion when things don't work at run time, or just flat out fail to build.
4. Brew is OS X specific. Nix works on OS X, Linux, and a FreeBSD. As someone who deploys to Linux virtual servers, it's nice that I can use the same versions of packages both in development and production.
It's not all roses, though. We have a smaller community of OS X users at this point, so not everything works (thus my "almost" qualification). Regarding the underlying tech and the outlook for the future, Nix is a superior tool.
http://inthebox.webmin.com/homebrew-package-installation-for...
After that post was written, I continued to tinker with Homebrew (because it is so popular, it was really hard to completely toss it aside), but found a number of other problems. While it has lots of packages and they are often very up to date, updating over time and upgrading/downgrading versions, both proved fragile.
In a world with so many really good package managers, I find it unfortunate that the one that captured so many people's imagination and enthusiasm is broken by design, and in ways that have been understood for decades (even before good package managers, it was understood that you don't run all your servers as the same user). Or, at the very least, cannot ever be a general purpose package manager for operating systems; if you understand the limitations and know you can never safely deploy to servers using Homebrew, and only ever use it on private development laptop/desktop systems, then I won't judge. I understand it is easy to use, has a lot of packages, and has a lot of good documentation. Those are good things.
Anyway, I'm a packaging nerd. It's a thing I'm weirdly passionate about (I've contributed patches to yum in the distant past, have been a maintainer of packages for all sorts of operating systems and OSS and commercial projects, and I maintain the package repositories for my company's products and projects). I have strong opinions, but they are based on much (much!) more than average experience; over the past two decades I've spent a lot of time building packages (for Linux, Windows, Mac OS X, Solaris, FreeBSD, etc.). It may even be the technical area I have spent the most time on, since it's been consistent across nearly every company and project I've ever worked for/on. Homebrew strikes me as a huge step backward.
Isn't this a false dichotomy? Why can't other measures be used that don't require "resources" to do "detailed user studies" yet don't require on-by-default information capturing? Surely there are many open source projects that persist to make their users happy without this information, correct?
Lately though, I've came across many packages that are available for Homebrew but not for macports.
[1] http://macports.org/
- Anonimizing IP address.
- Explaining what data is collected, and why
- A way to optout
Something that could be better:
- Make this optout for new users and opt-in for existing users?
- Notify the user in some manner when the data is sent to GA for the first time?
- Change the uuid every X period of time to make things more privacy friendly.
[Edit: wording]
Atom does the same thing and I'm not a fan. You have to explicitly remove the analytics 'package'. Soon every piece of software will be reporting, silently.
Not ethically written, free software. You would never see this behavior from a GNU program.
https://github.com/Homebrew/brew/blob/master/share/doc/homeb...
While I'm against this type of thing typically, this information is exactly what someone who is concerned about it needs to see, and if they don't want to be involved they include the opt-out on the very same page. I don't see how this could get any better, this could be held up as a gold standard for Microsoft and Google moving forward.
This type of data is invaluable to developers, I can't tell you how frustrating it is that so many people now refuse to share it because of overblown privacy concerns. The data is anonymized and no one cares enough about what you're doing to de-anonymize it.
There are real threats to your privacy out there and spending time on stuff like this just adds to the noise.
The data is not sufficiently anonymized. Your public IP address is sent to Google and--the burden of proof is on Google to prove this doesn't happen--there is nothing stopping Google from comparing that data to other requests they get from the same IP address (say, from your browser). Maybe Google can't personally identify me from this data, but they can sure target me with ads, which--shock--make them money.
BASH:
ZSH: Cheers.