Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homebrew 3.0

brew.sh

Post reply on HN
Print view View original

321–330 of 516 posts

Re: Homebrew 3.0

#321

Post by thaumasiotes »

spijdar wrote: post #296
gonehome wrote: post #286

Earlier quoted context omitted.

Gentoo is probably the most user hostile Linux distribution I can think of other than ones purposely austere for learning (LFS) or parody (Suicide Linux). If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.

If Gentoo makes your particular computer goal easier to achieve, I don't think it's "hostile". Most people will never need Gentoo or want to use it, but for those with either a need or a desire for a meta-distribution, Gentoo does a pretty good job. I don't think calling it "user hostile" is quite right. I think it's been partially supplanted by other package managers now like Nix/NixOS and even (IMO) XBPS/Void, but…

I used Gentoo for a while and mostly liked it. There was one reason I stopped using it -- dependency conflicts. Every time you update, there's a new set of conflicts that you have to personally untangle.

By any other metric, I would consider it more user-friendly than average. For example, I was very favorably impressed when (not knowing what I was doing), I gave the command to uninstall libc, and after confirming that I really wanted to do that, I was allowed to.

Re: Homebrew 3.0

#322

Post by gabereiser »

talentedcoin wrote: post #201

One thing I haven't seen mentioned here is that Homebrew forced people use Ruby to write formulas (ie packages), whereas MacPorts forced people to use Tcl. This one decision, plus hosting formulas on Github, was a major contributor to their present success. As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebre…

I still prefer MacPorts over Homebrew. However, like you said, Homebrew's marketing in the form of embedded into tutorials and setup's helped push them to where they are now.

Almost every Ruby on Rails tutorial I've seen in the last decade used Homebrew over MacPorts.

I found MacPorts just before Homebrew was a thing. I figure since Mac OS was BSD based, why not go with the traditional portage way.

I preferred my optional packages to be installed in /opt. I preferred MacPorts.

Sadly, in the last 3-4 years, Homebrew has been leading the charge, adding more bleeding edge package versions and just doing a better job of maintaining the formulas for install.

Happy to see it. I think for python/go/ruby devs they will continue to prefer Homebrew simply because the tutorials they learned from prefer it. It's a feedback loop.

Re: Homebrew 3.0

#323

Post by sirn »

LiberatedLlama wrote: post #307
sirn wrote: post #214

Earlier quoted context omitted.

> Like Homebrew does not need elevated privileges to work and actively discourages it It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Ma…

Running untrusted software on these sort of systems is fundamentally broken, no matter what the package manager chooses chown or not chown. A malicious program could edit ~/.bashrc to modify the user's PATH, or wrap sudo with a keylogger then use that password to chown anything it likes. That's not even a theoretical but unlikely sort of attack; it's quite trivial. > alias sudo='echo not what I expected' > sudo foo n…

That's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.

Re: Homebrew 3.0

#324

Post by jakeva »

TameAntelope wrote: post #300

I am fascinated by the polarizing nature of Homebrew on HN. I've used both MacPorts and Homebrew, and I think the only reason I switched to Homebrew years ago was that Homebrew didn't try to install stuff at a system level, which felt more in line with a package manager that wasn't integrated into the OS. But I'm sure MacPorts is fine still. Why are people so strongly opinionated about this, particularly on the pro-M…

People are strongly opinionated about everything if the internet forums are any indication. I think the truth is more like opinionated people speak up, and most people just enjoy life.

Re: Homebrew 3.0

#325

Post by upbeat_general »

I realize this is a bit counter to the thread title but can someone who’s familiar with macports give their take on whether it’s worth using both brew + macports at once is a good idea? I’ve been solely using brew and very much appreciate the convenience but I saw that macports allows multiple versions of a single package which has been a pretty big pain point for me with brew. It doesn’t happen super often but there have been several times that this limitation for brew has been a huge pain point, forcing me to pollute things by compiling manually, putting it in a new location, etc.

I know it’s a bit far fetched but if my package manager could replace say, pyenv, by just making it easier to install several different versions and then letting me pick the default symlink, that would be so helpful (or even just not removing python2...).

Re: Homebrew 3.0

#326

Post by banana_giraffe »

loeg wrote: post #187
shagie wrote: post #128

Earlier quoted context omitted.

MacPorts and Homebrew have a different philosophy of software installation. MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain. This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. Homebrew, on the other hand, uses the system toolch…

> This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. > Homebrew, on the other hand, uses the system toolchain and tries to avoid using root. What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as a…

