It's a Code, Code World

Normally I'm no fan of the "blog by repeating news" style, but in this case I have to make an exception. The headline above is from a Computerworld Security article dated June 20, 2008. Discussing a recent upgrade to Microsoft's Malicious Software Removal Tool, this excerpt caught my attention:

One password stealer, called Taterf, was detected on 700,000 computers in the first day after the update. That's twice as many infections as were spotted during the entire month after Microsoft began detecting the notorious Storm Worm malware last September.

"These are ridiculous numbers of infections my friends, absolutely mind-boggling," wrote Matt McCormack, a spokesman with Microsoft's Malware Response Center, in a Friday blog posting.

This may be mind-boggling to someone who lives deep in Microsoft culture, but to everyone else, it's barely a surprise. The missing part of McCormack's quote should have been "The Linux/Unix guys are right, Windows security still sucks at a deep structural level." Good thing regular doses of Microsoft Cool-Aid prevents that.

The good news is that Firefox 3, one of the best web browsers available, is set to release version 3 in a few days.

The weird news is that it's shipping with Bug 183689 fully intact. Under mysterious (or at least elusive) circumstances, Firefox fails to close a file that the user uploads to a web site. The file is locked and unusable until Firefox is restarted.

This has the ring of familiarity. Any user of Firefox 2.x who has lots of extensions installed will have noticed that it tends to get more and more sluggish over time. A quick look at the process will reveal that memory consumption continuously rises until the best thing to do is restart it.

That's not really a problem that the Firefox developers had a lot of control over. If an extension is leaking memory, there's not much the core can do to stop it. In fact this is one of the major improvements in Firefox 3. A new, sophisticated memory manager now finds a lot of these unreferenced data structures and cleans them up. On my system, the memory footprint for Firefox 3 is nearly 200Mib smaller at start up, and if it grows, it doesn't grow very fast. That alone is reason to upgrade on June 17, 2008 – Firefox Download Day.

The point of this digression is that I've become used to Firefox losing track of resources. But losing a file handle? Really. Can that be too hard to find? Apparently the answer is "yes", since Bug 183689 has been open since December, 2002! There are some good reasons why the browser needs to keep track of the file, for example if you refresh the resulting page, the file is part of the Post data that needs to be re-sent.

But eliminating memory leaks is hard, and it's easy to just rely on increasingly sophisticated garbage collection tools instead of finding the cause. Unfortunately, a garbage collector has no way of knowing that something it's cleaning up represents an open file, so the memory leak is fixed, but the file handle leak remains.

Five-plus years is far too long for a major bug to remain open, even for an open source project. But don't go updating that bug! Despite the fact that there's no explanation that the issue is independent of the user's specific circumstances, any provision of additional information will be considered spam by Jonas Sicking, the fellow who has been assigned the bug. Considering that the bug seems difficult to reproduce, the contradiction is obvious. One would think that more examples might lead to the discovery of a pattern, but that seems to not be the case as far as Mr. Sicking is concerned.

Hopefully he was just feeling a little stressed with a major release coming up so quickly, and his comment will be clarified or withdrawn. If not, I'm guessing this one is going to remain open for quite some time to come.

