The Fugue

I quickly ran some unscientific bench^Wlogmarks (3 or 4 samples after stabilization at the CLI with my friend time) for camping vs. just erb/cgi vs. just markaby vs. my current blosxom blog (with 10 entries):

time ruby -rrubygems -e "require 'camping'"  # about 0.5 seconds
time ruby -rcgi -rerb -e ""                  # about 0.05 seconds
time ruby -rrubygems -e "require 'markaby'"  # about 0.2 seconds
time blosxom.cgi >/dev/null                  # just under 0.3 sec
time fugue.rb >/dev/null                     # just over 1 sec

The blosxom and fugue runs dealt with the same 10 posts and produce almost to the angle-bracket the same HTML. It looks like to me that I should think about doing my super-simple blog without the overhead of a framework, even one as small as camping, and go with straight markaby or erb for the template.

Camping does fine once it's loaded, but I don't really want 20 megabytes of virtual memory being wasted just so the 5 people out there reading my blog can get it in less than two seconds. As it is I'm trying to find ways to prune rails/apache/etc. memory usage. I think I have an idea, too.

So apparently a lot of this time is startup time, but a lot of the time this startup stuff is the same over and over. I started thinking about one master process that somehow subthreads the rails/camping sites, but that gets messy and who knows when a global variable or some other rogue will really mess things up. Not to mention environment. But wait, I don't care about memory usage when it's actually doing something - it's the perpetual waste of RAM that I'm concerned about. Why don't I have N bootstrap processes that have done the equivalent of require 'rails' or require 'camping' and are ready to load the appropriate ruby script on-demand and then die gracefully after the page is served. I get precise control over how many processes are hanging around, the wasted RAM between requests is much less per lingering process than with a full-blown fastcgi app, and you get fast service.

Well, there's at least one problem: most page loads will have a bunch of requests all at once, so maybe it would be better to have the bootstrap process load up a fastcgi process that can serve the rest of the requests and die after a few seconds of idle time.

If you have thoughts on this scheme, let me know. Yeah, I know I don't have comments, so you'll have to do it the old-fashioned way. If my subconcious doesn't churn something up in the next few days/weeks I might just whip it up.

I whipped up my own replacement to "my blosxom" tonight using camping. It was fun and frustrating, as it always is when working with both ruby and html. It's a little slow, unfortunately, I'll have to profile where the time is. I hope I won't have to run yet another FastCGI process, I don't have the RAM for that. Hopefully some filesystem and pagination optimizations will do the trick.

Pagination was the whole point of moving away from what was already working, and a desire to escape from school and work for just a bit and do something pointless. Learning camping seemed good, because it can be even easier to whip up something small in camping than in rails.

Yeah, it's not exactly working yet. e.g. permalinks and category links don't work. I'll get to it.

Update: After sleeping on it I switched back to blosxom until I get the time to polish up the camping version.

Openbox 3 is a pretty nifty window manager. What I like about it is that it is simple, has a powerful but simple configuration (even if it is XML), ICCCM and EWMH compliant, and works well in Gnome.

Now that I can dual-boot my iBook without the bother of a USB wireless card, I took a few minutes to set up my desktop environment. I used to periodically spend way too much time doing this. I was always on a quest for the best window manager and desktop systems, and I mostly steered clear of Gnome and KDE. Maybe I'm getting boring, but my list of must-haves for window managers has shrunk recently (maybe I should blame OS X). As I'm no longer the primary user on falcon (my wife is), we've been running Gnome there for awhile, and I've gotten used to it for casual usage. I used it for a few months at my last job too, and with a decent window manager (I used FVWM then) it can be quite nice.

So openbox easily displaces metacity with a simple openbox --replace and saving the session. Once you find a theme that doesn't use itsy bitsy fonts it looks fine too (I like the Serenity theme, although the colors are a bit off).

Openbox has the *box feature I love dearly: the dock. gkrellm -w and WindowMaker dockapps I love dearly.

The keybindings and actions are not quite as rich as FVWM, but still quite good. On the other hand it does do MRU-style window switching (e.g. alt-tab), which is a feature mysteriously missing from FVWM.

Here is my ~/.config/openbox/rc.xml file. It matches the OS X keybindings I use most, and some others I made up which have proved quite useful in the past. Here's a preview (mentally replace cmd with meta or win, as appropriate):

• cmd-m to minimize (cmd-h doesn't offer anything more in the Gnome desktop, which is good because vi key emulation always trumps)
• cmd-w to close
• cmd-q to kill (use sparingly, this isn't quite the same as cmd-q in OS X)
• cmd-tab and s-cmd-tab (in addition to the more windows-like alt-tab and s-alt-tab)
• cmd-[hjkl] navigates desktops
• c-cmd-[hjkl] maximizes vertically or horizontally
• s-cmd-[hjkl] moves the window in that direction to the nearest edge. Openbox is the first WM I've seen with this action, and I anticipate that it will be very useful.
• cmd-t to spawn an xterm
• cmd-(up|down) to raise/lower a window

I am writing this blog entry from my iBook G4 with a wireless connection from Linux, with no external wireless device. That's right, you heard me correctly.

The Broadcom 43xx Linux Driver has made this possible. See this LWN article for a good starting place.

I stubbornly compile my own kernel so it wasn't as simple as installing bcm43xx-modules-2.6.15, but with module-assistant it wasn't hard either. The only trick was knowing to compile the softmac module and install its headers. Something like this should work:

apt-get install bcm43xx-source dpatch
m-a -t a-i ieee80211softmac
dpkg -i /usr/src/ieee80211softmac-headers*deb
m-a -t a-i bcm43xx
modprobe ieee80211_crypt_wep
modprobe bcm43xx
ip link set up eth1
iwconfig eth1 channel 1 essid fugal key restricted yourkeyhere
udhcpc -i eth1

It's still in the not-for-the-weak-of-heart stage, but it seems to work well to me.

At least on Debian, when I upgraded ruby to 1.8.4 (from 1.8.2) I got the infamous Logger::Format not defined error when starting up instiki. My other rails apps work fine, since I have a recent version of rails installed, but instiki ships with its own rails, which is apparently not new enough. Solution:

cd instiki-0.10.2/vendor
mv rails rails.foo

Voilá, you're now using your own rails install and it works great. This is where we cross our fingers that this doesn't introduce any bugs...

This was not at all obvious in the documentation, so I thought I'd give a real-world confirmation that if you want to specify a tftp server in your dhcpd.conf, this is what you do:

option tftp-server-name "192.168.1.5";

If you ever see strange sdp content like the following:

...
c=IN IP4 68.142.145.14568.142.145.145
...
m=audio 3501835018 RTP/AVP 0 8 3 98 97 101
...

That is, the IP address and port are repeated back to back (which really throws off the far end), and you are using openser and mediaproxy, then you are probably calling use_media_proxy twice in your ser routing. Apparently, this is a bad idea.