Live data from Hacker News

Homebrew 1.1.0

brew.sh

161–170 of 216 posts

Re: Homebrew 1.1.0

#161
It's funny how every hipster dev uses a MacBook for development, yet you have to resort to this kind of hacks from day one if you want to be productive. Anyway.

Re: Homebrew 1.1.0

#162
post #108

Earlier quoted context omitted.

> Why is this a really bad idea for a personal machine? It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root. > What's th…

Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Also you can actually install it wherever you like, this is just the default/recommended location: https://github.com/Homebrew/brew/blob/master/docs/Installati...

/usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.

Re: Homebrew 1.1.0

#163
post #4

There are lots of minor changes, but nothing major IMHO. The reason for bumping the minor version are a couple of breaking changes: - Disable SHA-1 checksum support in formulae - Disable running Homebrew as the root user (e.g. sudo brew) - Bottles with _or_later tags no longer use _or_later in their filenames so the existing bottle can be reused

Side-topic: Shouldn't the breaking changes be enough reason to bump the version to 2.0?

Unfortunately most people now consider major versions to indicate major feature additions rather than breaking changes.

Re: Homebrew 1.1.0

#164
Docker for mac has replaced homebrew for me. Run anything under the sun in a temporary container and mount the current directory. Works great and is very nice isolating everything

Re: Homebrew 1.1.0

#166
post #141

Earlier quoted context omitted.

I have the same concerns and have been using Nix for my Mac package manager [1] instead. Functionally it's far better, though with far fewer packages available currently. [1]: https://news.ycombinator.com/item?id=11772686

I've been meaning to try out Nix for probably years. I work in vfx and large facilities have particular needs that most packaging systems don't support, but there's a huge about of investment that can be leveraged (dependency resolution, caching). I did a fresh install of macOS with Sierra and decided to use Nix instead of Homebrew this time around. So far I've only started reading through the docs and only have a fe…

If you're considering it for a Homebrew alternative, the main thing is to make a list of all the packages you must have, and then all the ones you would like to have, and then check if they're in Nix. Decide whether you can live with that or not.

Besides that, it's great. The about page sums its features up nicely: http://nixos.org/nix/about.html

Re: Homebrew 1.1.0

#167

Earlier quoted context omitted.

I have the same concerns and have been using Nix for my Mac package manager [1] instead. Functionally it's far better, though with far fewer packages available currently. [1]: https://news.ycombinator.com/item?id=11772686

>Functionally it's far better For example?

The about page sums its features up pretty well, see if there's anything that particularly appeals to you there: http://nixos.org/nix/about.html

Also the HN link in my previous comment has some good discussion of it, just scroll down past the initial Docker comparison thread.

For me the main benefit of it is that I trust it. It doesn't take over system directories like Homebrew, which bugs me even though I'm on a single-user system where that should be ok. Both installs and uninstalls are deterministic, complete, and don't screw anything else up in the system. You can install different versions of the same package side-by-side, which the Debian and Red Hat Alternatives systems also enable, but Nix is more sophisticated about it tagging everything with a cryptographic hash of its build tree. MacPorts and pkgsrc may also provide some of this, but Nix feels more like the git of package managers than anything else I've used, eg the one that finally gets packaging right.

Re: Homebrew 1.1.0

#168
post #137

Earlier quoted context omitted.

> I don't need to worry about crap like whether some Python package will work with Apple's Python distribution This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO…

This is also exactly why i use MacPorts. It works. It doesn't do silly stuff. It's been consistently solid for years. Today, i got into a fight with Homebrew because i wanted to use a second user account on my laptop. I have one primary account, and another i use when doing workshops with clients, so i don't accidentally show them my sekrit files. The only way to get brew to install things without making trouble was…

> That said, 'sudo port upgrade git' has been failing for me for about a day now, because none of the archives have 2.10.1. I see this sort of thing occasionally, and it's annoying, but not really obstructive.

You are probably using on old version of OS X that does not yet support TLS 1.2. Therefore system's libcurl cannot talk to https://kernel.org anymore, which got very strict recently. As a workaround, you can download the tarball manually with your browser and place it into /opt/local/var/macports/distfiles/git/.

https://trac.macports.org/ticket/52604

Re: Homebrew 1.1.0

#169
post #37

Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?

I use pkgsrc due to portability and its clean separation between the base system and itself. https://pkgsrc.joyent.com/install-on-osx/

Pkgsrc is fantastic and never gave me the lib conflict headaches I had with Homebrew. It's also really easy to contribute a package or fix. Plus I use pkgsrc in the cloud, so my dev machine works like my production machine.

Can't say enough good things about pkgsrc.

Re: Homebrew 1.1.0

#170
post #37

Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?

Basically all of the unixy tools I need host-side (a lot of my work happens in Debian VM's or on remote Debian servers) are available as native Installer Packages (.pkg or .mpkg bundles) This boils down to: Vagrant, Mercurial, Git, GPG Suite, Autotools, tree and wget.

And for updates you manually hunt down the new .pkg installers? Package managers are not only there to install some version of the software, but also to keep it up-to-date.
Post reply on HN