Drab as a fool, aloof as a bard

So, here we are in Serendipity Land, enjoying software that cares about security and stopping spam. One noticeable drawback is the lack of a built-in backup feature (although WordPress doesn’t any more either). My old system of manually performing a full backup after each post was, in retrospect, probably not the most efficient way to do things, though. I need to improve the backup system for the rest of my hosting anyway, so I will probably write my own backup script which integrates well with it. I imagine a system where my local machine triggers a new backup of my hosting provider’s database by requesting a hidden script file, and the backup it produces is a file inaccessible to the webserver but SSH-able to my local machine. Having a backup process is particularly important, however, for systems which you intend to use, and until I fixed the “No entries to print” bug, I didn’t think Serendipity counted as such a system. If you are reading this, though, that means I have successfully tamed the bug, and here is how I did it.

For those of you who read this blog and pay attention to its HTML theme (as opposed to just reading the news feed of it), you may notice that these pages look different. I was not unhappy with the old appearance, or at least not unhappy enough to find and install a new theme, so the reason for the change is something more fundamental. I had been thinking of ditching WordPress for a while, for various reasons, but I had an experience with it recently which convinced me that now is the time. The initial objection I had to WordPress was based on a Slashdot article about a controversy over whether the software was spyware. That is a strong claim to make, and I won’t try to justify it here (although for me “spyware” includes any software which “phones home” without telling you, a definition which would apply to Firefox), but comments from the Slashdot discussion lead me to look into WordPress more and I realised that the development team did not share my views. To some extent you have to trust developers to make difficult decisions about ease of use versus security, and let the software speak for itself, but that is what I’ve done, and WordPress’s security record is self-incriminating. When you start setting aside time each month in anticipation of the next upgrade to fix a critical vulnerability in an application, then the developers do not deserve the benefit of the doubt about whether they have the best interest of their users at heart.