LWN.net Logo

This is the most ridiculous commentary...

This is the most ridiculous commentary...

Posted Dec 19, 2011 8:01 UTC (Mon) by khim (subscriber, #9252)
In reply to: Cracks in the Foundation (PHP Advent) by sxpert
Parent article: Cracks in the Foundation (PHP Advent)

Actually there are plenty of ways to use prepared statements with MySQL. You can use mysqli::prepare/mysqli_stmt::bind_param/mysqli_stmt::execute or PDO::prepare/PDOStatement::bindParam/PDOStatement::execute. People are using "good old" mysql_query because not all ISPs provide mysqli or PDO - but Postgresql is even rarer thus obviously not an option.

There is one thing PHP did right: it was ridiculously easy to add mod_php to the Apache server from the very beginning - and overhead was negligible when it was not in use thus a lot of ISPs offered mod_php and very few offered mod_perl or mod_python. This is what made PHP popular and this is what keeps it alive.


(Log in to post comments)

This is the most ridiculous commentary...

Posted Dec 19, 2011 10:06 UTC (Mon) by drag (subscriber, #31333) [Link]

It helps.

Also it's trivial to make a PHP script by taking some HTML code and putting PHP statements in it.

So it suckers developers in by trivial hello world type demos. More people come from a HTML editing background then a programming background so this sort of thing makes it easier to approach.

This is the most ridiculous commentary...

Posted Dec 19, 2011 21:58 UTC (Mon) by job (guest, #670) [Link]

As a side note, I believe what was important about mod_php was safe_mode. It is a rudimentary file i/o sandbox that only allows you to open files with the same UID your script was created with. That enabled shared script hosting, you don't have to use one process per user which was important for the nascent "web hotel" businesses.

Performance was worse than Perl (which was the dominant language at the time, and had decent template frameworks too), security was worse, the language itself was a stripped down Perl 4, but deployment was so easy you just had to install it and you had yourself a shared web hosting environment.

I see now that safe_mode is removed from PHP 5.4 so perhaps we're full circle now. I wonder what shared hosts are supposed to replace it with?

This is the most ridiculous commentary...

Posted Dec 20, 2011 10:17 UTC (Tue) by smurf (subscriber, #17840) [Link]

FastCGI and separate PHP processes per user, of course.

It doesn't make any sense at all to bloat your Apache with mod_php. If you have 200 Apache processes, of which 10 are needed for PHP, the (non-trivial, these days) memory space of 190 PHP interpreters sits idle. It can't even be swapped out because the set of Apache processes working on PHP requests constantly changes.

Using FastCGI, you have 10 busy PHP interpreters and 190 "normal" Apache (or lighttp or …) processors, and you get to run each customer's PHP stuff under their own UID – instead of having global access to anything that's readable by www_data when (not if) the next security hole is discovered.

This is the most ridiculous commentary...

Posted Dec 20, 2011 11:09 UTC (Tue) by job (guest, #670) [Link]

For large web apps this is (and has always been) true. But the issue here is altogether different.

A large shared webhost has many thousands of web sites and only a few of them are active at any time. It is unreasonable to keep thousands of idle PHP processes around (and that is without room for concorrency which would be required in production).

That is what the web hotel business is all about, very cheap hosting, and this is what made PHP popular.

This is the most ridiculous commentary...

Posted Dec 20, 2011 12:23 UTC (Tue) by smurf (subscriber, #17840) [Link]

Sure it's unreasonable to keep them around. So let them die when they're no longer useful.

Large sites increase the likelihood that somebody, somewhere on your system, is running code with a security hole or two. So it's even more important to shield individual customers from each other.

Your decision, of course. But the web servers I am responsible for will never load mod_interpreter, much less mod_php.

This is the most ridiculous commentary...

Posted Dec 20, 2011 16:14 UTC (Tue) by job (guest, #670) [Link]

When the number of idle sites are order of magnitudes larger than the number of active sites at any given moment that solution is equivalent to running PHP as CGI. That would price you out of the market. (And spare me the morals please, as much as I'd like to see mod_php dead it is still an important market which drove PHP's success.)

PHP won because of mod_php, but mod_php won the low end market because of safe_mode. My question still stands, what should replace it? Maybe SELinux can?

This is the most ridiculous commentary...

Posted Dec 21, 2011 12:02 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

> When the number of idle sites are order of magnitudes larger than the number of active sites at any given moment that solution is equivalent to running PHP as CGI. That would price you out of the market. (And spare me the morals please, as much as I'd like to see mod_php dead it is still an important market which drove PHP's success.)
Right, because idle sites cause that much load that cgi is actually a problem... Its the website that actually use their allotted bandwith/load/whatever that are a problem not the thousand with 3 visitors a day.

This is the most ridiculous commentary...

Posted Dec 22, 2011 0:22 UTC (Thu) by job (guest, #670) [Link]

On a large shared web host, a very small percentage of the sites are have traffic at any given time, but it's still a lot in absolute numbers.

The only possible way to cram as many sites as possible on your host is to run them with a common interpreter, which can pose security problems. That's where mod_php succeeded.

(By the way, I got the answer to my specific question below, which is that other restrictions still apply.)

This is the most ridiculous commentary...

Posted Dec 20, 2011 22:58 UTC (Tue) by hholzgra (subscriber, #11737) [Link]

Being able to define memory and cpu time limits, and maybe open-basedir restrictions, were (AFAIR) more important to shared hosters than safe-mode (which was never that safe anyway), and all of these still exist.

This is the most ridiculous commentary...

Posted Dec 21, 2011 8:48 UTC (Wed) by job (guest, #670) [Link]

That explains it. I thought basedir restrictions was part of safe_mode.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds