
El Capitan and Homebrew - juanfatas
https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md#if-usrlocal-does-not-exist
======
mapgrep
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.)

~~~
joshmoz
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.

~~~
msbarnett
For a while at least, when Homebrew was getting popular, MacPorts seemed
highly moribund and destined to be abandoned. It seems to have recovered some
life since then, though.

Homebrew got big in the ruby community first -- I distinctly remember trying
to get Rails to work with MacPorts' MySQL install and the whole thing turning
into a clusterfuck, and then someone introducing me to homebrew where the
whole thing just worked smoothly because every other Rails dev was walking the
same path.

Homebrew exploded among ruby devs because adding new recipes to it was a
couple of orders of magnitude easier (just write a few lines in a simple ruby
DSL and send a pull request on Github) than MacPorts (hack about in bash cruft
and then, what, open a ticket somewhere with a patch to ask for someone with
an SVN commit bit to commit it, I guess?

~~~
teacup50
Nothing really changed in terms of MacPorts liveliness; development continued
as it always had, and Homebrew has gradually learned _why_ MacPorts adopted
the solutions it did -- usually the hard way.

Homebrew's popularity was built on incredibly negative (and often dishonest)
marketing that painted MacPorts as old and busted.

For example, Homebrew touted the security advantages of not using sudo, as
compared to MacPorts, ignoring the fact that:

1) MacPorts dropped privileges when performing port builds to an unprivileged
user, providing generally _higher_ security than running with the current
user's full permissions.

2) MacPorts has _always_ also supported non-root installations that didn't
require sudo.

~~~
briandear
Dishonest marketing? Really? Homebrew, a free tool was out spreading lies
about MacPorts? That's ridiculous. When pretty much every major Ruby shop uses
Homebrew, why would I want to kick around with MacPorts? I trust Thoughtbot,
Pivotal, etc, far more than the two guys actually using MacPorts. Perhaps
Homebrew 'won' in that particular community because it was better, ever
considered that? Wide community adoption is a far bigger incentive to use a
tool over potentially trivial conceptual disagreements.

~~~
teacup50
> _Dishonest marketing? Really? Homebrew, a free tool was out spreading lies
> about MacPorts? That 's ridiculous._

Ridiculous? Homebrew's marketing tagline was "MacPorts driving you to drink?
Try homebrew!". The (obviously uninformed) slams of MacPorts and Fink didn't
stop there.

It was the first time I'd ever seen negative marketing against a competing OSS
project.

> _When pretty much every major Ruby shop uses Homebrew, why would I want to
> kick around with MacPorts?_

That wasn't the case then, was it?

> _I trust Thoughtbot, Pivotal, etc, far more than the two guys actually using
> MacPorts._

Yes, this is the kind of specious negative marketing Homebrew specialized in.

> _Perhaps Homebrew 'won' in that particular community because it was better,
> ever considered that?_

Sure, I considered that. Then I objectively reviewed Homebrew's claims.

~~~
shadowmint
> obviously uninformed...

Perhaps you never didn't use macports or fink a few years back?

They were terrible.

Perhaps, now, they're slightly better, but there was a time about oh... 2
years ago, when macports specifically actually made me want to punch my
computer.

I can't speak for anyone else, but I _can_ say, that for me, personally, every
complaint leveled against them was absolutely spot on.

------
alex1
I'm curious to know if there's a reason everyone installs Homebrew in
/usr/local (other than it being the default installation path). I've always
chosen to install it in ~/.homebrew and haven't had any problems. Everything I
install with Homebrew seems to handle an alternative prefix without issue.

~~~
eloisant
That's a common Unix practice to put system-wide stuff manually managed (as
opposed to managed by the OS/distribution) in /usr/local.

