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

361–370 of 516 posts

Re: Homebrew 3.0

#361

Post by bhaak »

bacon_blood wrote: post #77
bhaak wrote: post #62

Earlier quoted context omitted.

Homebrew is what a package manager would look like if Apple was doing it. So quite limited in scope and not much configurable options and if you say that you need some features, they'll tell you you're doing it wrong. It is quite easy to install though and has a lot of packages but if you have specific needs that are unmet, you are on your own. It's more of a update manager than a true package manager.

I disagree. Apple would spend the time to make universal binaries work (unlike homebrew, who has stated they won't support them). Not installing universal binaries has some bad implications for Rosetta for developers. Having mixed single processor binaries in PATH can cause architectures to switch unexpectedly for subprocess chains (like when running a build tool), or even get "bad CPU type" errors in some contexts i…

Universal binaries matter most for closed source. With Homebrew being used for Open Source software it’s by far not a priority for the generic user.

The last years have shown clearly that Apple doesn’t go out of their way to make things easy for devs if it doesn’t helps their main client group.

Re: Homebrew 3.0

#362

Post by soraminazuki »

sirn wrote: post #191
SkyMarshal wrote: post #79

Earlier quoted context omitted.

Fwiw you can use the Nix package manager ( https://nixos.org/ ) on OS X to accomplish those same things. Lots of discussion about that the past few years: https://google.com/?q=nix+on+mac+os+x Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there. And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew…

Unfortunately, Nixpkg doesn't check buildability on Darwin when merging PRs, so things can break quite often on the nixpkgs-unstable channel (compared to nixpkgs-unstable on Linux). It's not hard to rollback, though, but it does makes me never want to ever run `nix-channel --update`.

nixpkgs CI does check for buildability on Darwin, which can be confirmed by looking at any of their PRs. However, packages do tend to be get marked as broken on Darwin if it doesn’t build and the packager doesn’t own a Mac.

I feel things have stabilized significantly in recent days, though. I haven’t had a single Darwin breakage on the unstable channel since the release of 20.09. Perhaps the Zero Hydra Failures effort[1] helped.

[1]: https://github.com/NixOS/nixpkgs/issues/97479

Re: Homebrew 3.0

#363

Post by Wowfunhappy »

mikepurvis wrote: post #304
optimuspaul wrote: post #278

Earlier quoted context omitted.

I am confused by this. sudo seems like a far larger surface area than running as me. If it's just me then it's just me, but if it's sudo, then it's the entire box.

It depends whether you trust the tool maintainers more than the package definition maintainers. I certainly would. But don't take my word for it— here's a MacPorts developer explaining the sandboxing of builds: https://apple.stackexchange.com/a/106942

> Directories listed in multiple users' $PATH that are writable without superuser privileges can be used for attacks (e.g., by placing a sudo binary that will log the password there). The same can be done by malicious software running as your user in order to get your password

Yikes. That particular attack did not occur to me.

Re: Homebrew 3.0

#364

Post by shagie »

ashtonkem wrote: post #172
shagie wrote: post #128

Earlier quoted context omitted.

MacPorts and Homebrew have a different philosophy of software installation. MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain. This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. Homebrew, on the other hand, uses the system toolch…

Given the moving nature of the OSX toolchain and directory structure, having your third party package manager integrated into the system toolchain increasingly feels like a bad idea.

The flip side of that is "do you want to have two scripting and compiler toolchains installed on the machine - one that gets updates from the vendor and one that gets updates from volunteers?"

The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated.

I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up.

That's a "my experience" story and isn't meant to be defining.

I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them.

For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.

Re: Homebrew 3.0

#365

Post by panopticon »

busterarm wrote: post #327
panopticon wrote: post #290

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…

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

Re: Homebrew 3.0

#366

Post by anaerobicover »

banana_giraffe wrote: post #326
loeg wrote: post #187

Earlier quoted context omitted.

> This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. > Homebrew, on the other hand, uses the system toolchain and tries to avoid using root. What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as a…

> 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

Re: Homebrew 3.0

#367

Post by gigatexal »

So glad I sponsor this project. The mac would be entirely harder to use as a development platform without these package managers (this praise includes all the efforts not just that of Homebrew). Donate here: https://github.com/homebrew/brew#donations

Note: I am not affiliated with the project in anyway other than being a backer and a user.

Re: Homebrew 3.0

#368

Post by busterarm »

panopticon wrote: post #365
busterarm wrote: post #327

Earlier quoted context omitted.

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…

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 homebrew makes some amount of contribution (not 100% the reason for) engineers remaining ignorant about computers.

Re: Homebrew 3.0

#369

Post by brailsafe »

peteretep wrote: post #113
cwxm wrote: post #3

I can’t even begin to imagine how much value Max Howell (creator of Homebrew) has added to the world. It’s the recommended package manager at every place I’ve worked at and saves so much headache. I use Linux at home and package managers like AUR are great, but macOS is where the users are.

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.

This seems like a rather exceptional, unsubstantiated, and mean spirited take. I've run into some strange issues with brew over the years, but compared to npm and apt it's been far less prone to causing me headaches.

Re: Homebrew 3.0

#370

Post by Wowfunhappy »

kstrauser wrote: post #350
Wowfunhappy wrote: post #109

Earlier quoted context omitted.

The problem is that the way they do it breaks the UNIX model. /usr/local is common to all users, but Homebrew gives it the current user's permissions. This consequently creates weirdness if you actually use multiple user accounts.

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.
Post reply on HN