TSA Fear Mongering

So you think you're safe from the TSA when you get past security?

Think again!

I was sitting at my gate, ready to depart back to Houston to go to Rice, so I decided to pop out my laptop and try to check mail. I booted up into Ubuntu and probably freaked out the TSA security people standing behind me because after just 5 minutes on the computer, they asked me to power down my laptop. Then they told me that they were going to inspect my person and my bags!

Perhaps it was because I was using the console to try to configure wireless with iwconfig, or maybe my bags were just too big (I had two laptops with me, what can I say?). Perhaps they had gotten word from the main security people that I tried to sneak some hard earned(and paid for!) hairspray and toothpaste on board that didn't add up to fewer than 3 ounces. What was really the case, I'll never know, but I chuckled inside hoping that for once I was being singled out for using Linux.

I was the first person they checked. They also checked a ton of other people too. Maybe they were just training some of the new hires?

I'm Still Alive, I Promise

And in recent news, an update on the robot is coming, along with pictures, code, and much much more!

So far I've logged about 100 hours in the robot, most of which was soldering cables, dremeling really small embedded computer cases, and some of which learning the finer features of Linux, which admittedly has been the best reason to get paid, EVER! 

I think it's clear that this TA job has probably been the best job I've had to date.

- Nick

Cross-Compiling, gotta love it

I just spent the past couple of hours figuring out why I wasn't able to compile the Player server with plugin capabilities. It turns out that there were many intermediate steps that were axing the ability.

First obstacle: configure.ac
The autoconfigure script for the player project had a macro called AC_CHECK_LIB that checked to see if I had libltdl installed. Now, I have both libltdl for my system(system A) as well as libltdl for the target system(system B). If I want to cross-compile, then there's no way for this check to work because it tests for the existence of libraries by compiling, linking, and running a piece of test code with a particular function within the library. Since I'm compiling using B's libltdl, yet the check wants to run on architecture A, we have a problem!! To circumvent this, I simply removed the check and told the configure script to simply compile with the appropriate flags. (LIBS = -lltdl -dl $LIBS)

Second obstacle: misconfigured paths
After fixing the makefiles and ensuring the appropriate compile time flags were set, I went ahead and tried making the program only to find, Oh Noes! the program wasn't looking for libltdl in the right location. It was apparently looking for it in the standard /usr/lib/ directory. I figured this would be an easy fix as all I would have to do would be to change some path. As it turns out, I tried changing LD_LIBRARY_PATH, which on my distro of linux prepends that string to the path that ld searches. This didn't work either, and it kept insisting that libltdl was /usr/lib/libltdl.so. I was a little fed up at this point and didn't feel like reading about the intricacies of how ld caches library locations and deals with alternate scenarios like mine, so I simply made a soft link in /usr/lib to the real library that I wanted to link with.


Presto!! Out comes the beautiful binaries that I've been looking for this whole time!

Now I can finally get to testing the drivers I wrote for Player so that I can start reading range finder information over the network. Score!!!!

Robot Progress

Recently, I've been working on setting up a robot for the introductory CS class here at Rice. Because our interface to the robot is wireless through a small GNU/Linux computer, I've been able to learn oodles about how to do networking, cross-compiling, building kernel modules, etc for and embedded system. I would have never learned this from just taking a class. Sometimes I really think this whole higher education system is overrated.

Regardless, it's really been a great experience!

Some handy topics I learned more about today: automake, autoconf, readelf, objdump, CPLUS_INCLUDE_PATH, pkg-config, PKG_CONFIG_PATH, etc...

Developer tools rock!

Software Project Management

Just recently, I've started a course on software development. What?!? You might be thinking, how can a University level course teach something that can't be found in a book? The answer to that question is, we're not using books! The approach this class is instead to force a bunch of awkward, stinky CS majors together in a room and lock us up until we churn out a enterprise level piece of software.

Now I know that hardly sounds any better than reading from a book, and I'm sure it has the makings for a sci-fi horror movie, but it's actually not as bad as it seems. There are 6 of us who are truly dedicated to learning to work together, self-organize, design, document, code, and debug a large piece of software. I think we have great potential!

So far, the class and the meetings have been more like a comedy. We've done everything from pulling hysterical all-nighters, singing the cake song from Portal into the night, to coding to intense Trance music with awesome visualizations up on the big screens of the computer lab where we temporarily reside this semester.

Alright, now for the meat of the post, this is what I've actually learned in this short time...

1. Incremental Iterative approach
2. Avoiding waterfall design
   
3. Use Cases
4. Domain Modeling
5. System Sequence Diagrams
6. Operational Contracts

These themes have helped us so far guide our search for specific project requirements, and hopefully they will help us cut our time in half when it comes to actually trying to code our system. If you are looking into learning about project development, look some of these terms up, it will be very worth your while!

- Nick

Random Ubuntu Sillyness

Earlier today I wanted to use the OpenCV libraries to run a program I was working on, and I didn't have the libraries installed. There weren't any binaries available for Ubuntu 'Gutsy', so I went ahead and compiled the libraries myself. After wrangling with make and the compiler for a while, I finally got things set up and compiled the way I wanted. Fair enough. Afterwards, I compiled my program, no sweat. Then I tried to run my program, a straightforward task, except the loader came back and told me the libraries I just compiled and installed were no where to be found!!!!11!

Why? Apparently, the libraries were placed in /usr/local/lib, but the /etc/ld.so.conf file didn't know to search that directory by default. All I had to do was add /usr/local/lib to the end of the file and walk away, but still, it's silly to have to do such a thing because that's where libraries go by default.

What a crazy world.