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

501–510 of 516 posts

Re: Homebrew 3.0

#501

Post by bacon_blood »

bhaak wrote: post #495
bacon_blood wrote: post #438

Earlier quoted context omitted.

No. This isn't fixed by open source. Open source projects also do binary releases (see brew cask), and those need to be universal as well. Someone needs to build those universal binaries, and homebrew has decided to be incapable as a platform to do that by refusing to ship universal binaries. It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software…

Cross-compiling is a need that almost no user ever has. The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode. There would be now need for a Apple Homebrew to use or provide universal binaries. Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment…

I just checked your profile and it seems like you're a command line software developer for Linux. I'm not sure why you're telling a Mac developer what Mac developers do and don't need, or what use cases are "legitimate".

I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't respond further unless you are absolutely confident your position is in good faith and supported by personal relevant experience.

Re: Homebrew 3.0

#502

Post by loeg »

anaerobicover wrote: post #366
banana_giraffe wrote: post #326

Earlier quoted context omitted.

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

Parent's information is outdated, but originally/historically Homebrew did want you to chown /usr/local

As recently as like, 1-3 months ago, yeah? I would have tried to install homebrew for the first time sometime December 2020 or later.

Re: Homebrew 3.0

#503

Post by brmgb »

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 don't think Homebrew took the field purely through sneaky marketing or n00b decisions alone.

The Homebrew team was using a lot of FUD regarding MacPorts when Homebrew started. It's actually funny because they were criticizing some of MacPorts decisions which they then had to implement when they finally realized they were the correct engineering decisions years later.

Re: Homebrew 3.0

#504

Post by bhaak »

bacon_blood wrote: post #501
bhaak wrote: post #495

Earlier quoted context omitted.

Cross-compiling is a need that almost no user ever has. The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode. There would be now need for a Apple Homebrew to use or provide universal binaries. Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment…

I just checked your profile and it seems like you're a command line software developer for Linux. I'm not sure why you're telling a Mac developer what Mac developers do and don't need, or what use cases are "legitimate". I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't res…

Do you think command line software developing for Linux is a paid full time job? My day job is on macOS where I've been using Homebrew for about 7 years.

I know its warts. I don't say that it isn't broken for the usecase you are describing. I'm saying that like the Homebrew developers, if Apple were in charge of Homebrew, they wouldn't care about such a use case because it would only affect a tiny percentage of their user base.

If you don't believe that just look how old the user base command line tools are that are installed by default on macOS.

For example bash is "GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17), Copyright (C) 2007 Free Software Foundation, Inc." That's 14 years ago.

Re: Homebrew 3.0

#505

Post by brmgb »

jasonwatkinspdx wrote: post #254
quesera wrote: post #166

Earlier quoted context omitted.

But Homebrew wasn't (and isn't) better than MacPorts, either. They both work well (we can and do quibble about the internal mechanics of each), and appeal to different groups of people. My theory is that Homebrew was announced at exactly the right time in the MacOS adoption curve. A huge number of new users arrived with no existing knowledge of MacPorts or Fink. Most of them didn't know they needed a package manager…

I used MacPorts before Homebrew was a thing, and had plenty of experience with bsd ports going back to the late 90s. Homebrew was just straight up better, no doubt about it. It wasn't "noobs," "good timing," or "tricky marketing." They were just better, even if still not what these posters desire.

> They were just better

No offense but we are talking about a "package manager" which:

- complained when you installed things in /use/local (where they belong) not managed by itself;

- had a flag to install packages somewhere else which broken half of the packages because they were so poorly written and no one was checking;

- messed with the permission of the file system for no good reason wahtsoever;

- would fail to properly update its own package list if you waited too long because the way they used git was broken beyond belief.

As I never had any of these issues with MacPorts, I might suggest you have a very low ceiling for what you call better. It pains me so much that you have to use Homebrew if you want to have recent packages.

Re: Homebrew 3.0

#506

Post by bacon_blood »

bhaak wrote: post #504
bacon_blood wrote: post #501

Earlier quoted context omitted.

I just checked your profile and it seems like you're a command line software developer for Linux. I'm not sure why you're telling a Mac developer what Mac developers do and don't need, or what use cases are "legitimate". I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't res…

Do you think command line software developing for Linux is a paid full time job? My day job is on macOS where I've been using Homebrew for about 7 years. I know its warts. I don't say that it isn't broken for the usecase you are describing. I'm saying that like the Homebrew developers, if Apple were in charge of Homebrew, they wouldn't care about such a use case because it would only affect a tiny percentage of their…

This is a software supply chain issue, but it likely doesn't interest Intel Mac users who are still using x86 homebrew and who can't empathize with the experience of the upstream developers for all the Mac software they use.

Re: Homebrew 3.0

#507

Post by einpoklum »

Hackbraten wrote: post #425
einpoklum wrote: post #180

I'm not familiar with Homebrew. Is it the kind of thing I could use to manage packages in my own directory as a non-root user (on Linux)? If so, will it be able to base itself on what my distribution offers, or will it build things up from scratch with its own toolchain packages?

> Is it the kind of thing I could use to manage packages in my own directory as a non-root user (on Linux)? Yes, exactly. Not sure what exactly you mean with your second question though.

I mean, will it try to use the libraries and toolchain components available on my system to build other packages which I download, or will it kind of bootstrap its own toolchain for building?

Re: Homebrew 3.0

#508

Post by Hackbraten »

einpoklum wrote: post #507
Hackbraten wrote: post #425

Earlier quoted context omitted.

> Is it the kind of thing I could use to manage packages in my own directory as a non-root user (on Linux)? Yes, exactly. Not sure what exactly you mean with your second question though.

I mean, will it try to use the libraries and toolchain components available on my system to build other packages which I download, or will it kind of bootstrap its own toolchain for building?

From https://docs.brew.sh/Homebrew-on-Linux:

> Homebrew does not use any libraries provided by your host system, except glibc and gcc if they are new enough.

Re: Homebrew 3.0

#510

Post by weaksauce »

Hackbraten wrote: post #450
saagarjha wrote: post #446

Earlier quoted context omitted.

I'm surprised it still works, to be honest–Homebrew is usually fairly aggressive about dropping support for older systems.

We don’t support any scenario where things are built from source (i. e. we won’t help you if things break) so technically support has indeed been dropped.

Is there no way to enable downloads of builds in homebrew on those systems with the caveat that perhaps it'd have to go back to compiling if there aren't any?
Post reply on HN