Kit's Blog

Fixing up the old blog

     So I'm currently under a time constraint. And I have to shift my entire server over to a new one by the thirty-first of August. My web host, powweb, says that for the most part it should be a painless process... unless you have a lot of server-side scripting. Htaccess files are particularly painful. So what does this mean for me?

A shitload.

     My website relies heavily on server-side scripting and htaccess files to properly move you around to different areas. Hell, even Scuzzstuff is redirected to a different part of the server through htaccess files. In addition to this, the Berkely database that this blog operates on is starting to show it's first signs of fatigue. After well over 1400 comments (many of which ended up being spam), the thing no longer properly registers comments at all, and my mt-blacklist seems to be unable to successfully scan more than 67 comments back without crashing. One of the entries had become corrupt, but I managed to work around the issue and it is now (if only temporarily) repaired. And although it pains me to say it, this blog may be moving onto a MySQL server. You may ask "why is that painful? MySQL has way better support and is far more stable." But here's the thing, after being around this great, big internet of ours a few times, there's a few things I've realized:
     1) Anything that updates with great frequency is often a bad idea. This, of course, has exceptions. Anti-Virus software that updates with great frequency is good. Database securing software... not so much. Though it shows a great dedication and commitment in some cases to update frequently, more often than not it show instability or incompetence in the base code.
     2) Anything that's not on the same system (things that have to connect remotely to one another) are often liabilities. I've seen far too many websites that give the warning "Error: could not connect to MySQL database" or "Error: MySQL: Too many simultanious connections" to trust the system completely. Powweb offers MySQL servers that are on different machines than the HTML sever in order to maximize the number of databases offered and the security by having separate machines.
     3) Anything you can't have a direct, file-backup of is normally risky in and of itself. Though there is a way for MySQL servers to produce file backup copies, it requires that the entire system is in operation. And the time that you export a backup (in a bad situation) may actually end with a corrupted database if you fail to do so properly. I can set up all sorts of safety nets, it just bothers me.

Anyway, all of this doesn't change the fact that I'll probably switch over just to be sure I don't end up with no blog because the Berkley DB collapses under the strain. Hell, I may even upgrade to a version of movable type past version 2.661! They've got up to something like 3.2, with built in ad-blocker, but I must say I've grown fond of this old system, and may not switch over. My blacklist has grown enormous and cumbersome, but boy is it effective as hell. Anyway, we'll see what happens in the next 12 days.