There are two things I really need to get accomplished within the near future…at least on the tech side of my house.

1. Finally settle on a host OS for my websites. I’ve got a few on Debian right now and one on Gentoo, but running two MySQL databases and two Apache daemons is really starting to kill my hosting server and the downtime of my blog last week was the result of said resource exhaustion. I think I’m going to settle on Gentoo for right now for it’s virtual hosting capabilities, for better or for worse. But it will take a lot of work to recreate the setup I have.
2. I’ve had a sweet little perl script lying around the past couple years that draws pretty, but limited graphs. Stumbling across Blender, an open source 3D modeler has renewed my interest in the script as it could be much more effective with an animated 3D model! I should probably work out the kinks first, but half the kinks were with the graphing software I was using.

Of course, both of those are no easy task, especially when the rest of life comes into play. But, hopefully, I can have at least one of those wrapped up in the next month. I’ll give the other until the end of the year and hope that I find the motivation one night to pound through it.

I just spent the past three hours or so trying to get my 2005FPW monitor working on Gentoo with my T42 docked. It was not an easy process and I have to go to bed, but there were a couple things that pointed me in the right direction.

1. Ubuntu on a T42, specifically the Video portion, and even more specifically the MonitorLayout option actually got the monitor functional.
2. The ModeLine from this page gave me a proper resolution.

This FreeBSD post on dual monitors also helped quite a bit, but it was those two links above that made it perfect.

Now I have to crash. Pulling the night shift tomorrow, that’s why I’m up nice and late.

Well, after 1,100 miles of driving, a camp site overlooking the Pacific, a deer carcass…or what was left of it, beautiful sunsets, good times, good friends, and a speed tour of Temecula’s Wine Country, I’m back home!

I’ve got a bunch of pictures to upload later, but I had a great time camping and hiking in Big Sur.

Disconnecting for a bit… See you next Monday!

I did a race yesterday called Muddy Buddy with Jason. It’s a 10K with 5 legs where one person runs one leg while the other is biking and you switch up at every leg. There are obstacles between the legs as well such as monkey bars, low wall, and a couple rope climbs. It was a pretty cool race, but a lot more difficult than I thought it would be. I should also mention there’s a big huge mud pit you have to crawl through at the end, hence the name Muddy Buddy. Jason and I were pretty evenly matched, and did pretty well finishing with a time of 54 minutes, 36 seconds coming in 36th out of 60 in our division and 327th overall (out of 897 teams - official results). I sure do hurt today, and I’ve still got dirt coming out of various body parts, but I had a great time.

Thomas Ptacek made an interesting couple posts about making binaries into c-compatible representation. I could have used that a couple weeks ago…

Success! I can now successfully extract data from a Blind SQL-vulnerable web application with under 500 lines of perl. And Absinthe, after running for the entire 3-day weekend+, is just now beginning to pull the actual table names. I’m not knocking it as it’s data retrieval is probably much more robust than mine, but I’m a sucker for immediate gratification.

Now I just need to prettify the output…

*dances*

I’ve been playing with 0×90’s Absinthe quite a bit lately and while it’s an amazing tool, I’m a little disappointed in some of the methods it uses to gather database information. According to the presentation given at BlackHat in ‘04, table id’s are gathered first and then the table names are gathered using that information. The same is done with fields. Through my usage, I’ve noticed two things wrong with this approach, at least in terms of speed.

First, although I’m not completely sure of the size of the id field, it can be quite large…at least 10 digits…and can range in value to any number that will fit in those 10 digits (or a signed 32-bit integer if you want to get technical…). However, every single time Absinthe tries to identify the id, the search_value (see pdf) is initialized at 2 and increases exponentially. This becomes an increasingly expensive operation as the id value becomes larger and larger. Why not sort the id’s in the SQL query and then initialize search_value with the previously identified id? It seems to me that would save quite a few queries, especially when blind SQL injection is quite the expensive operation in the first place.

Second, querying for the id’s isn’t quite necessary. I’ve had Absinthe running for over 24 hours straight and it’s still querying for id’s. In approximately that same amount of time, although not contiguous, I’ve been able to code up some perl to pull the database structure without any use of id’s. Granted it uses inner joins, which can also be somewhat expensive, but I get much more immediate results. Gotta love immediate gratification.

Well enough of that…time to hit up the town!

2:25 am. I’m coming home after a late night out. Not too late, but late enough to bring out the guys asking for dollars for 4 quarters. I look to my right on the “L” platform and what do I see but a family of 4 - mother, father, and a set of twins. What could they be doing out this late, I wonder… What could they be doing that requires them to bring their poor sleeping daughters..slumped in their arms…out at this time of night. I may never know, but I can only hope I never have to do the same.

*irritated*