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

Homebrew 7.0.0

brew.sh

Post reply on HN
Print view View original

141–150 of 270 posts

Re: Homebrew 7.0.0

#141

Post by bitexploder »

d3Xt3r wrote: post #3
mikemcquaid wrote: post #2

Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).

Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post. Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew. Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.

It is Rust now?

Re: Homebrew 7.0.0

#143

Post by llimllib »

artdigital wrote: post #52
Sytten wrote: post #36

I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug

I also started using Mise for global CLI tools instead of brew and it’s working really well Eg: mise use -g gcloud instead of brew install xxx It can even do that for npm packages! Like mise use -g npm:xxx

re: npm, if you upgrade your global node version, you will lose that installation, right?

Re: Homebrew 7.0.0

#144

Post by csande17 »

mikemcquaid wrote: post #133
tkel wrote: post #129

These release notes appear generated by LLM, with the usual extreme verbosity. Wish a human had done a better job editing these.

An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me. I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why…

FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:

> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.

> No replacement opt-out; unavailable Landlock remains advisory.

With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.

Re: Homebrew 7.0.0

#146

Post by gwking »

blixt wrote: post #57

I was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?

You can download Xcode 27 RC now from https://developer.apple.com/download/applications/.

Re: Homebrew 7.0.0

#147

Post by nxobject »

curt15 wrote: post #37
mikae1 wrote: post #21

Earlier quoted context omitted.

Thank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.

Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?

It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.

But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".

Re: Homebrew 7.0.0

#148

Post by apothegm »

throw0101a wrote: post #118

As a MacPorts users (generally light-weight, just a few things here and there): Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?

I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t.

Haven’t used MacPorts since. Has it gotten any better at those things?

Re: Homebrew 7.0.0

#149

Post by atombender »

assimpleaspossi wrote: post #72
atombender wrote: post #70

Earlier quoted context omitted.

Replace "need" with "want" and it might make more sense? Homebrew is the Mac equivalent of APT, Pacman, RPM, BSD ports, etc. It's a fairly traditional package manager for software that doesn't come with macOS. "brew install postgresql" installs Postgres into /opt/homebrew, for example.

So how does one install postgresql on a Mac?

"brew install postgresql", unless you meant without Homebrew, in which case you could download the sources manually and compile with "make".

Re: Homebrew 7.0.0

#150

Post by staplung »

bitexploder wrote: post #141
d3Xt3r wrote: post #3

Earlier quoted context omitted.

Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post. Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew. Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.

It is Rust now?

It's still in ruby, although I see the new GUI is in swift: https://github.com/homebrew

Rewriting a program in Rust (specifically) really only makes sense for a few reasons:

1) the existing implementation is in an unsafe, cumbersome language (C, C++).

2) the existing implementation language is too slow and that slowness cannot be worked around.

3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.

1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.

Post reply on HN