Archive for Open Source Technology

British PHP? Cheers!


Several minutes ago, one of the regular and long-term contributors to the PHP community, a gentleman by the name of Daevid Vincent, posted a link to a blog post on the PHP General mailing list. (Enough links yet? Hang on, there’s more to come.)

The blog post, If PHP Were British, was something I enjoyed — despite my apparently inferior dialect of English, the bastardized American version. So I figured, what the hell? We got the land (after we, as Redcoats, knocked off a few million of those pesky Indians), so why not offer a peace treaty in the form of a few lines or reworked PHP core?

After about fifteen minutes of work, the result: BPHP (lifted straight from their comments section). It’s based upon the latest stable of the 5.4 branch as of this writing (5.4.4), and has the changes requested specifically by the main article, as well as few other related changes. Nothing serious, but it shows that, yes, most Americans are willing to reach out and be friendly and helpful world citizens, regardless of how we may appear to the rest of the nations around the globe.

Want to give it a test drive? Go ahead and download it in .tar.gz or in .tar.bz2 format.

You’ll no doubt see errors and such, but have no fear — I have absolute no intention of supporting this release, nor providing bug fixes, or really even acknowledging that I did, in fact, spend several minutes of my evening doing this.

I should probably mention that I did this in my own free time (I have about an hour before another client is re-running on the ABC network TV show “Shark Tank,” and finished some other work ahead of time), and not as part of the PHP team. And of course, it is licensed under the actual PHP license, is intended only for entertainment purposes, and neither myself (acting alone) nor the PHP Group, community, or anyone else is responsible for any damage, incompatibilities, et cetera. Just in case there are any future BPHP users out there who are lawyers. ;-P

Happy Friday…. mates.

Announcing the Release of the System Detonation Library for PHP

As discussed somewhat at length in a rapidly-devolving thread on the PHP General mailing list, I am in favor of a function that, when called, will initiate on the host system a self-destruct sequence.  Well, being a nice, sunny, spring Friday morning, I decided to offer just that:

Introducing the first public release of the System Detonation Library for PHP.

This useless extension provides one function with one purpose: to cause your server to explode.  Due to the obvious hazards involved, including (but not limited to) loss of hardware, limbs, and potentially life and liberty, this has only been tested on one single occasion, using a PC with Ubuntu 10.10 and a heavily-modified SVN version of PHP 5.3.6.  Thankfully, as the test was successful, there were no serious injuries.

Firstly, you may download the package here.

Second, as a very basic course on the compilation and installation of this unofficial PHP extension, here are some simple instructions for Linux users.  All others are on their own, and this may (read: probably) will not work anyway…. which is a shame, because I know plenty of Windows boxes that should have the right to self-destruct as well.

  1. Download the package above.
  2. Extract it: tar -zxf detonate-0.2.tar.gz
  3. Change to the newly-created directory where the files are located: cd detonate-0.2/
  4. Build the wrappers for your version of the Zend/PHP API: phpize (NOTE: on Ubuntu-built packages, this command may be: phpize5)
  5. Build the necessary makefiles for your system: ./configure –with-detonate
  6. Compile the code: make
  7. Install the binary (as root, or using sudo): make install
  8. Edit your php.ini to load the newly-installed extension by adding this line:
  9. If you plan to use it via the CLI, you’re done.  For use on the web, remember to reload/restart your web server.
  10. Create a basic PHP script with the following: <?php detonate(); ?>
  11. Check your insurance coverage.
  12. Run the script created in Step #10.

And that’s all there is to it.  Feel free to install this on all of your systems and use it as a replacement for exit or die() in your scripts.  Because, unlike die(), this function will absolutely get the point across, once and for all.

Replacing One Character In A String With A Random Character

Just an hour or so ago, Ron Piggot asked a question on the PHP General mailing list. The original question was how he could replace a single matching character in a string containing multiple matches with another random character.  I mocked up a working example in about five minutes or so.  It’s far from perfect, and not very elegant, but it’ll work as a starting point of reference.

The code I sent back in reply follows:

Distributing’s Synchronization Infrastructure

Several days ago, the primary server hosting all of the data comprising the site for synchrony with all of the mirrors around the world became completely inaccessible. Due to security policies with the provider hosting the server, it was some time before we were able to have the machine returned to normal operational status. As a result, network content became stale, and automated tests on the mirrors saw them as outdated and deactivated them. It pointed out a flaw that, though this time was just an inconvenience, has the potential to grow into something more serious – including a sort of self-denial-of-service, if you will, if it went unnoticed for several days and all mirrors were seen as outdated.

Mark Scholten from Stream Service, an ISP based in the Netherlands and provider of an official mirror for their countrymen at, offered to put up a second rsync server, which gave me an idea: take the load off the primary server by distributing it across three regions.

(Click the image to view the full size version.)

Mark set up the European (EU) box in their Amsterdam datacenter, we (Parasane) had already set up an emergency rsync mirror in case the primary dropped out again which would be repurposed for the Americas (AA), and I contacted Chris Chan at CommuniLink in Hong Kong for what would become the Asia-Pacific (AP) region. Chris had submitted an application to the official waiting list to become an official PHP mirror back in February of 2010.

Compiling data over the course of the last 12 months from mirrors in our network which had it readily available, accurate, and up to date, I drew out a plan for the regions so as to limit the load and stress on each new mirror. Thus, the tri-colored map above. I also learned in the process that we will have served roughly 223 gigabytes of data over HTTP, network-wide, by the end of January, 2011, which averages out to about 1.9GB per mirror, per day, with the 115 active mirrors we have worldwide as of right now.

Setting myself an arbitrary date of 30 April, 2011, the goal is to have all existing official mirrors flipped over to using the rsync server designated for their country. Visitors to should see no difference and should experience no negative impact during the transition, but the benefits will be great: far less of a likelihood of a mirror being automatically dropped from rotation due to stale content; the ability of the maintainer to decrease the amount of time to synchronize their mirror to hourly, providing the freshest content as it becomes available; less latency and greater speeds for many of those who are far from the current central rsync server; far, far less stress on our own network.

The immediate goal is ensuring that there are no snags, and that we can successfully synchronize all of the data to the website mirrors without omission. Beginning right away, I’ll be coordinating privately and directly with a few mirrors around the world to beta test the new layered design according to the rsync distribution plan. By 12 February of this year – a bit more than two weeks from now – I hope (and expect) to have all of the kinks straightened out. After that, we’ll begin migrating the rest of the network in its entirety to the new design.

All new mirrors from that point forward will be instructed to use their local rsync mirror as well, as defined by the map above.

It’s no large task, of course, but I’m hoping that the addition of just three new servers will help to ensure the health and stability of the network as a whole for years to come. While I don’t expect anyone to notice any difference – good or bad – in the user experience, behind the scenes I think we’ll not only see some differences in operations, but also begin to come up with even more ways to improve performance in the future.