Live data from Hacker News

HomeBrew Analytics – top 1000 packages installed over last year

brew.sh

91–100 of 168 posts

Re: HomeBrew Analytics – top 1000 packages installed over last year

#91
I wish there was a decent package manager on windows too. Chocolates used to be OK but I often find outdated packages and they keep breaking the syntax of existing scripts regularly (like by making almost all packages now require the flag --allowemptychecksum). I don't know why it never really took off. This is such a practical way to setup a machine.

Re: HomeBrew Analytics – top 1000 packages installed over last year

#92
post #6

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…

Mildly unrelated question.

Why is telemetry collected through Google? I suppose that’s because they have some particularly convenient APIs, however please consider that many user are concerned by the amount of information Google has about their lifes.

(I know, it’s possible to opt out, but good choices should be the default!)

Re: HomeBrew Analytics – top 1000 packages installed over last year

#93

Earlier quoted context omitted.

ripgrep's command line is `rg`, and it's much faster. When I first installed it I aliased `ag` to it to easy the transition.

How often do you handle files large enough to observe a difference between grep, ack, ag and rg ? I'm willing to bet (and happy to lose) that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement. They are people (I'm betting fewer) who need speed above all other concerns, and those people already make it to the top 1000.

> How often do you handle files large enough to observe a difference between grep, ack, ag and rg ?

> I'm willing to bet that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement.

Daily, but not for the reasons that I think you're thinking. I work in Python a lot, which means there is typically a virtualenv in the tree somewhere, sometimes more than one. Typically, I want to search the code base itself — not a virtualenv, not the .git directory, etc. ripgrep, by default, will ignore entries in the .gitignore (and the virtualenvs are listed there, as they're not source, and cannot be committed), and repository directories like .git, and will thus not even consider those files. For my use case (searching my own code base), this is exactly what I want, and culling out those entire subtrees makes rg considerably faster than grep.

Yes — I could exclude those directories with grep by passing the appropriate flag. But it's time consuming to do so: ripgrep wins out by doing — by default — exactly what I need.

I also greatly prefer ripgrep's output format; the layout and colors make it much easier to scan than grep's.

Most of the people I've recommended ripgrep to are using grep, and passing flags to it to get it to do what essentially rg does quicker and/or by default. Ripgrep is an excellent tool.

(I used `git grep`, which is also considerably faster for similar reasons, prior to rg. But `git grep` requires a repository — for obvious reasons — and thus fails in cases where you're not in one. I often need to search several codebases when doing cross repository refactors, and ripgrep has been quite useful there.)

Re: HomeBrew Analytics – top 1000 packages installed over last year

#94

Earlier quoted context omitted.

ripgrep's command line is `rg`, and it's much faster. When I first installed it I aliased `ag` to it to easy the transition.

How often do you handle files large enough to observe a difference between grep, ack, ag and rg ? I'm willing to bet (and happy to lose) that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement. They are people (I'm betting fewer) who need speed above all other concerns, and those people already make it to the top 1000.

Depends on the size of the codebase you're grepping. I routinely deal with larger ones that I have to dissect and the difference is more than noticeable.

Re: HomeBrew Analytics – top 1000 packages installed over last year

#95
post #24

Great. Caddy is #666. Hope that's not a sign. :P

I moved from NGINX to Caddy on my raspberry pi 3 for my home needs and couldn't be happier.

The automatic LetsEncrypt stuff is great and has removed crufty cron jobs to make sure the certs are up to date, and support for HTTP/2 out the box (with 0 configuration) has seen a marked improvement in the performance of my site.

Re: HomeBrew Analytics – top 1000 packages installed over last year

#96
post #54

I'm surprised (in I guess a good way =) that awscli is all the way up at #15. Definitely expected quite a few utilities and languages to rank higher.

I saw that and wondered if these count unique installations, or simply number of times downloaded. awscli updates a lot, so if we're counting downloads, that would give it a significant boost, I think.

Re: HomeBrew Analytics – top 1000 packages installed over last year

#98
post #10

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.

I actually do this, but annoyingly for quite a few (postgres/redis), the client tools are not separate packages so you still need to install the full db locally to use them.

Re: HomeBrew Analytics – top 1000 packages installed over last year

#99

Earlier quoted context omitted.

ripgrep's command line is `rg`, and it's much faster. When I first installed it I aliased `ag` to it to easy the transition.

How often do you handle files large enough to observe a difference between grep, ack, ag and rg ? I'm willing to bet (and happy to lose) that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement. They are people (I'm betting fewer) who need speed above all other concerns, and those people already make it to the top 1000.

Every time I search in VS Code, which now uses rg by default.

You'll easily notice the difference on any recursive search. grep is really slow.

Re: HomeBrew Analytics – top 1000 packages installed over last year

#100
post #6

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…

> volunteer-run open source projects to properly respect the privacy of their users

If you don't trust us to respect your privacy why are you trusting us to download and run code from the internet on your machine?

We need analytics to effectively run the Homebrew project (as you've noted: we are volunteers). If you no longer trust our project: go use something else.

Post reply on HN