Live data from Hacker News

Homebrew 3.0

brew.sh

481–490 of 516 posts

Re: Homebrew 3.0

#481
post #429
post #34

Brew is great. I’ve switched to using Nix as much as I could but most “Apps” aren’t supported yet where `brew install —cask` has it right away. Always nice to know Brew will always have the latest version around. The only problem with that ends up being that if you use brew for development dependencies like Node or Python you can’t manage multiple versions. Nix being the most powerful in this area.

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.

Recently made my first PR to nixpkgs. Definitely looking to see what it takes to manage more *.apps using only Nix.

Luckily this is much less of an issue on my NixOS desktop or EC2 instances.

Re: Homebrew 3.0

#482
post #298

Not really on-topic but am I the only one? I stopped developing locally, my notebook is just a thin client ssh'ing into a remote dev server. I get all amenities like developing on the production os, no awkward package managers, 1 GBit up and down—always and anywhere and Docker pushes within few seconds.

I never get people trying to set things up locally. You put stuff on a remote Linux server and the problems are instantly gone.

There are enough tools to work efficiently on a remote server and you can easily access what you do there from another machine.

Re: Homebrew 3.0

#483
post #443

Earlier quoted context omitted.

Along with Hackbraten's answer — I don't know if this would be more or less work for you but would a per-user Homebrew installation help? I don't have any multi-user machines but for years I've kept my Homebrew installation in ~/Homebrew, where I have complete ownership of it. (Really you can install Homebrew in any directory) Or would the space/compilation cost be prohibitive? Not a Homebrew maintainer, just a satis…

On macOS, one major drawback is that if you use a non-standard installation directory for Homebrew, you can no longer install binary packages and everything is compiled from source. If you can live with that, you should be fine though.

Not anymore, right? I've noticed that recently, many formula which don't longer require `/usr/local` specifically actually install from bottles, which has been neat.

Re: Homebrew 3.0

#485

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

This is very interesting, and maybe sheds light on why Google decided not to hire Max. There seems to be some consensus that MacPorts has the better architecture, while Homebrew has been better at responding to users, even according to Max himself. For Google, it's likely the former is more important than the latter for a lot of their projects. An architecture that doesn't scale or doesn't always do the right thing o…

> There seems to be some consensus that MacPorts has the better architecture

There isn’t, Homebrew is far superior in my opinion, and everyone I know using a Mac. We all left MacPorts ages ago.

It’s safe to say that has nothing to do with him not getting the job.

Re: Homebrew 3.0

#486
post #315
post #119

The majority of the ports and software I want installed are essentially Unix/Linux/GNU environment tools. Macports has always seemed to me to be a more "unix-y" way of doing that, and it works politely with Apple's ways on top of the Unix core (eg locking down the system volume). It also has a very nice "select" and "variants" system that allows you to have multiple versions of a package as well as packages with more…

Why is it bad that homebrew puts files in /usr/local? Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installati...

/usr/local was originally for local (ie host) software that wasn't in /usr/{bin,lib,sbin,slib...} or /{bin,lib,sbin,slib...}.

Then GNU took over and made some opinionated choices about how those subdirectories were to be used, which is fine.

However, because /usr/local is under /usr, it meant that it was more difficult to mount /usr as read-only or shared. There is also the issue of whether files under /usr/local should be owned by non-system users.

A while back, the creation of /opt and /opt/{some-app} (and /var/opt/{some-app} became a way to avoid writing into /usr and also made it possible to mount applications with their code as read only with writable locations under /var.

So I've taken writing to /usr/local as a packaging smell these days, purely to avoid writing into /usr.

Re: Homebrew 3.0

#487
post #468

Earlier quoted context omitted.

It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.

Are you sure about that? I currently have it installed in ~/brew and commands link from ~/brew/Cellar into ~/brew/bin and there is a .git directory in ~/brew. I used to put it in /usr/local and it irked me that there was a /usr/local/.git. That was the main reason I stopped putting it there.

They used to put the repo in /user/local but moved it to /usr/local/Homebrew a few years ago.

Re: Homebrew 3.0

#488
post #275
post #250

Earlier quoted context omitted.

MacPorts seem to be very “user” friendly for people with Unix and/or Gentoo (maybe a bit Arch too) background. I have experience with all three and when I needed to decide in between HomeBrew and MacPorts, it was very simple choice. I tried both to get the actual experience and stuck with MacPorts. All the naming in HomeBrew was just too confusing too me.

I've never used MacPorts. Go figure, I just realized that "MacPorts" means "bsd ports for mac". I'll have to try it sometime and see if I prefer the look and feel of MacPorts.

I've found it rather easy to use, I've only been a mac user for a couple of years. I've not had any problems with updates either. I switched from brew fairly quickly when brew told me I couldn't install packages because they weren't "safe" even though I knew they were in fact fine because I've used them for years on linux.

Re: Homebrew 3.0

#489

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.

brew is an amazing achievement. It doesn't do random unwanted updates at odd times. It doesn't do anything at all unless you run run it. And it tells you want it will do beforehand. Nobody would have "filled the void" - building software isn't a zero sum game. If someone had something better they would have continued to work on it and it would have "taken over". There, I said it.

That is incorrect. Brew will do random upgrades when running `brew install` unless you set the non-default `HOMEBREW_NO_AUTO_UPDATE=1` [1] so every now and then when you brew install something it will e.g. upgrade the python binary from 3.x => 3.(x+1) and break all virtualenvs using symlinks. Python is just one example, I've spend countless time fixing random broken packages due to the unpredictability of `brew install`.

[1] https://github.com/Homebrew/brew/issues/1670

Re: Homebrew 3.0

#490

Earlier quoted context omitted.

It seems to me that if you compare Apple and Microsoft, it's only the latter that cares deeply about the developer experience on their platform. https://github.com/microsoft/winget-cli

That's been mostly true since both of the company's founding (Microsoft in 1975 and Apple's in 1976). What was Microsoft's first product? Basic. Microsoft's Basic ran on the most popular home computer platforms of the day (except Apple's). Even Commodore's Basic was fully interoperable with Microsoft's. What was Apple's first product? A computer. A computer meant for people not having a CS background. The Apple II ki…

Pedantically, while it's true that the Apple II originally shipped with Steve Wozniak's Integer BASIC interpreter, a Microsoft BASIC implementation, Applesoft BASIC, was licensed soon after the II's release and replaced Integer BASIC in ROM on the II+ and all future models.

Also, to be fair to "graphic artists ... and the like", one of the reasons the Mac platform remained popular among graphics arts professionals through the '90s was that system-level inter-application scripting, added to the platform in 1993, was well-supported by both Apple and third-party application vendors, whereas analogous cross-application scripting in Windows was mostly limited to Microsoft Office products.

Post reply on HN