Or perhaps US HPalm3Compaquipspring Corporation...?

This is what Google is for. Pretend that everything you post online will live forever, and bear that in mind as you put it there... and you'll be close enough to reality to make no odds.

I'll actually go one step further on that: make personal connections. Think about anyone you know reasonably well who is in the field. Use them as resources. I got my first programming job via a friend of mine; you may say "nepotism", but think about it this way: if you're gonna hire someone, would you rather have one of your employees vouch for them, or have to rely solely on the impression you've gotten by chatting for an hour or two?

I've recently found myself job-hunting again, for the first time in ten years. While I am indeed going on an interview today, after having been called by a recruiter when he saw my resumé on Dice, I have four strong leads - one of which is for my "dream job" - and all of those came by contacting people I know.

Things I can mention that have worked very well for me:

• Participate in open-source projects - even just at the bug-fixing level. If you search Google for my name in quotes (and prospective employers will!), nearly every hit on the first four pages is me, despite sharing a name with a NASCAR driver and a judge in a prominent civil-rights case. The majority of those hits are mailing list posts I have made.
• Go to trade shows, if you can possibly manage it. Some of them offer a reduced rate if you're paying your own way, and obviously some of them (i.e., LinuxTag) are quite affordable (possibly excepting travel!) If you have any idea what you would like to specialize in, this gives you the opportunity to meet the "people behind the code", which - let me tell you - is one of the strongest "ins" that you can hope for.
• Spend some wetware cycles on software design! I can't tell you how many people I've worked with who are sharp, smart coders... and can't write a clean API to save their life. Hiring managers really, really like this. My recommendation there is - at the risk of "drinking the cool-aid" - going and studying the Qt or KDE source code and design guidelines. Even if you're not intending to be a C++ programmer. I've not looked hard at KDE, but Qt is some of the cleanest code from the standpoint of API design and modularity that I've ever seen. (I'm not necessarily talking about the code inside a module - some of that is pretty grody, but that happens on a project that big.)
• Lastly, I suggest striking a balance between specialization and still being very flexible. As an example, I worked at Maxtor for many years. When things started getting ugly from the work-environment perspective, I kept talking about leaving. Most people - particularly, say, servo engineers - generally responded with, "Where are you gonna go? Seagate's not hiring." My response was, "Hey, I'm an applications programmer. I don't care what's at the other end of the cable - I don't even care if there is a cable!" Basically, the servo engineers got paid a fair bit more... but I have a much, much easier time finding a job - and have never been laid off, short of the company going under.

Good luck!

Applying "slippery slope" to that logic, then if the secretary to the manager of the Widget Reshuffling Department within the FBI steals a car, then it's the taxpayers' faults, because ultimately the chain of command leads to someone The People(tm) elected??

There are two things, in my experience, that are holding Linux - and indeed, the majority of open-source projects - back. Firstly (in no particular order) is that documentation is generally nonexistent, inadequate, outdated, or even actively misleading. When this isn't the case, it's too frequently written from the viewpoint of someone who already knows exactly what they want to do, they have just forgotten where the button is. I've been using computers for thirty years (running just about every common OS there's been over that time period), and programming for most of that - and I still come across too many cases where they're using a different term than I would have used, and thus it ends up being a steeplechase to try to figure out how to do what I'm after. I also am frustrated at how often I need to try going to the documentation in the first place - if it's a simple, frequently-performed task, it should be fairly intuitive, which would indicate that after as long as I've been using computers, I should be able to figure it out! The other downfall I've come across is a "complexity gap" - Linux is, in my experience, fine for a beginning user, and okay for a gearhead... but the people in between are kind of screwed. The basic stuff "just works", and if you are willing to hack scripts or compile code, you can do just about anything - but all too often, if you need to do something even just a little past the basic stuff, you *have* to start hacking scripts.