~~~
alex1
Yep, I agree and that's where I install stuff on everything other than OS X.
One distinction though, I think, is that most of the stuff I install on OS X I
don't want to be available system-wide. I'm (typically) not using Homebrew to
install daemons that run all the time or things that serve critical
system/network functions, so I've never seen a reason to make them available
to the entire system. I agree that goes against the Unix way but I started
preferring this way of using Homebrew after I had similar problems upgrading
and even updating OS X.

Also, what if for some reason a single machine is shared by two people and
they need different versions of some programs installed with Homebrew?
Installing everything in /usr/local isn't going to look like a good idea then.

~~~
Camillo
It's not going to look like a good idea even if they need the same version.
You're not supposed to run homebrew as root; it runs as your own user instead.
If two users try to install things with homebrew in the same directory, you're
going to end up with some things owned by one user and some things owned by
the other, and things will start failing pretty soon.

A while ago I floated the idea of having a separate, low-privilege "brew" user
that installs things, with the brew command automatically switching to that
user, but there was no interest.

------
iuguy
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.

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

~~~
Steuard
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-style system that I've used in the past
20-ish years.

(Also, my wife and I both have active accounts on my machine, which makes me
uneasy having files in a systemwide directory like /usr/local owned by one
specific user. That also feels distinctly non-standard to me.)

~~~
omribahumi
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...](https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Installation.md#alternative-
installs)

~~~
halostatue
I have used ~/.brew for years—it means that I have to do a slightly custom
install every time I move to a new machine—but have never had a problem with
it.

------
antouank
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.

~~~
cbhl
I think the bigger headache will be the next time you buy a new Macbook with
El Capitan or later installed on it, because you'll need to do a song and
dance to create the /usr/local directory in the first place.

~~~
lsaferite
A simple 'sudo mkdir /usr/local' won't work with SIP?

~~~
lsaferite
Wow... I just re-read the page and saw what you have to do to create
/usr/local and that is insane. Reboot into recovery mode?!? W.T.F?

~~~
eddieroger
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.

~~~
lsaferite
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?

~~~
oddevan
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.

~~~
Karunamon
The integrity of the installed system could be violated by _creating a
directory_?

My system was plenty protected already - it had a root account with a password
only I knew. This is just more annoying Apple gatekeeping.

~~~
_Ogre
Your system is much more secure with SIP in place because it makes big parts
of your system immune to trojans and privilege escalation attacks, the two
biggest ways malware creeps into your filesystem. It's not very difficult to
disable (even permanently if you are inclined), and offers a big security
boost.

And yes, it is Apple "Gatekeeping"... the same gatekeeping that's kept OS X
almost completely free of major hacks for over a decade. I don't consider that
annoying but to each his own.

------
nailer
This is one of the reasons I love HN: a grapevine of important things to help
developers fix their dev environments, security things we need to be aware of
for our servers, new APIs to take advantage of, and other important stuff.

~~~
q3k
Well, if you use OS X, write against Node.JS, work at a SV startup and are
interested in big data / machine learning. It is quite a bubble.

~~~
thibaut_barrere
I live in a rural part of France, use OS X, Ruby/Elixir, I'm not working for
any SV startup, and indeed what the OP describes in one of my favorite things
in HN!

------
aorth
If you only need a Unix-style package manager for things like coreutils,
nodejs, tmux, irssi, vim, etc, pkgsrc runs on OS X and installs to _/
opt/pkg_. There is no Google Chrome, or fonts, etc in it though, so if you
enjoy installing those from Homebrew then this is not for you.

[http://pkgsrc.joyent.com/install-on-osx/](http://pkgsrc.joyent.com/install-
on-osx/)

------
rolux
How to disable SIP altogether:

[http://arstechnica.com/apple/2015/09/os-x-10-11-el-
capitan-t...](http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-
ars-technica-review/9/)

~~~
urda
Much like 'goto' statements in code, unless you _really_ have a good reason to
do you shouldn't disable SIP.

~~~
aorth
Every time you disable SIP ... a kitten dies? Related, stop disabling SELinux!

