I wouldn't really call it a drop-in replacement for php-fpm. It's more like emulating the way Apache+PHP was run traditionally, i.e. PHP is closer to the webserver instead of being a separate piece as it is with php-fpm (and needing fastcgi as protocol glue).
But yes, from a practical standpoint, your PHP apps should _just work_ if you run it with this instead of php-fpm, provided that you aren't doing anything weird.
If you're using a modern PHP framework (e.g. Laravel, Symfony) then you can use FrankenPHP's worker mode which is a huge boost in performance by keeping workers running which have the framework already warmed up and ready to accept requests right away, instead of having to boot the framework on every request.
Go is acting as the process manager for PHP (either keeping a pool of workers running, or directly invoking PHP via CGO), and as the HTTP/HTTPS server (Caddy, obviously), ACME automation, etc. It's not a "PHP interpreter", it's literally PHP itself (written in C, compiled in with CGO).
Downside: numpy, h5py and others use an embedded libhdf5 which is quite outdated. Meanwhile, homebrew has the current version, but they ignore it. In contrast, the Debian/Ubuntu/FreeBSD ports have python packages built against the packaged libhdf5. The pip packaging is inferior to the properly packaged stuff, which is what you get when language-specific packaging exists in its own isolated bubble.
I feel like the correct move here is to push the library maintainers to update to the new version. Distribution package mods should really be seen as temporary.
I have already opened an issue for this. However, it doesn't resolve the underlying and rather harder to fix problem of different language-specific package managers embedding copies of C and C++ libraries which can end up in a horrible incompatible mess. It's not specific to pip/pypy, it also applies to Java jars with embedded libraries and other systems which also embed.
Sometimes, this embedded copy can be more up to date than the system copy, but the convenience of embedding is often outweighed by the binary compatibility problems and being neglected and out of date.
I don't agree with your implication that shadowy intelligence agencies killed Jack Parsons, but the story of Jack Parsons is fascinating! I think he just mixed too many random rocket fuel precursors. Or maybe L Ron Hubbard really did successfully curse him. There are a few fun books written about this.
So that was definitely a bit of embarrassing, misremembered narrative overreach on my part. The point is that a lot of what these alt right guys are doing is a kind of cultural criticism, and if they can make a case for an overarching anti-white narrative in popular media it's a pretty short hop from there to the JQ.
Particularly when there are things they can point to and say "look, this is what your beloved minorities say about you behind your back" - it's a huge recruitment tool. That's why it's rational to hope that white people do not discover The Root.
Obvious prima facie. If we don't agree on this we don't inhabit the same intellectual universe.
Maybe your issue isn't the claim that the editorial slant is anti-white, but with my use of the term propaganda? Don't take that to mean much, I view most media as propaganda of one kind or another.
> and not too long ago a big portion of Internet were rerouted to Russia (BGP)
This happens every few months, and not always by Russian ISPs. This would never happen if all upstream providers had proper filters on accepting BGP requests.
It really means the current system of using BGP is not resilient, and never has been.
