As I’m sure you all know, Apple hasn’t been shy with their OS releases lately. This Mac Mini shipped with OS X 10.3 installed on it. While OS X 10.4 would have supported the PowerPC platform, I did not want to migrate it to the newer version of OS X. Enter Ubuntu. Some mainstream versions of Linux support alternative platforms (non-x86 platforms) and Ubuntu was one of them. Considering that I am very familiar with Ubuntu due to using it in my personal and professional lives, it was a no-brainer to install it onto the Mac Mini. Doing so was just as easy if not easier than performing an OS X install on it except that I didn’t have to run to the Apple Store first.

I decided to load the system down by compiling a Linux kernel which uses the make -j option. Essentially, the -j option spawns one compiler job for each source file it finds; which is a lot of compiler jobs to say the least. Interestingly enough, that little box is pretty noisy when its thrashing and kicking off lots of heat. Peak electrical consumption on this little box is around 30 watts which is still impressive considering that the average home light bulb consumes 60 watts.

Within 30 minutes of installing Ubuntu 8.04, I had OpenSSH, a LAMP stack installed and all of the applications I use the most, finch, irssi, screen, emacs and wget. The whole purpose of this system is to be a remotely-accessed server with everything running entirely inside of screen sessions without using the overhead of graphical user interfaces. The point of doing things this way is to keep things in a constant state no matter where I am and to keep everything secure; none of the data my applications use will actually traverse the network link and for what does traverse the network link, it is encrypted by ssh.

While shopping around (admittedly late) for the best airfare, I took notice at two airlines operating out of Pittsburgh International Airport; USA3000 and US Airways. USA3000 offered direct non-stop flights from PIT to CUN (Cancun), but at inconvenient dates for my travel and work plans, so I reluctantly booked on US Airways. I say reluctantly because the last time I flew on them, I got stranded in PHL on my way to YUL (Montreal).

Against my better judgment, I booked the ticket. The night before I was set to fly, I went to check in online and print my boarding pass. As I did this, I realized that my name was slightly messed up. It was spelled right, but it had my middle initial concatenated on the end of it. So essentially, ZACHARY H turned into ZACHARYH. This caused enough distress that I didn’t sleep that night. Turns out that this would be the least of my troubles.

So, at approximately 4:45 AM, my phone rings and its a computer calling to tell me that my flight from PIT to CLT (Charlotte) had been canceled. I called their number and waited around for about 20 minutes before I got an answer; the answer was, “Your flight was canceled but has been reinstated, you should get to the airport.”

15 minutes later, I arrived at PIT and headed for the check-in line. The check-in line took approximately 20-30 minutes to get through and deadlocked at several points because of their asinine policies on checked baggage which forced customers to unpack/repack/weigh their bags that they already had to pay to check. After explaining to the check-in agent about my early morning phone call, she rebooked me through PHL (Philadelphia). Against my better judgment, I accepted this and proceeded through the security checkpoint. As I was approaching my gate, I noticed that there was a long line of people at their sterile-side customer service desk and thought, “This can’t be good”. So I grabbed an Egg McMuffin and headed right to my gate.

After boarding the plane, I settled into my seat and tried to get comfortable on their Reagan-era Boeing 737-200 that was going to take me from PIT to PHL. As the plane started taxiing out of the gate, I thought that all would be ok and I fell asleep only to be awoken when the plane came to a halt and the pilot annouced that they were clearing off the runway in PHL and that we would be on the ground for an hour. Out of boredom, I fell back asleep and was awoken by another announcement which said that we would be delayed by another hour. Finally, the plane took off and got to PHL. Fortunately, we didn’t have to wait forever in a holding pattern and our plane landed.

Upon heading to the nearest flight status monitor, I noticed something both hilarious and disconcerting. All of the monitors were completely whited out and said, “Service Unavailable” on them. I headed to the customer service desk. Is it sad that I didn’t have to figure out where it was, but that I knew exactly where it was from my Montreal trip?

Service Unavailable

Service Unavailable