[http://stopdisablingselinux.com/](http://stopdisablingselinux.com/)

------
drinchev
Yeah I see Permission denied messages everywhere now.

    
    
        $ brew update
        error: unable to unlink old '.gitignore' (Permission denied)
        error: unable to create file .travis.yml (Permission denied)
        error: unable to unlink old '.yardopts' (Permission denied)
        error: unable to unlink old 'README.md' (Permission denied)
        Error: Failure while executing: git pull --quiet origin refs/heads/master:refs/remotes/origin/master
    

Nice. I saw that I can't change also system icons ( like Automator, AppStore,
Maps, Notes, etc. ).

Quick check on some forums suggest that I should do that in recovery mode. I
guess it will be a mess with almost any other app that needs a bit more
permissions and needs the raw UNIX filesystem.

~~~
eddieroger
It's not so much anything that needs the raw UNIX filesystem, it's anything
that touches files that Apple has deemed not needing to be changeable, which I
think app icons safely falls under. Fortunately, you can turn the whole thing
off if you want.

------
jackgavigan
Couldn't all this be avoided if Homebrew installed itself in a sub-directory
of /usr/local (e.g. /usr/local/homebrew) instead of /usr/local itself?

Edit: For the avoidance of any doubt/confusion, this is what a virgin
/usr/local/ looks like after Homebrew has been installed:

    
    
      $ ls -la /usr/local
      total 96
      drwxrwxr-x  13 root      admin    442 31 Aug 21:52 .
      drwxr-xr-x@ 12 root      wheel    408 31 Aug 21:52 ..
      drwxr-xr-x  14 jgavigan  admin    476 31 Aug 21:52 .git
      -rw-r--r--   1 jgavigan  admin    448 31 Aug 21:52 .gitignore
      -rw-r--r--   1 jgavigan  admin    291 31 Aug 21:52 .yardopts
      -rw-r--r--   1 jgavigan  admin   3161 31 Aug 21:52 CODEOFCONDUCT.md
      -rw-r--r--   1 jgavigan  admin   1103 31 Aug 21:52 CONTRIBUTING.md
      -rw-r--r--   1 jgavigan  admin   1241 31 Aug 21:52 LICENSE.txt
      drwxr-xr-x   9 jgavigan  admin    306 31 Aug 21:52 Library
      -rw-r--r--   1 jgavigan  admin   2319 31 Aug 21:52 README.md
      -rw-r--r--   1 jgavigan  admin  23801 31 Aug 21:52 SUPPORTERS.md
      drwxr-xr-x   3 jgavigan  admin    102 31 Aug 21:52 bin
      drwxr-xr-x   4 jgavigan  admin    136 31 Aug 21:52 share

~~~
runholm
That would break the unix convention they are trying to follow, so then they
might as well put it anywhere else as well.

~~~
jackgavigan
What unix convention are you referring to?

~~~
dagw
FHS
([https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard))

~~~
joosters
Can't see how that applies. Does FHS really say anything about the structure
underneath /usr/local ? Besides which, the Mac's filesystem isn't FHS in the
first place...

~~~
dagw
_Does FHS really say anything about the structure underneath /usr/local_

If you want to be strict about it, yes:
[http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html](http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html)

------
shurcooL
I just did this (from [1]):

    
    
        sudo chown -R $(whoami):admin /usr/local
    

And not `sudo chown $(whoami):admin /usr/local`. Are both really necessary?

