41–50 of 168 posts
Someone super needs to turn that list into an expanded version with a 2 line summary of each line. I found myself tabbing out to google constantly like 'fdk-aac, wow, that's a thing? cool~'
> brew info fdk-aac was querying locally with this.
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…
> as justification for removing an unused formula This does not, in my mind, help the case at all. This culture of deletion makes no real sense to me; something not being used for a month or a year doesn't mean it's not being used at all. What's the real cost of just leaving those formula around? A slight problem with it not working immediately when it is used? At least then it can be fixed, instead of seeing the "No…
I'm surprised that ripgrep is so low, at #227. I've been using it instead of grep the last few months and I could never go back. Check it out if you haven't! Here is the repo and a technical breakdown by the author: https://github.com/BurntSushi/ripgrep http://blog.burntsushi.net/ripgrep/
ripgrep wasn't released until late September last year or so, so it's missing a couple months of events based on that. Plus, it needed time to become popular. :-) Thanks for the kind words!
Earlier quoted context omitted.
> as justification for removing an unused formula This does not, in my mind, help the case at all. This culture of deletion makes no real sense to me; something not being used for a month or a year doesn't mean it's not being used at all. What's the real cost of just leaving those formula around? A slight problem with it not working immediately when it is used? At least then it can be fixed, instead of seeing the "No…
maintain burden. betroth and the fact that git/GitHub really doesn't like huge dirs.
(It's pretty easy to contribute your own formulas, too! The checklist is pretty small.)
That said, I've occasionally run into a broken `brew cask install X`, so I get that maintenance is a thing. But in that situation it seems best to let someone else notice that and contribute a patch rather than remove it entirely. I understand that might eventually lead to a large percentage of broken casks though.
Earlier quoted context omitted.
I'm curious why releasing data in this fashion is troubling? It think this kind of public data sharing in an open-source project is good, since it builds transparency. A top-N list seems like a good way to measure the health of the Homebrew ecosystem, similar to other package managers. Without any other identifiable information like email addresses, it seems near impossible to de-anonymize statistical usage from this…
> 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…
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…
> as justification for removing an unused formula This does not, in my mind, help the case at all. This culture of deletion makes no real sense to me; something not being used for a month or a year doesn't mean it's not being used at all. What's the real cost of just leaving those formula around? A slight problem with it not working immediately when it is used? At least then it can be fixed, instead of seeing the "No…
Maintenance.
When unused and unmaintained projects and formulae pile up in Homebrew, we end up spending a tremendous amount of time and effort patching mostly unused software for a very small part of the userbase. That dis-proportionality hurts the 95% of users who expect timely and well-tested updates to major packages.
We used to provide a "boneyard" tap for unused/unmaintained formulae, but even that led to a lot of requests for support that we simply can't provide. If something is being removed from the core tap, our current recommendation is to put it a personal tap[1].
> The culture of deletion surrounding the long tail of digital artifacts just doesn't make any sense.
Keep in mind that the "artifacts" in question are still available, since Homebrew and all Homebrew taps are just Git underneath. You might not be able to build an old formula for compatibility reasons, but all prior work is available for reference.
[1]: https://github.com/Homebrew/brew/blob/master/docs/How-to-Cre...
Can someone explain the popularity of imagemagick on there? As in, are that many people tinkering with graphics via the command-line?
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.
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.
I'm curious why releasing data in this fashion is troubling? It think this kind of public data sharing in an open-source project is good, since it builds transparency. A top-N list seems like a good way to measure the health of the Homebrew ecosystem, similar to other package managers. Without any other identifiable information like email addresses, it seems near impossible to de-anonymize statistical usage from this…
> 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…
I can't remember whether the default is opt-out or in with the current installer.
Earlier quoted context omitted.
maintain burden. betroth and the fact that git/GitHub really doesn't like huge dirs.
I've been delighted to install casks using `brew cask install X` where X is some obscure program that I thought brew cask would never have bothered adding. Stuff like that dazzled me about brew cask, so I hope it never goes away even under the guise of maintenance burden. (It's pretty easy to contribute your own formulas, too! The checklist is pretty small.) That said, I've occasionally run into a broken `brew cask i…
In the best case, the community does pick up the work of patching and maintaining formulae (and casks). However, that's the best case, and low-volume formulae rarely fall into it.
In my experience, formulae tend to get abandoned by the upstream that originally submitted them, causing them to eventually break when the system or surrounding dependencies change. One potential solution is to have a chain of custody for formula maintenance, but that hasn't worked so well for MacPorts.
Can someone explain the popularity of imagemagick on there? As in, are that many people tinkering with graphics via the command-line?