I’ve been liking barebone servers more recently. Sure they’re still a little more expensive than purchasing parts separately but when it comes to a 1U or 2U the convenience and security that comes with knowing all the parts are going to work together is often worth the price. I have a couple of projects where these servers might be needed but some of the architectural details still need to be resolved and as such a couple of models might work well given the different contraints.

A number of years ago I tested the Linux ECN support and found that so much of the internet became inaccessible that keeping it turned off was the only sensible things to do. A few days ago while working on ingress traffic shaping I decided to try again. With ingress traffic shaping the only way to get a host to send slower is to drop packets forcing them to be re-transmitted. ECN could help alleviate waste by allowing a host to signal that packets are coming to fast without dropping packets that have already arrived. Unfortunately it did not take very long to learn that ECN is still unusable due to the large number of devices which will not pass traffic from ECN enabled hosts. My home DSL modem was one of them. Maybe someday ECN will work and enable smarter traffic control but I won't be holding my breath.

Or perhaps it should be “Yet Another Rails-Like Framework”… In any case Ruby Waves was released today. I read through the tutorial and liked some of the things I saw. Ultimately Rails not being thread-safe is a huge problem that needs to be resolved if it is going to remain a viable framework compared with the other Ruby frameworks such as Merb and Waves. Waves is heavy on magic and in that sense I suppose it is taking Rails to it’s logical extension. I find it interesting that it uses Sequel instead of ActiveRecord as an ORM. I also wonder if any of these frameworks will work on development tools. That’s one area that Rails has been successful and a reason to stick with it and hope that Rails becomes thread-safe (especially in time for Ruby 1.9).

• Started working with Maruku as a replacement for BlueCloth and RubyPants
• Got Rails helper testing setup and started writing tests
• Found a way to switch the linebreaking mode for Maruku and BlueCloth
• Did more work with ICalendar to important and export calendar events
• Started exploring the new Rails 2.0 sanitize helper

The rubygems package in Ubuntu 7.10 (Gutsy Gibbon) is version 0.9.4. I have found that this causes problems with certain gems (such as gemsonrails). I decided that using the newest version might make things easier. I decided to leave the existing rubygems package installed in case anything went wrong and ran: sudo gem update --system followed by sudo ln -s /usr/bin/gem1.8 /usr/local/bin/gem. This means that the gem command will use 1.0.1 (currently) without touching any files from the rubygems package. I did note that trying to run /usr/bin/gem will fail due to it trying to use the newer files. So reverting to the older version presumably requires removing the updated files /usr/local/lib/site_ruby/1.8/. Since Ubuntu 8.04 (Hardy Heron) is also currently shipping with rubygems 0.9.4 this may be a useful setup for a while.

I decided to give the newer version of Tor a try today. It took a few more steps than I was expecting. I ended up having to move the existing /var/lib/tor directory and recreating it with the proper ownership (debian-top:debian-tor) and permissions (0700). After that everything worked fine. It seems like something about the existing configuration in the 0.1.2 branch prevents the 0.2.x branch from working after upgrading. Of course, if I decide to go back to the stable version I expect I may want to restore the previous version of the directory. But for now the 0.2.20 version seems to be running pretty well.

During some recent testing of traffic shaping I found that ingress traffic policing was important to maintaining low latency for high priority traffic such as VOIP. Unfortunately the traffic policy abilities of the Linux kernel are crude and limited to simply dropping packets over a given rate for specified conditions. This keeps latency low but requires the dropped packets to be retransmitted thus wasting bandwidth. IMQ has been one way of addressing it. Anyway I noticed that new IMQ patches were available for more recent Linux kernels and iptables versions. However, at the moment I’m more interested in trying the successor to IMQ, IFB (Intermediate Functional Block), which is supported in Ubuntu 7.10 (Gutsy Gibbon).

I've been noticing that a lot of cases do not have speakers these days. I find this to be an unfortunate trend as the PC speaker is the only way to diagnose certain hardware problems on the majority of motherboards. In dealing with some problems today on a system without a speaker I finally pulled a speaker from an old system marked for donation to use to diagnose the problem. I plan to keep this speaker in my toolkit from now on. Of course, the speaker was only so useful as when I looked up the beep code (long short short) I was told the problem was video. The problem ended up being the RAM. But at least once I had gotten the memory issue resolved I was rewarded by the sound of a post beep.

After installing a new heatsink in a machine I realized that although I had munin monitoring the machine I did not have the sensor data necessary to compare the performance on the new heatsink to the old one. So I decided to add that monitoring data as well as monitoring data for the hard drive temperature and SMART statistics. Here’s what I did on a 64-bit Ubuntu 7.10 (Gusty Gibbon) system.