I waited in line for about an hour and a half with deadlocking agents all the way. Pretty funny that I had been traveling for about 3 hours and never even left the state of Pennsylvania, eh? I remained perfectly polite and calm when I reached the desk because I know from experience that yelling and making unreasonable demands will get you nowhere. The agent initially gave me some bad news, that I might not make it to CUN that day. Mind you, I’ve already been delayed for about 3 hours at this point. She gasped when she discovered that there was room on a flight that was leaving in 15 minutes. She said, “I can get you on that plane, but you have to run”. She got me booked and I ran like a bat out of hell to my gate. (Note to readers, if you saw some guy who was wearing a t-shirt that said Google Pittsburgh dashing through the Philadelphia airport on Saturday, December 22, 2008 and standing at a gate out of breath, that was me.)

Upon arriving at the gate, I looked at the ticket to see my seat assignment and I noticed that it said 3A. I realized that I was flying First Class! How this happened, I have no idea, but needless to say, I was pleased. The gate area was packed full because out of the two flights to Cancun that morning, one was canceled and all of those passengers were forced standby onto the next flight. Not only that, the flight that I was trying to get on was so late that the next flight departing from that gate had their passengers there waiting as well! I felt kind of bad because I had a booked and confirmed ticket on the next flight out and not only that, it was first class and there were still families stranded there.

First Class

After boarding the Airbus A320 and getting settled in, the pilot told us that we would be delayed by approximately 20 minutes because they were trying to get the weight adjustment right in the cargo hold and that we would be taking on several standby passengers to fill the rest of the plane. That said, it took a lot longer than that, approximately 2 hours longer. So finally, the plane pushed back from the gate, taxied to the runway and took off and I was on my way to sunny Cancun. When the flight attendant asked me if I wanted a drink, my response was, “Whats the strongest stuff you have on board?”

All things considered, this ordeal was nothing compared to what I know some of the other people in PHL had to suffer through. One person I was talking to in line had just come home from Cancun and was trying to get home. She said that they got to PHL the day before and their next flight out was the following evening at 8:30 pm. I just thought to myself, “How does that happen?” That is something I’ll save for when I get home; if I get home.

The moral of this whole story and experience is:

1. Quadruple-check your booking information.
2. Never fly during busy holiday travel days.
3. NEVER fly to or through Philadelphia; drive, take a bus or the train.
4. Remain polite.
5. Keep a sense of humor.
6. If you get upgraded to first class, take it.
7. Expect the unexpected.

eanx@crocostimpy:~$ grep -R "goto" /usr/src/linux-source-2.6.24 | wc -l
50295

Edsger Dijkstra who is perhaps best known for his shortest-path algorithm, was a vehement opposer to the use of the goto construct made; A Case Against The GO TO Statement.

This question is frequently a topic found on Linux kernel hacking mailing lists. Linus himself offers a pretty good explanation of why you they’re good form for certain applications. One good reason he gives is breaking out of the middle of deeply nested conditional statements and for very rarely used exceptions. Remember, C doesn’t have a try-catch construct. Another reason given is that it enhances readability and therefore maintainability.

That said, I was curious about a few things. So I recently downloaded the source for the Pidgin IM client, version 2.5.2.:

eanx@crocostimpy:~$ grep -R "goto" pidgin-2.5.2 | wc -l
285

There are 285 occurrences in Pidgin and so naturally, I got a little curious to see if I could maybe refactor a few of them out of the program altogether and I discovered this amusing comment in ./libpurple/dbus-server.c in purple_dbus_iter_has_table(). I immediately thought, this is one of the joys of open source software; reading the comments!

367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405

GHashTable *
purple_dbus_iter_hash_table(DBusMessageIter *iter, DBusError *error)
{
	GHashTable *hash;
 
	/* we do not need to destroy strings because they are part of the message */
	hash = g_hash_table_new(g_str_hash, g_str_equal);
 
	do {
		char *key, *value;
		DBusMessageIter subiter;
 
		if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_DICT_ENTRY)
			goto error;
			/* With all due respect to Dijkstra,
			 * this goto is for exception
			 * handling, and it is ok because it
			 * avoids duplication of the code
			 * responsible for destroying the hash
			 * table.  Exceptional instructions
			 * for exceptional situations.
			 */
 
		dbus_message_iter_recurse(iter, &subiter);
		if (!purple_dbus_message_iter_get_args(&subiter, error,
				DBUS_TYPE_STRING, &key,
				DBUS_TYPE_STRING, &value,
				DBUS_TYPE_INVALID))
			goto error; /* same here */
 
		g_hash_table_insert(hash, key, value);
	} while (dbus_message_iter_next(iter));
 
	return hash;
 
