Live data from Hacker News

El Capitan and Homebrew

github.com

261–270 of 298 posts

Re: El Capitan and Homebrew

#262

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.

> It's all about protecting the integrity of the installed system

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 =/

Re: El Capitan and Homebrew

#263
post #170

Earlier quoted context omitted.

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

As I can't edit the comment, I wasn't referring to the name /usr/local as much as the permissions. It'd make more sense to store systemwide hierarchy in /opt/homebrew/* and user-specific hierarchy in ~/.homebrew/* instead.

Many unix tools are written to build looking for dependencies on default paths including /usr/local.

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.

Re: El Capitan and Homebrew

#264

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

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.

OS X has always provided a fine Unix experience for me.

Re: El Capitan and Homebrew

#265
post #256

Earlier quoted context omitted.

And that's totally fine, and I let Homebrew own /usr/local too. What I'm not going to do is freak out when a totally sane and useful security feature breaks that install mode, especially when I could, if I cared that much about convenience, just take 30 seconds to disable the security feature.

I just want to make clear I'm not freaking out (and I know you're not either). 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/…

Keep in mind that you can re-enable SIP right after you create the directory, if you had to create it at all.

Re: El Capitan and Homebrew

#266

Earlier quoted context omitted.

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

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

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.

Re: El Capitan and Homebrew

#267

Earlier quoted context omitted.

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

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…

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

Re: El Capitan and Homebrew

#268
post #199

Earlier quoted context omitted.

This sounds like the best suggestion/solution in this thread. But if you run brew from admin, why can't admin take ownership , and run brew without sudo?

So that Homebrew always requires my password to install an app, just like native OS X installs. It also preserves the default permissions. And it's not that hard to sudo.

    > Homebrew always requires my password to install an app
But isn't that _less_ safe?

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?

Re: El Capitan and Homebrew

#269

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?

No, it's not. Mainly because it's not just "adding a directory"

Re: El Capitan and Homebrew

#270

Earlier quoted context omitted.

El Capitan inclues a HUGE number of security fixes that you do want to have. https://support.apple.com/en-us/HT205267

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=... ). So security is probably not a reason to upgrade.

Are they back porting rootless?
Post reply on HN