Live data from Hacker News

Homebrew 3.0

brew.sh

451–460 of 516 posts

Re: Homebrew 3.0

#451

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.

Homebrew maintainer here: I'm sorry that we don't meet your expectations. Two things for your consideration: 1. It's uniquely visible among system package managers. When people have problems with a package in `apt` or `dnf`, they find a community or third-party repository for the package or bug the upstream directly. By contrast, Homebrew has always been visible on GitHub, does not require a special login to a bugtra…

I think that #2 might not happen as often if Homebrew better conformed to a "UNIXy" philosophy. And to Apple's philosophy, because there is a sort of mentality to how they operate, even if you can't predict exactly what they'll do.

MacPorts hasn't had as many of these issues over the years, and I suspect that's largely down to mindset. Broadly speaking, MacPorts seems to have "first, do no harm" approach to almost everything. They don't install files in directories they didn't create, and they avoid depending on systems which are out of their control.

Re: Homebrew 3.0

#452
post #52

Earlier quoted context omitted.

> Apple would be fools to not support it financially. Since people are already doing an excellent job for free, why would they start paying them? Clearly the lack of Apple funding has not hurt the project thus far.

One could say Homebrew is successful despite Apple not trying to even mention their name, even less help them be successful. Many groups also look at successful groups and think "How can we make them more successful?" but don't think that's in Apples DNA.

Apple has mentioned Homebrew; a screenshot of it is the banner on their Twitter account.

Re: Homebrew 3.0

#453
post #429

Earlier quoted context omitted.

I've switched to Nix and never looked back, thanks to Homebrew embedding spyware into the package manager. I keep my non-system apps in ~/Applications and back them up with the rest of my files.

> spyware Please.

Apps that silently transmit your activity without consent are spyware. It's an objective evaluation.

Re: Homebrew 3.0

#454

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. And it’s important for devs to have up to date tooling. There is no money to get from it. And developers are not the "end user" for Apple anymore. I don't see why Apple should even care about Homebrew.

Not directly, but developers provide Apple with billions of dollars in value every year.

Re: Homebrew 3.0

#455

Earlier quoted context omitted.

The fact that AAPL doesn't support brew's maintenance and development is a great reason to not buy more macs.

Apple is invested into MacPorts (and also pays several employees working on it).

To be fair, I think the number of employees specifically paid to work on MacPorts is probably zero. The ones that do work on it seemingly do it in addition to their regular duties.

Re: Homebrew 3.0

#456

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'm interested in this workflow, some questions:

- When you say "local editor, remote runtime", are you referring specifically to VS Code's remote development features?

- Is the remote runtime a Linux VM on the same machine, or running on another machine?

- Do you run git locally?

- Do tests run locally?

- Do you have a link to an article detailing this workflow?

Re: Homebrew 3.0

#457

If anyone from Homebrew is lurking on here. Thank you. I’m working with my management team to send a donation your way. We’ve been using it for IT and Engineering deployment builds for years and it’s something we feel we owe as a sign of gratitude and to keep the project running. Thank you again!

You’re welcome! Glad it’s useful to you. Appreciate your shout-out and donation!

Re: Homebrew 3.0

#459

Earlier quoted context omitted.

Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPorts. A more current update to this post would probably be more helpful. In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement. [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...

> found it a bit cumbersome with the “no sudo” requirement This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?

Yes, it does; you can just configure it with --prefix (to move it out of /opt/local) and --with-no-root-privileges. The downside is that you won't be able to use the binary packages anymore, but I think that is true for Homebrew as well.

Re: Homebrew 3.0

#460

Earlier quoted context omitted.

I don't buy the premise that package managers are the reason why companies need DevOps. Software deployment has gotten complicated for a variety of reasons (containerization, micro-services, continuous integration, cargo-culting FAANG practices, etc). When I first started my career, I FTP'd my code changes into the single production server that ran both Apache and MySQL. Homebrew is not the reason I don't do that any…

That's not really the argument that I'm making. I am a deployment engineer. Deployment is actually really easy. I'd argue that it's not far off from FTPing your code changes over in terms of difficulty. No, my argument is that more engineers today do not know how computers work. I'd even argue that many engineers would find FTPing over code changes to be too difficult (or they'd screw it up). My argument is that home…

Homebrew was the first package manager where I actually looked under the covers because everything was pretty easy to follow. I regularly use 'brew edit ' just to see how something is built. I don't see how brew obscures the internals of my computer at all.
Post reply on HN