error:
	g_hash_table_destroy(hash);
	return NULL;
}

When all is said and done, it is a useful construct if you understand the consequences and tradeoffs. Like everything else in computer science and software engineering, the dos and do nots should be studied and understood.

Read on for more.

All too often, when interviewers ask the following question, “Do you have any questions for me?”, the candidates are intimidated and don’t know what to ask, so they often reply, “No I don’t”. I admit I did the same thing during my job interview. It was all so surreal, sitting in the office of the biggest Internet company in the world being asked all kinds of questions to see what you’re made of. 11 months into it and adopting this new philosophy, I have determined that there are several questions that any new candidate should of their prospective employer. You basically flip the interview around so that now you are interviewing the company to see whether or not it is a good fit for you. Print this page out and take it with you; it could save you a lot of aggravation. You may not hear what you want to hear, but at least you’ll hear about it up front and not find it out down the line later.

1. What is the corporate culture like?
2. What metrics will I be evaluated on? How objective are those metrics? To what granularity will they be tracked?
3. How does the promotion process work? Is it a transparent process?
4. Who ultimately makes the decision to promote or not to promote?
5. How does a performance review work?
6. What will my day-to-day be like? Will it consist of project-based work or will it just be break/fix and putting out fires?
7. Will I be the only person performing this job function or will I be working with a team of people in the same physical location as me?
8. If I am not happy with what I am doing, can I easily change my job position/scope?
9. How much travel is involved?
10. What do you like about working here? (This is addressed to your interviewer.)
11. What do you dislike about working here? (This is addressed to your interviewer.)

Print this sheet out and take it with you to your next job interview. Got questions you think should be here? Put them in the comments section below and they may just end up on the site!

As far as I can tell, there are three root causes of this problem. The first cause is vendor lock-in. This is when you have a vendor which sells a particular hardware and/or software solution. If there is a problem with it and the vendor is the only person who can fix it, this would naturally cause a lot of stress; particularly if the vendor is giving you the run around. The solution is that vendors should be open with their customers about where the problem is, what is being done to fix it and how long they can expect until a resolution. Another thing that a vendor can do is attempt to make their product more resilient, but there is only so much that can be done with that.

The second cause of this problem is an access-control hierarchy. In smaller businesses, this tends to not happen nearly as much because if you’re the sole IT worker there, you pretty much set everything up and you have the power to dictate who has access to what. In a larger organization such as the one that I work in, there are access control systems to prevent complete and unfettered access to the systems. While those access control systems are a necessary evil, they don’t enable you to solve the problem. For instance, lets say you have to escalate an issue to another team due to the fact that your current access privileges do not let you handle the problem; even if you know where the problem is and can readily fix it. The solution to this problem isn’t nearly as clear as the previous one because those access control systems are a necessary evil in any large organization because someone with complete and unfettered access to the systems could do irreparable harm. What solution I can think of is the fact that the people who handle the issues escalated to them should always remember that the reason why they are being escalated to is because someone else doesn’t have the prerequisite privileges. Additionally, they should remember that they are probably a little stressed because of the third cause of the Helpless IT Worker Syndrome.

The third manifestation of this syndrome is the primadonna user that thinks that their issue is more important than anyone elses; even when they are having the same issue as everyone else. Typically, this manifests itself as the user threatening to go to your boss if you can’t resolve the problem in a reasonable amount of time. Additionally, the reason why you can’t resolve it in that time is because of the aforementioned causes above; either the vendor is being difficult or there is an arbitrary access control system in place preventing you from fixing it. There a few solutions to this problem; 1) Keeping a record of who turns into a primadonna and approaching them with caution, 2) Informing your boss of the situation first so that they know you’ve done your due diligence, 3) Reminding users that they are out of line and although you are there to help them, you are not there to take abuse from them. The bottom line is that when you deal with users who are primadonnas, you need to hold your ground and don’t let them rule you.

While all of these problems sound typical to any IT shop, that doesn’t mean that as IT workers, we are powerless to change it. As IT workers, we are customers and providers of technology solutions. We have the power to demand accountability and clarity from our vendors, effect policy change in our organizations and keep track of problem users and do our best to solve their problems while not having superficial threats dangling over our heads.