> Homebrew wants you to change ownership of /usr/local to your individual user

If I read homebrew's install.sh correctly, it changes ownership of a few directories under /usr/local, not /usr/local itself (on x86, on ARM it follows a different path). This matches how my current Mac, which has brew, is currently setup as well.

    # Required installation paths. To install elsewhere (which is unsupported)
    # you can untar https://github.com/Homebrew/brew/tarball/master
    # anywhere you like.
    ...
        # On Intel macOS, this script installs to /usr/local only
        HOMEBREW_PREFIX="/usr/local"
    ...
    directories=(bin etc include lib sbin share opt var
                 Frameworks
                 etc/bash_completion.d lib/pkgconfig
                 share/aclocal share/doc share/info share/locale share/man
                 share/man/man1 share/man/man2 share/man/man3 share/man/man4
                 share/man/man5 share/man/man6 share/man/man7 share/man/man8
                 var/log var/homebrew var/homebrew/linked
                 bin/brew)
    group_chmods=()
    for dir in "${directories[@]}"; do
      if exists_but_not_writable "${HOMEBREW_PREFIX}/${dir}"; then
        group_chmods+=("${HOMEBREW_PREFIX}/${dir}")
      fi
    done
    ... and further on, after some checks, group_chmods turns into chowns ...
    if [[ "${#chowns[@]}" -gt 0 ]]; then
      ohai "The following existing directories will have their owner set to ${tty_underline}${USER}${tty_reset}:"
      printf "%s\n" "${chowns[@]}"
    fi

Re: Homebrew 3.0

#327

Post by busterarm »

panopticon wrote: post #290
busterarm wrote: post #273

Earlier quoted context omitted.

You left out the entire generation of developers who are totally disconnected from how systems work and think that "it runs on my machine" should be good enough. Brew has lowered the bar enough that lots of folks simply don't have a clue how to deploy anything and worse, don't have a clue how to troubleshoot when something goes wrong in production. Obviously it's a double-edged sword. It's good to not waste time conf…

I don't understand this critique. Is this a complaint about package managers in general, or is `brew install git` lowering the bar from `apt install git`?

It's about a trend of developers who don't know how to interact with their system beyond `brew X Y` and the disconnect between the software on their Mac and the software on a production system.

There's a huge disconnect between A & B so much so that it's created an entire role for people like me that otherwise shouldn't exist.

I've been in the industry long enough to see a decline in ability for lots of developers beyond kicking deployment over the wall for someone else to figure out (not that this didn't exist before).

Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.

Re: Homebrew 3.0

#328

Post by sz4kerto »

desmap wrote: post #298

Not really on-topic but am I the only one? I stopped developing locally, my notebook is just a thin client ssh'ing into a remote dev server. I get all amenities like developing on the production os, no awkward package managers, 1 GBit up and down—always and anywhere and Docker pushes within few seconds.

VSCode made all this so much more convenient.

Re: Homebrew 3.0

#329

Post by lostcolony »

woodruffw wrote: post #245
jedbrown wrote: post #240

Earlier quoted context omitted.

Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.

> It speaks volumes that they are swimming in money and can't be bothered to make a token gesture. I agree with a lot of the sentiment here, but I want to make one important correction: Apple has helped us. In particular, they gave us access to DTKs for the M1 and provided us with a liaison for the migration. We're very thankful for that help. That being said, Apple is a massive company and they have their own develo…

Thanks for calling that out. This is totally unrelated to everything, but it's refreshing to see people giving credit -and thanks- to behemoth companies here on HN, with the proper nuance to also call out places they could have helped more (and the understanding of why they didn't). It's too easy, and common, to pile on the shortcomings. It struck me as a standout comment even in this generally polite community.

Re: Homebrew 3.0

#330

Post by busterarm »

upbeat_general wrote: post #302
busterarm wrote: post #273

Earlier quoted context omitted.

You left out the entire generation of developers who are totally disconnected from how systems work and think that "it runs on my machine" should be good enough. Brew has lowered the bar enough that lots of folks simply don't have a clue how to deploy anything and worse, don't have a clue how to troubleshoot when something goes wrong in production. Obviously it's a double-edged sword. It's good to not waste time conf…

Not everyone wants to troubleshoot things in production. In fact I’d argue most people dont want to do that. I’d certainly prefer to stay away from that type of hassle when I’m just trying to install a random package.

Nobody's saying you should want to.

This is a conversation about ability level.

Post reply on HN