Bug/Patch-a-week challenge

I had breakfast with Jon Trowbridge (of Beagle fame) last weekend. One of the things we talked about was contributing to open source. It was a refreshing and eye-opening conversation. People want to contribute but don’t know where to start. There is this vast amount of software, plenty of bugs or missing features, but where do you begin?

We don’t have enough time in the day to do all of the things we’d like but we tend to waste a minute here or there reading Penny Arcade or Google News or whatever. By themselves they don’t seem like much but add them up and you might be surprised how much time you’ve wasted.

So, I issue a challenge to everyone on Planet, one that doesn’t require the ability to code (but if you possess such ability, use it). Pick an application you commonly use and find it’s bugzilla. Bookmark it if necessary. Once a day pull it up while you’re surfing and skim through it. See one that looks familiar or interesting? Confirm it, reproduce it, and add details to it. It helps confirm that there is a problem and helps to track down the bug. Developers appreciate this, trust me.

If you can write code and you see one that you think you can fix, give it a try. No patch is too small. If you fix it, attach the patch and add yourself to the CC list. You’ll get a nice notification when someone responds to your patch and you can feel good about yourself for contributing and maybe fixing something that’s been annoying a user for months.

For as little as five minutes a day (okay, so I sound like Sally Struthers) you too can be a part of what makes open-source great. See your name in lights (or just plain text).

Changelog:
2005-10-25 Larry Ewing

* src/FlickrRemote.cs: Integrate patch from Adam Israel it quote
tag names with spaces in them.

Ordinary users to complain when something doesn’t work, rightly so. Be an extra-ordinary user and do something about it.

Speed blogging

I’m so backed up on things I wanted to say (again) I’ll just do another set of bullets.

  • We’ll be in New York City in early November. I’m going to Ad Tech and Dena is coming along. Hopefully we’ll have time for some fun touristy stuff and lots of picture-taking.
  • I discovered memcached last week while doing performance tuning. It was originally developed to help speed things up on LiveJournal. It’s especially useful in that it runs as a daemon and can be accessed from multiple machines and a variety of languages. If you’re looking for a way to boost performance, check it out.
  • National Novel Writing Month is approaching. I signed up again this year. It’s been far too long since I wrote some fiction so I’m going to use this as an exercise in motivation and scheduling.
  • Dena finally convinced me that I really do need to wear my glasses. I’d managed to convince myself that I could still make out enough of the fuzzy shapes to get by but a bought with a sinus infection made me realize that the strain that was putting on my eyes wasn’t helping. Thanks, dear!
  • Work is still kicking my ass. This migration is eating up way more hours than I ever put in at any real job, but at least I have a vested interest this time.

High performance mod_perl2

I’ve been spending a lot of time porting over some code from ASP.NET to mod_perl2. Along with that rewrite, I’ve been migrating a side business away from managed hosting running Windows 2003 to Linux. Between the porting and migrating, managing the clients and working to grow the business, I’ve had time for little else.

I’ve discovered some pretty cool things along the way, though.

Apache2’s prefork model seems to work much better than its worker model, specifically when interacting with mod_perl2. Gathering specific statistics is difficult so this is strictly empirical data. The worker model worked just fine during testing and initial testing. Once I started pushing some real traffic through the system (on the order of 1M requests/day) I began noticing some odd behavior. Internal to my application, I track how much time it took to complete each request, from start to finish. Those times remained consistent throughout the process, but when I tried going through Apache it took a minimum of 20 seconds.

Something was obviously wrong so I started eliminating possible bottlenecks, like network, processor, and memory. All of those checked out fine. I ran ngrep (one damn fine tool, btw) and watched the request. It was hitting Apache, hanging for a while, and then spitting back a response. So I tested against a static file — it was fast. I wrote a small mod_perl2 handler that did nothing but return OK. It hung. So, I figure that something with the request being handed off from Apache2 to mod_perl2 wasn’t working right.

I ran Apache2 through strace but I didn’t see anything enlightening. I googled, read, and googled some more. I tweaked all of the worker mpm settings with no success. There were plenty of processes waiting for connection but no apparent reason for the requests to be delayed. Then I remembered someone on IRC asked me about prefork vs. worker. I had thought, because it was the default when I apt-get installed mod_perl & Apache2, that the worker model was the one mod_perl2 preferred.

So on a hunch I removed the worker mpm in favor of the prefork one. I had to tune the prefork settings a bit from the default. Suddenly everything became responsive. No processes sitting in “sending reply” and lightning fast response times from Apache. Memory usage seems to be lower and almost nil processor usage. It’s working so well, in fact, that I’m afraid to go to bed for fear it’s just my imagination.

nautilus-wallpaper

I was chatting on irc and organizing my wallpaper when I realized that there was no way to set my background image directly through Nautilus. I cracked open Anjuta and got to work.

Here is the result: nautilus-wallpaper

I still need to wrap my brain around autoconf, automake, etc. I did manage to hack the Makefiles so that the extension is installed to prefix/lib/nautilus/extensions-1.0. Hopefully there aren’t any other quirks with that.