PHP 5.2.2 and 4.4.7 Released

daeg writes "PHP 5.2.2 and 4.4.7 have been released with a plethora of security updates. Many of the security notifications come from the Month of PHP Bugs effort, and range from double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize(), to input validation flaws that allow e-mail header injections, with an unhealthy sprinkling of other bugs and flaws fixed. All administrators that run any version of PHP are encouraged to update immediately."

Re:Bad release practices

[Ambush Commander]

What you're missing is that fact that PHP uses the three digit version numbering system to mean something slightly different than what you're used to. Increments in the 0.x.0 number indicate, besides major changes in the language, that extension compatibility was broken and thus they need to be recompiled (to see a great example of this, check PHP 4.4). 0.0.x releases do contain feature releases, but you don't have to worry about extensions breaking.

Firefox does the same thing too, except they end up stepping on extension authors feet when they increment the third version number! That's why they introduced a fourth number 0.0.0.x for memory leak / security fixes. But Firefox has the luxury of an auto-update system: something PHP doesn't have. It is in both sysadmin's and PHP's developer's best interests to not be releasing new versions every other week.

Re:I want to see someone claim again

[digidave]

The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.

There are plenty of good criticisms for PHP (and every other language), but performance is only a factor in PHP web apps when the programmers do really stupid things.

Re:Bad release practices

[Dragonslicer]

Yeah, I hate to admit it, but release management hasn't been the PHP developers' strength lately. I think 5.1.0 might have been the biggest screwup, where, after I think 7 release candidates, somebody committed new code a few days before the final release that created a builtin class named 'Date'. The thousands of people that used the PEAR class named 'Date' weren't too happy. In an amusing twist of irony, the developer that committed the code was a staunch opponent of adding namespaces to PHP.

Examples of PHP inconsistency and performance

[Snover]

Sure, I'll give you some.

Inconsistent function naming (underscores):

substr_compare() vs.
strcmp()

More inconsistent function naming (verb location):

file_get_contents() vs.
get_html_translation_table()

Even within the same extension:

imagesetstyle() vs.
imagecolorset()

Flipped haystack and needle:

strpos(haystack, needle) vs.
in_array(needle, haystack)

Speed:

Scutigena Computer Language Performance Comparison [sourceforge.net] (see graphs)
There used to be another site that you could compare one language's speed relative to another that also showed PHP as one of the slowest. I can't seem to find it now, though. Also PHP5 might compare a bit more favourably, but this is all I could find after a quick Google search. Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.

I think PHP is overall a fairly decent language; I've used it for many years with great success. But it does have major problems, and it would be nice for them to get fixed instead of pushed aside. (I read some minutes from a PHP 6 meeting a while ago where they touched on the issue of consistency, and the PHP Group decided that it wasn't important enough to fix. It's really annoying to me to need a PHP-aware IDE or a manual always handy to program in a language because the arguments and function names are so non-uniform.)

Re:Bad release practices

[daeg]

As a good start, i recommend Django [djangoproject.com]. It's a nice framework that takes care of a lot for you, but still lets you write Python. They have a few tutorials as well as a good community and an ongoing project, The Django Book [djangobook.com]. I transitioned directly from PHP to Python without any books. Most coding forms transition directly over to Python. As you learn more Python, you'll find shortcuts, e.g., the list constructs and lambda functions.

