Does it work natively on M1 Macs yet ?
It's literally the first line item!
Homebrew 3.0
71–80 of 516 posts
Re: Homebrew 3.0
#72Earlier quoted context omitted.
Was it him who was turned down by Apple and Google, after he built homebrew...?
>turned down by Apple and Google It was Google. Because he didn't know what a binary tree was or something similar during the infamous Whiteboard test. But I mean it make perfect sense. Google is all about building AI, ML, Algorithm, K8S etc. Complexity is their KPI, usefulness is not. So may be it isn't so much a bad thing after all. He wouldn't have fit in. Edit: I guess the tone didn't shine through. The "all abou…
Google is not all about that
Re: Homebrew 3.0
#73I 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.
But can he invert a binary tree?
"But well, what the fuck does comp-sci have to do with modern app development?" [1]
[1] Max Howell, https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
Re: Homebrew 3.0
#74Earlier 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. I can understand them not wanting to do it themselves. I don't think they want to take on the responsibility for maintaining all those packages (for legal reasons or otherwise). Because it's a "not officially Apple" thing, Homebrew can probably get away with a "no warranty" sticker that an official Apple project couldn't. What A…
Apple did help with implementing support for ARM CPUs as mentioned in the changelog: "Particular thanks on Homebrew 3.0.0 go to MacStadium and Apple for providing us with a lot of Apple Silicon hardware and Cassidy from Apple for helping us in many ways with this migration." Making sure Homebrew works on ARM Mac devices made sense for Apple.
Meanwhile providing money for no reason to Homebrew wouldn't make business sense. As far Apple is concerned, Homebrew works, and providing financial support wouldn't make it work better.
Re: Homebrew 3.0
#75Earlier 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. I can understand them not wanting to do it themselves. I don't think they want to take on the responsibility for maintaining all those packages (for legal reasons or otherwise). Because it's a "not officially Apple" thing, Homebrew can probably get away with a "no warranty" sticker that an official Apple project couldn't. What A…
IIRC, Apple does (or at least did) donate Hardware to some of the maintainers. I remember some of the Homebrew maintainers answering in comments here on HN that hey received M1-based MacMinis - this is of course in the interest of Apple but also shows that they do care about it.
Re: Homebrew 3.0
#76Earlier quoted context omitted.
My experience with homebrew is that it doesn't deal well with multiple version of packages at the same time. For example, it doesn't like to keep outdated openssl in parallel, which is good from a security standpoint but can make it difficult if your job involves a lot of looking at antique codebases and help with updating them... It's why I switched back to macports after briefly testing it
Can you explain exactly what you are describing: “it doesnt deal well with multiple versions at the same time” Also what system/os are you comparing to?
Probably comparing it to MacPorts, which does allow multiple versions of the same packages to be installed simultaneously.
Re: Homebrew 3.0
#77Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
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 if the wrong arch is first in PATH.
Re: Homebrew 3.0
#78Earlier quoted context omitted.
> It’s Weird that Apple doesn’t do this themselves. It’s not like they don’t have a cash. I can understand them not wanting to do it themselves. I don't think they want to take on the responsibility for maintaining all those packages (for legal reasons or otherwise). Because it's a "not officially Apple" thing, Homebrew can probably get away with a "no warranty" sticker that an official Apple project couldn't. What A…
> I don't think they want to take on the responsibility for maintaining all those packages That's not how a package manager works. The people responsible for APT/AUR do not maintain all the packages within the repositories themselves. This even applies to the App Store. Apple does not maintain the apps there themselves, it's up to the people publishing the apps. So there really isn't any reasons except they can't mak…
Yes and no, Apple doesn't want the support issues going into their queue and clogging up their customer support system.
When Billy Bob installs the wrong package from Homebrew now he just complains on a forum like this, or on stack overflow. He doesn't email Apple
Re: Homebrew 3.0
#79Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
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 does.
Re: Homebrew 3.0
#80Earlier quoted context omitted.
My experience with homebrew is that it doesn't deal well with multiple version of packages at the same time. For example, it doesn't like to keep outdated openssl in parallel, which is good from a security standpoint but can make it difficult if your job involves a lot of looking at antique codebases and help with updating them... It's why I switched back to macports after briefly testing it
Can you explain exactly what you are describing: “it doesnt deal well with multiple versions at the same time” Also what system/os are you comparing to?
I'm comparing to macports. I remember a brew update that removed an old version of openssl causing all of my older ruby packages to fail. Now I would definitely not use ruby 1.9.x in production but I sometimes do have to be able to run locally antique codebases that haven't been used in a long time. I was caught off guard because a simple install of an unrelated application with homebrew destroyed a big part of my work flow.
Macports never did this and kept libraries side by side cleanly.
Now, this is from the point of view of a software developer with a specific niche requirement. For normal users, from a security standpoint, it would most likely make sense to remove old versions of openssl.