Archive for the 'linux' Category

Ubuntu Hardy Heron vs Netgear WG511 v1

Sunday, April 27th, 2008

Dear Ubuntu. Please don’t go blacklisting the prism54 driver on me again? kthx!

For some reason, the v1 of this card (aka the Made in Taiwan version) doesn’t seem to work with the new p54 drivers…

For reference, in /etc/modprobe.d/blacklist change this:

# replaced by p54pci
blacklist prism54

to this:


# replaced by p54pci
#blacklist prism54
blacklist p54common
blacklist p54pci
blacklist p54usb

If you’re a programmer, you should know this…

Monday, March 27th, 2006

My initial post was going to be a snark-filled venting of all that ails me with my “day job” at the moment. Specifically, the woes of maintenance programming when dealing with a codebase from 2000 and ported from Windows to Linux.

If JP Sartre was a coder, he would have actually said:

“hell is other people’s (undocumented) code.”

So for your amusement, here is the list of simple mistakes I’ve seen of late. Consider these some simple C++ programming sins you may use to torment those that will follow you for eternity. (more…)

Coming up for air

Monday, March 27th, 2006

I’ve been too busy lately with real work to keep up with the Ruby spider project, but I’m hoping to get back to it real soon.

This is a vent/rant/gratitude post, based on what I’ve spent my last 2 weeks dealing with.

I’ll start with the gratitude, but it’s all downhill from there. I am immensely thankful for the developers responsible for the following tools which, IMO, no Linux developer should be without:

  • Valgrind – helped me track down a bunch of obvious memory errors in the code
  • dmalloc – helped me track down those which valgrind couldn’t
  • gdb – the more I use gdb, the more effective a tool it becomes to me. Why aren’t you using it? At least learn to get a backtrace and inspect variables if you’re at all programming anything with GCC.
  • distcc – chasing memory issues into base classes led to full recompilation more often than I would have liked. distcc let me put an extra 2 idle machines to work compiling the code.

What started as a rather curious crash in our dev branch a couple of weeks ago turned into a major audit of how we allocate, use and free memory in our codebase. When I did get to the bottom of the crash, it turned out not to be a memory issue, but a library dependency inherited from libstdc++.

So here’s a little nugget for you right off the bat:

If you use STL containers (or any code which uses STL’s default allocator) in a dynamic library which has been compiled with -MT, you must link any executable that dlopen’s said library with libpthread.

In hindsight this sounds fairly obvious, right? (more…)