There is, it is called the prefork MPM. It uses the same process model as Apache 1.3. Yes, there are a few API changes, but these really aren't a big deal and I really don't agree with the article that these API changes are the reason for the slow adoption.
Re:Why did Apache 2.0 need to break compatibility?
on
Sites Rejecting Apache 2?
·
· Score: 2, Informative
You are quite offbase here. The API change is a minor thing. It's the process model and the fact that everything you link into Apache now has to be threadsafe. Even if the API was perfectly backward compatible you wouldn't suddenly have rock-solid support for any old Apache 1.3 modules because the process model is completely different now.
Let's clear up a few things. Yes, PHP support has been somewhat slow in coming, but the main reason is that there is very little motivation for us to rush to support it. This is because most of us really don't see the advantage of 2.0 yet. The threaded mpms don't work at all on FreeBSD due to bugs in the FreeBSD kernel threading code. These are fixed in FreeBSD's CVS, but are not in any released version as far as I know. Also, as was mentioned, PHP itself is threadsafe, for the parts that count anyway, but what about the 100-150 different libraries that PHP can link against? We know some of these are not threadsafe. We also think we know that a number of them are threadsafe. The rest, who knows. Do you want to be the first to discover that a certain library is not threadsafe? Thread safety issues don't tend to show up until you start banging at the server with production-level load. And the errors can be quite subtle and random in nature. These are not PHP libraries we are talking about. These are things like libgd, freetype, libc, libm, libcrypt, libnsf.
Of course, if you run the non-threaded pre-fork mpm, it should be ok. But really, what is the point then? That's why PHP support has been slow going. We develop stuff because we need it ourselves for something. Right now spending a lot of energy on supporting Apache 2 seems somewhat futile. What we need here is a concentrated effort on the part of many different projects to pool their knowledge and generally improve the thread safetyness of all common libraries. I have written a summary and started this work here:
I would very much appreciate comments and additions to this. I don't think Apache 2.0 is dead in the water, it just needs better overall infrastructure in terms of non-buggy kernels and a push to make all libraries threadsafe before it can really become a viable solution for sites needing dynamic content.
Or, alternatively, we might start pushing the FastCGI architecture more to separate the Apache process-model from the PHP one.
PHP 4 includes a database abstraction layer. Obviously the presence of this feature is not advertised well enough as people keep thinking that there is no data abstraction layer available in PHP. A sample script would look something like this:
Well, PHP 4 has a foreach() construct and also a database abstraction layer. So if these were the only two things you hated about PHP, you should be jumping for joy now.
Just a couple of comments. There is no additional overhead involved when using Perl-style regular expressions in PHP. In fact, for most things they are actually marginally faster than POSIX-style regular expressions.
I agree, the leak() function is cool: User: Wha! My script is leaking memory!? Dev Dude: Don't call the leak() function. User: Oh yeah, thanks.
You can also include a module in PHP without recompiling. For example, let's say you install Apache, then install PHP (as either a static Apache module or as a DSO) and then you suddenly need to add MySQL support. You can go into your PHP source directory and do:./configure --with-mysql=shared and it will make you a mysql.so file. This file can be loaded by an individual script using dl('mysql.so'); or it can be loaded globally by putting: extension=mysql.so in your php.ini file.
PHP can be used for other than web scripts. But you are right, it is definitely geared at web stuff.
PHP's OO option has been improving steadily and I personally don't think it is all that bad. I never could figure out Perl's OO stuff.
We are working on that with PEAR. See the pear/ directory in the PHP 4 distribution.
global is fubarred. Yeah well, personal preference here I guess. I take full responsibility for this one. I had just gotten home from a 20-hour debug session with reams and reams of C code printed out on an old dot-matrix printer. The problem turned out to be a variable in a function that was meant to have local scope stepping all over a global variable. I swore I would never have this problem in PHP and implemented the "declare your globals" feature right then and there.
system("ls/some/dir"); The result is a listing of/some/dir in your web page. Seems pretty sensible to me. What's your beef on this one?
Bodged? PHP supports two styles of regular expressions. POSIX 1003.2 regular expression through Henry Spencer's regex library and also Perl-style regular expression through the PCRE library. You are saying these libraries are broken? I personally think Perl-style regular expressions are horrible. Try counting all the different ways the '?' character can be used sometime. I have counted 15 different meanings for '?' and I am sure there are more.
PHP can generate HTML or you can embed it. Your choice.
And yes, you can run PHP scripts from the command line as well. It is as simple as: php script.php
You can even stick the command-line PHP parser alongside perl in/usr/local/bin and write standalone PHP scripts that have #!/usr/local/bin/php on the first line.
I am really not trying to convince anybody to dump Perl for PHP. If you know and love Perl, I suggest sticking with what you know.
We have a bad habit in the open source community of beating up on each other. Linux and FreeBSD users fight, Emacs and vim users fight, Gnome and KDE users fight. Perl, PHP and Python users fight. When it comes down to it, these different open source systems are much more alike than they are different and we are not helping ourselves by being overly critical of each other. Constructive criticism and code sharing will ensure the technology advances. Infighting and destructive criticism will ensure that we will drag our old and grey beaten bodies to CompUSA to plop down $400 for an update to Windows-2005 and another $250 for that fix to C# that makes it stop eating all available RAM on a simple database query.
-Rasmus
Would be nice if these conferences would schedule themselves such that those of us without alien timewarp technologies can attend all the related ones. In particular OLS conflicts with the O'Reilly Open Source conference. Grr...
Netcraft has been sending these numbers to both the PHP and mod_perl teams every month.
The mod_perl numbers are here: http://perl.apache.org/netcraft/
The PHP numbers are here: http://www.php.net/usage.php3
There is also an interesting survey done by e-soft here: http://www.e-softinc.com/survey/data/199911/news.h tml#modules
They have a much smaller sample size than Netcraft, but it does give you a general impression of how big a percentage of Apache servers use the various server modules.
There were probably about 125 people in the audience by my estimation.
RMS explained why they eliminated Knuth from the 3 finalists by basically saying that he was in a whole other league and has already won just about every award out there and there wouldn't be any point in adding yet another award to the long list. He is already recognized.
That should shed some light on what they mean by XML-RPC over HTTP. If you ask me, this sort of firewall-prevention "standard" is bogus, but nobody is likely to ask me...
That is hard to say. There are certainly a lot of servers out there with PHP enabled that host domains that may not use PHP at all. Hence the IP count of 357,481 unique ips found to have PHP enabled. Then you also have quite a few large ISPs that use PHP in CGI mode under suExec with a bunch of people using PHP that way and none of those guys are counted in these stats, so that might even things out a bit. The real number is probably somewhere in between the 357,481 and 1,114,021, but exactly where is impossible to say.
Are you referring to me? I did not say I hadn't done a thing for free software. I have spent just about every minute of my spare time in the past 5 years working on free software. It just so happens that it isn't Linux-specific. That was the simple point I was making. Someone claimed that only Linux developers were getting these and this would hurt other open source projects.
How do you figure? I have never done a thing for Linux and I got both letters. Looks to me like all sorts of open source projects are being considered here.
No, it is not US-only. It looks like they have gone to quite a bit of trouble to make sure it is open to as many international developers as possible. At least from my quick read of the offer.
I really don't understand this attitude? You must therefore also refuse to run Apache because it isn't GPL'ed? The PHP license is almost an exact clone of the Apache license which is based on the BSD license. Are these all evil projects? We are about as Open Source as they come.
Every contributor was personally asked before we made the license change to drop the GPL between version 3 and version 4. There were a couple that said no, and their code unfortunately had to be removed. You will notice that the bcmath functions are no longer shipped with PHP 4, for example.
ASP was not out even out in 1995, PHP was. In fact there were 2 M$ engineers on the PHP mailing list in the early days asking people what they would like to see in an html-embedded scripting language. If anything, ASP is a copy of PHP.
As for the PHP is not GPL'ed beef that some of you have. Neither is Apache, FreeBSD and all sorts of other stuff. What is the problem?
There is a slight problem when you move though. I have a personal domain, for example, lerdorf.on.ca, but now that I no longer live in Ontario, Canada, it is a bit silly.
Well, the versioning is still work in progress. It should actually just be called DA right now. Stay tuned for the V part..;)
And I do agree that Zope is a very nice environment. The scope of Zope (ack!) is larger than PHP's. It could have been built on top of PHP actually, or mod_perl or even Java. I don't think comparing the two directly is really correct. A bit of an apples and oranges comparison. Then again, LinuxWorld put PHP up against Qt recently and Qt won. So comparing Zope and PHP is more like comparing an Apple to an Apple core.
And yes, there are ways to do most of the things you listed for Zope with PHP. Like the WebDAV support. Install mod_dav on your Apache server and there you go. Sessions and persistent objects are there in PHP 4. To get all of Zope's functionality with PHP would take a bit of work and piecing things together. Various people are working on PHP-based environments like that. We tend to just worry about providing the lower-level functionality.
To avoid the lowest common denominator problem with db abstraction layers. It is really not that difficult to put your db layer code in an include file like db.inc and if you do change your database, just change your db_* functions. And for the performance-oriented people out there having *all* API features of a specific database available is a huge bonus. There are databases out there that are so different from each other that trying to abstract them into a single API just doesn't work very well.
This comes up a lot, but how often do you really change your backend database? And if you are changing from MySQL to Oracle, you are going to have a lot of more complex issues to worry about. Or try moving from MS-SQL to Oracle with triggers and stored procedures and stuff to port. Trust me, changing 10 lines of PHP code was a breeze compared to the headaches of moving the schemas.
Having said that, we are looking into a DB abstraction layer for PHP 4, but I really do believe from experience that this is not such a big deal.
You also have the option of sticking with ODBC calls. Most databases support ODBC and some even have native CLIs and PHP is smart enough to let you use the ODBC interface to access these so you are getting native API performance through ODBC calls. This is known as unified-odbc in PHP-speak.
There are no known security issues, correct. Sure, it is possible to install PHP in an insecure manner, but it is possible to install just about anything in an insecure manner.
Slashdot Mirror
There is, it is called the prefork MPM. It uses the same process model as Apache 1.3. Yes, there are a few API changes, but these really aren't a big deal and I really don't agree with the article that these API changes are the reason for the slow adoption.
You are quite offbase here. The API change is a minor thing. It's the process model and the fact that everything you link into Apache now has to be threadsafe. Even if the API was perfectly backward compatible you wouldn't suddenly have rock-solid support for any old Apache 1.3 modules because the process model is completely different now.
Let's clear up a few things. Yes, PHP support has been somewhat slow in coming, but the main reason is that there is very little motivation for us to rush to support it. This is because most of us really don't see the advantage of 2.0 yet. The threaded mpms don't work at all on FreeBSD due to bugs in the FreeBSD kernel threading code. These are fixed in FreeBSD's CVS, but are not in any released version as far as I know. Also, as was mentioned, PHP itself is threadsafe, for the parts that count anyway, but what about the 100-150 different libraries that PHP can link against? We know some of these are not threadsafe. We also think we know that a number of them are threadsafe. The rest, who knows. Do you want to be the first to discover that a certain library is not threadsafe? Thread safety issues don't tend to show up until you start banging at the server with production-level load. And the errors can be quite subtle and random in nature. These are not PHP libraries we are talking about. These are things like libgd, freetype, libc, libm, libcrypt, libnsf.
Of course, if you run the non-threaded pre-fork mpm, it should be ok. But really, what is the point then? That's why PHP support has been slow going. We develop stuff because we need it ourselves for something. Right now spending a lot of energy on supporting Apache 2 seems somewhat futile. What we need here is a concentrated effort on the part of many different projects to pool their knowledge and generally improve the thread safetyness of all common libraries. I have written a summary and started this work here:
Thread Safety Issues
I would very much appreciate comments and additions to this. I don't think Apache 2.0 is dead in the water, it just needs better overall infrastructure in terms of non-buggy kernels and a push to make all libraries threadsafe before it can really become a viable solution for sites needing dynamic content.
Or, alternatively, we might start pushing the FastCGI architecture more to separate the Apache process-model from the PHP one.
PHP 4 includes a database abstraction layer. Obviously the presence of this feature is not advertised well enough as people keep thinking that there is no data abstraction layer available in PHP. A sample script would look something like this:
require_once 'DB';
$db = DB::connect('odbc://rasmus:pw@host/my_db');
$stmt = $db->prepare('select * from my_table');
$result = $db->execute($stmt);
while($row = $db->fetchrow($result)) {
while(list($key, $value) = each($row)) {
echo "$field: $value\n";
}
}
$db->disconnect();
Well, PHP 4 has a foreach() construct and also a database abstraction layer. So if these were the only two things you hated about PHP, you should be jumping for joy now.
I agree, the leak() function is cool:
User: Wha! My script is leaking memory!?
Dev Dude: Don't call the leak() function.
User: Oh yeah, thanks.
You can also include a module in PHP without recompiling. For example, let's say you install Apache, then install PHP (as either a static Apache module or as a DSO) and then you suddenly need to add MySQL support. You can go into your PHP source directory and do: ./configure --with-mysql=shared and it will make you a mysql.so file. This file can be loaded by an individual script using dl('mysql.so'); or it can be loaded globally by putting: extension=mysql.so in your php.ini file.
- PHP can be used for other than web scripts. But you are right, it is definitely geared at web stuff.
- PHP's OO option has been improving steadily and I personally don't think it is all that bad. I never could figure out Perl's OO stuff.
- We are working on that with PEAR. See the pear/ directory in the PHP 4 distribution.
- global is fubarred. Yeah well, personal preference here I guess. I take full responsibility for this one. I had just gotten home from a 20-hour debug session with reams and reams of C code printed out on an old dot-matrix printer. The problem turned out to be a variable in a function that was meant to have local scope stepping all over a global variable. I swore I would never have this problem in PHP and implemented the "declare your globals" feature right then and there.
- system("ls
/some/dir"); The result is a listing of /some/dir in your web page. Seems pretty sensible to me. What's your beef on this one?
- Bodged? PHP supports two styles of regular expressions. POSIX 1003.2 regular expression through Henry Spencer's regex library and also Perl-style regular expression through the PCRE library. You are saying these libraries are broken? I personally think Perl-style regular expressions are horrible. Try counting all the different ways the '?' character can be used sometime. I have counted 15 different meanings for '?' and I am sure there are more.
- PHP can generate HTML or you can embed it. Your choice.
And yes, you can run PHP scripts from the command line as well. It is as simple as: php script.php You can even stick the command-line PHP parser alongside perl inWe have a bad habit in the open source community of beating up on each other. Linux and FreeBSD users fight, Emacs and vim users fight, Gnome and KDE users fight. Perl, PHP and Python users fight. When it comes down to it, these different open source systems are much more alike than they are different and we are not helping ourselves by being overly critical of each other. Constructive criticism and code sharing will ensure the technology advances. Infighting and destructive criticism will ensure that we will drag our old and grey beaten bodies to CompUSA to plop down $400 for an update to Windows-2005 and another $250 for that fix to C# that makes it stop eating all available RAM on a simple database query. -Rasmus
I did my time at U Waterloo as well. Systems Design Engineering, 1993.
-Rasmus
http://www.lpi.org
Think cnews
Think regex
Think 10 Commandments for C programmers
CANet, RNP as well (I was in Brazil when he spoke in Rio)
Pretty much a legend and he still has a bunch of code in many of today's popular open source projects including Apache and PHP among many others.
Would be nice if these conferences would schedule themselves such that those of us without alien timewarp technologies can attend all the related ones. In particular OLS conflicts with the O'Reilly Open Source conference. Grr...
-Rasmus
Netcraft has been sending these numbers to both the PHP and mod_perl teams every month.
h tml#modules
The mod_perl numbers are here: http://perl.apache.org/netcraft/
The PHP numbers are here: http://www.php.net/usage.php3
There is also an interesting survey done by e-soft here: http://www.e-softinc.com/survey/data/199911/news.
They have a much smaller sample size than Netcraft, but it does give you a general impression of how big a percentage of Apache servers use the various server modules.
Whoa.. the /. crowd goes nuts again...
There were probably about 125 people in the audience by my estimation.
RMS explained why they eliminated Knuth from the 3 finalists by basically saying that he was in a whole other league and has already won just about every award out there and there wouldn't be any point in adding yet another award to the long list. He is already recognized.
-Rasmus
Have a look here:
S OAP_V09.asp
http://msdn.microsoft.com/workshop/xml/general/
That should shed some light on what they mean by XML-RPC over HTTP. If you ask me, this sort of firewall-prevention "standard" is bogus, but nobody is likely to ask me...
-Rasmus
That is hard to say. There are certainly a lot of servers out there with PHP enabled that host domains that may not use PHP at all. Hence the IP count of 357,481 unique ips found to have PHP enabled. Then you also have quite a few large ISPs that use PHP in CGI mode under suExec with a bunch of people using PHP that way and none of those guys are counted in these stats, so that might even things out a bit. The real number is probably somewhere in between the 357,481 and 1,114,021, but exactly where is impossible to say.
-Rasmus
Are you referring to me? I did not say I hadn't done a thing for free software. I have spent just about every minute of my spare time in the past 5 years working on free software. It just so happens that it isn't Linux-specific. That was the simple point I was making. Someone claimed that only Linux developers were getting these and this would hurt other open source projects.
-Rasmus
How do you figure? I have never done a thing for Linux and I got both letters. Looks to me like all sorts of open source projects are being considered here.
-Rasmus
No, it is not US-only. It looks like they have gone to quite a bit of trouble to make sure it is open to as many international developers as possible. At least from my quick read of the offer.
-Rasmus
I really don't understand this attitude? You must therefore also refuse to run Apache because it isn't GPL'ed? The PHP license is almost an exact clone of the Apache license which is based on the BSD license. Are these all evil projects? We are about as Open Source as they come.
-Rasmus
Every contributor was personally asked before we made the license change to drop the GPL between version 3 and version 4. There were a couple that said no, and their code unfortunately had to be removed. You will notice that the bcmath functions are no longer shipped with PHP 4, for example.
-Rasmus
ASP was not out even out in 1995, PHP was. In fact there were 2 M$ engineers on the PHP mailing list in the early days asking people what they would like to see in an html-embedded scripting language. If anything, ASP is a copy of PHP.
As for the PHP is not GPL'ed beef that some of you have. Neither is Apache, FreeBSD and all sorts of other stuff. What is the problem?
-Rasmus
There is a slight problem when you move though. I have a personal domain, for example, lerdorf.on.ca, but now that I no longer live in Ontario, Canada, it is a bit silly.
-Rasmus
Well, the versioning is still work in progress. It should actually just be called DA right now. Stay tuned for the V part.. ;)
And I do agree that Zope is a very nice environment. The scope of Zope (ack!) is larger than PHP's. It could have been built on top of PHP actually, or mod_perl or even Java. I don't think comparing the two directly is really correct. A bit of an apples and oranges comparison. Then again, LinuxWorld put PHP up against Qt recently and Qt won. So comparing Zope and PHP is more like comparing an Apple to an Apple core.
And yes, there are ways to do most of the things you listed for Zope with PHP. Like the WebDAV support. Install mod_dav on your Apache server and there you go. Sessions and persistent objects are there in PHP 4. To get all of Zope's functionality with PHP would take a bit of work and piecing things together. Various people are working on PHP-based environments like that. We tend to just worry about providing the lower-level functionality.
-Rasmus
To avoid the lowest common denominator problem with db abstraction layers. It is really not that difficult to put your db layer code in an include file like db.inc and if you do change your database, just change your db_* functions. And for the performance-oriented people out there having *all* API features of a specific database available is a huge bonus. There are databases out there that are so different from each other that trying to abstract them into a single API just doesn't work very well.
This comes up a lot, but how often do you really change your backend database? And if you are changing from MySQL to Oracle, you are going to have a lot of more complex issues to worry about. Or try moving from MS-SQL to Oracle with triggers and stored procedures and stuff to port. Trust me, changing 10 lines of PHP code was a breeze compared to the headaches of moving the schemas.
Having said that, we are looking into a DB abstraction layer for PHP 4, but I really do believe from experience that this is not such a big deal.
You also have the option of sticking with ODBC calls. Most databases support ODBC and some even have native CLIs and PHP is smart enough to let you use the ODBC interface to access these so you are getting native API performance through ODBC calls. This is known as unified-odbc in PHP-speak.
-Rasmus
There are no known security issues, correct. Sure, it is possible to install PHP in an insecure manner, but it is possible to install just about anything in an insecure manner.
-Rasmus