Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

El Capitan and Homebrew

github.com

Post reply on HN
Print view View original

171–180 of 298 posts

Re: El Capitan and Homebrew

#171

Post by quesera »

DannyBee wrote: post #168
quesera wrote: post #164

Earlier quoted context omitted.

A. /usr/local has never ever been writable by a nonprivileged user. Every standard that exists, including the principle of least surprise, is emphatic on that point. The security implications of "any other way" are massive. B. If Linus or the FHS changed their ways in this, there would be outrage. It's inappropriate and just plain dumb. [edit: I shouldn't have said "dumb", please replace with "in violation of all gua…

A. Single user systems are not the same as server systems, and plenty of single user systems have had the equivalent of /usr/local as writable. If you want to argue this security is worth it, that's a different argument. I suspect most people who just want to get shit done are going to find it a huge pain in the ass. You can also argue these people are stupid. As for standards, vendors follow FHS and friends exactly…

A. OSX is not a single user system. It inherits from various Unixes, and no Unix has ever had nonprivileged writability on any directory under /usr.

FHS does not apply to OSX in any way. Why do people think so?

Also, /Applications is not writable by nonprivileged users either!

Agreed on ~"changes yield outrage", but in this case, it's just a software application vendor violating obvious historical and specific guidelines from software OS vendor, and people blaming OS vendor when things break. This perplexes me.

Re: El Capitan and Homebrew

#172

Post by joshmoz »

mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy.

I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return.

Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.

Re: El Capitan and Homebrew

#173

Post by robbles »

mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't compiling.

Re: El Capitan and Homebrew

#174

Post by cdonnellytx »

mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. SIP doesn't block /opt; if it did, MacPorts would also have broken, sudo or no sudo.

Re: El Capitan and Homebrew

#175

Post by tptacek »

quesera wrote: post #171
DannyBee wrote: post #168

Earlier quoted context omitted.

A. Single user systems are not the same as server systems, and plenty of single user systems have had the equivalent of /usr/local as writable. If you want to argue this security is worth it, that's a different argument. I suspect most people who just want to get shit done are going to find it a huge pain in the ass. You can also argue these people are stupid. As for standards, vendors follow FHS and friends exactly…

A. OSX is not a single user system. It inherits from various Unixes, and no Unix has ever had nonprivileged writability on any directory under /usr. FHS does not apply to OSX in any way. Why do people think so? Also, /Applications is not writable by nonprivileged users either! Agreed on ~"changes yield outrage", but in this case, it's just a software application vendor violating obvious historical and specific guidel…

You might just as productively argue that there is no such thing as a modern single-user system, since Windows isn't that either. His point is pretty clear.

OTOH: The debate here is a little confusing. What SIP is doing w/r/t/ /usr/local isn't unprecedented; securelevels and the immutable flag could have the same effect on OpenBSD all the way back in the 1990s.

Re: El Capitan and Homebrew

#176

Post by tptacek »

quesera wrote: post #169
alextgordon wrote: post #166

Earlier quoted context omitted.

Where in FHS does it specify that system and user files should be put in /Applications /Library /Network /System /User Information /Users /Volumes ?

FHS does not apply to OSX. Never has, never will.

He's asking because you brought FHS up.

Re: El Capitan and Homebrew

#177

Post by mmastrac »

robbles wrote: post #173
mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

Ditto. And Homebrew's policy of avoiding installation of built-in packages by default means that you don't accidentally break your whole system when MacPorts shadows a critical core package.

Re: El Capitan and Homebrew

#178

Post by icebraining »

coldtea wrote: post #153
icebraining wrote: post #80

Earlier quoted context omitted.

Why would they run as root, just because they were owned by root? Only brew itself would need to run as root (just like most package managers do anyway).

> Why would they run as root, just because they were owned by root? Because "sudo" (that OP wants to run them with) runs them as root by default?

OP wants to run it (ie, brew) with sudo, not them.

Re: El Capitan and Homebrew

#179

Post by quesera »

tptacek wrote: post #175
quesera wrote: post #171

Earlier quoted context omitted.

A. OSX is not a single user system. It inherits from various Unixes, and no Unix has ever had nonprivileged writability on any directory under /usr. FHS does not apply to OSX in any way. Why do people think so? Also, /Applications is not writable by nonprivileged users either! Agreed on ~"changes yield outrage", but in this case, it's just a software application vendor violating obvious historical and specific guidel…

You might just as productively argue that there is no such thing as a modern single-user system, since Windows isn't that either. His point is pretty clear. OTOH: The debate here is a little confusing. What SIP is doing w/r/t/ /usr/local isn't unprecedented; securelevels and the immutable flag could have the same effect on OpenBSD all the way back in the 1990s.

> You might just as productively argue that there is no such thing as a modern single-user system, since Windows isn't that either. His point is pretty clear.

Correct, and nonprivileged users can't install software globally on Windows either. Because it's now a modern OS, and that's how things are done. For very good reasons.

His point, as far as I can tell, amounts to: applications should be able to trash permissions on convenient directories and not have the OS complain or repair their damage.

Perhaps I'm being ungenerous here? I apologize if so.

On re read, I realize that tptacek is responding only to the SIP part of the discussion. OK, SIP is surprising to desktop computer users. But it's a good feature that requires a little adjustment to work with. But really not much, and none for the vast majority of users who don't muck with system directories.

Re: El Capitan and Homebrew

#180

Post by mapgrep »

robbles wrote: post #173
mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

> reliant on 10 different additions to my PATH and environment variables

MacPorts adds exactly two directories to the $PATH: export PATH=/opt/local/bin:/opt/local/sbin:$PATH

No new environment variables are added. The only required environment variable tweak is the PATH one above.

(In a corner case, where you have modified your MANPATH in your bash profile, which almost no one does, you may want to add another variable for man pages, but normally this works fine out of the box without an env var. The other optional env var is for versions of OS X older than 10.5.)

(FWIW, I've had the opposite experience — MacPorts rarely fails, every time I need to switch to Homebrew, several times now, I get a fail right out of the gate with whatever thing wasn't available or not working on MacPorts.)

Post reply on HN