Live data from Hacker News

Homebrew 1.0.0

brew.sh

221–230 of 255 posts

Re: Homebrew 1.0.0

#221

Earlier quoted context omitted.

It's hard for me to understand the issue with this. Google didn't hire the guy who wrote software that had a big impact on the community. Does it mean Google misses good engineers because of their less-than-ideal interview process, or simply Google hires only people who are a good fit for their organisation? Writing the overly bitter tweet surely won't help with improving hiring points. Seems highly unprofessional an…

Does it mean Google misses good engineers because of their less-than-ideal interview process Google intentionally prefers false negatives to false positives.

They do have false positives. Quite a bit. They just fool themselves into thinking they minimize false positives by their hiring process.

Re: Homebrew 1.0.0

#222
post #21

Earlier quoted context omitted.

I don't know much about Linuxbrew, but that looks like a fork, not Homebrew officially supporting Linux.

We're attempting to merge the two projects so eventually Linuxbrew/brew can go away. It's a relatively slow process, though.

What about chromebrew [0] (homebrew for chrome os)?

[0]: https://github.com/skycocker/chromebrew

Re: Homebrew 1.0.0

#223
post #202

Earlier quoted context omitted.

Apt is the second worst linux package manager. RPM is the first worst.

`apt` isn't that bad, really—it's been available for a year or two now, and will likely replace apt-get and friends eventually (apt-cache, dpkg, dselect, are pretty horrible user experience really). RPM hasn't been a package manager for like 10 years—now it's just a package format. `yum` and its successor `dnf` are actually fantastic package managers on Red Hat family stuff.

IMO yum is slow as molasses, feature poor and really bad at resolving conflicts. Haven't tried dnf though.

Re: Homebrew 1.0.0

#224
post #127

I've worked with mike to maintain formula for years and he is always pleasant and on top of things in what is a very hectic job. Homebrew is such a good package manager (and not for the reasons any package manager is classically considered good). It's great because the community is so vibrant, the user experience is so well thought out, and the formula dsl makes so much logical sense. It's actually both a GitHub and…

> not for the reasons any package manager is classically considered good You can say that again. Homebrew's dependency management is a fucking joke, to the point that it might as well not exist.

That's the reason I stopped using Homebrew and plenty of other comments have said the same thing. Maybe it's changed recently, but last time I used it (about a year ago), dependencies were not cleanly resolved in every case.

Re: Homebrew 1.0.0

#225

Ugh, ugh, ugh. I just tried Homebrew for the third time the other day and it made a complete mess of my /usr/local/bin and also screwed up my install of rvm ... never again will I give it a chance. Sorry, but IMO Homebrew is crufty, opinionated software with poor separation of concerns. Macports is the (objectively?) better choice for my needs.

MacPorts isn't without problems, but I can't use Homebrew. Just the message that is printed when you `brew install texlive` is a deal breaker. I don't want to manage packages separately from my package manager, that's crazy and defeats the purpose of a package manager.

Re: Homebrew 1.0.0

#226

I've had few (minor) issues with Homebrew, so I've been wondering about pkgsrc. Has anyone tried using pkgsrc, as a replacement for Homebrew?

I found pkgsrc to to be pretty great, but some of the packages are organized in odd ways and badly named. For example TexLive isn't called texlive. Same with xorg-server. I also couldn't figure out how to install Mac specific variants of things like Emacs. So I'm not giving up MacPorts anytime soon.

Re: Homebrew 1.0.0

#227

Be aware of "update bug" If Homebrew was updated on Aug 10-11th 2016 and brew update always says "Already up-to-date". you need to run: ``` cd "$(brew --repo)" && git fetch && git reset --hard origin/master && brew update ``` I had to.

Yep, had to too. They released a revision with a broken update fn? Or did they force-push?

Re: Homebrew 1.0.0

#228
post #4

Among all the software I use, Homebrew must be the one giving me the least trouble. I have 100 installed packages and I don't remember the last time anything didn't work. Plus, for anything I care about, updates seem to always take less than a day, usually it's almost instantaneous. In comparison with MacPorts before, it's like night and day. npm/pip/mix/bundler all seem to periodically conspire to waste a few hours…

So npm is bad in your opinion, because it correctly handles different dependencies on packages with varying versions, screwing up? Or is the problem the vast js ecosystem? I don't think that "tree X" can be a good argument against using any kind of package manager.

Yeah, I'm not seeing how "tree node_modules" is an argument against npm per se. Maybe one could argue npm, inc promotes the small-modules approach, but I don't think that's relevant to whether npm itself is a good package manager.

No matter whether you think small modules are good or bad, I personally have experienced npm to at least manage them well. Admittedly, however, I've never actually worked on projects of any great size.

Re: Homebrew 1.0.0

#229

Earlier quoted context omitted.

> we remove software Why? Personally, the only reason I would remove software from a repository is if it didn't work, impacted performance, or cost me an unreasonable amount of money/time. There's a really long tail for software packages.

In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.

Are the usage analytics available to package maintainers? What about in downstream taps such as Homebrew-Versions and Homebrew-Science? Would be nice to know when it comes to grant writing time.

Re: Homebrew 1.0.0

#230

Earlier quoted context omitted.

So npm is bad in your opinion, because it correctly handles different dependencies on packages with varying versions, screwing up? Or is the problem the vast js ecosystem? I don't think that "tree X" can be a good argument against using any kind of package manager.

It's just popular to hate JavaScript and npm right now. It's not perfect, but it's not bad either.

This whole "JS and it's ecosystem is the worst"-meme is just awful. Same goes for the PHP counterpart. I think it's fine to search for better solutions for our backends, but there is no denying that 1) our browsers rely on JS and will do so for the close future, and 2) that there is an ecosystem for every programming language that can use it efficiently and proficiently.
Post reply on HN