Live data from Hacker News

El Capitan and Homebrew

github.com

161–170 of 298 posts

Re: El Capitan and Homebrew

#161

Earlier quoted context omitted.

I can't think of anything more standard than /usr/local/.

It's been a while since I looked into it, but I opted to stick with MacPorts rather than Homebrew in large part because I got the impression that Homebrew wanted to own /usr/local rather than sharing it with other software. (Maybe that's inaccurate?) I still occasionally compile software by hand rather than through a package manager, and /usr/local has been the default target for a system-wide install on every Unix-s…

It is possible to switch /usr/local according to [1], they state it's not recommended though.

[1] https://github.com/Homebrew/homebrew/blob/master/share/doc/h...

Re: El Capitan and Homebrew

#162
post #100

When I first read this I was a little pissed at Apple, but what if brew were to install everything to /brew? It doesn't need to install into /usr/local.

You'd run into exactly the same problem. Apple doesn't provide /brew in the default image, so something would have to create a new inode in /, and that something presumably requires SIP be disabled (assuming / is protected in SIP at least). Even if it worked, you'd be no better off than just using ~/.homebrew or something like it. Their whole reason for wanting /usr/local is that (a) /usr/local/bin is in the default…

> You'd run into exactly the same problem.

I think you misunderstand the problem. /usr/local exists in OSX, and is one of the recommended install locations for user software. But if you change the permissions on /usr/local, OSX will interpret that as damage and fix it. Homebrew does this, which is in conflict with all uses of /usr/local in Unix history.

> and (b) it can be written to by a normal user.

Critically, no. This is a security risk. A larger one back when multiuser systems were the only Unix systems, but still a risk. Violates all standards, even the ones OSX doesn't attempt to comply with.

Re: El Capitan and Homebrew

#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 libraries for various things. But then it is much more fragile when your system updates. Macports really only depends on a slice of Xcode; from time to time updates will fail to install until you open Xcode and accept whatever new license Apple has bundled with it. But you don't get key components changing out from underneath your packages due to an Apple System Update.

My bias here is that I'm a longtime happy Macports user who has tried to use homebrew repeatedly, encountered lots of failed recipes, and gone back to Macports, shaking my head at all the hype around homebrew and the fact that is has somehow become a defacto developer default despite some really sloppy, poorly thought through practices. (And I know that's harsh but for a long time they trashed Macports right in their tagline — "Is MacPorts driving you to drink?" — which just seemed gratuitous.)

Re: El Capitan and Homebrew

#164

Earlier quoted context omitted.

BSD and Linux use /usr/local, it's not universal. But /usr/local has never been writable by non-privileged users. Homebrew depends on that nonstandard and undesireable permissions model. Apple doesn't bend to accommodate an inappropriate use. Hombrew doesn't want to use a location that is outside the default PATH, and they don't want to install with proper permissions, so they purposefully misinterpret the "standard"…

A. There is no real standard here B. Apple doesn't bend, period. They don't actually care whether the use is appropriate or inappropriate. C. Blaming this on homebrew is hilarious Remind me again why i should need to reboot into recovery mode to create a directory?

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 guarantees of system integrity".]

C. See above.

You apparently have issues with SIP. That's a separate issue from the current thread, but OK. You should reboot to securely change nvram settings that will allow you to manipulate the protected zone of the file system (including /usr) because this concession to inconvenience saves you from privilege escalation attacks.

The real question is why you deleted /usr/local in the first place. It's standard OSX, and always has been. If you deleted it before SIP, but object to its absence now that SIP applies to the directory where it lives...I'm not sure how to help.

Re: El Capitan and Homebrew

#165

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…

Perhaps the easy of writing recipes, combined with good timing (Ruby was all the rage), is what made people go to homebrew.

Re: El Capitan and Homebrew

#166

Earlier quoted context omitted.

A. There is no real standard here B. Apple doesn't bend, period. They don't actually care whether the use is appropriate or inappropriate. C. Blaming this on homebrew is hilarious Remind me again why i should need to reboot into recovery mode to create a directory?

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…

Where in FHS does it specify that system and user files should be put in

    /Applications
    /Library
    /Network
    /System
    /User Information
    /Users
    /Volumes

?

Re: El Capitan and Homebrew

#167
post #86

To be fair, homebrew shouldn't need to change perms, it should follow common unix standards or at least fit in with OSX rather than require a hack. For years I've felt homebrew should really use either /opt/ or ~/.homebrew/ by default.

I can't think of anything more standard than /usr/local/.

As others have mentioned, /usr/local may be a fairly standard place to put stuff, but homebrew's permissions model changes the way /usr/local works.

Additionally, /usr/local is used by other applications, and there's no way to ensure that it isn't written over by them or by homebrew when installing or upgrading software.

Putting homebrew in /opt/homebrew means that you can have a systemwide directory that is self-contained, can have a working unix hierarchy underneath and should work.

Putting homebrew in ~/.homebrew/ lets you have a user-specific directory that is self-contained with a hierarchy underneath.

In an ideal world, homebrew would use something like /opt/* for systemwide hierarchy and ~/.homebrew for user-specific hierarchy. We don't live in an ideal world, so we just have to make do with fudges to /usr/local permissions for now.

Re: El Capitan and Homebrew

#168

Earlier quoted context omitted.

A. There is no real standard here B. Apple doesn't bend, period. They don't actually care whether the use is appropriate or inappropriate. C. Blaming this on homebrew is hilarious Remind me again why i should need to reboot into recovery mode to create a directory?

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 as far as it helps them justify whatever they want to do.

If you really want to argue from the perspective that "this is standard and that's the reason it's done", that seems awfully silly to me given the layout and other permissions of apple systems.

It's pretty non-FHS/etc to have /Applications be writable, for example.

B. let's be clear: there is outrage no matter what is changed and why, and the argument is always "it is inappropriate and dumb". So this statement is fairly independent of this change.

Re: El Capitan and Homebrew

#169

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…

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.

Re: El Capitan and Homebrew

#170
post #86

To be fair, homebrew shouldn't need to change perms, it should follow common unix standards or at least fit in with OSX rather than require a hack. For years I've felt homebrew should really use either /opt/ or ~/.homebrew/ by default.

What makes you think /usr/local isn't a 'common unix standard'?

As I can't edit the comment, I wasn't referring to the name /usr/local as much as the permissions. It'd make more sense to store systemwide hierarchy in /opt/homebrew/* and user-specific hierarchy in ~/.homebrew/* instead.
Post reply on HN