I also recommend reading over PEP 0008 [python.org], the "standard" coding structure for the Python core libraries. It may seem restrictive limiting yourself to 79 character columns, but you get used to being able to read your code very quickly, especially if you come from PHP or Perl. (Tip: USE SPACES FROM THE START! You'll thank me later.) I can't underestimate the awesomeness of the interactive Python shell, either, especially for beginners.

There are also other platforms out there, Turbogears and Pylons being two notable ones. I think the Django documentation is a bit better, though.

You may also look up Web.py, which is as close to "drop and run" PHP as you'll get without going to pure CGI.

Python takes a little more care to set up at the server level, and you won't find may $1 hosts that support it.

Re:PHP is junk

[Anonymous Coward]

The buffer overflow you have referenced is in the mod_jk Apache module, written in C, which provides an AJP connector for communicating with Tomcat. It was not in the Tomcat application server.

Re:I want to see someone claim again

[CopaceticOpus]

This is where we need to draw a line when talking about how good PHP's security is. For the case of a PHP developer running his own trusted code on a server, PHP can be very secure if the code is well written. That's the developer perspective. The other case is the PHP hosting company or system admin, running other people's untrusted code. In that case, the situation is much trickier. It may be possible to host that code securely, but it will take a lot of work and paying attention to security notices.

So how worried you should be about PHP security comes down to whether you'll be running your own code you trust, or hosting someone else's code you don't trust.

Re:I want to see someone claim again

[RzUpAnmsCwrds]

At first I thought you were trolling but from your "fix their performance" statement I realize you just don't know what the hell you're talking about.

Right. PHP's the fastest language out there, as proven in this test.

You're comparing two completely differnet language types. You might as well compare Java and C++.

Compared to other interpreted (e.g. parse tree is built on the fly rather than by a compiler) languages like Python or Ruby, PHP is about average.

Compare PHP to the CLR (or Mono) or to the JRE, and PHP is going to be way slower.

But calling PHP slow because of some benchmark is just bull. Yes, Java or .NET is faster, and if you're writing an application that does a lot of crunching, by all means you should use a platform that is good at it. There are plenty of good reasons to choose J2EE or ASP.NET over PHP, but performance just isn't one of them in a lot of applications.

The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers. What does that prove? It proves that application design and system architecture is FAR more important than what platform you choose. You can run benchmarks all day long, but that doesn't change the fact that Wikipedia does far more with far less than most websites out there - and they do it with PHP.

I serve over 10 million pageviews a month on WS Network [wikinote.com] using PHP, MySQL, and a virtual server with 50MB of memory, a fraction of a 2.4GHz P4, and 100MB of swap. My informal load testing indicates that I could handle as many as 30 pageviews per second (80 million per month) with my current hardware and DB setup.

Maybe I could do more with J2EE or ASP.NET (or, perhaps I could do far less - ASP.NET and J2EE aren't as easy on memory as PHP for small apps). But the fact is that I am doing a hell of a lot already considering the very limited hardware I'm running on.

PHP code execution performance is not, and has never been, a major issue in my experience. It's the same way with Python, Perl, Ruby, and any other "scripting" language. The fact is, you're not going to write an H.264 codec or a PS3 game in Python. But many, many applications are not constrained by CPU performance. 8-core servers are now cheap. 16-core servers will be soon. Changing your language might give you 10x better performance. But architecture and algorithm improvements will probably get you much, much more.

"Performance isn't a problem until it's a problem."

Re:You must be mistaken.

[Jasin Natael]

For multi-threading, install a shared-memory cache, like apc, eAccelerator, or mmcache -- or use an in-memory table in your RDBMS. Now, you can spawn background tasks and monitor their progress or receive return values through the cache. You can even start a task as a server and keep it running indefinitely with set_time_limit(). I do plenty of unicode apps as UTF-8, and haven't had problems yet. If you're talking about UCS-2, then you have a good case. It's in development [php.net], but it's for PHP 6. Honestly, I'll probably switch languages before v6, based on all the other crap they're talking about throwing in. Version 5 is already getting pretty bloated, and it's only marginally faster than Java.

Here's the utility function I use to spawn background threads (like, sending a thousand customized newsletters or updating hundreds of thousands of database rows). The background process can either lock a file or create some shared-memory structure to indicate its progress, and you can return immediately and end the script before it's done running. The nice prefix is optional.

function fork($shellCmd) {
exec("nice $shellCmd > /dev/null 2>&1 &");
}