Live data from Hacker News

Homebrew 3.0

brew.sh

461–470 of 516 posts

Re: Homebrew 3.0

#461

I realize this is a bit counter to the thread title but can someone who’s familiar with macports give their take on whether it’s worth using both brew + macports at once is a good idea? I’ve been solely using brew and very much appreciate the convenience but I saw that macports allows multiple versions of a single package which has been a pretty big pain point for me with brew. It doesn’t happen super often but there…

Homebrew and MacPorts tend to not do well because Homebrew installs itself to /usr/local, which is on PATH by default and can cause strange build failures for other things. However, with the new prefix it might be possible to do this better now.

Re: Homebrew 3.0

#462
post #417

One thing I haven't seen mentioned here is that Homebrew forced people use Ruby to write formulas (ie packages), whereas MacPorts forced people to use Tcl. This one decision, plus hosting formulas on Github, was a major contributor to their present success. As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebre…

It reminds me about this answer from Homebrew's creator, Max Howell, on Quora[1]: > I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly. > Is it any surprise I couldn’t answer their heavily computer-science questions well? > On the other hand, my softwa…

I am using brew because it works, as simple as that. If in 99% of cases I can type "brew install stuff" and it installs stuff, I am happy. Does it have outliers? Sure, as pretty much any other software, sometimes it breaks. But it delivers environment where I can install stuff without wasting my time on boring crap like figuring out how to build it and resolve conflicts with other crap - it's enough for me. Even if it only does that in 99% of cases, still much better than not having it.

Re: Homebrew 3.0

#463
post #453

Earlier quoted context omitted.

Apps that silently transmit your activity without consent are spyware. It's an objective evaluation.

What makes you think it happens silently or without your consent?

Silently: it does not print any indication it is transmitting activity data when it does so.

Without consent: it does so automatically, without prompting the user to opt-in to such spying.

Re: Homebrew 3.0

#464

Earlier quoted context omitted.

Stop calling names and searching for lies where there are none. I didn't bother explaining that all, because I assumed people coming here are already Homebrew users, as those who are usually already know that all. It's just pity to see where is it going[0][1]… -- [0] Regarding spyware: https://github.com/Homebrew/brew/blob/master/Library/Homebre... [1] Regarding the forceful approach to unshallowing, they just chose…

Re. [0]: how does anonymous telemetry (number of unique installs per package) constitute spyware? Re. [1]: GitHub pays the bills for (a large part of) the infrastructure we’re using. They reached out to us, explained the problem and asked us to unshallow. Honestly, what would you have done instead of complying?

Ad "Re. [0]": If some program is calling a third party without explicitly asking the user in the first place (especially when we're talking about a compromised company such as Google), that's spyware. Debian has solved it in a user-friendly manner in their ``popcon``: they just ask you kindly if you want to report stats to them. It's hard for me to imagine someone putting opt-in telemetry in good will…

Ad "Re. [1]": It's pretty obvious that there are people who cannot afford "unshallowing"; one would expect at least a command line switch for "power users", even if it was to be called ``--i-am-a-stubborn-jerk-and-i-am-fine-with-generating-excessive-load-on-github-infrastructure``. I'm sure that GH would be satisfied. :)

Re: Homebrew 3.0

#465

Earlier quoted context omitted.

I completely disagree with this comment. Not to mention the comments to his Quora answer, suggesting he should try a TPM position... people are so out of touch. The main problem is that he went through the standard interview process. To prevent bias you need to maintain a consistent interview process and bar. All interviewers in big tech have annual trainings about this. If someone underperforms it's considered bad j…

This seems off - based on most interactions Googlers and especially ex-Googlers, arrogance must be a practical requirement to work there.

From the many folks I know there the arrogance is learned once you join (and exceptionally easy to do so), but it's not a pre-requisite.

Re: Homebrew 3.0

#466

I don't understand if there are implications to upgrading to homebrew 3.0 for me a lowly user. Will things break? Will I lose access to formulae that haven't yet been upgraded to work with brew 3.0? Should I upgrade right away or hold off for a while? Which is least likely to interupt my workflow in which I count on brew just working?

Homebrew will automatically update the next time you use the install, tap, update, or upgrade command, unless you have HOMEBREW_NO_AUTO_UPDATE set to 1

Re: Homebrew 3.0

#467
post #376

Earlier quoted context omitted.

There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.

How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?

I've never had an issue with it. I just add ~/brew/bin to my PATH and everything works fine.

Re: Homebrew 3.0

#468
post #376

Earlier quoted context omitted.

There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.

It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.

Are you sure about that? I currently have it installed in ~/brew and commands link from ~/brew/Cellar into ~/brew/bin and there is a .git directory in ~/brew. I used to put it in /usr/local and it irked me that there was a /usr/local/.git. That was the main reason I stopped putting it there.

Re: Homebrew 3.0

#469
post #376

Earlier quoted context omitted.

There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.

How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?

I'm upgrading right now on Big Sur, and everything was installed from pre-built binaries; nothing was compiled locally.

Re: Homebrew 3.0

#470

Earlier quoted context omitted.

Homebrew maintainer here: I'm sorry that we don't meet your expectations. Two things for your consideration: 1. It's uniquely visible among system package managers. When people have problems with a package in `apt` or `dnf`, they find a community or third-party repository for the package or bug the upstream directly. By contrast, Homebrew has always been visible on GitHub, does not require a special login to a bugtra…

Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.

Apple has always been pretty cavalier with breaking things and also full of NIH syndrome. It works for point-n-click users which don't care which hardware or software they are clicking as long as it's shiny and pointy and clicky. But if you're a developer that cares about the OS plumbing, let alone relies on parts of it, Apple is not going to do you any favors.

The thing is efforts like homebrew is basically the only thing that keeps Apple platforms as a viable developer's platform (without it it'd be intolerable, as Apple has zero official solutions for managing software not coming in pointy-clicky Appstore packaging) - and given that macs are still popular among many developers, it's a mystery why Apple corporate pays so little attention to it. It's like they sold a car without any tires and wouldn't even acknowledge the existence of tire manufacturers, let alone how vital they are for the actual users of the product.

Post reply on HN