El Capitan and Homebrew
github.com
github.com
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.)
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.
This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive.
The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.
I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.
In an ideal world, there would be a dependency declared on Xcode for all those ports so MacPorts would work with command line tools only and fail gracefully whenever Xcode is required. However, that is currently not the case because nobody implemented an easy and automated way to tell whether a port will build fine without Xcode.
Homebrew just worked, and when it breaks, brew doctor is typically spot-on in telling me how to fix it. I've never had the time to figure out why MacPorts gave me trouble.
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?
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.
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.
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.
- MacPorts' /opt/local is not in any of the default system paths.
- MacPorts uses sandboxing to ensure that builds can't stomp anything outside of /opt/local
edit
should be noted you really ought not do this and if you absolutely have to you should use DYLD_FALLBACK_LIBRARY_PATH
http://stackoverflow.com/questions/6612009/macports-port-sel...
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.)
The line I pasted, from my own .bash_profile, is identical to the recommended approach: https://guide.macports.org/chunked/installing.shell.html
One issue is that the MacPorts built versions of things don't always integrate in a nice way with other parts of the system. For example, it used to be the case (and may still be) that LibSDL built under MacPorts would hard-code the absolute build path used to build it into the shared object, so that the frameworks wouldn't work if you moved them (e.g., if you wanted to use the frameworks to distribute an SDL-based game to your friends). This appears to be a choice that the MacPorts devs made explicitly, since standard source builds of SDL don't do that, and the standard SDL binaries don't do that.
I understand there are trade offs here, but the ones the MacPorts devs chose were not the ones I would have wanted. Homebrew, for better or worse, makes it much easier to make local changes to recipes, if you disagree with what the devs choose. However, I find that most of the disagreements I had with the MacPorts folks just haven't shown up with Homebrew.
$ man install_name_tool
Edit: I looked in one of my Makefiles:
install_name_tool -change \
/bar/baz/lib/libfoo.7.dylib @executable_path/lib/libfoo.7.dylib a.outYou should also look at otool as well while you're at it. They're useful commands, just difficult to discover unless you already know what you're looking for.
That's resolved all of the fragility (and heinous build times) that previously existed.
This goes against all that I have read and my own experiences with the betas. Maybe Apple changed something last minute. See here: http://www.macworld.com/article/2948140/os-x/private-i-el-ca...
The specifics of System Integrity Protection are that no user, application, or process will be able to write files or modify files in the root System folder or the /bin, /sbin, and /usr directories, which are hidden by default in OS X’s Finder. The /usr/local folder remains accessible, however; it’s a long-running convention in Unix and variants as a place to stash material and software that individual users rely on.
If it exists, we can use it as before.
Considering how many times I've installed OS X, I can't recall if /usr/local is there by default (excluding 10.11 for the moment). Will have to do another few installs and check.
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.
Enjoy using Apple's computers...and they are Apple's, not yours because if they were, you'd be in control.
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?
"Apple documentation hints that /usr/local will be returned to root:wheel restricted permissions on every OS X update; Homebrew will be adding a brew doctor check to warn you when this happens in the near future."
Aside: I really wish Homebrew didn't encourage having a single user own /usr/local. If they're going to insist on never needing sudo to install things, it should just default to installing in your home directory.
Someone I know puts it in ~/brew and that works just fine, too. His reasoning is that /usr/local/ is for all users, and though he's really the only user on his laptop, it's just wrong to install a bunch of stuff that's just for him into a global user directory.
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.
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.
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/
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?
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 Hierarchy Standard for /usr
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the /usr hierarchy.
And no, I am not the one downvoting you.
> The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
> Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...
It says "The /usr/local hierarchy is for use by the system administrator when installing software locally."
That seems to kind of conflict with what you quoted "Large software packages must not use a direct subdirectory under the /usr hierarchy.", unless they mean a vendor-specific directory rather than "/usr/local".
I dunno, all I can say is that in my experience on various unixes, it is a "common unix standard" to install software that is not controlled by the OS package manager to /usr/local. I don't interpret "common unix standard" as "FHS" though -- if you mean FHS, say FHS. To me "common unix standard" just means "something that is commonly done on unix". And installing locally-installed (not using OS distro) software to /usr/local is pretty commonly done, as many people can attest. That's why homebrew chose it, they didn't just make it up.
'common unix standard' is whatever POSIX states as standard.
> Homebrew always requires my password to install an app
Instead of trusting Homebrew with /usr/local, you have to trust every formula with `sudo`? Or does it only use sudo for part of it, a `mv` or something?
If you don't run brew as root you at least protect places like /usr/lib, but you are protected from that and more with macports (where stages and uses nobody).
But for now your approach seems the best pragmatic course to take, thank you for the suggestion.
Putting packages installed in a custom /opt/homebrew location would make it harder to install and use software that often assumes a /usr/local possibility, but not an /opt/homebrew it's never heard of.
It is in fact a pretty common place to put non-distro installed software. And was not (and still is not?) used by OSX out of the box. It made a lot of sense for homebrew to use it.
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".
Hijinks ensue, and people blame Apple, which is silly.
Remind me again why i should need to reboot into recovery mode to create a directory?
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.
/Applications
/Library
/Network
/System
/User Information
/Users
/Volumes
?Apologies if that was not clear.
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.
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.
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.
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.
I more agree with you than with him, but his argument seems pretty straightforward.
OSX suggests /usr/local as a good location to install software, but insists that the directory itself be owned by root, and protects the parent directory /usr under SIP.
My assertion is that Homebrew is using /usr/local incorrectly (and in contravention to all expectation), and that blaming Apple for the problems thereby created is inappropriate.
I also think SIP is a good thing.
Even assuming OSX is a single user system (which is arguable), it is 2015 and should that single user be able to accidentally damage /usr/local? I think not, that by today an OS should help protect you from broken postinstall script or what not.
Moreover please think about this: homebrew is not wanting /usr/local/ root:admin but instead /usr/local/ `/usr/bin/whoami`:admin.
Further even on our laptops where there is just one user, I use a non-admin user. I have no problems using FUS, GUI prompted temporary admin permissions, or /usr/bin/login -p and sudo day-to-day, but homebrew has a problem with sudo.
Apple SIP has no problem with /usr/local/ 0:0 but homebrew does. Because of shortcuts homebrew has forced a number of poor decisions on it's users.
I use Homebrew and will probably keep doing that because Homebrew is really convenient and just generally works better than MacPorts for me, but what Homebrew is demanding --- ownership over /usr/local --- is not in fact reasonable. It makes a lot of sense to me that OSX will want to keep perms on /usr/local (which is in everyone's PATH) locked down, and so it seems extra hacky that they're going to add a 'brew doctor' check to see if Software Update has "broken" those privileges.
The commenter upthread that suggested Homebrew should use ~/.homebrew or something by default is right.
I would hope though that out of this someone would think, "Hmm... oh drat... yeah I guess this is just one of those things that nobody predicted at first. Shot I think it was a bad idea to have a user own /usr/local/. But you know, it's a good time to improve things... hmm... I know let's build and stage as nobody and then copy under /usr/local/! We still can have binary packages always work and nobody has to mess with PATH, man pages, or dynamic linker trivia. We might have to write something though that asks for a username and password, but whoa... OSX makes that surprisingly easy... I should do that!"
It's not going to be me cause I don't use homebrew, but that would be way better than these hacks that will ammount to people being encouraged to just disable SIP cause of the headache after ever software update.
This is from RedHat. Not implemented by everyone, but modern OSes (e.g. CoreOS) seem to follow the patterns. CoreOS also do everything in their power to prevent you from mounting /usr as writeable.
Perhaps that doesn't pass your bar for 'real' though since it's not globally implemented ;)
(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.)
[1] https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
This is still accurate. Homebrew creates/manages /usr/local/.git. /usr/local/.gitignore starts with /* which is … not conventional.
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.
I'm now using /usr/local/bin.
I looked for a guide, no joy. The more opinionated, the better, because I just want to follow the norm.
> it should follow common unix standards
> or at least fit in with OSX
> rather than require a hack
People keep writing here as if El Cap removes /usr/local entirely. It does not. /usr/local is there by default. You only have to go into recovery mode if you've somehow removed it yourself.
It's worse than that. Homebrew wants 775 $(whoami):admin.
$ /usr/bin/env -i /bin/sh -c \
'id | grep -lw admin >/dev/null && echo admin || echo non-admin'
non-admin
BTW, thanks for the down vote?
My system was plenty protected already - it had a root account with a password only I knew. This is just more annoying Apple gatekeeping.
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.
Why is this important? It's trivial to reformat my drive and have a fresh install. The stuff I have that's actually sensitive is in my home directory and still unprotected =/
For the 0.01% who need to screw around with the operating system directories, they can take the 90 seconds to hop into recovery mode.
This is a situation where 100% of the user community has a reasonable solution, 99.99% aren't inconvenienced in the slightest, and the security situation goes up significantly. It's like hiding ~/Library by default - 99% of users probably don't need to mess around there, and hiding it probably reduced a lot of failure modes. (and, once again, for the 1%, chflags solves the problem in 5 seconds)
Honestly - I've always been terrified whenever I've been asked for my password during installation (I do a gut check every time an ARQ upgrades asks me for my password - "Do I trust them one more time? Well, they are my backup software, so, ...) - What if it's dropping something in my system directory?
I usually follow up with a cd /; sudo find -cmin -5 to see if things look reasonable - but I'm guess not all users do that. Also - with all the extended attr stuff on OS X, it's not even clear that a find -cmin -5 would be sufficient.
So - count me in the group that is really, really pleased that Apple is locking down those system directories by default.
Sorry, but I can't resist mentioning that there's no need for that `cd /`; `sudo find / -cmin -5` would work just fine.
> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
(though personally I'm not sure why you were downvoted originally)
This is a good feature, and it's not a new one: the BSDs have done it for over a decade with securelevels and immutable mounts --- where you also had to take the system down to make alterations.
If you think about it for a second, you'll see that anything that would have allowed you, a normal user typing at the keyboard, to create directories under /usr would probably render the security of SIP meaningless. It's the fact that you do have to go into recovery mode to hack up your filesystem that indicates that there's actually a meaningful security check happening here.
Just think of SIP's filesystem protections as literally just being "you have to boot the system into a special mode to change certain parts of the filesystem". I want that feature, and I hack up my filesystem all the time! The overwhelming majority of Mac users don't even know they want the feature and benefit enormously from it regardless. A major win.
http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-t...
$ 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
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.
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.
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 shareIf you want to be strict about it, yes: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html
$ which brew
/usr/local/brew/10.10/bin/brew
sudo chown -R $(whoami):admin /usr/local
It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.
- 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.
I'm not sure what to do to fix this.
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.
TBH, things like this make me really mis debian. It's really nice when your package manager is a first class citizen (and geared towards software development rather than consumption).
PATH=/opt/homebrew/bin:/opt/homebrew/sbin:$PATH
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
You're probably thinking of `~/Library/"Application Support"`.
https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-ca...
Is all that current mess just so that I don't need sudo for brew?
Error: Cowardly refusing to `sudo brew install`
You can use brew with sudo, but only if the brew executable is owned by root. However, this is both not recommended and completely unsupported so do so at your own risk.
I don't know if it's different now, but a quick Google search indicates that brew still behaves like this. I would like to use brew with sudo, but I don't want to use unsupported methods.
When XCode needed some license approval after the recent upgrade to support iOS9, Brew warned me that license can only be approved ( programatically ) by root. I tried to sudo brew and received the warning you showed. That was 1 week ago.
sudo su at your own risk, hehe.
Just curious whats wrong with using /usr/local. This is what its for, after all ..
Using sudo would also be a security advantage since not every program running under your username would be able to modify all binaries in /usr/local.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...
Really brew should always be installing somewhere under ~/ if you are installing packages as a user.
Because "sudo" (that OP wants to run them with) runs them as root by default?
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.
Or you don't chown and run brew as root.
> 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.
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.
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.
Now since many people say they never run into problems with nonstandard homebrew path, I'd like to give it a try too.
ref: Apple keynote slide #35 on http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/7...
I'm glad I read this before moving the /usr/local directory as was previously suggested https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/
Read this:
http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-a...
$ sudo mv local local.old
mv: rename local to local.old: Operation not permittedEven 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.
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.
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?
/bin was where you kept your binaries, and /lib for your libraries.
brew doctor brew prune sudo chown -R `whoami` /usr/local brew missing
https://twitter.com/senthilnayagam/status/649400417323880448
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.
See also: Android
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.
> 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.
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.
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.
You haven't given a reason why. And no, the existence of iOS is not a reason.
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...
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.
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.
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.