Slashdot

So, reading this, it got me to thinking (again): why do I work for the government?

First, a little background: I graduated with a BS in CS in 2000. I then went to work for a startup started by my most challenging professor (I figure I'd learn more working for him than going to graduate school). Half a year later, they lay me off (but toss me some contracting work) because they can't afford to pay me (dotcom bust and all that). Somewhat naively, I decide to try consulting. Seven months later, after burning through all my savings, I'm desperate for a job. I mention this to a college friend who had gone back to his home town to work for DoD, and he manages to get me a site visit. A month later (surprisingly fast for the Feds!), I'm working at a Navy base in the middle of the desert.

So here I am, seven years later, wondering "why do I still work for the government?". A lot has changed since then. I love the town. It's small, dry and hot year round (I grew up in very similar desert). Plenty of very tall and fun to climb/hike/camp in mountains are within a days drive. I play alto sax in the local big band (and occasionally orchestra). I just got sworn in to the local mountain rescue group. The one thing that sucks is the job, and even it's not that bad.

You know how everyone says government employees don't work? It's true, but not for reasons you think. Sure, there are many who are just plain lazy. But out here at a place where we are far from the bureaucracy, where the majority of employees are engineers and scientists who are passionate about their work, the real reasons work doesn't get done are also the major reasons people quit or just gripe about their jobs. Security, while necessary, is a significant speed bump on the road to productivity. Having to get hardware you need to test out of a safe that only one person (not you) has access to, only to find out that you need a computer (that's in another safe that you don't have access to), can be demoralizing.

Not being allowed to install software that you need to do your job is another frustrating thing. It seems that even though someone may be trustable with state secrets, and be an expert in their field, they aren't allowed to decide what the best tool for the job is.

There are numerous other reasons: waiting for months for parts, having to pay credit card bills out of pocket for travel expenses (because vouchers in the travel system are 3 months behind), being forced to "standardize" on one software platform at a place where by definition, standards may be in flux (we are a research center, after all), or the standards are not the best tool for the job and were only chosen for political reasons.

So why do I still work here? I have been tempted, quite often to quit. However, there is nowhere else in this town where I could get the same salary for the same job. It's too small a town. I don't want to move; I love the town. I could try consulting/contracting, but that's iffy. And despite all it's drawbacks, it's not really all that bad. I work with smart people, and the one good thing about bureaucracy is that it's slow, so I haven't been completely cut off yet in the self-administration arena (I have a development machine that I alone am root on; the network admins and I have an understanding: I never call for help or create a problem, and they keep my connection up). All those times when I can't get real work done because I'm waiting for something? I've been playing with different programming languages, toolkits, development tools, etc. Recently, I've been going through "The Pragmatic Programmer" and quite enjoying it. I have some qualms about helping a corrupt government design weapons, but I don't blame Smith and Wesson for gun deaths.

I would jump at an opportunity to get paid to work on open source software from home (telecommute), but I'm not moving. I'm married and my wife also works on base. She has complaints about her job as well, but we both like the town; relocation is out of the question unless we could both get comparable jobs somewhere else in a similar environment.

Now, if they try to make me into a manager who doesn't get to write any code, then I will be looking for a new job.

Given the recent controversy over Prof. Knuth's comments, I'm left pondering one (of many) questions: why can't code be both re-usable and re-editable? (no, I haven't read the article)

Are re-usable and re-editable code fundamentally opposed? Would it just take too much time (or genius) to make code both re-usable and re-editable? Or is Knuth just calling designing for re-usability a waste of time like unit tests?

