
Some time ago my engine decided to eat itself on my way down to Youngstown. This picture shows where my old engine’s balancer used to be. Three of the four bolts screwed themselves out over time, leaving just the one to keep it in place. Eventually that too gave up, sending the balancer tearing away, taking a bit of my crankshaft with it. The crankshaft was bent up pretty bad, leading me to get a new engine.
Well the new engine has almost 1500 miles on it already, and its doing great. However, my transmission isn’t. The 1337Mobile has a manual transmission, which introduces a bit of human error. While I was shifting into 3rd, my foot slipped on the clutch pedal and wedged the synchro mesh on the 2nd gear somehow. The car is still drivable, but I just don’t have second gear. Sometime next week, I’ll be able to take the transmission out and mess with it. But for now, the 1337Mobile is limping along…
With Twitter’s ever growing reach and limitless possibilities, I thought it’d be handy for the world to have a simple little list of all the robots, services, and otherwise non-human twitter users. A few minutes ago I finished just that: the Twitter Service Directory.
You can find it at http://wm161.net/labs/twitter-bots/. If you know of some neat service and want to share it, submit it and I’ll make sure it gets into the directory.
To keep updated on the latest submissions, you can follow @ServiceBook, which gets updated after every accepted submission.
Be gentle with it for now. I have it using ServiceBook’s API calls whenever a new username is submitted, and if a call fails it doesn’t tell you. I’ll rewrite it later to only suck up those API calls when I use my mod powers (hooray wordpress plugins!), or if its close to the end of an hour where calls reset back to 30.
Ok, as I said, here are some more fabio pictures. I didn’t upload them as I said I would on sunday, because I was hoping to acquire a worm clamp to attach around the barrel to further strengthen the whole device. Here’s the final product:
Looks fantastic, doesn’t it? Soon, we’ll be trying it out with its full potential.
I’ve been a wee bit busy the last few weeks. Working in construction is exhausting, even though I’m only shop help. I’ve made a good list of the topics I want to write, but I just haven’t had the time yet:
I’m more exited about the video than anything. Its something new for me to try. I thought up the idea while I was repairing the wiring in Fabio’s control box, because not a lot of my friends know how to properly solder.
So keep an eye out soon for those new writeups (hopefully)! I should have at least the fabio pictures done before monday.
To add a few megs of space to my LiveDrive USB project, I repartitioned the drive in gparted, created some new LVM parititions, and then reinstalled the disk data by unpacking a tar archive I previously created. One crucial step I left out was telling my bootloader where everything went. Originally, my /boot partition was stored as the first partition. Somehow, I managed to make it the second partition (after my LVM), and now GRUB was all confuzzled.
To fix it, I tried running the command grub-install /dev/sdf. It failed saying it didn’t know which BIOS device corresponds to that linux device. The reason behind that is because on my host computer’s /boot partition, there is a file called /boot/grub/devices.map. In it is a cached mapping of BIOS devices to linux devices. Probing for devices takes a good bit of time, so it makes sense to cache it. This map file is only used by the command line version of GRUB, which recreates it when it doesn’t exist anyways. Renaming it let me progress a step further.
Now that GRUB sees the relation that /dev/sdf is my second BIOS disk (hd1), I tried messing around with grub-install again. It worked without complaint, but it still couldn’t boot. GRUB spit out a series of ‘GRUB’s to the console on boot, indicating some kind of horrible failure. Turns out, GRUB still thought my /boot was the first partition.
To finally fix this, I ran setup (hd1) (hd1,1). grub-install uses grub’s install command internally, but it uses it rather blindly. It assumes that the drive you give it is the same place where GRUB’s images are (those ’stage2′, ’stage1_5′, etc files). The setup command takes two arguments, and the second one is optional. The first argument indicates where you want to install the bootloader. I specified (hd1) to indicate I wanted it install in the MBR for my USB drive. The second argument indicates to grub where it can find its images and the menu.lst file. Remembering that partitions are 0-numbered, I told it to use the second disk and the second partition.
A few lines scroll by explaining exactly what commands it is running, then it should complete without failure. Once it did, my LiveDrive was bootable again.
Fabio is fully repaired, and I added a few new features while I had the time:



I use the Gnome application Glom to maintain a personal database of things. I use it instead of KDE’s Kexi because it is more complete and doesn’t crash nearly as much. I created my Glom database before I upgraded to Fedora 9 to get my new KDE4, which means it used Postgres 8.2. Fedora 9 uses Postgres 8.3.1, which uses an incompatible database format. Upgrading it takes a bit of work, but it can be done very easily.
First, you need to get a copy of Postgres 8.2. I downloaded the source tarball from postgresql.org and unpacked it. In it, I created two directories, build and install. Since I will only need to run 8.2 very briefly, I’m installing and building it all in once place. After its all done, I can then just remove the tarball and the one directory it created.
Enter build and run ../configure --prefix=/absolute/path/to/install/dir with the correct prefix. Then make and make install. Now you’ve got a tiny temporary installation of postgresql. Set your PATH environment variable to the bin subdirectory where you installed it, then run glom. It should start normally and everything works. In another terminal, use pg_dumpall -h localhost -p 5434 >outfile.sql to get a dump of the glom database.
Once your database is neatly tucked away inside that file, you can kill the 8.2 server with ctrl-c or SIGINT. Now, rename the directory where the glom database is held. You’ll have to ‘recreate’ the database in glom, using the new 8.3 server. Just rerun glom and create a new database with the same name and folder as before. Keep it running while you run pgsql -f outfile.sql -h localhost -p 5434. After that finishes, exit glom.
After that, copy the .glom file you find in your backup over to replace the one glom just created. All properties of your database should now be upgraded to the 8.3 postgres format. Feel free to delete the temporary install now (after checking to make sure it works of course).
I can imagine that there are one or two people out there with these questions, so I’ll answer them right here:
Because 8.3 is a newer version. The frontends (pgsql, pg_dumpall) shouldn’t care what version the server uses. They contain bugfixes and are more (read: exactly) compatable with the 8.3 server, so it makes sense to use something that is both forwards and backwards compatible. 8.2 doesn’t know about 8.3, so there might be some unforseen confusion.
That file holds all your form layouts. Without it, you’d have to redesign all your data entry pages. That’d suck, huh?
Found my camera charger. It hid itself away in my gameboy bag, which makes perfect sense. Nobody ever puts things where they belong, right? Anyways, here are those other pictures of Fabio’s damage:
BoingBoing discovered The Ladybird Book of The Policeman today. My favorite bit is the 66 foot tall police man.