[Note: it has since been determined that an extension, LiveHTTPHeaders, is the culprit for this bug. My "duh" is withdrawn. My disdain for Mr. Sickling's response remains unchanged, however.]

...that means "Gentoo is too hard for me."

This line came from a chat with another developer, and I had to write it down. It has a lot of truth to it, as I watch my system compile the latest point release of KDE, while telling me I need to compile a new kernel and rewrite my MBR with the latest version of grub. Sigh.

Maybe it's not so much "too hard", but just "too much trouble." Don't get me wrong, I love Gentoo. I've made my Gentoo box do some really neat things, and most of the time I know I have the latest and greatest installed and ready to go.

On the other hand, my Kubuntu laptop is a lot easier to maintain, even if it's not right up there on the cutting edge. An Ubuntu maintenance update takes minutes; KDE will be compiled in 5 hours or so, and there will be manual steps to be done after that.

Then there's the matter of "not by me" maintenance. If I put Gentoo into a production server, how long will it take me to train someone else to take care of it? What are the odds that they'll fail? If they quit, how easy will it be to find a replacement? It used to be that I planned to build a stable binary build on a stand-alone machine, then use it to send binary packages to production servers, but even that still needs someone willing to deal with Gentoo's quirks and complexities on the back end.

Tossing Gentoo and moving to Ubuntu may be copping out, but it's a lot simpler. It's not the "best" solution from a bit-head's point of view, but from the management side, it's "Keep It simple, Stupid" in action.

The biggest problem will be moving all the development tools and demos across. Switching distributions isn't something to be taken lightly. It's a job for when I have a few days to play... like that's about to happen.

The decision to drop PHP4 support in the next version of Joomla was made yesterday.

There's going to be some controversy over this one, but in my opinion, it's the right move. It's actually something I've been (gently, I hope) lobbying for for months.

Top reasons to move to PHP5:

1. By the time 1.6 comes out, PHP4 will be completely unsupported.


2. We can make Joomla run faster under PHP5.


3. The only people this will cause a really serious problem for are lazy ISPs who haven't got their act together. Hosting providers who don't have PHP5 support in place by now probably have all sorts of other maintenance issues outstanding and deserve this pain, in my opinion.


4. It makes my AP5L ACL code a candidate for use as a "rights provider" in the next release, which would makr my first really significant contribution to the project.


5. PHP5 is a lot nicer to code in.

Very happy.

Shortly after finishing the PHP AP5L_Debug class, I encountered a nasty problem with an AJAX enabled page. Although it's possible to include diagnostic information in an AJAX response, the client side JavaScript has to figure out it's there and then figure out how to display it in a sensible way, which also means putting it on the page in some dynamic HTML, or extracting it in a debugger. That's just not fun.

Or you can try setting up an XDEBUG connection, which seems like a lot of work for a couple of diagnostic messages, and if you're running on some shared hosting plan, you can probably forget about that anyhow.

So I figured why not just route the diagnostics out through a socket and write the output on a console somewhere?

So after a little work, AP5L_Debug now offers two variations.

• AP5L_Debug_Stdout just echoes the data to the output stream (well not quite: if no headers have been sent, it buffers the data and then writes everything on the first post-header output, or on an explicit flush).
  
• AP5L_Debug_Udp sends the data to the address and port of your choice. There's also AP5L_Debug_Listener, which is a crude command line tool that reads data from the port and dumps the information to the console.
  

It worked like a charm. The diagnostics identified what was a pretty simple mistake, I fixed the code, and the problem was solved in no time.

Also, since the diagnostics don't mess up the generated page, I can see using this technique even when there's no AJAX involved. That's more than welcome.

I just added a class to the AP5L PHP library that does something I've wanted for a long time.

Most applications have a debug mode that shows developers what's going on under the hood, so that they can diagnose problems. The problem with these modes is always selectively controlling what gets displayed at runtime. Most of the time, debugging is an on/off switch. Turn it on and you get reams of information. Usually only a small part is relevant and you have to dig through it all to find the information you need.

The AP5L_Debug class maintains an array of debug settings. The format of a setting is "type@namespace::class::method". Any value can be associated with a setting. The setting mechanism allows simple fine-grained control over what gets written as diagnostics. Want to turn on all the diagnostics in MyClass? Simple. Do it with AP5L_Debug::getInstance() -> setState('::MyClass', true); Only interested in the close function? AP5L_Debug::getInstance() -> setState('::MyClass::close', true);

The real joy of this is that the actual output statements remain very simple. Just use AP5L_Debug::getInstance() -> write('My debugging message); Debug automatically figures out the class and method names, and looks for relevant settings. Namespaces will be implemented when they arrive in PHP 5.3.

There's some more great features as well. Check out the comments at the beginning of the AP5L_Debug class.

While working on a unit test facility for the "Joomla!" project, one of the developers made me aware of functions in the "Standard PHP Library" that let you do some powerful things with class auto-loading.

One of the biggest challenges with code libraries is making them easy to configure in a wide range of server environments. PEAR is a large, powerful set of packages that is useful in just about any application, but getting the installation right can be a real pain, particularly in shared hosting environments.

The SPL allows an application to manipulate a stack of auto-load functions. So now to use AP5L, all you have to do is include the base AP5L.php file and then call AP5L::install(). The "installer" injects an auto-loader that recognizes all AP5L classes. Since the code for these classes is relative to the base AP5L.php, it can derive the appropriate file name from the class name with ease. If the class isn't part of AP5L, it simply passes it along to the next loader in the stack.

AP5L::install() also has an option for a more traditional approach, adding the install path to PHP's include file path. However this leaves the application with the responsibility of including the class files before they're used. In highly tuned systems with performance optimizers there are some good reasons to load all classes in one shot, and this option makes that slightly easier. [If you're really interested in performance, the best easy thing to do is to merge everything into one big file, stripped of comments and whitespace, but that's another topic.]

One day I needed a simple form for list subscription that needed a CAPTCHA image and I didn't want to go through the trouble of trying to crowbar it into any of the "complex" PEAR form packages.

So I thought "why not build something really simple and lightweight that will create and validate a simple form?" I wanted three methods: create, validate, and save. Sweet, simple, easy to code.

That might not have been the smartest thing I ever did.

Over the years that I've been using Eclipse, my main workspace has been accumulating bit rot. Older versions of plugins have left settings around, many small configuration details have been "not quite right", and I never really figured out how to deal with the glitches, so I just tolerated them.

But the Europa build, or PDT, or something in my configuration brought in "Buckminster". In my workspace, Buckminster had an annoying habit of pausing for several seconds, dumping a bunch of error messages about deprecated constructs in some meta data file (to which I say "it's your damn file, you deal with it" to no avail).

While trying to deal with a major annoyance in Eclipse, namely that settings for tabs/spaces are Workspace global (duh), I gave in to this limitation and set up a new workspace and imported some of my tab based projects.

This is more a case of "release prematurely, release often" than anything else, but I've just completed the move of my PHP5 libraries up to a Google Code repository, with a GPLv3 license attached.

The primary reason for the release is to get the generic ACL code out in the wild.

As the project description says, documentation is thin to nonexistent, and significant parts of the code are just straight copies of the equivalent PHP4 library. I'll be "porting" code as the opportunity arises.