151–160 of 298 posts
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.
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/
Earlier quoted context omitted.
I can't think of anything more standard than /usr/local/.
BSD and Linux use /usr/local, it's not universal. But /usr/local has never been writable by non-privileged users. Homebrew depends on that nonstandard and undesireable permissions model. Apple doesn't bend to accommodate an inappropriate use. Hombrew doesn't want to use a location that is outside the default PATH, and they don't want to install with proper permissions, so they purposefully misinterpret the "standard"…
Remind me again why i should need to reboot into recovery mode to create a directory?
Earlier quoted context omitted.
So you'd want all those programs to run as root? Isn't that against any notion of security?
Why would they run as root, just because they were owned by root? Only brew itself would need to run as root (just like most package managers do anyway).
Because "sudo" (that OP wants to run them with) runs them as root by default?
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.
Earlier quoted context omitted.
Never used Homebrew, but taking ownership of /user/local as I understand it does by default, certainly isn't a 'common unix standard'.
It doesn't take ownership by default IIRC - just recommends that you do so. It will work with sudo if you want to go that way.
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 director…
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
Earlier quoted context omitted.
Being required to reboot my computer into recovery mode just to add a directory is certainly a WTF worthy situation. BTW, thanks for the down vote?
To add a directory to a system-protected directory. It's all about protecting the integrity of the installed system. If you don't like/want it, you can reboot into recovery, disable it, and leave it that way.
My system was plenty protected already - it had a root account with a password only I knew. This is just more annoying Apple gatekeeping.
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.
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.
Earlier quoted context omitted.
Most Mac users will never need to do this, and the short reboot cycle is, to many, worth the extra security rootless brings. It's hardly WTF.
Being required to reboot my computer into recovery mode just to add a directory is certainly a WTF worthy situation. BTW, thanks for the down vote?
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.
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
It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.