Live data from Hacker News

El Capitan and Homebrew

github.com

141–150 of 298 posts

Re: El Capitan and Homebrew

#141
post #86

To be fair, homebrew shouldn't need to change perms, it should follow common unix standards or at least fit in with OSX rather than require a hack. For years I've felt homebrew should really use either /opt/ or ~/.homebrew/ by default.

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

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

Hijinks ensue, and people blame Apple, which is silly.

Re: El Capitan and Homebrew

#143
post #95

Earlier quoted context omitted.

What makes you think /usr/local isn't a 'common unix standard'?

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.

Re: El Capitan and Homebrew

#144

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.

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

Re: El Capitan and Homebrew

#145
post #85

Earlier quoted context omitted.

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

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 w…

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.

Re: El Capitan and Homebrew

#147
post #145

Earlier quoted context omitted.

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 w…

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 programm…

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.

Re: El Capitan and Homebrew

#148
post #86

To be fair, homebrew shouldn't need to change perms, it should follow common unix standards or at least fit in with OSX rather than require a hack. For years I've felt homebrew should really use either /opt/ or ~/.homebrew/ by default.

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

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

Re: El Capitan and Homebrew

#149

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…

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.

Re: El Capitan and Homebrew

#150
post #145

Earlier quoted context omitted.

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 programm…

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 ca…

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

Post reply on HN