Out Of The Stone Age

If your OpenBSD 4.3 laptop is extremely hot and noisy, you can put it in Cool Running Mode with
apm -C

This took my Core2Duo T5300 from 1.73 Mhz to 800 Mhz and significantly reduced the noise and heat, when not in heavy use.

So, I still can’t correctly configure my /etc/xorg.conf file using xorgconfig or Xorg -configure. Everytime I try to add my native laptop resolution of 1280×800 it still goes back to 1024×768. So I keep deleting it and using no xorg.conf. OpenBSD then correctly detects my resolution.

However, I can’t downgrade it to 1024×768 at runtime. My main goal for doing that was to use the VGA cable to hook up my laptop to my Samsung 46″ LCD to watch movies and such.  Under Ubuntu, I had to do this because my tv wouldn’t accept the 1280×800 resolution, but worked fine with 1024×768.

Just for the hell of it I decided to just hook up my OpenBSD laptop and reboot. Amazingly it actually output at 1920×1080 to my TV! I couldn’t get Ubuntu to do that! Simply Amazing. I just keep being impressed by the quality of OpenBSD. And I haven’t even started digging into the kernel sources yet

I just installed OpenBSD 4.3 recently. I’ve played with it before and even purchased the 3.6 CD set.  However, I never had much success running it as my hardware wasn’t supported and usually just went back to Linux. I really am trying to get back into the security mindset and figured I might as well throw OpenBSD on my HP dv6345us laptop.

The Install was a breeze! At least it was until I realized that GDM wasn’t included in the AMD64 packages. So I had to reinstall the i386 version. I got Gnome up and running trivially and the native 1280×800 resolution was detected.  The weird thing here is that there is no xorg.conf file in /etc/X11. Being used to Ubuntu and other various Linux distros, this seemed strange. Each time I tried to add one and  tweak by hand I would end up with a 1024×768 resolution. So for now I’m sticking with the default config.

At this point and then it was on to configure the wireless. My laptop has an integrated “Intel PRO/Wireless 3945ABG” card. Surprisingly enough an open source driver is installed out of the box for this. Terrific! What is lacking however is the firmware. But that is easily added with the package created by Damien Berganini. It can be installed easily enough with the command:

pkg_add http://damien.bergamini.free.fr/iwifw/OpenBSD/iwi-firmware-2.3.tgz

Information on how to configure wireless with ifconfig was also readily available with a quick search of the web.

I then installed firefox, emacs, and a whole host of other thirdparty packages.

The only things that disappointingly don’t work are my function keys (f7 and f8 for brightness, etc…) and my softkeys. I will eventually have these working as they work out of the box on Ubuntu 7.04, 7.10, and 8.04.

I also can’t use an external monitor, once again do to the lack of use of the function keys.

I now have to decide if I’m willing to install Linux binary compatibility and the Adobe flash plugin so I can watch tv on sites like hulu.com. I still haven’t decided If I want to go down that road, although hopefully gnash will catch up soon, since Adobe just opened up their specs.

I’ll be back with more updates soon.

Titus Brown has recently posted a very good diatribe on why people should test. It should be required reading for anyone who is not currently testing. I especially like the straw men arguments, as most developers advocating testing are likely to come across at least a few of these. My favorite is:

“We don’t have time to test.” Why do you have time to write software, but not time to make sure it works?

Please take a look.

I learned about Test Driven Development recently and have been using it along with CXXTest for about a week now. I understood the supposed benefits, but in a very short period of time I have realized substantial actual benefits.

First off, by writing tests before I code I think of simple use cases for my code and understand it from a user’s perspective. This is fine in and of itself, but not necessarily that noteworthy. Once I code simple (maybe even throw-away) solutions to these tests I further my belief in my use cases. This may also sound nice, but this is certainly achievable with Big Design Up Front as well. And I don’t disagree, necessarily. Especially if you are a very experienced developer.

However, the test cases themselves are the biggest benefit of TDD. By coding these test cases I can provide a giant safety net for myself when I redesign my data structures or algorithms. Furthermore, by writing the tests first, I make sure they actually do get written. Therefore If I so desired I could code with reckless abandon and rewrite a class completely with lots of STL containers and algorithms, and by re-running my test cases I could ensure that the code still works the way it previously did. While this is not necessarily the “incremental changes” path advocated by TDD experts, it is a form of larger scale refactoring. This is what I did today, and the safety net I had created saved me in two distinct ways that I did not expect.

1. A simple corner case: Several member variables were keeping track of state in my class. I needed multiple instances of these, so I wrapped them up in a struct and used a std::map to store them keyed on an IP address. However, after storing my variables inside the stl::map, I altered an algorithm I had written to organize the data in these variables so that it would be more coherent. However I broke a very simple corner case that I likely would not have noticed for at least a few days down the road. As soon as I compiled my changes and ran the code my test caught the error and it was fixed in a matter of seconds.
2. Misuse of third-party code: First let me state that I consider the STL third-party code. Like third party code, you need examples to use it and experimentation to use it correctly. Although I have used the std::map class many times before, it has been a while since I’ve last used it. And thanks to my TDD safety net I was coding with reckless abandon. I made the classic mistake below:

std::map<KeyType, DataType> exampleContainer;
DataType extractedData = exampleContainer[someKey];

/* modify extractedData */

exampleContainer[someKey] = extractedData;

What I did was modify a copy of the data and attempt to reinsert it into the map. This is not how a std::map works. The correct way is to retrieve a reference to the data and just perform the modification. Once the key is associated with a value in the map, insertions fail. But the syntax of the [] operator does not allow for visibility of the failure. The correct code is below.

std::map<KeyType, DataType> exampleContainer;
DataType& extractedData = exampleContainer[someKey];

/* modify extractedData */

It is important to note that other tests in my test suite passed even with these code mistakes. Therefore a cursory manual test would have certainly passed over these seemingly glaring errors leaving them for much later in the debugging stage. Furthermore these errors probably would’ve percolated up into extremely odd behavior in the application, causing me to spend much more time debugging the program with gdb or print statements than I spent writing the tests in the first place. Even worse, they may have evaded me and made it to SQA, although unlikely

By having this safety net in place the errors were caught quickly and corrected immediately. I am already enjoying the benefits of TDD and I encourage every developer to give it a try. Test Driven Development By Example, by Kent Beck gives an excellent introduction to the topic.