El Capitan and Homebrew • Hacker News Board

Re: El Capitan and Homebrew

#131

Post by pjmlp » Thu, Oct 01, 2015, 1:22 PM UTC

baldfat wrote: post #98

pjmlp wrote: post #95

Earlier quoted context omitted.

Never used Homebrew, but taking ownership of /user/local as I understand it does by default, certainly isn't a 'common unix standard'.

> certainly isn't a 'common unix standard' Here I google.com it for you. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY EDIT: Why is it okay to NOT look up a Standard and be uncertain in your comments when it can be found in 20 seconds tops on the Internet?

Filesystem Hierarchy Standard is a GNU/Linux standard.

'common unix standard' is whatever POSIX states as standard.

Re: El Capitan and Homebrew

#132

Post by School-Cotton » Thu, Oct 01, 2015, 1:22 PM UTC

omegote wrote: post #101

Shit like this happens everyday and yet many regard OS X as the best development platform. Wtf?

Nobody else sells nice, super-useable, high-end UNIX personal workstations.

Agree with your point -- Apple is a developer-hostile company and their OS is bad for people whose work involves tinkering with computers. Still the best development platform, though, which is a sorry state of affairs.

Re: El Capitan and Homebrew

#133

Post by pjmlp » Thu, Oct 01, 2015, 1:23 PM UTC

baldfat wrote: post #112

dyladan wrote: post #102

Earlier quoted context omitted.

I don't see anywhere in there where it says you should take ownership of /usr/local

That is why I said I searched and got the standard for the person who said "certainly it isn't the standard." We have the ultimate resource to know the answer to any question that does have an answer. I gave this down voted "I googled it for you" because people need to just look up what the Standard is and than speak from a position of knowledge and not some vague non-answer. For the still lazy the Unix File Hierarch…

You are being downvoted because it is a GNU/Linux specific standard, not something that has been adopted by the UNIX standard, POSIX.

And no, I am not the one downvoting you.

Re: El Capitan and Homebrew

#134

Post by rhapsodyv » Thu, Oct 01, 2015, 1:25 PM UTC

Anyone having issues with macports too?

Re: El Capitan and Homebrew

#135

Post by twic » Thu, Oct 01, 2015, 1:25 PM UTC

emanuelev wrote: post #92

_b8r0 wrote: 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/.

/opt? MacPorts uses /opt/local.

Re: El Capitan and Homebrew

#136

Post by lectrick » Thu, Oct 01, 2015, 1:26 PM UTC

It does kind of make sense to me that user-owned things should kind of live in /Users/username.

Unfortunately that pattern in this case would lead to the redundant-seeming /Users/username/usr/local, but at least that's rooted to the user in the event other users don't want a "global" Homebrew install.

Also, I believe (even if it kills some ignorant build scripts) that Homebrew lets you reconfigure where this directory lives, anyway.

Re: El Capitan and Homebrew

#137

Post by quesera » Thu, Oct 01, 2015, 1:30 PM UTC

eggie wrote: post #126

massysett wrote: post #90

Earlier quoted context omitted.

I think SIP gives me more control over my machine, not less. I don't want programs installing junk into my system directories. Don't mess with what my distributor shipped me. I've had this same complaint on Linux and OS X for years: to install system wide, you are typically asked to become root, and then some random installer has free reign to wreak absolute havoc. It turns out Haskell Platform was installing symlink…

It's an unusual linux installer these days that requires root. Programs aren't going to write junk into your system directories on linux unless you give them permission to. I'm not sure how adding an additional layer of complexity on top of this will solve anything. Now, rather than asking for root, your random installer would be asking you to open up SIP permissions for it.

Privilege escalation is a real problem. SIP fixes it.

Re: El Capitan and Homebrew

#138

Post by matwood » Thu, Oct 01, 2015, 1:33 PM UTC

antouank wrote: post #41

Installed El Capitan yesterday. Process took almost half an hour. Afterwards, brew just gave me a warning to do "chown" to my usr/local. That's it. Everything works fine.

I had the same experience in the betas so I've been a little confused by all the problems people are experiencing.

Re: El Capitan and Homebrew

#139

Post by oddevan » Thu, Oct 01, 2015, 1:37 PM UTC

lsaferite wrote: post #119

eddieroger wrote: post #114

Earlier quoted context omitted.

Most Mac users will never need to do this, and the short reboot cycle is, to many, worth the extra security rootless brings. It's hardly WTF.

Being required to reboot my computer into recovery mode just to add a directory is certainly a WTF worthy situation. BTW, thanks for the down vote?

To add a directory to a system-protected directory. It's all about protecting the integrity of the installed system. If you don't like/want it, you can reboot into recovery, disable it, and leave it that way.

Re: El Capitan and Homebrew

#140

Post by drvdevd » Thu, Oct 01, 2015, 1:39 PM UTC

Osmium wrote: post #85

quotemstr wrote: post #61

Users should have full control over their own machines. System Integrity Protection is obnoxious paternalism at best, and at worst, it's just another step toward iOS-ification. If Apple keeps this up, I expect a revival of Linux desktop distributions.

> Users should have full control over their own machines. Agreed. > System Integrity Protection is obnoxious paternalism at best Couldn't disagree more. The user maintains full control: you can disable it at will, temporarily or permanently. Protections like this are becoming essential as a result of current malware threats. Thanks to System Integrity Protection, we're now much more protected against rootkits and sim…

Immediately upon reading 'csrutil disable' I thought of 'setenforce 0' and the fact that this is usually the first measure taken to deal with SELinux by many users, usually against better judgement. However this, like SELinux, begs the question: is this a good user interface design? Or simply a small stumbling block for malware authors? I suppose the devil is at least partly in the details: can a kernel exploit at runtime easily flip a few bits somewhere and disable SIP?