You’re likely running on an old version of MacOS that isn’t able to use the precompiled binaries. So, brew is installing all the dependencies necessary to build eza from scratch.
Your Homebrew may not be configured to pull only the runtime dependencies; as others in this thread have mentioned, it's pulling in all those dependencies becauase it's building "eza" (or something, perhaps one of "eza"'s few transitives) from source, which brings in quite the list, including openjdk as you saw.
Homebrew can accidentally end up configured to do this in a number of ways. Some of these may no longer be issues; this list is from memory and should be taken with a grain of salt:
- You might be running an outdated homebrew.
- You might have homebrew checked out as a git checkout, thus missing "brew update" abilities. "brew doctor" will report on this.
- You might have "inherited" your Homebrew install from a prior Mac (e.g. via disk clone or Time Machine), or from the brief transitional period where Homebrew was x86-via-Rosetta on ARM macs, thus leaving your brew in a situation where it can't find prebuilt packages ("bottles") for what it observes as a hybrid/unique platform. Tools, including your shell, which install Homebrew for you might install it as the wrong (rosetta-emulated) architecture if any process-spawning part of the tool is an x86-only binary. More details on a similar situation I found myself in are here: https://blog.zacbentley.com/post/dtrace-macos/
- (I'm pretty sure most issues in this area have been fixed, but) you might have an old or "inherited" XCode or XCode CLT installation. These, too, can propagate from backups. Removing Homebrew, uninstalling/reinstalling XCode/CLT, and reinstalling Homebrew can help with this.
- The HOMEBREW_ARCH, HOMEBREW_ARTIFACT_DOMAIN, HOMEBREW_BOTTLE_DOMAIN, or other environment variables may be set in your shell such that Homebrew either thinks the platform doesn't have bottles available or it shouldn't download them: https://docs.brew.sh/Manpage#environment
- Perhaps obvious, but your "brew" command might be invoked such that it always builds from source, e.g. via a shell alias.
- Homebrew may be unable to access the bottle repository (https://ghcr.io/v2/homebrew/core/), either due to a network/firewall issue or a temporary outage.
Noob friendly homebrew seems like such a great idea. I especially want just one strategy which spans both utils and apps (casks). Versus cobbling together Apple App Store, SetApp, and homebrew.
Those GUIs would be even more useful if they spotted and explained the config issues you listed. (I have no idea if "brew doctor" suffices.)
You’re welcome! One more issue that I missed calling out: a bottle may not yet be available for your platform (Sequoia) as it is very new. In that case, patience.
Well, whether it's worth it is going to depend both on the use case and on the user. (I figure for many folk in this thread, the difference in price is going to be pretty negligible for a tool they use ~weekly.)
For me, I eliminated BC immediately because I was often diffing prose and it didn't have word wrap; that ability is apparently available now in the beta version of BC5, but it wasn't when I was testing it. I suspect it will continue to be non-optimized for prose in how it handles long lines.
I also did something similar 14 years ago. It was a php website that allowed you to subscribe to online newspapers and get the news sent to your Kindle, in MOBI format. It worked but it was basically calling calibre under the hood. I never made it public (and I remember a similar website existed already at that time that did not work well)
It's simple and there is less overhead. Since PHP runs directly within the Apache process, there is no need for inter-process communication (no TCP, no sockets), reducing the overhead. This can lead to lower latency for individual requests.
mod_php does give you better response times for individual requests, but at the expense of being able to handle a higher load of traffic; you'll run out of memory and/or experience timeouts on mod_php way before you do with php-fpm.
With mod_php, every Apache process has the PHP engine embedded in it, even if PHP isn't needed, e.g., to serve a request for a .css file. When Apache gets a bunch of requests for flat files, it forks all those processes and fills up RAM with copies of the PHP engine that aren't used. That's not only wasteful, but it dramatically increases the chances that you'll run out of memory. You can limit the number of Apache children of course, but you'll see timeouts sooner when you get a traffic spike.
By having Apache proxy over to php-fpm for PHP requests, you can configure Apache to use mpm_event for serving static files, which allows for much leaner Apache workers (memory-wise) since they aren't carrying PHP around on their backs.
While you're at it, you can use haproxy on the same machine for TLS termination, then you can disable mod_ssl thus making Apache workers even lighter.
> With mod_php, every Apache process has the PHP engine embedded in it, even if PHP isn't needed, e.g., to serve a request for a .css file. When Apache gets a bunch of requests for flat files, it forks all those processes and fills up RAM with copies of the PHP engine that aren't used. That's not only wasteful, but it dramatically increases the chances that you'll run out of memory. You can limit the number of Apache children of course, but you'll see timeouts sooner when you get a traffic spike.
Yes, that is true. But most high-traffic websites will cache static files such as CSS files and images, using a reverse proxy (e.g. Varnish, a CDN, or usually both). So I don't think this is a real problem, most of the time (99.9%?), a request for a static file will not hit Apache.
I'm not saying mod_php is better for all scenarios, of course, but I think it can be ok.
I tend to agree with you - using in "default" setup with mod_php and mpm_prefork is known to be far from optimal (still fine for blog about you and your cat).
With reverse proxy in front of such setup is - much better in terms of performance. For shared hosting - yet again, may be not optimal if one needs to support multiple system users.
I fail to understand why this, now. For these minimal gains (compared to Brotli), servers and CDNs will need to increase memory and disk space to store the cached responses in zstd.
We don't use brotli for any responses under 25kb and in those cases, for us, zstd is the clear winner. We are still tweaking zstd and expect to improve the performance to bring it inline with brotli. Additionally, our biggest expense per month is egress, any savings goes a long way for us.
