51–60 of 168 posts
MySQL. Still more popular than Postgres.
People should install stuff like their db with docker or vagrant anyhow. It'd be annoying to keep your app's db version in sync with the homebrew package.
Earlier quoted context omitted.
Imagemagick and graphicsmagick are being used for server side image manipulation. E.g when you upload your images on a server, two of the first things to be done is to delete the metadata and resize.
That makes sense, so it's to generate thumbnails/resize uploads. Could it be some node package that has a dependency on imagemagick? What I'm having trouble wrapping my head around is so many people being aware of imagemagick and reading through it's documentation to learn how to use it.
Earlier quoted context omitted.
There's significant value, when developing a product, in knowing which other products your customers are likely to have, so that you can prioritise your different integrations. Similar data could probably be compiled from Google Trends, but this clean and authoritative view is something that can be trusted, and I think the result makes the open-source ecosystem stronger.
That only sets up the value proposition for the maintainers - not for making it public. What value do any of us, not on the Homebrew maintenance team, derive from this list (other than fuel for "X is better than Y" arguments)?
Homebrew's use of analytics still bothers me; specifically, making data public like this. It was supposed to only be used for development efforts, not showing off top-1000 lists. Also, I guess this following statement is - taking the charitable option - out of date. > Homebrew's analytics are accessible to Homebrew's current maintainers. https://github.com/Homebrew/brew/blob/master/docs/Analytics.... Yeah, I know, my…
Homebrew maintainer here. That language could probably be more precise - only current maintainers have access to detailed analytics (the details being specified on that same page). I wasn't part of the creation of that particular page, but one thing we (the maintainers) commonly find ourselves doing is publicly referencing install statistics as justification for removing an unused formula or taking extra care during…
It may well be that some relatively-little-used tool nontheless has a very significant use. Popularity is one factor within the mix, but only one.
I would estimate I download tmux via homebrew once a year on average. It is possible 112,000 represents a good estimate of all mac carrying tmux users in the world [*]. For comparison this is roughly the same number as employees at Apple.
Assuming these stats aren't opt in.
Earlier quoted context omitted.
Homebrew maintainer here. That language could probably be more precise - only current maintainers have access to detailed analytics (the details being specified on that same page). I wasn't part of the creation of that particular page, but one thing we (the maintainers) commonly find ourselves doing is publicly referencing install statistics as justification for removing an unused formula or taking extra care during…
Beware the Tyranny of the Minimum Viable User. It may well be that some relatively-little-used tool nontheless has a very significant use. Popularity is one factor within the mix, but only one. https://redd.it/69wk8y
We generally only refer to popularity after a formula comes up on our radar due to failing other sniff tests. To give you an idea for some of them:
1. Multiple subsequent releases without anybody bothering to update the formula
2. Historical problems with the package (flaky builds, complex build systems)
3. Historical problems with the upstream (patches ignored, unwillingness to cooperate with packagers, unreliable download servers)
Earlier quoted context omitted.
Beware the Tyranny of the Minimum Viable User. It may well be that some relatively-little-used tool nontheless has a very significant use. Popularity is one factor within the mix, but only one. https://redd.it/69wk8y
You're right, which is why popularity isn't the sole factor in determining whether to remove a formula from the core repository. It's just one of the things we reference to justify our choice, when relevant. We generally only refer to popularity after a formula comes up on our radar due to failing other sniff tests. To give you an idea for some of them: 1. Multiple subsequent releases without anybody bothering to upd…
Since homebrew is aimed mostly at technical types and devs, build tools themselves are probably fairly highly featured, but those are easy things to lose in large general-public releases. (Android's abysmally poor shell tools come to mind.)
Sounds like a pretty good basic set. The flaky builds criterion in particular seems like a strong signal of a low-quality upstream.
Earlier quoted context omitted.
> similar to other package managers Interesting; I don't see apt, dpkg, nix, or yum maintainers releasing top lists of packages. Even the package providers rarely provide a "top" list, especially one with compile-time flags. Those flags being provided in this list are very explicit, which could be easily correlated with data provided (or harvested) by other parties. > a good way to measure the health of the Homebrew…
Debian publishes statistics gathered by the optional "popularity-contest" package at http://popcon.debian.org I can't remember whether the default is opt-out or in with the current installer.
It also doesn't sent data to a privacy abusing company like google.