Live data from Hacker News

Homebrew 1.1.0

brew.sh

131–140 of 216 posts

Re: Homebrew 1.1.0

#131
post #113

Earlier quoted context omitted.

We don't require you to take ownership of any directories that already exist when macOS is installed (i.e. `/usr/local` subdirectories but not `/usr/local` itself). Regardless of whether we should have picked another path, changing now would require rebuilding all our binary packages and that's a lot of effort with little return and almost certain breakages.

I haven't done a clean install of OS X in a long time, but I'm pretty sure /usr/local/bin exists. But even if it doesn't I don't find this a compelling argument. Having /usr/local/bin owned by root is a universally accepted standard in the unix world, and with very good reason: having /usr/local/bin owned by a user introduces security risks.

I believe /usr/local/bin is empty on a fresh install.

Re: Homebrew 1.1.0

#132
post #37

Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?

Here is one more reason I use MacPorts, because it never does crap like this:

   $ brew search x11
   x11vnc
   Error: GitHub API Error: API rate limit exceeded for 0.0.0.0. (But here's the good n ews: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
   Try again in 54 minutes 49 seconds, or create a personal access token:
     https://github.com/settings/tokens
   and then set it as HOMEBREW_GITHUB_API_TOKEN.

Re: Homebrew 1.1.0

#133

Earlier quoted context omitted.

Agreed. Homebrew has saved countless hours for developers, I can't believe how many hours I used to spend installing/updating different versions for testing. Now we just run (>brew switch package version) done.

Whoaaa didn't know that command. This could replace something like say nvm?

It probably could.

But I'm not sure if brew has everything or is updated faster than nvm.

Re: Homebrew 1.1.0

#134
post #51

Earlier quoted context omitted.

brew update I just tried `brew upgrade` but that is upgrading not itself, but every package installed with it instead. >:-&

brew update should do it. You might be using too-old a version or hit an update bug. Try: cd $(brew --repo); git fetch; git reset --hard origin/master; brew update

Thanks for this comment, it fixed my update problems.

Re: Homebrew 1.1.0

#135
post #108

Earlier quoted context omitted.

> Why is this a really bad idea for a personal machine? It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root. > What's th…

Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Also you can actually install it wherever you like, this is just the default/recommended location: https://github.com/Homebrew/brew/blob/master/docs/Installati...

Other than being in a different directory, what difference is that going to make?

Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.)

You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.

Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise.

Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.

Re: Homebrew 1.1.0

#136
post #12

Earlier quoted context omitted.

/usr/local is explicitly for user/administrator managed software versus /usr being for system managed stuff, it's the correct location for this on any UNIX/POSIX-like system.

Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts. For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade co…

Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts.

The multiuser features are used to provide defense in depth, especially for developer machines.

For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade computers, there's only one thing to copy over.

Apple's migration tool and cloning have always worked for me.

Re: Homebrew 1.1.0

#137
post #43

Earlier quoted context omitted.

I still use macports! As for why, there are a couple of reasons. First, Macports is often the fastest at updating their ports database after new versions of an upstream are released. Next, I also like that Macports doesn't really rely on anything OS-X specific except for Xcode. So I don't need to worry about crap like whether some Python package will work with Apple's Python distribution, or whether installing a new…

> I don't need to worry about crap like whether some Python package will work with Apple's Python distribution This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO…

This is also exactly why i use MacPorts. It works. It doesn't do silly stuff. It's been consistently solid for years.

Today, i got into a fight with Homebrew because i wanted to use a second user account on my laptop. I have one primary account, and another i use when doing workshops with clients, so i don't accidentally show them my sekrit files. The only way to get brew to install things without making trouble was to sudo -i to my primary account in a shell.

Don't get me started on "brew install docker" vs "brew cask install docker".

That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.

Re: Homebrew 1.1.0

#138
post #132
post #37

Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?

Here is one more reason I use MacPorts, because it never does crap like this: $ brew search x11 x11vnc Error: GitHub API Error: API rate limit exceeded for 0.0.0.0. (But here's the good n ews: Authenticated requests get a higher rate limit. Check out the documentation for more details.) Try again in 54 minutes 49 seconds, or create a personal access token: https://github.com/settings/tokens and then set it as HOMEBRE…

How often are you querying GitHub's API from your local machine?

Re: Homebrew 1.1.0

#139
post #49

Disabling sha1 does not seem like a good decision. There are still enough upstream software projects that only publish their checksums as sha1 or even only md5. Keeping the original checksum allows quick comparison that a Formula is meant to use the same tarballs that were published by upstream. The problems of algorithms such as sha1 or md5 can be remedied by an additional strong checksum in the Formula. Checksum ca…

Homebrew does, in fact, always use its own strong additional checksum (sha256) in the individual Formulae for all downloaded resources.

Re: Homebrew 1.1.0

#140
post #132

Earlier quoted context omitted.

Here is one more reason I use MacPorts, because it never does crap like this: $ brew search x11 x11vnc Error: GitHub API Error: API rate limit exceeded for 0.0.0.0. (But here's the good n ews: Authenticated requests get a higher rate limit. Check out the documentation for more details.) Try again in 54 minutes 49 seconds, or create a personal access token: https://github.com/settings/tokens and then set it as HOMEBRE…

How often are you querying GitHub's API from your local machine?

I've encountered that error too. Sometimes, I am just seeing if stuff I want to play with are out there in brew land.
Post reply on HN