Skip navigation.

Stefan Esser ruminates on PHP Security #

Stefan Esser, one of the foremost PHP security gurus in the world is interviewed in Security Focus. He's also well known for disagreeing with the PHP Group (that oversees PHP Core development) about the way PHP security issues are treated. Disturbing in more ways than one.

The Shape of Future Processors? #

I read this article on CPU trends Converging Design Features in CPUs and GPUs. Matthew Papakipos writes:

Where are both CPU and GPU designs converging?

  • Both processors will be massively multi-core –- think hundreds of cores -- within a five-year period.
  • Both processors will have complex memory hierarchies, with programmer managed core-local memories and core-local hardware-managed cache. (My own belief is that hardware-managed cache will decrease substantially in importance.)
  • Memories will be strongly non-uniform with significant latency and throughput differences between local and non-local memory.
  • Accelerators that can offer substantial speedups for specific tasks, either integrated on-chip or available via a HyperTransport-type interconnect, will be ubiquitous.
  • I'm more interested in modern CPUs trends and their relation to PHP, and not GPUs. Here are some of my thoughts:

    Well PHP running in pre-fork mode on Apache or FastCGI on IIS/Apache should have no problems handling massively multi-core architectures, assuming the cores are uniform in design.

    As to complex memory hierarchies, we already have to handle the different latencies in harddisk -> harddisk cache -> cpu data/instruction caches. We always had the option of caching data on a hard disk or RAM disk, and some PHP Accelerators already give you the option of caching data in shared memory -- I just see it as more of the same for PHP developers. Things get more interesting for PHP compiler and opcode cache designers as they will have more options for caching PHP opcodes and data.

    What is interesting is the possibility of hardware acceleration of PHP. To me, it's not likely that any CPU vendor will come up with a hardware accelerator for PHP, but a CPU accelerator for .NET or java opcodes is a strong possibility. Thus in the long run, .NET or java compilers for PHP (and Python and Perl) could become mainstream.

    My experience moving to PHP5 #

    In August of this year, we decided to move from PHP4 to PHP5 for all our future PHP development. The transition was relatively painless, as the core libraries we use (ADOdb, PHPLens, some PEAR modules) are already PHP5 compliant and have been for some time. What's nice about PHP5 is that it caught some errors that have been lingering in our code: PHP5 no longer allows a function to be defined twice, and some basic variable referencing errors that we missed previously.

    We have ported our key web applications over to run on PHP5, but for some key customers with extremely large PHP4 code bases, we felt it was safer to keep them running on PHP4 for the time being as the cost of migration would be high; and we weren't sure whether it was worth it as the customers seem to be happy with PHP4's current performance.

    Other things that we have changed is that we have transitioned to using XMLHttpRequest for all our Ajax calls. Formerly we were using the excellent JSRS library, but I can already see most programmers we hire in the future will be more familiar with XMLHttpRequest than JSRS. The nice thing about using XMLHttpRequest is that all XMLHttpRequests can be debugged using the excellent Firebug, a Firefox/Mozilla extension that is extremely useful for Javascript debugging.

    I admit we are still retrograde when it comes to exploiting PHP5's new functionality. Last month, we had to do a presentation so we moved our PHP5 web application to a notebook. Later I found out that notebook only had PHP4 installed. The web application worked flawlessly.