[1]:
[https://news.ycombinator.com/item?id=10307800](https://news.ycombinator.com/item?id=10307800)

~~~
pilif
The -R was a bit overkill - what's _inside_ /usr/local should already have had
the correct owner - the problem is the owner of /usr/local itself.

~~~
mjs
The upgrade changes the permissions of all files within /usr/local to
root:wheel.

~~~
m_eiman
Didn't for me, only /usr/local itself.

------
neckro23
By the way, there's a way to create /usr/local without rebooting four times
like suggested in the doc:

\- Boot into Recovery (hold cmd+R during boot)

\- Open Disk Utility

\- Unlock your system drive (assuming it's encrypted) -- I forget where
exactly the option was but it's in DU somewhere.

\- Open Terminal

\- Go to your system drive now mounted under /Volumes and do what you gotta
do.

------
heimatau
This didn't work for me. Upon 3rd bullet point 'Reboot back into OS X' my
system kept showing me the apple logo, black background and status bar. When
the status bar progressed ~30%, information about my system would popup and
then stagnate/momentarily freeze. Then the system would go to black saying 'os
had a problem, rebooting in a few seconds' then...it would repeat this process
again and again, without any input from me.

I'm not sure what to do to fix this.

~~~
mzs
Maybe clear your kext cache. Also boot it single user mode so you can see
where it fails.

------
lectrick
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.

~~~
berdario
It's very common for linux applications to store stuff in $XDG_DATA_HOME
(~/.local/share by default) (config files and caches go somewhere else)

In my ~/.local I also have a bin/ directory (created by some Haskell tool), so
rather than putting stuff in /Users/username/usr/local, I think it might make
more sense to recreate the (needed parts of) a unix fs hierarchy in
/Users/username/.local

There's also ~/LibrarySupport on Macosx, if I remember correctly... but I
think that contains user editable configuration files as well

~~~
JadeNB
> There's also ~/LibrarySupport on Macosx, if I remember correctly...

You're probably thinking of `~/Library/"Application Support"`.

------
ohthehugemanate
In case it's helpful, I blogged the steps I had to take to get my environment
back up and running:

[https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-
ca...](https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-capitain-
working-with-my-developer-tools/)

------
skrause
Why does brew need to install everything owned by my user in /usr/local? I
would honestly prefer if everything installed by brew was owned by root:wheel
and brew would gracefully abort if I forgot to run it with sudo.

Is all that current mess just so that I don't need sudo for brew?

~~~
fit2rule
What is /usr/local for, if its not for locally installed (by the user) sub-
components?

Just curious whats wrong with using /usr/local. This is what its for, after
all ..

~~~
potatosareok
/usr/local makes sense to me if you've installed brew with sudo. But as other
comment says, it's weird to me to have files owned by login user in system
directory. It's such a rare scenario now I guess of multiple people on same
machine, but isn't user home directory place for files owned by login user?

~~~
__d
Typically /usr/local relies on group permissions: the accounts that you trust
to build and install stuff are added to, eg. 'admin' group, and /usr/local is
group writable for admin with the group s-bit set.

------
t413
Will homebrew switch the default install location out of /usr/local for new
installations then? I doubt most developers will want to dive into recovery
mode just to install wget.

~~~
pilif
you don't need to. You only need to if you have manually deleted /usr/local
for some reason. /usr/local is exempt from system integrity protection.

The only problem is that its owner gets reset to root on every OS update,
whereas Homebrew wants its owner to be the Homebrew user.

The advantage of /usr/local as the installation root is that /usr/local/bin is
in the default PATH of the OS and that setting the PATH in a way that it takes
effect no matter what starts an application is a bit... tricky in OSX as there
are many ways to launch an application that doesn't go through a shell, so
.profile and friends aren't enough.

~~~
Tehnix
Are you sure it gets reset to root? I've been on since the first public beta,
quickly fixed the homebrew problem, and haven't had any permission issues
since. Admittedly I can't say if normal updates will behave different from the
beta ones.

~~~
pilif
I can't be sure obviously, but if it's done once by the installer, there's no
reason to assume it won't ever do it again. So in the worst case, you'll have
to re-chown every time you install an update.

Or you don't chown and run brew as root.

------
atmosx
My MacTex (Latex) installation broke for the same reason. Luckily, all I had
to do was set put "/Library/TeX/Root/bin/universal-darwin/" in my $PATH and
change the path of "pdtlatex" and "bibtex" to the GUI tools I use. But still,
I lost about an hour or so trying to figure out what is happening.

------
vbezhenar
So I guess, for new installations it's better to put homebrew into $HOME?

~~~
laurent123456
I was just reading the Arstechnica article, which mentions this:

> Instead of allowing developers to put files wherever they want, El Cap
> offers four canonical safe locations for applications, support files, and
> drivers:

> /Library

> ~/Library

> /usr/local

> /Applications

> The local or system library directories are the preferred stand-in for
> /System, and /usr/local is the preferred stand-in for /usr, /bin , and
> /sbin. However, Apple strongly recommends that developers use /Applications
> for everything if possible, since that keeps all of an app’s files in a
> single location for ease of uninstallation.

------
dvcrn
The first thing I did after the upgrade was disabling SIP. Now my system acts
exactly the same way before with all the goodies (except rootless) el capitan
has to offer.

Having root not able to write system stuff is good for people that like to
blindly execute shell scripts from the internet but I think apple should add
something that makes it easier for developers to disable it.

I don't know if there is a new method yet, but before you had to boot into
recovery and execute `csrutil disable`. In the early days there was a boot
flag you could set but that got removed quickly.

~~~
Zirro
It has to be a method that can not be accessed by malware - the very thing SIP
is meant to protect from. I believe that is the reason the option ended up on
the recovery partition.

------
LaSombra
To me, the fact that you are directed to install Homebrew to /usr/local is
wrong since there's no guarantee how /usr/local is going to treated by Apple
in the future and this is now an example of that. The only directory that
Apple, probably, doesn't have control is your home directory.

I've been using homebrew for a long time without issues because, in my
opinion, I installed it on ~/homebrew. I wonder why is that so difficult for
others to use.

~~~
gnurag
Apple has indicated that even with SIP, they're leaving /usr/local available
for developers.

ref: Apple keynote slide #35 on
[http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/7...](http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/706/706_security_and_your_apps.pdf?dl=1)

------
No1
Does is still take a few hours to copy over /usr/local during the upgrade like
it did during the Yosemite upgrade or has Apple fixed that?

I'm glad I read this before moving the /usr/local directory as was previously
suggested [https://jimlindley.com/blog/yosemite-upgrade-homebrew-
tips/](https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/)

------
glogla
Homebrew troubles aside, does System Integrity Protection means the end of
OpenVPN and FUSE on Mac OS? Those need to add kernel modules and such.

~~~
rsy96
No. The official installers are signed, and are thus not prevented.

------
phkahler
Should I create this folder or install brew now? I've been thinking about
installing it on my macbook and doing some development on it but haven't yet.
Last night it told me the OSX update was available. Which order should I do
this? Or should I just not put brew in /usr/local ??

~~~
occam65
I definitely recommend installing El Capitan first, followed by Homebrew. That
will lead to less possibility of the upgrade screwing with your Homebrew
installation.

------
l3x5
It's easy to get Homebrew and Java running smoothly after the El Capitan
upgrade.

Read this:

[http://lexsheehan.blogspot.com/2015/10/el-capitan-
homebrew-a...](http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-and-
java.html)

------
mjs
Is this also related to why you can't rename /usr/local to /usr/local.old? (To
do a fresh install of homebrew into /usr/local.)

    
    
      $ sudo mv local local.old
      mv: rename local to local.old: Operation not permitted

~~~
raverbashing
mv /usr/local /tmp/local.old might work (or just somewhere outside of /usr)

------
ilaksh
Using a $150 Chromebook from Walmart with the built-in ssh and my VPSs or xfce
via crouton when I feel like it. Works great for web development. No
UNIX/linux compatibility problems since it is actually Linux.

------
dafstone
I installed El Capitan this morning and was expecting to have to do this - I
did not. chown stayed owned to me properly, brew functioned as it was
before... everything fine.

~~~
evolve2k
Did you do anything in advance of the install? Eg some people were mentioning
earlier to move files out of usr/local before upgrade then copy them back in.
Do anything like that?

------
littlewing
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.

~~~
deong
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 $PATH, and (b) it can be written to by a
normal user. Using /brew gives up (a) anyway, so you may as well just put it
in a user's home directory somewhere.

~~~
quesera
> 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.

~~~
deong
Oh, I know it's a huge problem on multi-user systems. I was just pointing out
that homebrew treats it that way so they can have sudo-less access.
Technically I guess it's not world writable in a default homebrew install
though, just owned by a normal user. Which also defeats the purpose of
/usr/local really, but I've never found that design decision from Homebrew to
be very good.

It is entirely possible I misunderstood SIP. The first thing I did was disable
it, and I haven't bothered any more about it. My impression though was that it
locked down all "system directories", however Apple chooses to define that.
Which would disallow changing the permissions on /usr/local, but also would
disallow creating new files or directories under a protected directory. Is
that not what it does?

------
anuraaga
Before Apple there was companies' IT's Puppet mangaging away /usr/local from
usefulness. Main reason I only use Macports which has never failed me.

------
sandaru1
Just make sure that if there are any launch daemons plist files, those should
be root:wheel. Otherwise "launchctl" won't load those daemons.

------
rhapsodyv
Anyone having issues with macports too?

------
liveoneggs
pkgsrc allows you to build into any directory you want.

------
grandalf
Dear Apple: Please start using apt

------
mozumder
The sad part is that /usr was supposed to be the original Unix user home
directories.

/bin was where you kept your binaries, and /lib for your libraries.

------
fleitz
I'm starting to regret upgrading...

~~~
JoachimS
El Capitan inclues a HUGE number of security fixes that you do want to have.

[https://support.apple.com/en-us/HT205267](https://support.apple.com/en-
us/HT205267)

~~~
carlosrg
Those fixes applicable to Yosemite will be available as a separate Security
Update. Apple usually supports the current OS and the OS X version behind (for
example, this for Mavericks was released in August:
[https://support.apple.com/kb/DL1834?viewlocale=en_US&locale=...](https://support.apple.com/kb/DL1834?viewlocale=en_US&locale=en_US)).
So security is probably not a reason to upgrade.

~~~
JoachimS
Are they back porting rootless?

~~~
carlosrg
No, and thank God for that. The only thing Rootless prevents is system
modification like iOS jailbreak, i.e. prevents tinkering with the system with
things like debugging running processes or modifying system files (for
example, utilities that modify the UI theme don't work with Rootless). Most
malware out there is not that sophisticated, does not try to modify the OS and
can still happily live in any other location of the system, like any other
program.

------
sabujp
osx just got selinux?

------
schmichael
Why does homebrew install things as root anyway? Seems like defaulting to
installing in your home directory would be a much better practice.

~~~
superchink
Homebrew does not advocate installing things as root. You can read more about
it here:
[https://github.com/Homebrew/homebrew/blob/master/share/doc/h...](https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/FAQ.md#why-
does-homebrew-say-sudo-is-bad-)

~~~
schmichael
Fantastic! Then why is this an issue?

~~~
s73v3r
They want /usr/local to be owned by you.

~~~
schmichael
That kind of blows my mind... why not use homedirs instead of abusing global
paths!?

~~~
s73v3r
If it's in a home directory, then the stuff installed is really only usable by
that person. I can see some instances where that would be desirable, but I
would prefer that the stuff I install is usable by the whole system, even
though I'm the only one on the machine.

------
senthilnayagam
I update 6 hours ago and tweeted about it

brew doctor brew prune sudo chown -R `whoami` /usr/local brew missing

[https://twitter.com/senthilnayagam/status/649400417323880448](https://twitter.com/senthilnayagam/status/649400417323880448)

------
amelius
Concepts such as "ownership" and "permissions" have always been a bit of an
issue with Apple.

------
quotemstr
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.

~~~
Osmium
> 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 similar attacks. This is a
good thing.

I feel like I have to keep defending it because it's perceived as this removal
of user freedoms, when it's factually just not the case–you can still do
everything you could do before, you just have to restart into recovery mode to
do so (to be able to do this without the restart into recovery mode would
undermine the security this technology provides). System Integrity Protection
is closer in spirit to something like SELinux than anything.

~~~
umanwizard
Well, if we somehow knew for sure that you'll always be able to disable it,
sure, this feature is fine.

But Apple can't be trusted -- they sell two very popular lines of computers
(iPhones and iPads) that are completely locked down. It's not unreasonable to
be worried that they'll try to move towards locking down their other lines
also. Not to mention that they're a remarkably developer-hostile company and
probably wouldn't care much about the outcry it would raise from the HN crowd.

~~~
Osmium
It seems a little unfair to judge a company against their hypothetical future
actions. I agree that if they do remove the option to disable it in future
then that's a problem, of course.

> they sell two very popular lines of computers (iPhones and iPads) that are
> completely locked down.

Note that iOS is _less_ locked down now than it has been in the past.
Previously, you had to enroll in the $99/year developer programme to run your
own code on your device, but now you just need to register for a free
developer account. So they're moving in the right direction, even if this is
still too restrictive for some.

~~~
umanwizard
I'm not judging them based on hypothetical future actions. I'm not really
judging them at all; I'm just uneasy and worried. I'm _predicting_ that the
probability of hypothetical future actions for which I'd judge them is too
high for my comfort.

I'm also judging the hell out of them for their past and current action of
keeping iOS locked down.

The developer program thing, IMO, is a bit of a red herring; everyone who can
buy an iPhone can also pay $99, so _pragmatically_ there is nothing you can do
now that you couldn't before, unless you're a student and your parents bought
you your phone. Sure, it's a step in the right direction or at least not
negative, but I don't think it's particularly meaningful.

~~~
Osmium
> unless you're a student and your parents bought you your phone

It's a bit tangential, but speaking for myself this actually matters. I was a
student until recently, I bought my own phone, but I couldn't afford the
developer programme (especially when it was two separate programmes, one for
OS X and one for iOS). Now, I can build apps and only need to buy the
developer programme when I want to deploy them, and then I only have to
subscribe to the one programme for both OS X and iOS too. So honestly it does
matter to some people.

I hear you about your concerns though. I'm hopeful, with the iPad Pro, that
they're actually going to open up iOS more in future, not less. It'd be nice
to do proper development on an iOS device. A BSD-like jail environment (e.g. a
full sandboxed unix environment with shell access, with maybe iCloud Drive
mounted in the filesystem) would be lovely. If they want to sell 'pro' iOS
devices, they must be thinking about these sorts of problems.

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

~~~
eggie
You could have a stable free environment that will work for a decade or a
proprietary one that's designed to cause older computers to break and require
expensive upgrades. For various reasons many people love the latter.

I also don't mind having excuses to upgrade my hardware but I dislike being
driven forward by planned obsolescence, which is basically how every piece of
Apple hardware I've ever owned has ended its life. Exploding batteries.
Horrible one-way OS upgrades. I thought it'd be helpful for art and music
software, but I found the opposite. I thought it'd be good for programming but
had to invest absurd amounts of time in installing basic open source
development software. Never again.

~~~
oldmanjay
I'm not totally sure how exploding batteries and optional OS upgrades are
driving you forward through planned obsolescence. I feel like maybe in your
apparent "rage" you lost the logic thread of the point you actually wanted to
make and conflated a few things into an incoherent rant.

------
eccstartup
Homebrew sounds like a malware of EI Capitan. :)

