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.
If LEO is involved, they wouldn't be disclosing evidence to avoid the public interacting with suspects or possibly leapfrogging them and tipping off someone new.
In this case the public would benefit from knowing quickly who are the bad actors and what other projects they touched.
Can we not dogpile Lasse after his vacation was ruined by this. He has much bigger concerns right now than trying to export and sanitize his entire communication history with Jia.
I have a lot of respect for xz's original author, I just didn't think about the legal stuff, and that sounds quite reasonable to me now.
Personally, I find it hard to subscribe to certain theories, such as the possibility of Lasse being impersonated or involved in the incident. But that doesn't mean we should dismiss them outright at this stage. (And I'm sorry if you don't like to hear that, saying this is not comfortable for me either).
Because it may be good enough. In my case, because I already maintain an instance of MariaDB in production, and I may prefer to share this that maintain another thing
