281–290 of 403 posts
Earlier quoted context omitted.
They'd be well advised to make this opt-in only for legal reasons. This is not going to go down well in a lot of places and they might get exposed to law suits.
Opt-in analytics are useless, unless a large part of your userbase just clicks through the entire wizard without thinking; there’s little overlap with Homebrew’s userbase
Earlier quoted context omitted.
> instead of checking out the large (and slow) homebrew/core and homebrew/taps repos I actually wanted to ask why they don't just prune the history of those repos to cut down on their clone size? OT1H, I could actually imagine some software historian being curious what flags were required to build sqlite 3.6.20 from 2009 (872f50ac61d7) but OTOH building a whole new distribution system instead of effectively git-squas…
> OTOH building a whole new distribution system instead of effectively git-squash feels weird Or even just `clone` with `--depth=1`? Just because the history exists doesn't mean you have to fetch it.
Earlier quoted context omitted.
Why does a package manager need to track their users at all? If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.
> 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…
Earlier quoted context omitted.
Homebrew doesn't "report" anything to Google, much less anything of yours (implying unique identification). This is an unnecessary editorialization. You can see exactly how Homebrew does analytics here[1], and you can see the sum total of the information collected here[2]. No identifiable information is collected or retained. [1]: https://github.com/Homebrew/brew/blob/master/Library/Homebre... [2]: https://formulae.b…
>You can see exactly how Homebrew does analytics here[1], and you can see the sum total of the information collected here[2]. No identifiable information is collected or retained. If my computer is sending data to Google then Google has my IP address and can correlate that data however they want. You simply can not claim that identifiable information isn't collected or retained unless you work for Google. I don't kno…
FTA:
> We expect to migrate entirely from Google Analytics to our self-hosted InfluxDB instance in ~90 days at which point we will remove all Google Analytics and destroy all existing data.
Earlier quoted context omitted.
What’s unethical about counting errors with no PII?
Errors are the property of the user on the system in which they occurred. Exfiltrating them without consent is unethical and oftentimes illegal, and leaks the user's IP to Google. Homebrew has no claim to them without the consent of the user. It's simple spyware. Unless you report with Tor, it's not without PII. (Homebrew also includes a unique install UUID supercookie which persists, so every analytics data point in…
Users are informed upon installation.
> IP to Google.
Lots of people seem to care. I haven't heard a reason why though.
But regardless, Homebrew is deprecating and nuking the google system, so that's nice.
Earlier quoted context omitted.
> 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…
What kind of decisions do you make based on the analytics? Do you drop unpopular packages? To me, one of the advantages of a package manager is having a huge database of long-tail packages that are just one command away. If you kept only the popular packages you might as well just have an installer that installs them all together in bulk.
Yes: Homebrew deprecates and/or disables packages if we see evidence that they're unmaintained and not actually supported on the platforms we support, or only used by a tiny fraction of users while also requiring disproportionate maintainer time (e.g. due to complex or flaky builds).
The goal is to balance conflicting user interests: 99% of users want maintainer effort focused on the top 100 (or 500, or 1000) packages, and many of those packages also require significant maintainer effort (e.g. making sure that they don't cause transitive breakages).
While I use Homebrew on my Mac — it is a major risk. I am afraid that the project is not following strict security policies and will be compromised at some point. Evil package or evil version of brew can steal or modify my data. I think this will also hurt the Mac platform. I wish Apple would invest some effort into building an App Store for cli programs. While it may be complicated for the community(require signing,…
Yes. If you install untrusted code, it can do nefarious things. No platform can save you from yourself.
Specifically, I would expect two things:
1. In general, macOS .app bundles should be able to “provide” a bin/ directory that gets added (appended, not prepended!) to your PATH while you have the package available on disk + non-quarantined. Just like .app bundles can “provide” file extension bindings that cause things to open in them. (And probably, just like with file extension bindings, you’d want to give the user the same “this is a program downloaded from the Internet…” Gatekeeper warning the first time a command-line invocation causes the user to end up running an executable from a given .app package, if the .app hasn’t yet been Gatekeeper-blessed.) Kind of surprised this hasn’t always been a thing since NeXTSTEP, actually.
(And, ideally, rather than needing to care about PATH ordering re: these applications’ exposed bin/ executables, instead make a generic system for interactively choosing preference-ordering, like Debian’s update-alternatives(1) but as a per-user runtime-bound preference.)
2. The App Store should allow at least apps that contain both GUI and CLI versions (e.g. gVim packaging its own command-line `vi`; or Sublime Text with its `subl` command) — where all the same capability-manifest sandboxing applies to the command-line executables that applies to the GUI app; and where the CLI version of the executable linker-loader is made slightly smarter re: auto-granting capabilities, such that if you e.g. pass a file or directory path as a command-line argument to a CLI program, then that CLI program should be auto-granted a capability on that file/directory during that run.
As an old hand who was around when homebrew started, I feel obliged to let people know there are alternatives. If you find brew's take-over-your-system-and-youll-thank-me approach off putting, and/or you value stability over the coolness factor, MacPorts is still alive and well ( https://www.macports.org ), and in-fact has basically all the same packages brew does. In 18 years of using MacPorts, it's never messed up…
I've been trying Nix devenv[0] and nix-darwin[1] on Mac recently and having a blast. Definitely better than the stuff I had to build around Homebrew to make development environments consistent across machines. Nix-darwin even has support to install Homebrew packages. [0] https://devenv.sh [1] https://github.com/LnL7/nix-darwin
If you aren't using home-manager[4] yet, I strongly recommend taking a look at it.
nix-darwin significantly elevates the competency of MacOS.
[1]: https://gitlab.com/jcdickinson/nix/-/tree/darwin [2]: https://gitlab.com/jcdickinson/nix/-/blob/darwin/packages/ho... [3]: https://gitlab.com/jcdickinson/nix/-/blob/darwin/flake.nix#L... [4]: https://nix-community.github.io/home-manager/
> 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…
This has been a known things for a long long time. That is on you for not knowing about it. And it isn't doing anything that you are trying to infer in your statement anyway.