Live data from Hacker News

Homebrew 3.0

brew.sh

431–440 of 516 posts

Re: Homebrew 3.0

#431
post #344

But does it still try to update literally every time you use it?

If you set HOMEBREW_NO_AUTO_UPDATE to 1, it won't update when you run the install, upgrade, and tap commands like it normally does

Also don't forget HOMEBREW_NO_ANALYTICS=1 in your environment to keep it from silently phoning home a machine-specific unique identifier and your client IP (city-level geolocation) to Google every time you run it.

https://github.com/Homebrew/brew/issues/142

Re: Homebrew 3.0

#432

When do we get to install brew without sudo?

You can install it unprivileged somewhere in your home directory and it will generally work fine, even though they warn you against it.

Re: Homebrew 3.0

#433
post #4

/me searches changelog for "`brew update` now runs asynchronously and doesn't block the process to install a 3 year-old package." Dismayed, I do not find it. Asynchronous formula updates would IMO save the most Mac man-years of almost any macOS tool.

You can set up launchd to run `brew update` and `brew upgrade` regularly -- it's what I do.

Don't do this if you're attached to specific versions of any formulae you have installed. You can try `brew pin`ning them though.

Re: Homebrew 3.0

#434

Earlier quoted context omitted.

Yes, he posted more information in an answer on Quora[1] to clarify why he felt he was turned down. [1]: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

> But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that. Actually, no. There's no level of rockstarness that excuses being a dick and difficult to work with. That kind of attitude can turn a who…

> I am often a dick, I am often difficult, I often don’t know computer science, but. BUT.

I'll stop him right there. Definitely not googley.

Re: Homebrew 3.0

#435

Earlier quoted context omitted.

Gentoo is probably the most user hostile Linux distribution I can think of other than ones purposely austere for learning (LFS) or parody (Suicide Linux). If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.

Hostile, as in not everything is mouse clicky for you? It was a great learning experience nearly 20 years ago. It's just not for you.

It was a great learning experience for me too.

It's just not user friendly.

It was my first experience with linux in 2003, going through some 80 page wiki to get things configured and built. Learning how to configure an fstab file.

Hostile as in everything requires following a multipage guide of commands and manual configuration that often didn't quite work. Also when I asked on the forum I was told they didn't want more users, but more skilled users (I was 12).

So not really mouse clicky, more that basic functionality takes enormous effort to get working and the community at the time wasn't great.

Re: Homebrew 3.0

#436

Earlier quoted context omitted.

> Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be. I dunno who says that but they're dead wrong. I'm working as a dev somewhere with a dedicated DevOps finally after years of being dev + ops (+dba +sysadmim +qa) and I can't tell you how much of a relief it is to have o…

It feels nice but organizations with cross-functional teams are outmaneuvering yours and probably by at least 3x. I'd rather work harder at a business that succeeds and has equity that's worth a damn.

That's fine, I'd rather work on stuff I enjoy and have a life outside of work.

Re: Homebrew 3.0

#437

Earlier quoted context omitted.

> 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

Actually (I can't edit the original comment anymore) it looks like they were still recommending this as recently as last year?? https://discourse.brew.sh/t/permission-problems/3011/29

Haven't used Homebrew in quite a time, so I'm not sure.

Re: Homebrew 3.0

#438
post #361

Earlier quoted context omitted.

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.

No. This isn't fixed by open source. Open source projects also do binary releases (see brew cask), and those need to be universal as well. Someone needs to build those universal binaries, and homebrew has decided to be incapable as a platform to do that by refusing to ship universal binaries.

It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer.

Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild).

Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects).

I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.

Re: Homebrew 3.0

#439

Earlier quoted context omitted.

The usual non-productive rant. What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project? "It sucks" doesn't help anyone understand your frustrations and does not serve the message you're trying to share (let this one be valid or not). Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who app…

> What prevents you to do it better then? The mindshare of nearly the entire community that develops software for the Mac. Homebrew, the tool, is inferior to several other options, but developers of software treat it as the one true package manager on Mac. It's so frustrating to see projects offer it as the only supported way to install their software on Mac apart from building it from source. Your question reads lik…

I think the big difference is that Homebrew, unlike Facebook, is open-source (and doesn't have a huge trove of data to protect, leading them to go after third-party clients).

It's plausible that you could just write a front-end that keeps using the same remote package repository, that fixes everything you complain about.

I suppose it depends on what exactly your complaints are, but most of the complaints here (CLI, auto-update, etc) seem like they could be addressed with just a client fork.

Re: Homebrew 3.0

#440

Earlier quoted context omitted.

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…

Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.

Apple swims in money and can't even be bothered to implement a hassle-free way of changing your Apple ID, especially if you own more than one device and even worse if you have 'Find My' enabled on them.

More than one person just last week got stuck in a loop where the system wants credentials for your old deactivated Apple ID. The solution isn't hard but the UX flow fucking sucks.

You must manually sign out of all devices using your old ID and sign in again. Except before you can do that you have to disable Find My. With the deactivated credentials again.

It shows the OLD email and wants the old password but you have to actually enter the NEW password in the dialogue so Find My deactivates and you can sign out.

Post reply on HN