RIP Old Sites

Over the years I’ve created several websites, some with the hope of becoming big and popular. Naturally, I’m still waiting to create a site that becomes big and popular. In the meantime, it seems appropriate to retire some of the older sites and ideas. The truth is, I’m moving all my little sites from MySQL on a mediocre VPS to Postgresql on EC2.

Because I put some sweat and blood into these sites, I thought it would be only appropriate to record how the sites looked for future sentimental value. I downloaded a small plug-in for Firefox to take full-length pictures, and I thus post them here.

Back in Taiwan I created a site to demo blogs. The idea certainly wasn’t revolutionary, but I thought that somebody would find it useful. Nope.

The second idea was to send a bunch of little ducks around the world and track their progress. My friend Jamie took one to Europe, but besides that, I don’t think most people really understood that they were supposed to hand the duck off to somebody else. I’ll re-brand and launch it again if I can find a little twitter logo to send around, because hopefully people on twitter will understand to pass the duck onwards.

So photos for nostalgic sake.

It is always a bit rough retiring old sites, but looking back I learned a little, had some hope, and that’s all I can ask for.

Size of Uncompressed OSM File

I’ve been playing around with OSM a little lately, and have been meaning to construct my own slippy map. At first I wanted to do it on my VPS – but with rather limited storage, and even more limited memory, there just isn’t a way. Three problems exists: the first occurs when trying to use osm2pgsql to import the OSM file into the database. Current records state that this typically uses 650+ MB, something my 512MB VPS just doesn’t have (although I’m writing some code that might make this possible in the future).

The second problem exists with CPU usage. Processes on my VPS don’t really utilize the CPU much, which means renicing the process doesn’t do a thing. The CPU pegs at 100%, as it is supposed to do, except that the VPS auto-kills processes that stay at 100% for any length of time. Luckily somebody wrote a program called “cpulimit” (apt-get install cpulimit) that will cap the CPU usage for a process.

The last problem that I thought about is what if I could uncompress the file. Would that use less memory to stick it in the database? I searched and searched but couldn’t find an answer to how big the actual .osm file is. I ultimately broke down and decided to spend the 50c it would take to get this all done with EC2, and write some scripts to automate it in the future.

However, since I’ve finally uncompressed the .osm, I can tell you that as of about January 1st, 2008, the uncompressed OSM size is 67GB.