Live data from Hacker News

Homebrew 3.0

brew.sh

351–360 of 516 posts

Re: Homebrew 3.0

#352
Dear Homebrew maintainers,

one simple effing thing: thank you! For all the hard work and the sheer pleasure Homebrew adds to the experience of developing software on a Mac.

Re: Homebrew 3.0

#353
post #189

Earlier quoted context omitted.

I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked. Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.

This, so much this. I tried to use MacPorts. It was pulling teeth every time. Brew was a It Just Works breath of fresh air. I agree that it's a very opinionated tool, and note that those opinions fit in well with the Mac ecosystem. They aren't as good a fit for Linux or Windows.

I think often 'it just works' and 'opinionated' goes hand in hand. Without choosing what to say no to, you create infinite workload with finite amounts of people and thus something breaks, somewhere.

Re: Homebrew 3.0

#354
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…

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

(As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)

Re: Homebrew 3.0

#355

Earlier quoted context omitted.

I only use it because IT forces Macs down our throats. It's understandable, the hardware is light years ahead of any other manufacturer, along with the OS support. But I just do the bare minimum of setup to get VNC and SSH working and GTFO to a proper remote dev box.

> But I just do the bare minimum of setup to get VNC and SSH working Lucky for you those are both fully supported out-of-the-box, and have been for a couple of decades. Sounds like your IT team is forcing the right solution down your throats.

It's a matter of opinion and the opiner I guess. To go from factory OS to be able to run what's on the server side is not simple, and has been brittle. For me a better solution would be a Linux native box with the same distro & configuration to be able to avoid the VNC remote altogether. But for the company, perhaps that kind of solution would have costs in support and maintenance that would make it a bad choice.

Re: Homebrew 3.0

#356

Earlier quoted context omitted.

Contrarian view here: brew fucking sucks. It’s the worst package manager I’ve used for doing random unwanted updates at odd times. Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better. I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming. There, I said it.

> I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming. You may be interested in trying out nix for package management [1], or even for configurations and providing development environments (see my other comment [2]). [1]: https://builtwithnix.org/ [2]: https://news.ycombinator.com/item?id=26038614

When I tried nix on my mac a while back, it took forever to install basic things, had very verbose logs, was far more complicated and was missing packages. Is it still like that?

Re: Homebrew 3.0

#357

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…

I wasn't even aware it was polarizing. Have enjoyed using it for the past 6 years and never thought much about it. The comments of "it sux", "worst thing ever" feel very petulant.

Love that i can install/update the packages i might need and get on with my day.

Re: Homebrew 3.0

#358

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 find it unfortunate that those two occupy the 1-2 in Mac packaging options. It never really got much attention, but I've always liked Rudix [0] better. The package selection is much worse and not really kept as up-to-date, but the installation mechanism is far superior to Homebrew and MacPorts (and even Fink). It uses actual packages (the kind that Installer.app understands) so it integrates much more cleanly with the Mac ecosystem and packages installed without using the package manager. Compared to the other options, it's an administrator's dream in a managed environment since all the first-party Apple tools for managing a fleet of Macs just work. Also, users who don't want to install the actual rudix tool can simply download the packages and install using using Installer.app (which they may never even realize they're running because it opens automatically when opening a .pkg file).

Unfortunately, most Mac users have never even heard of it and it doesn't really have the momentum or mindshare necessary to have a complete, up-to-date list of packages.

[0] https://rudix.org/

Re: Homebrew 3.0

#359
post #35

Earlier quoted context omitted.

It’s Weird that Apple doesn’t do this themselves. It’s not like they don’t have a cash. And it’s important for devs to have up to date tooling. This intrepid band of volunteers are adding huge value to one of the largest corporations on earth. I appreciate the DIY effort of anyone who volunteers, though I see the donate tab on their website and sigh a little.

> It’s Weird that Apple doesn’t do this themselves. It’s not like they don’t have a cash. I can understand them not wanting to do it themselves. I don't think they want to take on the responsibility for maintaining all those packages (for legal reasons or otherwise). Because it's a "not officially Apple" thing, Homebrew can probably get away with a "no warranty" sticker that an official Apple project couldn't. What A…

Apple needs to dump a truck of money on their own developer tooling team and double every team size. If you knew how small they were you would be surprised!

Xcode / swifts build speed is still pretty bad, xcode still chokes on large projects, codesign is an eternal flaky nightmare, they still don't have first class command line support for many things, they don't have network indexing & build caching like bazel does, it's worse than android for maintaining a device lab for testing (adb vs... `instruments` kind of) and on and on it goes.

Post reply on HN