3 ms·

On PHP 25year birthday Rasmus Lerdorf talked about how php came to be. He literally thought something better would replace it at all times. https://thenewstac

On PHP 25year birthday Rasmus Lerdorf talked about how php came to be. He literally thought something better would replace it at all times. https://thenewstack.io/php-creator-rasmus-lerdorf-shares-lessons-learned-from-the-last-25-years/ https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les... I think he thought it would be Perl: "And Lerdorf tells an only-in-the-1990s story about the day when Perl finally also released its own optional embeddable module for Apache web servers — mod_perl. “They’d made it way too powerful… If you were on the virtual host on an Apache server, and you had mod_perl access, you could steal the requests from every other virtual host if you wanted to…” Because of this vulnerability, ISPs wouldn’t offer mod_perl alongside other clients in a single Apache instance. “So if you came to an ISP and said ‘I would like mod_perl‘, they would say, ‘Okay, that’ll be $600 a month,’ because back then, we also didn’t have VMs, containers, anything like that. So you had to have a separate, physical bare metal box for mod_perl. Whereas on PHP, you could put 3,000 customers on one machine, versus one mod_perl customer.” the 25 year php talk: https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s

pengaru 6y ago
I was a sysadmin through this era, and we refused access to both mod_php or mod_perl on shared hosting accounts. Customers always received php-cgi. Even if one could convince themself mod_php was safe, it was so unstable version-wise syntactically and every webapp wanted its own snowflake combination of version and configuration and versions of dependencies like imagemagick/gd, it was simply impossible to satisfy all customers on a given host sharing a single apache+mod_php instance. By the time I left that role we had what must have been nearly 100 different php cgi builds in a global repository maintained on behalf of customers. Whenever a vulnerability came out we'd have to go revisit all these snowflakes and push fixes out. At least the pushing out was mostly automated since we had all the hashes, but the maintaining of the variously configured source trees and backporting of fixes was always a largely manual nuisance. In retrospect we spoiled our customers, and I learned PHP was a damn disaster area. At one point we forced all customers to migrate IIRC from php3 to php4 and in that transition we learned the previous version was ignoring such glaring syntactic problems as mismatched curly braces ambiguously delimiting blocks of code. What a nightmare that week was, before that we could largely ignore the contents of customers' scripts. But with so much broken we had to start looking at what they were doing and automating counting of open vs. close curly braces in php scripts across the fleet. What a horror show. Edit: forgot to mention shared hosting providers generally relied on suexec which only works w/cgi processes anyways. Nobody in the shared webhosting space cared about the subtle differences of mod_php vs. mod_perl, they were both irrelevant to anyone trying to isolate web customers sharing a single host.

pengaru 6y ago

I was a sysadmin through this era, and we refused access to both mod_php or mod_perl on shared hosting accounts. Customers always received php-cgi. Even if one could convince themself mod_php was safe, it was so unstable version-wise syntactically and every webapp wanted its own snowflake combination of version and configuration and versions of dependencies like imagemagick/gd, it was simply impossible to satisfy all customers on a given host sharing a single apache+mod_php instance. By the time I left that role we had what must have been nearly 100 different php cgi builds in a global repository maintained on behalf of customers. Whenever a vulnerability came out we'd have to go revisit all these snowflakes and push fixes out. At least the pushing out was mostly automated since we had all the hashes, but the maintaining of the variously configured source trees and backporting of fixes was always a largely manual nuisance. In retrospect we spoiled our customers, and I learned PHP was a damn disaster area. At one point we forced all customers to migrate IIRC from php3 to php4 and in that transition we learned the previous version was ignoring such glaring syntactic problems as mismatched curly braces ambiguously delimiting blocks of code. What a nightmare that week was, before that we could largely ignore the contents of customers' scripts. But with so much broken we had to start looking at what they were doing and automating counting of open vs. close curly braces in php scripts across the fleet. What a horror show. Edit: forgot to mention shared hosting providers generally relied on suexec which only works w/cgi processes anyways. Nobody in the shared webhosting space cared about the subtle differences of mod_php vs. mod_perl, they were both irrelevant to anyone trying to isolate web customers sharing a single host.