This is a video of a new custom map for Quake III Arena. I'm guessing that it'll also work on the Open Source "Open Arena". It's Springfield!

I've been using VMWare's client for quite some time and have had great success with it. I've run several different guest OS's (some linux flavours, windows xp) without any real problems. I read a blog entry the other day that claimed that VirtualBox was just as fast as VMWare. Since I had previously tried QEmu and found it slow, I just had to try out VirtualBox.

It's fast, fast enough to run video's on it (celeron 3ghz, running Ubuntu, Running VirtualBox with XP in the VirtualBox VM. My next step, try video editing. For the first time I can see myself running Linux as the primary OS on all of my boxes, of course I will keep Windows XP around for my video editing and some other minor stuff, since I bought an xbox 360 I don't game on the PC much any more.

I finally got Shrek Text working for gimp 2.4. Click on one of the shrek-text images to download it. Shrek Text (shrek-text) is a script-fu plugin for Gimp 2.4. To install it under windows put it in your:

C:\Program Files\GIMP-2.0\share\gimp\2.0\scripts

Directory (adjust as appropriate of course) and then choose Xtns...Script-Fu...Refresh Scripts (or just exit and restart Gimp).







Note that I did not create this script, I just modified it so that it will run under Gimp 2.4.

This week I was playing around on my trusty linux box (Ubuntu) and decided to upgrade my linux kernel. Simple enough, it was actually part of the general Ubuntu updates that I chose to apply to my 7.04 install.

Much to my disappointment, my vmware player no longer worked after the update. After playing around a bit, I figured it was because my kernel had been updated. So, I went about trying to install a new vmware player. I must have messed something up, because the install went ok, but the player now complained about mismatched modules.

So, I'm going around my system getting rid of all the old vmware references so that I can do a new install and I find myself in the usr/bin directory and I do:

/usr/bin rm -rf vmware*

to which my machine replies (paraphrase)
"Hey, bub you don't have permission to remove these files"
so, I say...oh yeah...
/usr/sudo bin rm -rf vmware *

Note the difference between the two statemets.
Yep, trusty old rm removed all the vmware files and...all of my other files under usr/bin, essentially rendering 95% of my machine useless.

I am (as we speak) ftp'ing into my machine to try to recover any files I need to backup before my fresh install of Ubuntu 7.10. Thank goodness that my ftp daemon is still running.

So, to make a long story short, sudo and I are on the outs right now...

If you look at a PHP source file you will notice one thing. It's a source file. Not particularly surprising, but think about when you deploy a PHP application, what do you deploy? PHP source files. Now for many other languages; Java, C, etc when you deploy an application you deploy the compiled file. So, the question that you want to ask yourself is this, how much time does a PHP application spend compiling source files vs running the code? I'll answer that for you, a lot.

There are advantages to being able to deploy source files though. It makes it easy to do on the fly modifications or bug fixes to a program, much like we used to do in the early BASIC languages. Just change the file and the next time it's accessed your change is reflected. So, how do we keep the dynamic nature of PHP, but not recompile our files every time they are accessed?

A PHP cache. It's surprising to me that this concept isn't built into the base PHP engine, but perhaps that's because some company's can sell this add on to speed up PHP. Luckily for us, some companies/open source projects provide this plug in to PHP at no charge. These plug ins are generally known as PHP accelerators, some of them do some optimization and then caching and some only do caching. I'm not going to pass judgement on which one is the best, any of them are better than nothing, but I decided to use APC, the Alternative PHP Cache. I chose this one because it is still in active development and is open source and free.

Alternative php cache can be found at php.net, just look down the left column for APC. It comes in source form, so you will need to compile it before installing it, don't worry about that part. If you're using Red Hat 4 or CentOS4 I'll tell you exactly how to do it. If you're using something else, you'll need the same tools, but getting the tools might be a bit different.

1. The Tools
Do you know how many web sites, forums and blogs I went to with my error messages before I found the answers as to what I was missing when I was trying to install APC - Alternative PHP Cache? Two days worth, but I finally found the correct combination and it's really quite obvious as is everything once you know the answer. There are three sets of dev tools that you will need.

1a. You'll need a package called "Development Tools" this will include all the important dev tools like the GCC compiler, etc.
1b. You'll need a package called php-devel which as you might guess are development tools for PHP
1c. You'll need a package called httpd-devel which of course are dev tools for Apache web server.

On Red Hat or CentOS getting these should be as easy as the following 3 commands:

yum groupinstall "Development Tools"
yum install php-devel
yum install httpd-devel

You'll do these three one at a time and follow any instructions (usually just saying yes).

Now it's time to follow the instructions contained in the APC package. Since these may change over time I'm not going to go through them. They are very complete. If you follow the instructions and get an apc.so file out of it, then you're all set, just modify your php.ini file and you're good to go.

There are two problems that I encountered that you may encounter too. The first is an error when running phpize. I ignored this error and everything succeeded okay, but not before I spent hours looking for the solution to this error. Here is the error.

configure.in:9: warning: underquoted definition of PHP_WITH_PHP_CONFIG
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:32: warning: underquoted definition of PHP_EXT_BUILDDIR
configure.in:33: warning: underquoted definition of PHP_EXT_DIR
configure.in:34: warning: underquoted definition of PHP_EXT_SRCDIR
configure.in:35: warning: underquoted definition of PHP_ALWAYS_SHARED
acinclude.m4:19: warning: underquoted definition of PHP_PROG_RE2C

People would have had me updating my PHP version from 4.3.9 and everything else under the sun to get rid of this error, but in the end it didn't matter. My APC compiled and installed nicely and I am good to go.

The other slight problem that I ran into was the location of php-config. The install instructions wanted me to do the following:

./configure --enable-apc-mmap --with-apxs --with-php-config=/usr/local/php/bin/php-config

However my php-config is in /usr/bin/php-config. Making that change allowed this part to work.

So, have at it, once it's done you can expect to see huge improvements in your web site response times and reductions on your CPU load. One more quick note, My server hosts about 20 web sites, but only 3 or 4 are really busy. To reduce the memory footprint of caching everything for all 20 sites I used the apc.filters property. Although this property is slightly flawed for non qualified includes, it worked nicely for my Serendipity blogs. Your mileage with this property will vary according to the software you are using and how it does it's includes.

I run about twenty websites, formerly spread over two shared hosting accounts. Last month my hosts, both independently shut me down for over utilizing CPU. Fair enough, I didn't think that I was abusing the accounts, but I don't make the rules.

I immediately started looking for alternatives and decided on Go Daddy dedicated hosting. The price was right and for just over $100 a month I got a nice server with 2 GB of memory, 500GB of monthly bandwidth, a speedy CPU all to my self, to abuse as I see fit.

Fast forward to UFC 77. You see I run a web site which does UFC predictions and UFC results. On fight night, the site can get pretty busy, my previous high was 18,000 visitors in the 3 or so hours that the fights take place. My shared hosting account never had a problem with this load, at least not as far as I could tell. However, with UFC 77 on my new dedicated hosting account my server hit a brick wall. The CPU was at 100% and there were 200 apache processes all vying for the available CPU and memory. Immediately I started looking for reasons and more importantly solutions. Three days later I think I have most of my answers.

It's important to know that Go Daddy was not at fault, I asked for a box with certain specs and that's exactly what they gave me, complete with all the software they said. MySQL, PHOP 4.3.9 and Apache 2.0.52. So I started looking (when the server calmed down) at what was happening when a user requested a page. The first thing that I noticed was that the current apache process would take about 5% CPU, I did not pay attention to how long it ran. The next thing I noted was that mysql would also take significant CPU, if only for a short period of time. It's important to know that during UFC 77 MySQL was taking approx 50% CPU for the whole busy period. Time to search for some optimizations.

For my site, where there are 20,000 visitors in 3 hours and maybe 10 updates during that time, caching would obviously be helpful. I noticed searching the web that apache has some caching and even better some min caching, however it is not considered production ready in the 2.0.52 build that I have, so I discarded that idea rather quickly. I did however notice some things when I looked at MySQL optimizations.

The most important MySQL optimization that I found is the query_cache_size option. You see, MySQL has this concept of query caching, here's a simple explanation. If I do a simple query, say

SELECT customer_name from customer where customer_id > 10 (I know, a silly query)

Generally the database goes through all of it's magic and returns back the result set of all customers names who's id's are greater than 10. For this query it wouldn't take very long, but the more complex the query the longer it would take. However, with MySQL query caching, the result of that query would be kept in memory, along with the query itself, meaning that the next time the same query was run the database would just check that no tables in the query have been changed and then look up the result in memory and give it back. This is much faster. MySQL has query caching turned on by default, but the query_cache_size variable is set to 0, essentially disabling the feature. To turn it on you must do:

query_cache_size=64M in my.cnf

Note: I also increased my query_cache_limit to 4M and my thread_cache_size to 384. There are many other MySQL options which you can set to enhance performance, look for a good MySQL book or maybe I'll post some of them on my open source depot blog at www.open-source-depot.com/blog.

After setting those options in my.cnf you'll need to restart MySQL, being that I'm kind of impatient and I don't like restarting processes I went to the MySQL command line and set the global options. For some reason the 64M didn't work for me there, so I used the expanded (bytes) version

i.e mysql> SET GLOBAL query_cache_size = 60000000;

to see what's set, do a:

mysql> SHOW VARIABLES LIKE 'have_query_cache';

Note: You need to tell MySQL to "go" with a \g on the next line.

Now I tried hitting my blog a bit and found that the CPU for MySQL never went over 1 or 2 (except for the first hit), very very cool. I must make a note that I have found some references on the net where query caching on MySQL actually degrades performance for certain circumstances. I would guess that in a heavy update environment (a shopping cart for instance) that the overhead of the cache might outweight it's usefullness, but for sites like mine where it's 99.9% reading and only .1% writing query caching is awesome. There are other MySQL optimizations that I want to look at like table caching and maybe even persistent connections, but one step at a time. I want to see what kind of difference this one change will make. I'm hoping for good things. My next step is PHP caching, but I'll save that for another article.

Visit ubuntu.com to get it.

Ya, so do I. I know that they now have "Fedora Core" and I'm sure it's really really good, but I wanted to get my hands on a free copy of Red Hat enterprise 4. Well, a little searching turned up CentOS.

Yep, the same CentOS that godaddy uses on their accounds is a free "binary compatible" version of Red Hat enterprise. I immediately pulled it down, stuffed it into a VMWare virtual machine (running on Ubuntu) and gave it a test drive. Pretty cool stuff.

So, if you need Red Hat Enterprise, but don't need the support contract, give CentOS a try. Just google centos...it'll be the first one that comes up.

I have no idea why the ubuntu install wouldn't do this automatically, but here it is:

Edit the file /etc/dhcp3/dhclient.conf. The first commented configuration line sets the hostname. Uncomment it (remove the #) then change the hostname. I have found I don't need a fully-qualified name (like is there by default), just the name of the computer itself. The machine I'm on looks like this:
send host-name "myhost";

Save the file, and get dhclient to restart. (Simplest way is just to reboot, but that's a Windows answer so... )

First things first, this article isn't only about which hosting is best for Serendipity blogs. It's just a general shared vs dedicated hosting article. However, most of the web sites that I do use the Serendipity blog engine, so the title is appropriate in that way.

When you first start thinking about building your first web site you are faced with a lot of choices. You need to choose a domain name, but also somebody to register that domain name. You need to decide on whether you'll use a CMS tool like Joomla or a blog engine like Wordpress, or maybe you'll purchase a nice template and use that. One of the biggest choices you'll need to make is your hosting service. The right hosting service can be the difference between spending time installing and configuring your site and spending time adding content.

Once you've chosen your hosting service you will be asking yourself one more important question. Do I choose shared hosting or dedicated hosting? There is not an easy one or the other answer to that question. In fact I'm having trouble even phrasing it generically so that you can size up your situation and decide, but I'll lay down a few rules and gotcha's and see where we end up.

On the surface shared hosting seems like a great deal. For instance from Go Daddy you can get shared hosting plan for just $3.99 a month. The plan will give you 5GB of disk space and 250GB bandwidth. For a little more, $6.99 you get 100GB disk and 1000 GB bandwidth. Now, I just used Go Daddy as an example, but Host Gator and others are similar, some with slightly higher prices and some with slightly lower, but all have the same rules.

Hidden somewhere in your shared hosting agreement there will be a clause about not hogging system resources. What that means is that even if your site is not busy 99% of the time, if you get a big spike they have the right to shut you down. You see, the factor to be concerned with is not bandwidth or disk storage, it's CPU cycles. It's not average CPU cycles over the month, if you spike even for a short time all hosting services will shut down your shared account.

How do I know about the shared host shutdown? It happened twice to me. I'm not complaining, that's the price of having a successful web site while paying for bargain basement hosting. In my one case I got shut down because I had 8000 hits in about an hour. My daily average was about 500 hits. It seems that the blog engine I was using was using too much CPU time on my shared host, so they shut me down. Okay, so you're thinking that you can go shared and when you get to around 7000 then you can switch over to dedicated. Maybe that'll work, but in another case I was shut down with just 346 hits. Now for the 346 hit case my host sent me the log file and to my eyes it didn't seem that I was using much CPU at all. It showed my account using 100% CPU for .2 seconds. It also showed (in another case) my process taking 29 seconds, but using 0% CPU. I believe this was a case of mistaken identity. They saw that their server was slow and looked for long running processes, but didn't look at actual cycles taken. The long wait by the way was because of a YouTube vid running on my site.

So, after a full year on two shared hosting accounts, from two different companies, it was time to try my hand at dedicated hosting. One thing you must know about dedicated hosting is that you are running and responsible for all aspects of the box. That means that you are "root". There is nobody else monitoring for hung processes, nobody else installing software for you, but the best part is nobody kicking you off for using too much CPU for 10 seconds of the month.

My shared hosting accounts were $6.99 and $10 (total of $17/month). My new dedicated hosting account started at $79/month, but I bumped up the memory and CPU on the box and the final price is $111/month. That's a huge difference when you're just starting out, and over the first year I've saved $1200 going that way, but now I feel to move forward with my web sites I need the freedom that dedicated hosting allows. Freedom to have a busy day, freedom to be successful.

I don't want to make you shy away from shared hosting when you're just starting out. It's a great way to get your feet wet, establish a proof of concept and build your knowledge while keeping your budget low. Many small businesses or personal pages may never need more than a shared hosting account. For me, one year on shared hosting gave my little business enough time to grow enough for me to justify paying for dedicated hosting.

As a closing note, my ongoing move from my shared hosting accounts to my dedicated hosting account has taken about two weeks. The first couple of days was experimenting and learning, followed by a few days moving my best performing sites over and the last week has been spent moving the rest of my web sites over, cleaning up security and doing more learning. In the end, I chose Go Daddy as my dedicated host. I figured they deserved it, at least when they shut me down at 8000 hits it was conceivable that I was over stressing my shared account. As for the other company, the one who shut me down with the log file which proved nothing at 350 hits, sometimes you only get one mistake and in the web business when your site is having it's best day ever and your host shuts you down without good reason, it's time to move on.

I've found GoDaddy.com Hosting Plans to be the best that I've tried, but I am only one person. Shop around and see what fits your needs best.

If you do decide to purchase one of the GoDaddy.com Hosting Plans come back here and click my ad for godaddy It will cost you the same amount of money as if you go there directly, but I'll get a bit of a kickback...and isn't that what it's all about?

Moving to a new server is never easy or painless no matter how much work a software company (or open source project) has taken to make paths relative and isolate server specific settings. The fine authors of the Serendipity blog engine have done a very good job with these abstractions, but there are a couple of tricks and tips which will help you out if you need to move to a new server and/or a new domain name.

The first thing you need to do is make sure your security on your new server is set up correctly. For my case I had to move about 20 web sites from a shared hosting account (where security was managed for me) to a dedicated hosting account (where I had to implement the security myself). I am not going to elaborate on what I had to do for my security requirements, but for yours you will need to make sure that the appropriate directories have write access from PHP (or more likely the web server that PHP is running under). If you have a shared hosting account you can pretty much assume that this is taken care of for you and the files you upload via FTP will be given write access by apache.

Once your security issues are sorted out you are ready to move your stuff. What I did is I FTP'd all the files from my installation to my local drive. From there I would be free to modify what is needed. I also created an export from MySQL using myPHPAdmin. When I created my export I chose drop database and drop table options, this way my new database was being created right from scratch. If you are installing to an existing database on your new server clearly you don't want the drop database option. I also pulled down this generated .sql file to my local box.

Now for the fun, a couple of quick steps and you'll be ready to start the move.

1. Go into the generated .sql file and do a search for your old path. For example mine was something like /home/a/b/c/jonny/html/serendipity/ then modify all instances of this string to where your new install is going to be. For example, my new install dir is something like /home/mma/public_html/

i.e. search and replace old install path with new install path in MySQL file.

2. If you are changing your table prefixes on your new install (you probably aren't), then change all these instances. My old was serendipity_mma_ and I decided to keep that, so no changes were necessary.

3. If you are changing your domain name, then make all of those changes. My old domain name was mma.gocurious.com and my new one is www.ufcresultslive.com, so I did the search and replace on all of those. Technically I didn't need to do this step as I am redirecting all traffic from my old domain to my new one anyway, but it's better to have it changed.

4. You are now finished with the .sql file, save it and remember where it is. You will need to upload and apply it later.

5. We now need to fix your serenendipity_config_local.php file. This is the file in serendipity which contains your database information (name and password), database prefix (serendipity_mma_ in my case) and all the other goodies that serendipity needs to connect to the db. Make sure that these values correspond to your values on your new database. You can now save your serendipity_config_local.php file.

6. You can now upload (probably via FTP or SFTP) your serendipity files to the new server.

7. We need to build your new database. How you do this will be specific to the tools that you have access to. If you are moving to a dedicated host then you can simply upload the .sql file and apply it via the MySQL command line tools. If you are moving to a new shared host then the myPHPAdmin import will only handle up to 2 meg. If your db is larger than 2 meg you will need to get a tool known as BigDump. Note that I have not used BigDump myself, but have read that it works quite well. BigDump essentially splits your sql into < 2MB chunks and applies them.

8. You're almost done, you've updated your config file, built your new db with all the changed info and uploaded it all to the server. All you need to do now is change your domain to point to the new server and wait for the change to take effect.

That's it. Congratulations you should have now succesfully moved Serendipity to your new server. When I did all of this my security wasn't set up properly, so I had to chmod some files temporarily to make them writable. The most notable was the config which was 700 I believe and since my FTP user and web user aren't the same I didn't have write access. Serendipity is nice enough to tell you when it can't write to a file.

Note: Always make sure that your new server is up and running and stable before cancelling your old account or deleting your files off your old server. I made that mistake and was down for about a day with a problem as a result. If I'd left my files on the old server I could have just switched my domain to point back at it while I figured the new problem.

This video aims to answer that very question.

In my previous entry I talked about this suite of applications from portableapps.com which can be installed to a memory stick (USB, Flash, whatever). All of the application info is stored on the stick and the host machine never needs to know about the apps...cool, right.

Well, I found a new addition to the Portable Apps family. It's called DOSBox. It's essentially a DOS emulator which runs right off the stick. I tried it out and was able to run Doom, Wolfenstein, Duke3d and others all in their glory. Apps can run in a window or fullscreen.

Below is a pic of Wolfenstein 3d