To me, the re-usableness and re-editableness of code seem orthogonal. You can write code that is re-usable but completely un-editable (it's usually unreadable at that point). If you're writing code properly, it seems to me that re-editable is a given. Re-usable is more difficult to do, but it seems like a good idea, and a best practice that most programmers should try to get into the habit of (just like writing re-editable code).

Maybe I'm just missing something here, but I always aim to make my code re-editable and re-usable, and one doesn't seem to get in the way of the other, other than competing for my time. Thoughts?

I learned some very interesting things today. First, valgrind kicks ass. Second, don't always believe what you read in man pages. Take this little snippet I'd been working on for the past 1.5 days:

uint16_t
checksum (packet)
    struct re_packet *packet;
{
  int i = 0;
  uint16_t checksum = 0, temporary = 0;
  unsigned int intermediate = 0;
  unsigned int *binary_blob = calloc (1, sizeof (struct re_header) + packet->header.size);
  if (binary_blob == NULL)
    return (-1);
 
/// Necessary because checksum doesn't include itself.
  temporary = packet->header.checksum;
  packet->header.checksum = 0;
 
  if (!memcpy (binary_blob, &packet->header, sizeof (struct re_header)))
    return (-1);
  if (!memcpy (binary_blob + sizeof (struct re_header),
          packet->data, packet->header.size))
    return (-1);
 
  for (i = 0; i < (packet->header.size + sizeof (struct re_header)) / 4 ;
      ++i)
    intermediate ^= binary_blob[i];
 
// Restore original checksum.
  packet->header.checksum = temporary;
 
  checksum = intermediate ^ (intermediate >> 16);
 
  SAFE_FREE (binary_blob);
 
  return (checksum);
}

Now, you see, the "binary_blob" has to be a pointer to an array of unsigned integers because that's what we're using for the checksum. So far so good, right? Except that the program using this little snippet has weird memory errors, and when I say weird, I mean segfaulting in calloc(). A sure sign of heap corruption. But where could it be coming from. Just as a check, I insert some code to print out how many iterations it goes through before it crashes; ends up being just one. Hmm, heap corruption usually takes longer than that.

As I watch the compile for the zillionth time, it occurs to me that wxWidgets is being linked because this project has a separate GUI; but this little piece of code doesn't need it. Perhaps wxWidgets is doing some weird initialization stuff that is really not necessary in a piece of C code. So I also quickly learn how to turn that off in automake, and recompile. Still the same error in the same place. Hmmm . . .

Go learn how to use valgrind with memory checking. It says that "binary_blob" is being written beyond it's end. Huh? It's exactly as big the writes *should* be. Double-check memcpy(3); nope, it clearly says the third argument "n" is the number of bytes.

After banging my head against this for another couple of hours, I finally get the crazy idea, "hey let's just try casting to see if that fixes it, even though it shouldn't make a difference." Et voila! It works:

uint16_t
checksum (packet)
    struct re_packet *packet;
{
  int i = 0;
  uint16_t checksum = 0, temporary = 0;
  unsigned int intermediate = 0;
  unsigned int *binary_blob = calloc (1, sizeof (struct re_header) + packet->header.size);
  if (binary_blob == NULL)
    return (-1);
 
/// Necessary because checksum doesn't include itself.
  temporary = packet->header.checksum;
  packet->header.checksum = 0;
 
  if (!memcpy ((void *) binary_blob, &packet->header,
    sizeof (struct re_header)))
    return (-1);
  if (!memcpy ((void *) binary_blob + sizeof (struct re_header),
          packet->data, packet->header.size))
    return (-1);
 
  for (i = 0; i < (packet->header.size + sizeof (struct re_header)) / 4 ;
      ++i)
    intermediate ^= binary_blob[i];
 
// Restore original checksum.
  packet->header.checksum = temporary;
 
  checksum = intermediate ^ (intermediate >> 16);
 
  SAFE_FREE (binary_blob);
 
  return (checksum);
}

Apparently, memcpy(3) does some hinky where it actually looks at the type of the dest you pass it and decides that, no, "n" doesn't actually mean bytes, it means the number of elements you want to write to in that array. At least that's my theory.

(Posting this here because I don't have my own blog and I'm too lazy to look up the C newsgroup on groups.google.com; excuse the incoherence; I'm really frazzled and just happy it works (for now)).

(posting this under "GNU is Not Unix" as there doesn't appear to be a "Linux" category or an "Ask Slashdot" category; WTF is up with slashdot these days? Are they forgetting their roots? Anyways, that's another rant . . . ).

I've been looking for a webcam that works with Linux for a long time. I've tried ordering Logitech QuickCams of the 3000 and 4000 variety once I was fairly certain they would work with Linux only to be told that they were "out of stock" or "back-ordered" (another rant: why can't these retards keep their online inventory up to date? it really should be prosecutable under false-advertising to list a product as available when it isn't; I found a blog posting along these lines somewhere, but can't find it now; I can't remember if I found it linked from slashdot.org or planet.debian.org; if anyone has a link to it, let me know).

Here's my question: is there a webcam that I can use with Ekiga and MythTV's MythPhone plugin? Where can I buy it? Please note that getting used hardware off of eBay is not an option; binary only drivers are also not preferred. I'm just looking for a simple webcam that I can do videoconferencing with under Linux. I know that many people will say "just search google", but believe me, I've tried and every time I find that the webcams supported by Linux aren't for sale anymore.

Okay, so I went and did the Apple fanboys research for them. Well, not really "did research" as much as "saw an ad" (despite MythTV's ad filtering, the wife still watches a lot of live TV while I cook dinner) about one of the features of the iPhone: visual voicemail.

This is one of those things you go "it's so obvious, why didn't I think of it?" or "why aren't other companies doing it?". To be able to see a list of people who called and what the length of the call was, that would be kind of useful. And it meets the "not offered before" (that I'm aware of) criterion that I had stated earlier in my request for proof of inventiveness in the iPhone. Not that I get a lot of voicemail, but I hate checking voicemail because it feels like I am serving the system, not vice versa ("Please input your f*cking long PIN in 4seconds or you will be disconnected", "Please press a button or I will continue to annoy you with menu options you won't remember anyway").

So, score one for iPhone. It's still not enough to make me switch, especially considering my iPhone would probably be bricked in a week for "tampering" (there's software I need in a smartphone that's not on the iPhone, dammit!). Not to mention it doesn't (currently) work with Linux, but I suppose that will be fixed soon. Not by Apple, but by the Linux community.

Note to Apple fanboys: I'm perfectly happy with my current smartphone. It does everything I need; some of those things can't currently be done with an iPhone. That's okay. The world doesn't need just one operating system, one browser or one smartphone. Don't believe the hype; use what works best for you and please STFU to me about the iPhone. I've evaluated it and it doesn't meet my needs.