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.)
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.
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.
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.
Unless you're making iOS software, why not just use Linux?
I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.
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.
brew supports pre-compiled binary packages (what they call bottles) only when you use the default install location /usr/local. If you use any other prefix brew will always compile all packages on your system, which might take a long time depending on the performance of your system. So using /usr/local saves time and energy since all brew needs to do is to download and install binary packages.
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.
It did - before now /usr/local was available unprivileged with ownership.
> rather than require a hack
It only needs that now, since requirements to "fit in with OSX" have changed. That's not Homebrew's fault - they need a fast solution. Kudos in my book for responding before it's a problem.
If I have already installed a bunch of packages, how do I move everything to something like ~/.homebrew? (1) Change the HOMEBREW_PREFIX (2) move the existing aliases from /usr/local/bin (3) add the directory to my path (4) ???
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 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.
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.
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.
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.
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.
The only problem is that after the update, the /usr/local belongs to root again. That's easily fixed with a chown though.
Apps still have access to the raw UNIX filesystem. The only restriction is that they can't write to /usr, /usr/bin, /usr/sbin, /System and into pre-installed Apple apps. Normally, Apps shouldn't need write access to these directories.
I'd say the "-R" might actually be harmful; for example the mysql GPL distribution binaries from dev.mysql.com installs in /usr/local/mysql and you definitively don't want to mess with the database file permissions there.
It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.
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.
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.
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
Homebrew can be installed anywhere, and after ~2 years of having it outside of /usr/local I have not run into any problems. There is a disclaimer somewhere that states some "packages" may not work well with this setup, but that seems like an upstream bug to me. Things should not require things to live in a specific path or prefix.
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?
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.
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.
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.
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.
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.
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.
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.
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 ??
I definitely recommend installing El Capitan first, followed by Homebrew. That will lead to less possibility of the upgrade screwing with your Homebrew installation.
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.
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.
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?
Did you do anything in advance of the install?
Eg some people were mentioning earlier to move files out of bin/local before upgrade then copy them back in. Do anything like that?
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 $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.
Why do you feel this way? I mean, seriously, at the end of the day we're talking about computers and operating systems. That's it. No reason to be upset. It's just stuff.
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 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.
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 symlinks in /usr.[0] Why? There was no need for that and no easy way to get it out or even know it was doing that in the first place. So as a solution people had "uninstaller" programs that would look for gunk like this left by other programs? Ridiculous.
I'm glad Apple is locking this down. If you don't like it turn it off.
They do have full control - see the bit about being able to disable/enable via recovery mode. I for one am very happy to have moved on from an era where desktop security was abysmal and compromises lurked around every corner.
Isn't the goal to prevent malware from modifying core system files? How different is this than a simple mandatory access implementation? As long as it is possible to disable it, should I choose to, I am not outraged.
The common problem of today OSes is that shall malware breach security at least once, it can hide in the system and you will have no idea that you have it. SIP is a good step towards fixing that problem.
A couple of year ago I made a prediction that Apple is going to try to throw out OSX long term. While I thought it would proceed at a greater pace, gradually locking down things because of "security" can easily have double utility. I hope I'm wrong, I like my OSX machines ...
Yeah, iPhone a very very unpopular for this reason, right?
You have the same amount of control, this is an option you can disable if you need to. I think the amount of people who need that is very small, even among technical crowd.
> System Integrity Protection is obnoxious paternalism at best
As is ASLR? Users should always know what addresses their libraries are loaded at in their own machines! While we are at that, let's remove file permissions. That's paternalism - users should know what they are doing.
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.
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.
mapgrep|10 years ago
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.)
robbles|10 years ago
joshmoz|10 years ago
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.
cdonnellytx|10 years ago
outworlder|10 years ago
unknown|10 years ago
[deleted]
WorldWideWayne|10 years ago
I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.
alex1|10 years ago
skrause|10 years ago
eloisant|10 years ago
favadi|10 years ago
tvon|10 years ago
dingaling|10 years ago
Not sure about OS X but common corporate Unix protocol is to make /home/ noexec.
Non-core ( i.e. outside central package management ) installations go to /opt/
Tehnix|10 years ago
Other than this one-liner, which is done once, there really isn't any extra hassle with using the default.
I'd be more interested in why you didn't want to install it there?
_b8r0|10 years ago
OJFord|10 years ago
emanuelev|10 years ago
sneak|10 years ago
jrochkind1|10 years ago
isnotchicago|10 years ago
antouank|10 years ago
cbhl|10 years ago
matwood|10 years ago
kiernan|10 years ago
nailer|10 years ago
q3k|10 years ago
aorth|10 years ago
http://pkgsrc.joyent.com/install-on-osx/
rolux|10 years ago
http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-t...
urda|10 years ago
mahouse|10 years ago
drinchev|10 years ago
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|10 years ago
pilif|10 years ago
Apps still have access to the raw UNIX filesystem. The only restriction is that they can't write to /usr, /usr/bin, /usr/sbin, /System and into pre-installed Apple apps. Normally, Apps shouldn't need write access to these directories.
jackgavigan|10 years ago
Edit: For the avoidance of any doubt/confusion, this is what a virgin /usr/local/ looks like after Homebrew has been installed:
runholm|10 years ago
mitchty|10 years ago
shurcooL|10 years ago
[1]: https://news.ycombinator.com/item?id=10307800
pilif|10 years ago
0x0|10 years ago
It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.
favadi|10 years ago
neckro23|10 years ago
- 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|10 years ago
I'm not sure what to do to fix this.
mzs|10 years ago
lectrick|10 years ago
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|10 years ago
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
tvon|10 years ago
ohthehugemanate|10 years ago
https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-ca...
skrause|10 years ago
Is all that current mess just so that I don't need sudo for brew?
fit2rule|10 years ago
Just curious whats wrong with using /usr/local. This is what its for, after all ..
pilif|10 years ago
coldtea|10 years ago
t413|10 years ago
pilif|10 years ago
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.
atmosx|10 years ago
vbezhenar|10 years ago
laurent123456|10 years ago
> 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|10 years ago
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|10 years ago
LaSombra|10 years ago
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|10 years ago
ref: Apple keynote slide #35 on http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/7...
rsy96|10 years ago
Now since many people say they never run into problems with nonstandard homebrew path, I'd like to give it a try too.
No1|10 years ago
I'm glad I read this before moving the /usr/local directory as was previously suggested https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/
glogla|10 years ago
rsy96|10 years ago
Zirro|10 years ago
joosters|10 years ago
phkahler|10 years ago
occam65|10 years ago
l3x5|10 years ago
Read this:
http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-a...
mjs|10 years ago
raverbashing|10 years ago
ilaksh|10 years ago
dafstone|10 years ago
evolve2k|10 years ago
evolve2k|10 years ago
littlewing|10 years ago
deong|10 years ago
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.
anuraaga|10 years ago
sandaru1|10 years ago
rhapsodyv|10 years ago
liveoneggs|10 years ago
grandalf|10 years ago
racl101|10 years ago
[deleted]
mozumder|10 years ago
/bin was where you kept your binaries, and /lib for your libraries.
fleitz|10 years ago
JoachimS|10 years ago
https://support.apple.com/en-us/HT205267
TurboHaskal|10 years ago
[deleted]
colinplamondon|10 years ago
Most years (like this one!) there's a one-liner for Homebrew upvoted to the top of HN, and that's it.
JustSomeNobody|10 years ago
sabujp|10 years ago
schmichael|10 years ago
superchink|10 years ago
senthilnayagam|10 years ago
brew doctor brew prune sudo chown -R `whoami` /usr/local brew missing
https://twitter.com/senthilnayagam/status/649400417323880448
amelius|10 years ago
quotemstr|10 years ago
Osmium|10 years ago
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.
massysett|10 years ago
It turns out Haskell Platform was installing symlinks in /usr.[0] Why? There was no need for that and no easy way to get it out or even know it was doing that in the first place. So as a solution people had "uninstaller" programs that would look for gunk like this left by other programs? Ridiculous.
I'm glad Apple is locking this down. If you don't like it turn it off.
[0] https://mail.haskell.org/pipermail/haskell-cafe/2015-October...
cmdkeen|10 years ago
stock_toaster|10 years ago
hamstergene|10 years ago
mickronome|10 years ago
rimantas|10 years ago
jawngee|10 years ago
unknown|10 years ago
[deleted]
outworlder|10 years ago
As is ASLR? Users should always know what addresses their libraries are loaded at in their own machines! While we are at that, let's remove file permissions. That's paternalism - users should know what they are doing.
omegote|10 years ago
thom_nic|10 years ago
umanwizard|10 years ago
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.
eggie|10 years ago
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.
eccstartup|10 years ago