Live data from Hacker News

Homebrew 3.0

brew.sh

381–390 of 516 posts

Re: Homebrew 3.0

#381
post #230

Earlier quoted context omitted.

Meanwhile providing money for no reason to Homebrew wouldn't make business sense. As far Apple is concerned, Homebrew works, and providing financial support wouldn't make it work better. This is idiotic.

Try putting on your management hat. Would you approve donating money to some random project that vaguely benefits the users of your platform, with no apparent reason? After all, the Tool seems to work fine and nobody is complaining. You can surely imagine the course of such an initiative inside Apple.

> some random project that vaguely benefits the users of your platform

Be interesting to see what percentage of users actually install Homebrew - I'd wildly stab in the dark about 25-30%, tops?

Re: Homebrew 3.0

#382

I personally found Homebrew to be really helpful when I looked at MacOS as a unix environment and tried to engage in local development as if it were a unix environment. [Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for w…

I agree with this.

I use homebrew on my personal machine mostly to get more modern versions of the terribly outdated commands that Apple ships but that's .. a small surface. I don't use it for anything really appropriate and would not.

Professionally - for people who build locally on the mac - the sheer awkwardness of pinning specific versions so all developers have a common environment regardless of install order or timeframe is quite painful with homebrew vs. apt.

Re: Homebrew 3.0

#383

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…

[deleted]

Re: Homebrew 3.0

#384

Earlier quoted context omitted.

Fair point, but I bet the number of Macs in the wild shared by multiple people who would want to run Homebrew are vanishingly small.

Sure, but it's a native feature built into the Mac platform. If software is going to prevent that from working properly, then that should be communicated very clearly.

Is this an issue in practice in more than a rounding error number of Macs? I'd bet lots of money that the vast majority of developers (that is, people likely to be installing Homebrew in the first place) are using effectively single-user systems.

Re: Homebrew 3.0

#385
post #292

Earlier quoted context omitted.

Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg. M…

MacPorts does also still drop to compiling from source more often than Homebrew. But that’s mostly because they take a more conservative legal approach towards the GPL—for instance, they won't distribute binaries of any GPL software that links with OpenSSL. Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparis…

> Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair point of comparison.

On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.

Re: Homebrew 3.0

#386

Earlier quoted context omitted.

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

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

I dunno who says that but they're dead wrong. I'm working as a dev somewhere with a dedicated DevOps finally after years of being dev + ops (+dba +sysadmim +qa) and I can't tell you how much of a relief it is to have other people shoulder that stuff so I don't have to think about it.

I understand your point that devs who have a higher level understanding of systems and deploy pipelines and such are probably able to write good systems themselves, but when it comes to the humans doing the work? I absolutely love having it separated.

Re: Homebrew 3.0

#387
post #292

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…

Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg. M…

This is one reason why using Rust crates in cargo's current form irritates me, if I wanted that kind of experience I would be using Gentoo as daily driver.

All the other languages I use support binary libraries on their package managers.

Re: Homebrew 3.0

#388
post #317

Earlier quoted context omitted.

Yes. I'm really torn about brew. On the one hand, I hate to crap on the work that the maintainers have done, and it's clearly the best thing out there for macos. On the other hand, it's a terrible dictatorial piece of software that wants to command precisely how you use your computer; those same maintainers are actively hostile to users, as evidenced by the endless stream of nasty responses to issues, arbitrary chang…

Ah, this reminds me of how shitty the maintainers were to me when I said I was using hackintosh (for an issue that had nothing to do with it).

Apologies about that. I’m sure none of us wants to be shitty to anyone. It’s never ok when we are.

Re: Homebrew 3.0

#389
post #292

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…

Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg. M…

This is a weird take.

Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).

Re: Homebrew 3.0

#390

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 agree with this (other than maybe hating to see Homebrew “win”). And I’ll add:

And although I’m not arguing Homebrew is above reproach or critique, some of the criticism here seems both a little unfounded and a little bit ignorant (either willfully or because people just don’t know/remember) about the state of package managers BEFORE Homebrew. Like you, I used MacPorts/Darwinports and Fink for years before Homebrew was a thing and have immense respect for all three of those projects (even though DP merged with MP over a decade ago, my mind still sees them as separate things) and the massive role they played in my own life and development as a developer, but Homebrew didn’t just pop-up and supplant the existing options and through nefarious means.

At the time that it came to existence, despite the very good existing options, those communities and their progress had stagnated — at least from the perspective of the end user. There was a wealth of older packages, but newer stuff wasn’t there. And the death of PPC with Snow Leopard hit subsets of that community hard. It wasn’t just that Homebrew was easier to use and install (though it was, a bit), it was that it had more modern and more frequently updated packages.

I distinctly remember when Homebrew first arrived, my initial reaction was, “why do I need this, I already have MacPorts?” But then I used it and found that people were bottling up newer stuff at a much more rapid pace and the tools embraced by that community were modern and frankly, to an outsider, much more accessible. As you said, choosing GitHub over MacForge or whatever was a great choice too.

MP has had a renaissance of sorts over the years which has been amazing to see. I think having options is awesome. But Homebrew was very much filling a void for some beloved projects that had fallen behind. It’s hard to win that momentum back, once the community (including a whole generation of new users) goes to the new thing.

We’ve seen that with Mac text editors too. TextMate, to me, is still one of the best editors I’ve ever used and I would argue is one of the most influential software applications of the aughts. But as it faced all of its challenges to move to 2.0 (the feature creep, the technical challenges, the scope changes), it created a window for Sublime to come in and take the the extension community (which was really pioneered in the way that it worked by TextMate), and thus the userbase with it. And when Sublime faced similar challenges in its own troubled releases (for some of the same but also different reasons that TextMate had), we again saw momentum shift to VS Code.

Post reply on HN