this should just become the default package manager on all linux distros.
Homebrew 3.0
491–500 of 516 posts
Re: Homebrew 3.0
#492Earlier quoted context omitted.
I'm interested in this workflow, some questions: - When you say "local editor, remote runtime", are you referring specifically to VS Code's remote development features? - Is the remote runtime a Linux VM on the same machine, or running on another machine? - Do you run git locally? - Do tests run locally? - Do you have a link to an article detailing this workflow?
There are a couple different ways to implement this type of workflow. You can use tools like VSCode's remote development features, you can use an IDE/editor with built-in rsync/sftp capabilities, you can also use git via a local command line (though that defeats the purpose), or a tool like Mountain Duck if you want to 100% eschew a CLI. Admittedly, for myself, I prefer to simply shell into a remote machine and use v…
Thanks a lot for the details!
Re: Homebrew 3.0
#493Earlier quoted context omitted.
> I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming. You may be interested in trying out nix for package management [1], or even for configurations and providing development environments (see my other comment [2]). [1]: https://builtwithnix.org/ [2]: https://news.ycombinator.com/item?id=26038614
When I tried nix on my mac a while back, it took forever to install basic things, had very verbose logs, was far more complicated and was missing packages. Is it still like that?
Not my experience at all.
Re: Homebrew 3.0
#494Earlier quoted context omitted.
> dictatorial piece of software Isn't that generally the point, for Apple consumers? At HN we have a skewed sample but I imagine for a lot of users (myself included), having an easy solution with configurations set for you is exactly what they want.
Not for developers, no. "Normal" Apple consumers have little reason to use brew.
I'm not a developer and I have plenty of reasons to use homebrew.
Re: Homebrew 3.0
#495Earlier quoted context omitted.
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…
Cross-compiling is a need that almost no user ever has.
The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode.
There would be now need for a Apple Homebrew to use or provide universal binaries.
Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment) with the tools he needs on this system. Switching CPU architecture would be solved with reinstalling Homebrew on the new system (like it is now).
Re: Homebrew 3.0
#496Earlier quoted context omitted.
There is a prompt. It’s impossible to miss.
It is not a prompt; I encourage you to review it. It proceeds automatically. It also only occurs once, on install, and is silent thereafter on each data exfiltration.
> It is not a prompt; I encourage you to review it. It proceeds automatically.
It won’t start telemetry until the next invocation. It also clearly tells you the options you have.
That’s as prompt-y as it gets.
Re: Homebrew 3.0
#497Earlier quoted context omitted.
How is that better than a pm specifically designed for Mac?
I use Homebrew, and am genuinely appreciative of the amount of effort all the contributors have put in. However, as far as package managers go, it's kind of awful. Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run. If you've ever updated readline v…
Have you tried MacPorts?
Re: Homebrew 3.0
#498Earlier quoted context omitted.
I use Homebrew, and am genuinely appreciative of the amount of effort all the contributors have put in. However, as far as package managers go, it's kind of awful. Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run. If you've ever updated readline v…
Have you tried MacPorts?
Not in about 8 years. I do most of my development in Docker these days so tend to make use of Linux package managers.
Re: Homebrew 3.0
#499Earlier quoted context omitted.
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.
That’s correct. A major part of formulae is still not relocatable though.
Re: Homebrew 3.0
#500Earlier 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…
I promise you that Homebrew is operating "at scale." Considering that Google hires many kids straight out of school who have never built any significant real-world software at all, I think this hypothesis is highly unlikely.